From nobody Mon Jun 19 11:48:35 2017 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 A8AE613180D; Mon, 19 Jun 2017 11:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xQfNEmNuuxv; Mon, 19 Jun 2017 11:48:31 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1B370131807; Mon, 19 Jun 2017 11:48:27 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 38EF41E37E; Mon, 19 Jun 2017 14:57:16 -0400 (EDT) Date: Mon, 19 Jun 2017 14:57:16 -0400 From: Jeffrey Haas To: "Reshad Rahman (rrahman)" Cc: Mahesh Jethanandani , "Acee Lindem (acee)" , Jeffrey Haas , OSPF WG List , "rtg-bfd@ietf. org" , "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Subject: Re: IETF OSPF YANG and BFD Configuration Message-ID: <20170619185715.GB22146@pfrc.org> References: <38DEB571-2918-4464-B18A-71B24221772F@gmail.com> <47325462-2430-4197-AA8D-D3FEF74A834D@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 19 Jun 2017 18:48:34 -0000 [Long delayed response.] Reshad picked up the key points: Some things may make sense in the per-client (protocol) users of BFD, some things perhaps do not. And some come down to questions for timer granularity. The OSPF and ISIS models both make use of BFD simply by providing a boolean that says "I'm using BFD or not". Where we run into some issues are the cases highlighted: when the sessions don't share common properties, how should the protocol pick what BFD session to use? The current BFD yang model only permits a single IP single-hop session to be configured. (Key is interface/dst-ip) This means that if different parameters *were* desired, the BFD model won't permit it today. However, BFD sessions for many protocols tend not to be configured, but may spring forth from protocol state, such as IGP adjacencies. Thus, it's not "configured" - it's solely operational state. However, the BFD yang model doesn't really make good provision for that as an "on". Where all endpoint state is known a priori, config state makes better sense. To pick the example of Juniper's configuration, if OSPF and eBGP were using BFD, both can choose differing timers. This represents two pieces of configuration state for the same endpoints. Additionally, only one BFD session is formed using the most aggressive timers. I partially point out the situation of multiple timers since there have been prior list discussions on the situation where clients have different timing requirements. I don't think we handle this operationally in the BFD protocol in the cleanest fashion right now - the session will go to Down when the aggressive timers fail and there's no clean way to renegotiate to the less aggressive timers. -- Jeff On Fri, May 19, 2017 at 02:31:38AM +0000, Reshad Rahman (rrahman) wrote: > We started off with the intent of having BFD parameters in the applications/protocols which make use of BFD. For timer/multiplier this is pretty straight-forward, although the discussion of what to do when not all applications have the same BFD parameters for the same session (e.g. Go with most aggressive etc). Then we started looking at authentication parameters and having BFD authentication parms in OSPF/ISIS etc is not intuitive. And what do we do if applications have different BFD authentication parms. We concluded that the BFD authentication parms were better off in BFD. And once we did that, the timer/multiplier followed.... > > I may not recall all the details/discussons, but I do recall that we went back and forth on this and it took some time to make the decision. > > Regards, > Reshad (as individual contributor). > > From: Mahesh Jethanandani > > Date: Thursday, May 18, 2017 at 5:34 PM > To: "Acee Lindem (acee)" > > Cc: Jeffrey Haas >, OSPF WG List >, "draft-ietf-bfd-yang@ietf.org" >, "draft-ietf-ospf-yang@ietf.org" >, "rtg-bfd@ietf.org" > > Subject: Re: IETF OSPF YANG and BFD Configuration > Resent-From: > > Resent-To: >, Reshad >, >, >, > > Resent-Date: Thursday, May 18, 2017 at 5:40 PM > > Resending with correct BFD WG address. > > On May 18, 2017, at 2:33 PM, Mahesh Jethanandani > wrote: > > Agree with Acee's assessment. After much debate, we decided that we should leave BFD parameter configuration in the BFD model itself, and have any IGP protocol reference the BFD instance in BFD itself. This makes sense specially if multiple protocols fate-share the BFD session. > > Cheers. > > On May 18, 2017, at 12:27 PM, Acee Lindem (acee) > wrote: > > Hi Jeff, > > At the OSPF WG Meeting in Chicago, you suggested that we may want to provide configuration of BFD parameters within the OSPF model (ietf-ospf.yang). We originally did have this configuration. However, after much discussion and coordination with the BFD YANG design team, we agreed to leave the BFD session parameters in BFD and only enable BFD within the OSPF and IS-IS models. > > We did discuss the fact that vendors (notably Cisco IOS-XR and Juniper JUNOS) do allow configuration within the IGPs. However, the consensus was to leave the BFD configuration in the BFD model. The heuristics to determine what parameters to use when the same BFD endpoint was configured with different parameters in different protocols were proprietary and somewhat of a hack. > > I may have not remembered all the details so I'd encourage others to chime in. > > Thanks, > Acee > > Mahesh Jethanandani > mjethanandani@gmail.com > > > > > Mahesh Jethanandani > mjethanandani@gmail.com > > > From nobody Mon Jun 19 12:07:56 2017 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 C21A9131689 for ; Mon, 19 Jun 2017 12:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgFtk896rc_f for ; Mon, 19 Jun 2017 12:07:53 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id EA068131809 for ; Mon, 19 Jun 2017 12:07:50 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 17CEB1E37D; Mon, 19 Jun 2017 15:16:40 -0400 (EDT) Date: Mon, 19 Jun 2017 15:16:39 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: WG not meeting at IETF-99 (Prague) Message-ID: <20170619191639.GD22146@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 19 Jun 2017 19:07:55 -0000 Working Group, BFD will not be meeting at IETF-99 in Prague. There's however the usual room for side meetings relating to BFD. We do have active items for the Working Group to provide feedback on. The chairs would love it if we moved progress forward on these: draft-ietf-bfd-yang draft-ietf-bfd-stability draft-ietf-bfd-optimizing-authentication draft-ietf-bfd-secure-sequence-numbers Additionally, I'm behind in driving forward work to conclude BFD Multipoint. Please expect a WGLC on this soon. As always, the BFD wiki provides the chairs' view of WG status: https://trac.ietf.org/trac/bfd/wiki -- Jeff From nobody Mon Jun 19 12:30:44 2017 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 B3FE613182E for ; Mon, 19 Jun 2017 12:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRClHkPcSyRI for ; Mon, 19 Jun 2017 12:30:41 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA3E1316F6 for ; Mon, 19 Jun 2017 12:30:41 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 237771E37D; Mon, 19 Jun 2017 15:39:30 -0400 (EDT) Date: Mon, 19 Jun 2017 15:39:29 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: WGLC for BFD Multipoint documents (ending July 14, 2017) Message-ID: <20170619193929.GE22146@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 19 Jun 2017 19:30:43 -0000 Working Group, https://tools.ietf.org/html/draft-ietf-bfd-multipoint-10 https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-04 The BFD Multipoint documents have been stable for some time. Prior discussion at meetings has suggested we have an implementation for the main protocol component. Also per prior discussions, we split the active-tail component of the original multipoint document to permit implementors to not have to worry about implementing active-tail procedures if they weren't interested in that feature. We are starting an extended last call on these documents. The WGLC will conclude on July 14. This provides ample time for list discussion. If necessary, the IETF-99 meeting may provide for opportunities to close any contentious technical points. (BFD is not currently scheduled to meet.) One item I would like to kick off is the document status of the active-tail mechanism. At this time, no one has implemented it that I am aware of. Discussion with our AD suggests that publishing the document with Experimental status may be reasonable to preserve the work that went into the proposal. -- Jeff From nobody Mon Jun 19 15:10:56 2017 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 62A16129329; Mon, 19 Jun 2017 15:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NAeNl0p9HEO; Mon, 19 Jun 2017 15:10:46 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 522EB1200CF; Mon, 19 Jun 2017 15:10:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8852; q=dns/txt; s=iport; t=1497910246; x=1499119846; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3yQZcxOEQct6B1g//j+QsxFvSjhpGr5d8B1PxqIsB9c=; b=MLRpJZ+bI0XGLuk2xBrDDA48sI6IHPC5Ti4TmCIwQoAhQhD4YFu86X2J Zq9Pf56xPHZgIy54Whyutzue0iAlKfPYp8sz/0LZGX9MPFHOlm/BvKYDG wy1SPQXP1350IgPjR92ayZRhM2c4FmI0Ijm0vLdOFaTFME/nDObJt5Ywg c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DqAADCSkhZ/5tdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1iBbweDZIoZkXyIK41MghGGJAIagj8/GAECAQEBAQEBAWsohRg?= =?us-ascii?q?BAQEBAyMRRRACAQgOAwMBAgECAiMDAgICHxEUAQgIAgQBDQWKFAMVrWqCJoc1D?= =?us-ascii?q?YQWAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYELhzeCF4EMgleCEiaCbIJhAQSeIzs?= =?us-ascii?q?CjnaEZ5INi1iJMAEfOIEKdBVJhQ0cgWUBdohCgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.39,363,1493683200"; d="scan'208";a="439813834" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jun 2017 22:10:45 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v5JMAi6N027442 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 19 Jun 2017 22:10:45 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 19 Jun 2017 18:10:44 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Mon, 19 Jun 2017 18:10:44 -0400 From: "Acee Lindem (acee)" To: Jeffrey Haas , "Reshad Rahman (rrahman)" CC: Mahesh Jethanandani , Jeffrey Haas , OSPF WG List , "rtg-bfd@ietf. org" , "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Subject: Re: IETF OSPF YANG and BFD Configuration Thread-Topic: IETF OSPF YANG and BFD Configuration Thread-Index: AQHS6Syo68r6z3GylU2z1PR9VYBctaIsv2uA Date: Mon, 19 Jun 2017 22:10:43 +0000 Message-ID: References: <38DEB571-2918-4464-B18A-71B24221772F@gmail.com> <47325462-2430-4197-AA8D-D3FEF74A834D@gmail.com> <20170619185715.GB22146@pfrc.org> In-Reply-To: <20170619185715.GB22146@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="utf-8" Content-ID: <82487D7558C7FD47B2FF4A9204D1E925@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 19 Jun 2017 22:10:49 -0000 SGkgSmVmZiwgDQoNCkkgZG9u4oCZdCByZWFsbHkgZmVlbCB0aGVyZSBpcyBhIHN0cm9uZyByZXF1 aXJlbWVudCB0byBzdXBwb3J0IGRpZmZlcmVudA0KdGltZXJzIHZhbHVlcyBwZXIgcHJvdG9jb2wg ZXZlbiB0aG91Z2ggc2V2ZXJhbCBpbXBsZW1lbnRhdGlvbnMgYWxsb3cNCmRpZmZlcmVudCBwcm90 b2NvbCBzcGVjaWZpYyB2YWx1ZXMgdG8gYmUgY29uZmlndXJlZCAod2l0aCB2YXJ5aW5nDQpiZWhh dmlvcnMpLiANCg0KSWYgdGhlcmUgd2VyZSBzdWNoIGEgcmVxdWlyZW1lbnQsIEkgd291bGQgdGhp bmsgaXQgd291bGQgYmUgYmV0dGVyDQpzYXRpc2ZpZWQgYnkgZXh0ZW5kaW5nIHRoZSBCRkQgbW9k ZWwgc2Vzc2lvbiBrZXkgd2l0aCBhbiBhZGRpdGlvbmFsDQppZGVudGlmaWVyLCBlLmcuLCA8aW50 ZXJmYWNlL2RzdC1pcC9pbnN0YW5jZT4uIElNTywgdGhpcyB3b3VsZCBiZQ0KcHJlZmVyYWJsZSB0 byBhbGxvd2luZyB0aGUgZGV0YWlscyBvZiBCRkQgdG8gcGVybWVhdGUgaW50byBhbGwgdGhlIG90 aGVyDQpwcm90b2NvbCBtb2RlbHMuIFRoaXMgd291bGQgcmVxdWlyZSBjb25maWd1cmF0aW9uIG9m IHRoZSBpbnN0YW5jZSByYXRoZXINCnRoYW4gYSBib29sZWFuIGluIHRoZSBwcm90b2NvbHMuDQoN ClRoYW5rcywNCkFjZWUgDQoNCg0KDQoNCk9uIDYvMTkvMTcsIDI6NTcgUE0sICJKZWZmcmV5IEhh YXMiIDxqaGFhc0BwZnJjLm9yZz4gd3JvdGU6DQoNCj5bTG9uZyBkZWxheWVkIHJlc3BvbnNlLl0N Cj4NCj5SZXNoYWQgcGlja2VkIHVwIHRoZSBrZXkgcG9pbnRzOiBTb21lIHRoaW5ncyBtYXkgbWFr ZSBzZW5zZSBpbiB0aGUNCj5wZXItY2xpZW50IChwcm90b2NvbCkgdXNlcnMgb2YgQkZELCBzb21l IHRoaW5ncyBwZXJoYXBzIGRvIG5vdC4gIEFuZCBzb21lDQo+Y29tZSBkb3duIHRvIHF1ZXN0aW9u cyBmb3IgdGltZXIgZ3JhbnVsYXJpdHkuDQo+DQo+VGhlIE9TUEYgYW5kIElTSVMgbW9kZWxzIGJv dGggbWFrZSB1c2Ugb2YgQkZEIHNpbXBseSBieSBwcm92aWRpbmcgYQ0KPmJvb2xlYW4NCj50aGF0 IHNheXMgIkknbSB1c2luZyBCRkQgb3Igbm90Ii4NCj4NCj5XaGVyZSB3ZSBydW4gaW50byBzb21l IGlzc3VlcyBhcmUgdGhlIGNhc2VzIGhpZ2hsaWdodGVkOiB3aGVuIHRoZSBzZXNzaW9ucw0KPmRv bid0IHNoYXJlIGNvbW1vbiBwcm9wZXJ0aWVzLCBob3cgc2hvdWxkIHRoZSBwcm90b2NvbCBwaWNr IHdoYXQgQkZEDQo+c2Vzc2lvbg0KPnRvIHVzZT8gIA0KPg0KPlRoZSBjdXJyZW50IEJGRCB5YW5n IG1vZGVsIG9ubHkgcGVybWl0cyBhIHNpbmdsZSBJUCBzaW5nbGUtaG9wIHNlc3Npb24NCj50byBi ZSBjb25maWd1cmVkLiAgKEtleSBpcyBpbnRlcmZhY2UvZHN0LWlwKSAgVGhpcyBtZWFucyB0aGF0 IGlmIGRpZmZlcmVudA0KPnBhcmFtZXRlcnMgKndlcmUqIGRlc2lyZWQsIHRoZSBCRkQgbW9kZWwg d29uJ3QgcGVybWl0IGl0IHRvZGF5LiAgSG93ZXZlciwNCj5CRkQgc2Vzc2lvbnMgZm9yIG1hbnkg cHJvdG9jb2xzIHRlbmQgbm90IHRvIGJlIGNvbmZpZ3VyZWQsIGJ1dCBtYXkgc3ByaW5nDQo+Zm9y dGggZnJvbSBwcm90b2NvbCBzdGF0ZSwgc3VjaCBhcyBJR1AgYWRqYWNlbmNpZXMuICBUaHVzLCBp dCdzIG5vdA0KPiJjb25maWd1cmVkIiAtIGl0J3Mgc29sZWx5IG9wZXJhdGlvbmFsIHN0YXRlLiAg SG93ZXZlciwgdGhlIEJGRCB5YW5nIG1vZGVsDQo+ZG9lc24ndCByZWFsbHkgbWFrZSBnb29kIHBy b3Zpc2lvbiBmb3IgdGhhdCBhcyBhbiAib24iLg0KPg0KPldoZXJlIGFsbCBlbmRwb2ludCBzdGF0 ZSBpcyBrbm93biBhIHByaW9yaSwgY29uZmlnIHN0YXRlIG1ha2VzIGJldHRlcg0KPnNlbnNlLg0K Pg0KPlRvIHBpY2sgdGhlIGV4YW1wbGUgb2YgSnVuaXBlcidzIGNvbmZpZ3VyYXRpb24sIGlmIE9T UEYgYW5kIGVCR1Agd2VyZQ0KPnVzaW5nDQo+QkZELCBib3RoIGNhbiBjaG9vc2UgZGlmZmVyaW5n IHRpbWVycy4gIFRoaXMgcmVwcmVzZW50cyB0d28gcGllY2VzIG9mDQo+Y29uZmlndXJhdGlvbiBz dGF0ZSBmb3IgdGhlIHNhbWUgZW5kcG9pbnRzLiAgQWRkaXRpb25hbGx5LCBvbmx5IG9uZSBCRkQN Cj5zZXNzaW9uIGlzIGZvcm1lZCB1c2luZyB0aGUgbW9zdCBhZ2dyZXNzaXZlIHRpbWVycy4NCj4N Cj5JIHBhcnRpYWxseSBwb2ludCBvdXQgdGhlIHNpdHVhdGlvbiBvZiBtdWx0aXBsZSB0aW1lcnMg c2luY2UgdGhlcmUgaGF2ZQ0KPmJlZW4NCj5wcmlvciBsaXN0IGRpc2N1c3Npb25zIG9uIHRoZSBz aXR1YXRpb24gd2hlcmUgY2xpZW50cyBoYXZlIGRpZmZlcmVudA0KPnRpbWluZw0KPnJlcXVpcmVt ZW50cy4gIEkgZG9uJ3QgdGhpbmsgd2UgaGFuZGxlIHRoaXMgb3BlcmF0aW9uYWxseSBpbiB0aGUg QkZEDQo+cHJvdG9jb2wgaW4gdGhlIGNsZWFuZXN0IGZhc2hpb24gcmlnaHQgbm93IC0gdGhlIHNl c3Npb24gd2lsbCBnbyB0byBEb3duDQo+d2hlbiB0aGUgYWdncmVzc2l2ZSB0aW1lcnMgZmFpbCBh bmQgdGhlcmUncyBubyBjbGVhbiB3YXkgdG8gcmVuZWdvdGlhdGUgdG8NCj50aGUgbGVzcyBhZ2dy ZXNzaXZlIHRpbWVycy4NCj4NCj4tLSBKZWZmDQo+DQo+DQo+DQo+DQo+DQo+DQo+T24gRnJpLCBN YXkgMTksIDIwMTcgYXQgMDI6MzE6MzhBTSArMDAwMCwgUmVzaGFkIFJhaG1hbiAocnJhaG1hbikg d3JvdGU6DQo+PiBXZSBzdGFydGVkIG9mZiB3aXRoIHRoZSBpbnRlbnQgb2YgaGF2aW5nIEJGRCBw YXJhbWV0ZXJzIGluIHRoZQ0KPj5hcHBsaWNhdGlvbnMvcHJvdG9jb2xzIHdoaWNoIG1ha2UgdXNl IG9mIEJGRC4gRm9yIHRpbWVyL211bHRpcGxpZXIgdGhpcw0KPj5pcyBwcmV0dHkgc3RyYWlnaHQt Zm9yd2FyZCwgYWx0aG91Z2ggdGhlIGRpc2N1c3Npb24gb2Ygd2hhdCB0byBkbyB3aGVuDQo+Pm5v dCBhbGwgYXBwbGljYXRpb25zIGhhdmUgdGhlIHNhbWUgQkZEIHBhcmFtZXRlcnMgZm9yIHRoZSBz YW1lIHNlc3Npb24NCj4+KGUuZy4gR28gd2l0aCBtb3N0IGFnZ3Jlc3NpdmUgZXRjKS4gVGhlbiB3 ZSBzdGFydGVkIGxvb2tpbmcgYXQNCj4+YXV0aGVudGljYXRpb24gcGFyYW1ldGVycyBhbmQgaGF2 aW5nIEJGRCBhdXRoZW50aWNhdGlvbiBwYXJtcyBpbg0KPj5PU1BGL0lTSVMgZXRjIGlzIG5vdCBp bnR1aXRpdmUuIEFuZCB3aGF0IGRvIHdlIGRvIGlmIGFwcGxpY2F0aW9ucyBoYXZlDQo+PmRpZmZl cmVudCBCRkQgYXV0aGVudGljYXRpb24gcGFybXMuIFdlIGNvbmNsdWRlZCB0aGF0IHRoZSBCRkQN Cj4+YXV0aGVudGljYXRpb24gcGFybXMgd2VyZSBiZXR0ZXIgb2ZmIGluIEJGRC4gQW5kIG9uY2Ug d2UgZGlkIHRoYXQsIHRoZQ0KPj50aW1lci9tdWx0aXBsaWVyIGZvbGxvd2VkLi4uLg0KPj4gDQo+ PiBJIG1heSBub3QgcmVjYWxsIGFsbCB0aGUgZGV0YWlscy9kaXNjdXNzb25zLCBidXQgSSBkbyBy ZWNhbGwgdGhhdCB3ZQ0KPj53ZW50IGJhY2sgYW5kIGZvcnRoIG9uIHRoaXMgYW5kIGl0IHRvb2sg c29tZSB0aW1lIHRvIG1ha2UgdGhlIGRlY2lzaW9uLg0KPj4gDQo+PiBSZWdhcmRzLA0KPj4gUmVz aGFkIChhcyBpbmRpdmlkdWFsIGNvbnRyaWJ1dG9yKS4NCj4+IA0KPj4gRnJvbTogTWFoZXNoIEpl dGhhbmFuZGFuaQ0KPj48bWpldGhhbmFuZGFuaUBnbWFpbC5jb208bWFpbHRvOm1qZXRoYW5hbmRh bmlAZ21haWwuY29tPj4NCj4+IERhdGU6IFRodXJzZGF5LCBNYXkgMTgsIDIwMTcgYXQgNTozNCBQ TQ0KPj4gVG86ICJBY2VlIExpbmRlbSAoYWNlZSkiIDxhY2VlQGNpc2NvLmNvbTxtYWlsdG86YWNl ZUBjaXNjby5jb20+Pg0KPj4gQ2M6IEplZmZyZXkgSGFhcyA8amhhYXNAanVuaXBlci5uZXQ8bWFp bHRvOmpoYWFzQGp1bmlwZXIubmV0Pj4sIE9TUEYgV0cNCj4+TGlzdCA8b3NwZkBpZXRmLm9yZzxt YWlsdG86b3NwZkBpZXRmLm9yZz4+LA0KPj4iZHJhZnQtaWV0Zi1iZmQteWFuZ0BpZXRmLm9yZzxt YWlsdG86ZHJhZnQtaWV0Zi1iZmQteWFuZ0BpZXRmLm9yZz4iDQo+PjxkcmFmdC1pZXRmLWJmZC15 YW5nQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWJmZC15YW5nQGlldGYub3JnPj4sDQo+PiJk cmFmdC1pZXRmLW9zcGYteWFuZ0BpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1vc3BmLXlhbmdA aWV0Zi5vcmc+Ig0KPj48ZHJhZnQtaWV0Zi1vc3BmLXlhbmdAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0 LWlldGYtb3NwZi15YW5nQGlldGYub3JnPj4sDQo+PiJydGctYmZkQGlldGYub3JnPG1haWx0bzpy dGctYmZkQGlldGYub3JnPiINCj4+PHJ0Zy1iZmRAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmRAaWV0 Zi5vcmc+Pg0KPj4gU3ViamVjdDogUmU6IElFVEYgT1NQRiBZQU5HIGFuZCBCRkQgQ29uZmlndXJh dGlvbg0KPj4gUmVzZW50LUZyb206IDxhbGlhcy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzphbGlh cy1ib3VuY2VzQGlldGYub3JnPj4NCj4+IFJlc2VudC1UbzogPHZlcm8uemhlbmdAaHVhd2VpLmNv bTxtYWlsdG86dmVyby56aGVuZ0BodWF3ZWkuY29tPj4sDQo+PlJlc2hhZCA8cnJhaG1hbkBjaXNj by5jb208bWFpbHRvOnJyYWhtYW5AY2lzY28uY29tPj4sDQo+PjxtamV0aGFuYW5kYW5pQGdtYWls LmNvbTxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+PiwNCj4+PHNhbnRvc2gucGFsbGFn YXR0aUBnbWFpbC5jb208bWFpbHRvOnNhbnRvc2gucGFsbGFnYXR0aUBnbWFpbC5jb20+PiwNCj4+ PGdyZWdpbWlyc2t5QGdtYWlsLmNvbTxtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tPj4NCj4+ IFJlc2VudC1EYXRlOiBUaHVyc2RheSwgTWF5IDE4LCAyMDE3IGF0IDU6NDAgUE0NCj4+IA0KPj4g UmVzZW5kaW5nIHdpdGggY29ycmVjdCBCRkQgV0cgYWRkcmVzcy4NCj4+IA0KPj4gT24gTWF5IDE4 LCAyMDE3LCBhdCAyOjMzIFBNLCBNYWhlc2ggSmV0aGFuYW5kYW5pDQo+PjxtamV0aGFuYW5kYW5p QGdtYWlsLmNvbTxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+PiB3cm90ZToNCj4+IA0K Pj4gQWdyZWUgd2l0aCBBY2VlJ3MgYXNzZXNzbWVudC4gQWZ0ZXIgbXVjaCBkZWJhdGUsIHdlIGRl Y2lkZWQgdGhhdCB3ZQ0KPj5zaG91bGQgbGVhdmUgQkZEIHBhcmFtZXRlciBjb25maWd1cmF0aW9u IGluIHRoZSBCRkQgbW9kZWwgaXRzZWxmLCBhbmQNCj4+aGF2ZSBhbnkgSUdQIHByb3RvY29sIHJl ZmVyZW5jZSB0aGUgQkZEIGluc3RhbmNlIGluIEJGRCBpdHNlbGYuIFRoaXMNCj4+bWFrZXMgc2Vu c2Ugc3BlY2lhbGx5IGlmIG11bHRpcGxlIHByb3RvY29scyBmYXRlLXNoYXJlIHRoZSBCRkQgc2Vz c2lvbi4NCj4+IA0KPj4gQ2hlZXJzLg0KPj4gDQo+PiBPbiBNYXkgMTgsIDIwMTcsIGF0IDEyOjI3 IFBNLCBBY2VlIExpbmRlbSAoYWNlZSkNCj4+PGFjZWVAY2lzY28uY29tPG1haWx0bzphY2VlQGNp c2NvLmNvbT4+IHdyb3RlOg0KPj4gDQo+PiBIaSBKZWZmLA0KPj4gDQo+PiBBdCB0aGUgT1NQRiBX RyBNZWV0aW5nIGluIENoaWNhZ28sIHlvdSBzdWdnZXN0ZWQgdGhhdCB3ZSBtYXkgd2FudCB0bw0K Pj5wcm92aWRlIGNvbmZpZ3VyYXRpb24gb2YgQkZEIHBhcmFtZXRlcnMgd2l0aGluIHRoZSBPU1BG IG1vZGVsDQo+PihpZXRmLW9zcGYueWFuZykuIFdlIG9yaWdpbmFsbHkgZGlkIGhhdmUgdGhpcyBj b25maWd1cmF0aW9uLiBIb3dldmVyLA0KPj5hZnRlciBtdWNoIGRpc2N1c3Npb24gYW5kIGNvb3Jk aW5hdGlvbiB3aXRoIHRoZSBCRkQgWUFORyBkZXNpZ24gdGVhbSwgd2UNCj4+YWdyZWVkIHRvIGxl YXZlIHRoZSBCRkQgc2Vzc2lvbiBwYXJhbWV0ZXJzIGluIEJGRCBhbmQgb25seSBlbmFibGUgQkZE DQo+PndpdGhpbiB0aGUgT1NQRiBhbmQgSVMtSVMgbW9kZWxzLg0KPj4gDQo+PiBXZSBkaWQgZGlz Y3VzcyB0aGUgZmFjdCB0aGF0IHZlbmRvcnMgKG5vdGFibHkgQ2lzY28gSU9TLVhSIGFuZCBKdW5p cGVyDQo+PkpVTk9TKSBkbyBhbGxvdyBjb25maWd1cmF0aW9uIHdpdGhpbiB0aGUgSUdQcy4gSG93 ZXZlciwgdGhlIGNvbnNlbnN1cw0KPj53YXMgdG8gbGVhdmUgdGhlIEJGRCBjb25maWd1cmF0aW9u IGluIHRoZSBCRkQgbW9kZWwuIFRoZSBoZXVyaXN0aWNzIHRvDQo+PmRldGVybWluZSB3aGF0IHBh cmFtZXRlcnMgdG8gdXNlIHdoZW4gdGhlIHNhbWUgQkZEIGVuZHBvaW50IHdhcw0KPj5jb25maWd1 cmVkIHdpdGggZGlmZmVyZW50IHBhcmFtZXRlcnMgaW4gZGlmZmVyZW50IHByb3RvY29scyB3ZXJl DQo+PnByb3ByaWV0YXJ5IGFuZCBzb21ld2hhdCBvZiBhIGhhY2suDQo+PiANCj4+IEkgbWF5IGhh dmUgbm90IHJlbWVtYmVyZWQgYWxsIHRoZSBkZXRhaWxzIHNvIEknZCBlbmNvdXJhZ2Ugb3RoZXJz IHRvDQo+PmNoaW1lIGluLg0KPj4gDQo+PiBUaGFua3MsDQo+PiBBY2VlDQo+PiANCj4+IE1haGVz aCBKZXRoYW5hbmRhbmkNCj4+IG1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0aGFu YW5kYW5pQGdtYWlsLmNvbT4NCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gTWFoZXNoIEpldGhhbmFu ZGFuaQ0KPj4gbWpldGhhbmFuZGFuaUBnbWFpbC5jb208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21h aWwuY29tPg0KPj4gDQo+PiANCj4+IA0KDQo= From nobody Mon Jun 19 15:11:40 2017 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 0CF221200CF; Mon, 19 Jun 2017 15:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pbljjKxfvUP; Mon, 19 Jun 2017 15:11:29 -0700 (PDT) Received: from mail-oi0-x241.google.com (mail-oi0-x241.google.com [IPv6:2607:f8b0:4003:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3C521294D8; Mon, 19 Jun 2017 15:11:28 -0700 (PDT) Received: by mail-oi0-x241.google.com with SMTP id v74so10475848oie.2; Mon, 19 Jun 2017 15:11:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=S9DwLnx/RXK7D5/Mp7Rgee5ki275NebAQBY/bq8mc50=; b=lOGTZBW/OC2EXHyudmVrLuzX7hvAyKo9CRSR+PkfMlTE72sTW3/b6wLiG43x0B/nVV 5ATZtp9jR27ZEvWFnOeWoKdKeeEDF/I6rCAoS9O8ENo0l6fzJKFtWLzXAqMMopqgRZec BNEYC2xlbVcw/pFW3dVpP/Xqelz0+x6lKR1nNdsDNhZMrnfzf3Ugx4dA7PdJP8NI7MY+ 1vihI48fbUNQBVox+XZzazWiNNzGSZmf4eQUl0XZ3S6+J9k6wM0uRmLRp9iQGoiNoUgi BCO1xAfJxvNPSuQFPFf5x1TKOmU74Yl9GGD9AJMvadyu1eb3RLDnF0eadtHbYZApBYup biig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=S9DwLnx/RXK7D5/Mp7Rgee5ki275NebAQBY/bq8mc50=; b=dGWvpULLR2yKf/0xHR3zvQ7l7pBC//8RUAye0b5iHTUkIm5i8zWvV1EHnnxbuAiOUJ GCaq88bZtUQe//hE3YwO2vxZJ79V6K03dKobsDpSk8j4pE7xeXFpc0EX9KF0Dz15urfH L7gGNerw6OJNCjnqGzaSxsWhdMeOGGu1hZyE/rjOns8hbXU1LTOQfHDWZ4uqXpgkrc+D l4AyWViH58sZXjdMk5AJ7T7twOQU9j/0kfEaInxKaZ88X+y83/my38RxuGX0AG5t+kpk sicSqK6u5mVmc8BA7erkh5/9lg9SBWcxjKLgjjc0vwU8l6EW+Jwdw4j69bOLkHNZVG1K pIHA== X-Gm-Message-State: AKS2vOxF+Abb4qZ+ZDantxS2zIwxkHPHsadGhcKbmGQ2n6fti9wLPY07 eUINjionsffrYQ== X-Received: by 10.202.105.138 with SMTP id e132mr6573587oic.9.1497910288187; Mon, 19 Jun 2017 15:11:28 -0700 (PDT) Received: from dhcp-128-107-151-90.cisco.com (dhcp-128-107-151-90.cisco.com. [128.107.151.90]) by smtp.gmail.com with ESMTPSA id w193sm5461617oie.37.2017.06.19.15.11.26 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 19 Jun 2017 15:11:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: IETF OSPF YANG and BFD Configuration From: Mahesh Jethanandani In-Reply-To: <20170619185715.GB22146@pfrc.org> Date: Mon, 19 Jun 2017 15:11:25 -0700 Cc: Reshad Rahman , "Acee Lindem (acee)" , Jeffrey Haas , OSPF WG List , "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <0578CD07-8678-4FF2-939F-0EF6F68CE34A@gmail.com> References: <38DEB571-2918-4464-B18A-71B24221772F@gmail.com> <47325462-2430-4197-AA8D-D3FEF74A834D@gmail.com> <20170619185715.GB22146@pfrc.org> To: Jeffrey Haas X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 19 Jun 2017 22:11:32 -0000 > On Jun 19, 2017, at 11:57 AM, Jeffrey Haas wrote: >=20 > [Long delayed response.] >=20 > Reshad picked up the key points: Some things may make sense in the > per-client (protocol) users of BFD, some things perhaps do not. And = some > come down to questions for timer granularity. >=20 > The OSPF and ISIS models both make use of BFD simply by providing a = boolean > that says "I'm using BFD or not". >=20 > Where we run into some issues are the cases highlighted: when the = sessions > don't share common properties, how should the protocol pick what BFD = session > to use? =20 The issue that I hear most is the timer granularity. Is there something = else? >=20 > The current BFD yang model only permits a single IP single-hop session > to be configured. (Key is interface/dst-ip) This means that if = different > parameters *were* desired, the BFD model won't permit it today. = However, > BFD sessions for many protocols tend not to be configured, but may = spring > forth from protocol state, such as IGP adjacencies. Thus, it's not > "configured" - it's solely operational state. However, the BFD yang = model > doesn't really make good provision for that as an "on=E2=80=9D. The idea is that a BFD session is configured a priori and before a IGP = session is configured with the most aggressive timer. IGP sessions then = refer to the BGP session configured. If a IGP session is added that = requires a more aggressive timer, we would have to renegotiate the more = aggressive timer value. =20 >=20 > Where all endpoint state is known a priori, config state makes better = sense. >=20 > To pick the example of Juniper's configuration, if OSPF and eBGP were = using > BFD, both can choose differing timers. This represents two pieces of > configuration state for the same endpoints. Additionally, only one = BFD > session is formed using the most aggressive timers. That is what we are suggesting also. >=20 > I partially point out the situation of multiple timers since there = have been > prior list discussions on the situation where clients have different = timing > requirements. I don't think we handle this operationally in the BFD > protocol in the cleanest fashion right now - the session will go to = Down > when the aggressive timers fail and there's no clean way to = renegotiate to > the less aggressive timers. A BFD session would fail more likely because there is a real network = failure than because the timer was more aggressive than what IGP had = requested.=20 >=20 > -- Jeff >=20 >=20 >=20 >=20 >=20 >=20 > On Fri, May 19, 2017 at 02:31:38AM +0000, Reshad Rahman (rrahman) = wrote: >> We started off with the intent of having BFD parameters in the = applications/protocols which make use of BFD. For timer/multiplier this = is pretty straight-forward, although the discussion of what to do when = not all applications have the same BFD parameters for the same session = (e.g. Go with most aggressive etc). Then we started looking at = authentication parameters and having BFD authentication parms in = OSPF/ISIS etc is not intuitive. And what do we do if applications have = different BFD authentication parms. We concluded that the BFD = authentication parms were better off in BFD. And once we did that, the = timer/multiplier followed.... >>=20 >> I may not recall all the details/discussons, but I do recall that we = went back and forth on this and it took some time to make the decision. >>=20 >> Regards, >> Reshad (as individual contributor). >>=20 >> From: Mahesh Jethanandani = > >> Date: Thursday, May 18, 2017 at 5:34 PM >> To: "Acee Lindem (acee)" > >> Cc: Jeffrey Haas >, OSPF = WG List >, = "draft-ietf-bfd-yang@ietf.org" = >, = "draft-ietf-ospf-yang@ietf.org" = >, = "rtg-bfd@ietf.org" = > >> Subject: Re: IETF OSPF YANG and BFD Configuration >> Resent-From: > >> Resent-To: >, = Reshad >, = >, = >, = > >> Resent-Date: Thursday, May 18, 2017 at 5:40 PM >>=20 >> Resending with correct BFD WG address. >>=20 >> On May 18, 2017, at 2:33 PM, Mahesh Jethanandani = > wrote: >>=20 >> Agree with Acee's assessment. After much debate, we decided that we = should leave BFD parameter configuration in the BFD model itself, and = have any IGP protocol reference the BFD instance in BFD itself. This = makes sense specially if multiple protocols fate-share the BFD session. >>=20 >> Cheers. >>=20 >> On May 18, 2017, at 12:27 PM, Acee Lindem (acee) = > wrote: >>=20 >> Hi Jeff, >>=20 >> At the OSPF WG Meeting in Chicago, you suggested that we may want to = provide configuration of BFD parameters within the OSPF model = (ietf-ospf.yang). We originally did have this configuration. However, = after much discussion and coordination with the BFD YANG design team, we = agreed to leave the BFD session parameters in BFD and only enable BFD = within the OSPF and IS-IS models. >>=20 >> We did discuss the fact that vendors (notably Cisco IOS-XR and = Juniper JUNOS) do allow configuration within the IGPs. However, the = consensus was to leave the BFD configuration in the BFD model. The = heuristics to determine what parameters to use when the same BFD = endpoint was configured with different parameters in different protocols = were proprietary and somewhat of a hack. >>=20 >> I may have not remembered all the details so I'd encourage others to = chime in. >>=20 >> Thanks, >> Acee >>=20 >> Mahesh Jethanandani >> mjethanandani@gmail.com >>=20 >>=20 >>=20 >>=20 >> Mahesh Jethanandani >> mjethanandani@gmail.com >>=20 >>=20 >>=20 Mahesh Jethanandani mjethanandani@gmail.com From nobody Mon Jun 19 21:21:35 2017 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 9F1EE12704B; Mon, 19 Jun 2017 21:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2E2OqsiYEIL; Mon, 19 Jun 2017 21:21:24 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 446591243F3; Mon, 19 Jun 2017 21:21:24 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id b6so65676229oia.1; Mon, 19 Jun 2017 21:21:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=vgCOqoKjgcr2ZWf3QemD4Hu0jZVB56cJTsP9ROjCEDg=; b=Est6awMw/2fsKHduDx4ELLb9T2bz++wfhw/W2B6VRN8uVtphEF/yxt2hHRBeGEFkUT gRtN2tgJ7ltBYUb1odvq/hq3vdh3ByhBdDtXCV7CVIIHxAGT3rAf3reFNk2xX7NbyLZy 0hZ1e1UR6Vu/TacCE2ESfevUEj/UnijybrSVqssndF/9pC5+uXY+ibfDqbADbTGUNQ0V mKjXGZEsk7ujby276MTlQmjyAu42t3pcU8gpPW+sOR4Z7SGNUtIwehDQ/whzW7PMZJcg im6WGdXTpMPGtAOV/2isrHDIXwQkcZ/SY2JfHMC/HyceX3VGkRIK74KmHOl79Fc3Lp/f P1aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=vgCOqoKjgcr2ZWf3QemD4Hu0jZVB56cJTsP9ROjCEDg=; b=Ah4fHjHtiHvvyR9mDc8SjqxcwWNH1CVFStGRlDtYkJ9G1ivZ30HyNBLFKoKcVFAHRI PdTcJA93liwlEXDeYHXJBvtc/0d+FvIoyimw4PImHjILFeh/C3l4YyyCEWOgL2M+xItS 472+HX3iUEklDeY3Bbv120clqeNM071hypOHUmjZWvclkokUYbC0HXtjTMby8yBigYby WnpG7fPidf3GNdOlDpAwkUeuZ2uYWas7h5G4Msh0lZoV96CM0x+dGw9AueekpnoOftmh c37FB+6B/AQP8iwIjdqzzGVax52OMxbqOTXoC/QkuYVZmqa/0VnRg9EVxYNhd5N4s/2J pTcQ== X-Gm-Message-State: AKS2vOye76PSEXfR5Wr5rk82rq8eaU4va29QXWqUL5ciw6T4dQNzllo0 9P4Ue4SaXiNMl6QTG7sMz1Suhkj9WQ== X-Received: by 10.202.87.87 with SMTP id l84mr13613621oib.214.1497932483350; Mon, 19 Jun 2017 21:21:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.171 with HTTP; Mon, 19 Jun 2017 21:21:22 -0700 (PDT) In-Reply-To: <149791573372.23708.11815253927158130940.idtracker@ietfa.amsl.com> References: <149791573372.23708.11815253927158130940.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Mon, 19 Jun 2017 23:21:22 -0500 Message-ID: Subject: Fwd: New Version Notification for draft-mirsky-bfd-mpls-demand-00.txt To: "rtg-bfd@ietf.org" , "mpls@ietf.org" , spring@ietf.org Content-Type: multipart/alternative; boundary="001a113d2ecc916e5405525c95be" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 04:21:27 -0000 --001a113d2ecc916e5405525c95be Content-Type: text/plain; charset="UTF-8" Dear All, I think this new draft may be of interest. Looking forward to your comments, questions. Regards, Greg ---------- Forwarded message ---------- From: Date: Mon, Jun 19, 2017 at 6:42 PM Subject: New Version Notification for draft-mirsky-bfd-mpls-demand-00.txt To: Gregory Mirsky A new version of I-D, draft-mirsky-bfd-mpls-demand-00.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-mirsky-bfd-mpls-demand Revision: 00 Title: BFD in Demand Mode over Point-to-Point MPLS LSP Document date: 2017-06-19 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-mirsky-bfd-mpls- demand-00.txt Status: https://datatracker.ietf.org/doc/draft-mirsky-bfd-mpls- demand/ Htmlized: https://tools.ietf.org/html/draft-mirsky-bfd-mpls-demand-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-mirsky-bfd- mpls-demand-00 Abstract: This document describes procedures for using Bidirectional Forwarding Detection (BFD) in Demand mode to detect data plane failures in Multiprotocol Label Switching (MPLS) point-to-point Label Switched Paths. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --001a113d2ecc916e5405525c95be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,
I think this new draft may be of interest. L= ooking forward to your comments, questions.

Regard= s,
Greg

---------- Forwa= rded message ----------
From: <internet-drafts@= ietf.org>
Date: Mon, Jun 19, 2017 at 6:42 PM
Subject: N= ew Version Notification for draft-mirsky-bfd-mpls-demand-00.txt
To: Greg= ory Mirsky <gregimirsky@gmail.c= om>



A new version of I-D, draft-mirsky-bfd-mpls-demand-00.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mirsky-bfd-mpls-demand<= br> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BFD in Demand Mode over Point-to-P= oint MPLS LSP
Document date:=C2=A0 2017-06-19
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-mirsky-bf= d-mpls-demand-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-mirsky-bfd-mpls-demand/=
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https= ://tools.ietf.org/html/draft-mirsky-bfd-mpls-demand-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-mirsky-bfd-mpls-= demand-00


Abstract:
=C2=A0 =C2=A0This document describes procedures for using Bidirectional For= warding
=C2=A0 =C2=A0Detection (BFD) in Demand mode to detect data plane failures i= n
=C2=A0 =C2=A0Multiprotocol Label Switching (MPLS) point-to-point Label Swit= ched
=C2=A0 =C2=A0Paths.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--001a113d2ecc916e5405525c95be-- From nobody Tue Jun 20 07:08:00 2017 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 4C4DB129B20; Tue, 20 Jun 2017 07:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uquf-JlGLNev; Tue, 20 Jun 2017 07:07:49 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9947C12EC78; Tue, 20 Jun 2017 07:07:49 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 4BE031E37E; Tue, 20 Jun 2017 10:16:39 -0400 (EDT) Date: Tue, 20 Jun 2017 10:16:39 -0400 From: Jeffrey Haas To: Mahesh Jethanandani Cc: Reshad Rahman , "Acee Lindem (acee)" , Jeffrey Haas , OSPF WG List , "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Subject: Re: IETF OSPF YANG and BFD Configuration Message-ID: <20170620141639.GA22550@pfrc.org> References: <38DEB571-2918-4464-B18A-71B24221772F@gmail.com> <47325462-2430-4197-AA8D-D3FEF74A834D@gmail.com> <20170619185715.GB22146@pfrc.org> <0578CD07-8678-4FF2-939F-0EF6F68CE34A@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0578CD07-8678-4FF2-939F-0EF6F68CE34A@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 14:07:52 -0000 Mahesh, On Mon, Jun 19, 2017 at 03:11:25PM -0700, Mahesh Jethanandani wrote: > > On Jun 19, 2017, at 11:57 AM, Jeffrey Haas wrote: > > Where we run into some issues are the cases highlighted: when the sessions > > don't share common properties, how should the protocol pick what BFD session > > to use? > > The issue that I hear most is the timer granularity. Is there something else? Potentially mode (async vs. echo) and authentication. However, I believe timer granularity is the biggest one. > > The current BFD yang model only permits a single IP single-hop session > > to be configured. (Key is interface/dst-ip) This means that if different > > parameters *were* desired, the BFD model won't permit it today. However, > > BFD sessions for many protocols tend not to be configured, but may spring > > forth from protocol state, such as IGP adjacencies. Thus, it's not > > "configured" - it's solely operational state. However, the BFD yang model > > doesn't really make good provision for that as an "on”. > > The idea is that a BFD session is configured a priori and before a IGP session is configured with the most aggressive timer. IGP sessions then refer to the BGP session configured. If a IGP session is added that requires a more aggressive timer, we would have to renegotiate the more aggressive timer value. Consider a broadcast network segment such as Ethernet. Consider a few dozen routers on such a segment. Is it your expectation that an IGP would require each of those routers to be manually configured in the Yang module a priori? That is, after all, much of the point of an IGP: automatic discovery. > > Where all endpoint state is known a priori, config state makes better sense. > > > > To pick the example of Juniper's configuration, if OSPF and eBGP were using > > BFD, both can choose differing timers. This represents two pieces of > > configuration state for the same endpoints. Additionally, only one BFD > > session is formed using the most aggressive timers. > > That is what we are suggesting also. The distinguishing point is configuration vs. operational state. The current model doesn't permit more than one set of parameters to be provisioned even if the implementation may choose to instantiate exactly one session. > > I partially point out the situation of multiple timers since there have been > > prior list discussions on the situation where clients have different timing > > requirements. I don't think we handle this operationally in the BFD > > protocol in the cleanest fashion right now - the session will go to Down > > when the aggressive timers fail and there's no clean way to renegotiate to > > the less aggressive timers. > > A BFD session would fail more likely because there is a real network failure than because the timer was more aggressive than what IGP had requested. Please note that I raise this point mostly because of prior discussion. I'm well aware of the headaches this currently causes: Different protocols have different survivability requirements. An IGP may very well want sub-second timers, potentially for repair behaviors. BGP may want fast failover, but may be fine with second level granularity. This is particularly true since the cost of too aggressively flapping BGP is of significantly greater impact to the network and the router. But moving to what *is* rather than what should be, if there are two different timing setups for the same endpoint: If you deprovision the more aggressive timer, the session should likely renegotiate to the less aggressive one rather than drop. -- Jeff From nobody Tue Jun 20 07:12:09 2017 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 CA75012EC57; Tue, 20 Jun 2017 07:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJ-UG4aBlnil; Tue, 20 Jun 2017 07:12:06 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC3112EC16; Tue, 20 Jun 2017 07:12:06 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id EF7251E37E; Tue, 20 Jun 2017 10:20:56 -0400 (EDT) Date: Tue, 20 Jun 2017 10:20:56 -0400 From: Jeffrey Haas To: "Acee Lindem (acee)" Cc: "Reshad Rahman (rrahman)" , Mahesh Jethanandani , Jeffrey Haas , OSPF WG List , "rtg-bfd@ietf. org" , "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Subject: Re: IETF OSPF YANG and BFD Configuration Message-ID: <20170620142056.GB22550@pfrc.org> References: <38DEB571-2918-4464-B18A-71B24221772F@gmail.com> <47325462-2430-4197-AA8D-D3FEF74A834D@gmail.com> <20170619185715.GB22146@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 14:12:08 -0000 Acee, On Mon, Jun 19, 2017 at 10:10:43PM +0000, Acee Lindem (acee) wrote: > I don’t really feel there is a strong requirement to support different > timers values per protocol even though several implementations allow > different protocol specific values to be configured (with varying > behaviors). > > If there were such a requirement, I would think it would be better > satisfied by extending the BFD model session key with an additional > identifier, e.g., . I suspect multi-instancing may be where this conversation goes. > IMO, this would be > preferable to allowing the details of BFD to permeate into all the other > protocol models. This would require configuration of the instance rather > than a boolean in the protocols. My lingering concern is whether the client protocol may have preferences about what session to use when such multi-instancing is permitted. Minimally this would require some sort of Yang reference to the specific instance. As I'm noting in the other response, do we really expect BFD Yang model users to pre-provision every single OSPF/ISIS adjacency in the config stanza? Likely, no. What I tend to expect is a template being used for a service profile. We don't currently have such a thing. > Acee -- Jeff From nobody Tue Jun 20 07:14:36 2017 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 A6EF412ECA3; Tue, 20 Jun 2017 07:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12NnJKf_MgQk; Tue, 20 Jun 2017 07:14:32 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11C0C12EC9B; Tue, 20 Jun 2017 07:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5638; q=dns/txt; s=iport; t=1497968071; x=1499177671; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=E1Nyft3AVxGnI/1NLcz0A4woydYIX0j0wl9r6BEw108=; b=L4XIylraqhxRQtAr+N6wZvW/mvJaUIb/AtFr+7c1oIjsW/YwzEzGAIeF gcps4pwQFrhvUuMuOg1V/kS+XKz3QdIMpbQM5YfQClu1o78DSDH4wlkbQ CBP/bJL32tylMLmdO20DqqmApdnlSSbweL3TMrnO2yzd46PZbAX41Bckw k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DGAAAVLUlZ/5tdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1iBbweDZIoZkX+VeIIRhiQCGoJHPxgBAgEBAQEBAQFrKIUZAQU?= =?us-ascii?q?jEUUQAgEIDgoCAiYCAgIwFRACBAENBYosrCmCJotbAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBHYELiVmBDIRpgxKCYQEElxyHRQKTYIIIhUiKPpUMAR84gQp0FUmHDgF?= =?us-ascii?q?2iEyBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.39,364,1493683200"; d="scan'208";a="440190795" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jun 2017 14:14:30 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v5KEETW2020036 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 20 Jun 2017 14:14:29 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 20 Jun 2017 10:14:28 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Tue, 20 Jun 2017 10:14:28 -0400 From: "Acee Lindem (acee)" To: Jeffrey Haas , Mahesh Jethanandani CC: "Reshad Rahman (rrahman)" , Jeffrey Haas , OSPF WG List , "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Subject: Re: IETF OSPF YANG and BFD Configuration Thread-Topic: IETF OSPF YANG and BFD Configuration Thread-Index: AQHS6Syo68r6z3GylU2z1PR9VYBctaItArCAgAENr4D//7xOAA== Date: Tue, 20 Jun 2017 14:14:28 +0000 Message-ID: References: <38DEB571-2918-4464-B18A-71B24221772F@gmail.com> <47325462-2430-4197-AA8D-D3FEF74A834D@gmail.com> <20170619185715.GB22146@pfrc.org> <0578CD07-8678-4FF2-939F-0EF6F68CE34A@gmail.com> <20170620141639.GA22550@pfrc.org> In-Reply-To: <20170620141639.GA22550@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="utf-8" Content-ID: <0039AF82AD00B24E8B65CD98B24EB038@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 14:14:34 -0000 SGkgSmVmZiwgTWFoZXNoLCANCg0KU2VlIGEgY291cGxlIGlubGluZXMuDQoNCk9uIDYvMjAvMTcs IDEwOjE2IEFNLCAiSmVmZnJleSBIYWFzIiA8amhhYXNAcGZyYy5vcmc+IHdyb3RlOg0KDQo+TWFo ZXNoLA0KPg0KPk9uIE1vbiwgSnVuIDE5LCAyMDE3IGF0IDAzOjExOjI1UE0gLTA3MDAsIE1haGVz aCBKZXRoYW5hbmRhbmkgd3JvdGU6DQo+PiA+IE9uIEp1biAxOSwgMjAxNywgYXQgMTE6NTcgQU0s IEplZmZyZXkgSGFhcyA8amhhYXNAcGZyYy5vcmc+IHdyb3RlOg0KPj4gPiBXaGVyZSB3ZSBydW4g aW50byBzb21lIGlzc3VlcyBhcmUgdGhlIGNhc2VzIGhpZ2hsaWdodGVkOiB3aGVuIHRoZQ0KPj5z ZXNzaW9ucw0KPj4gPiBkb24ndCBzaGFyZSBjb21tb24gcHJvcGVydGllcywgaG93IHNob3VsZCB0 aGUgcHJvdG9jb2wgcGljayB3aGF0IEJGRA0KPj5zZXNzaW9uDQo+PiA+IHRvIHVzZT8gIA0KPj4g DQo+PiBUaGUgaXNzdWUgdGhhdCBJIGhlYXIgbW9zdCBpcyB0aGUgdGltZXIgZ3JhbnVsYXJpdHku IElzIHRoZXJlIHNvbWV0aGluZw0KPj5lbHNlPw0KPg0KPlBvdGVudGlhbGx5IG1vZGUgKGFzeW5j IHZzLiBlY2hvKSBhbmQgYXV0aGVudGljYXRpb24uICBIb3dldmVyLCBJIGJlbGlldmUNCj50aW1l ciBncmFudWxhcml0eSBpcyB0aGUgYmlnZ2VzdCBvbmUuDQo+DQo+PiA+IFRoZSBjdXJyZW50IEJG RCB5YW5nIG1vZGVsIG9ubHkgcGVybWl0cyBhIHNpbmdsZSBJUCBzaW5nbGUtaG9wIHNlc3Npb24N Cj4+ID4gdG8gYmUgY29uZmlndXJlZC4gIChLZXkgaXMgaW50ZXJmYWNlL2RzdC1pcCkgIFRoaXMg bWVhbnMgdGhhdCBpZg0KPj5kaWZmZXJlbnQNCj4+ID4gcGFyYW1ldGVycyAqd2VyZSogZGVzaXJl ZCwgdGhlIEJGRCBtb2RlbCB3b24ndCBwZXJtaXQgaXQgdG9kYXkuDQo+Pkhvd2V2ZXIsDQo+PiA+ IEJGRCBzZXNzaW9ucyBmb3IgbWFueSBwcm90b2NvbHMgdGVuZCBub3QgdG8gYmUgY29uZmlndXJl ZCwgYnV0IG1heQ0KPj5zcHJpbmcNCj4+ID4gZm9ydGggZnJvbSBwcm90b2NvbCBzdGF0ZSwgc3Vj aCBhcyBJR1AgYWRqYWNlbmNpZXMuICBUaHVzLCBpdCdzIG5vdA0KPj4gPiAiY29uZmlndXJlZCIg LSBpdCdzIHNvbGVseSBvcGVyYXRpb25hbCBzdGF0ZS4gIEhvd2V2ZXIsIHRoZSBCRkQgeWFuZw0K Pj5tb2RlbA0KPj4gPiBkb2Vzbid0IHJlYWxseSBtYWtlIGdvb2QgcHJvdmlzaW9uIGZvciB0aGF0 IGFzIGFuICJvbuKAnS4NCj4+IA0KPj4gVGhlIGlkZWEgaXMgdGhhdCBhIEJGRCBzZXNzaW9uIGlz IGNvbmZpZ3VyZWQgYSBwcmlvcmkgYW5kIGJlZm9yZSBhIElHUA0KPj5zZXNzaW9uIGlzIGNvbmZp Z3VyZWQgd2l0aCB0aGUgbW9zdCBhZ2dyZXNzaXZlIHRpbWVyLiBJR1Agc2Vzc2lvbnMgdGhlbg0K Pj5yZWZlciB0byB0aGUgQkdQIHNlc3Npb24gY29uZmlndXJlZC4gSWYgYSBJR1Agc2Vzc2lvbiBp cyBhZGRlZCB0aGF0DQo+PnJlcXVpcmVzIGEgbW9yZSBhZ2dyZXNzaXZlIHRpbWVyLCB3ZSB3b3Vs ZCBoYXZlIHRvIHJlbmVnb3RpYXRlIHRoZSBtb3JlDQo+PmFnZ3Jlc3NpdmUgdGltZXIgdmFsdWUu DQo+DQo+Q29uc2lkZXIgYSBicm9hZGNhc3QgbmV0d29yayBzZWdtZW50IHN1Y2ggYXMgRXRoZXJu ZXQuDQo+Q29uc2lkZXIgYSBmZXcgZG96ZW4gcm91dGVycyBvbiBzdWNoIGEgc2VnbWVudC4NCj4N Cj5JcyBpdCB5b3VyIGV4cGVjdGF0aW9uIHRoYXQgYW4gSUdQIHdvdWxkIHJlcXVpcmUgZWFjaCBv ZiB0aG9zZSByb3V0ZXJzIHRvDQo+YmUNCj5tYW51YWxseSBjb25maWd1cmVkIGluIHRoZSBZYW5n IG1vZHVsZSBhIHByaW9yaT8gIFRoYXQgaXMsIGFmdGVyIGFsbCwgbXVjaA0KPm9mIHRoZSBwb2lu dCBvZiBhbiBJR1A6IGF1dG9tYXRpYyBkaXNjb3ZlcnkuDQoNCkkgdGhpbmsgdGhlIEJGRCBtb2Rl bCBzaG91bGQgc3VwcG9ydCBhIHdpbGRjYXJkIGZvciBkZXN0aW5hdGlvbiBJUCBhZGRyZXNzDQp0 byBhdm9pZCB0aGlzIHByb2JsZW0uDQoNCj4NCj4+ID4gV2hlcmUgYWxsIGVuZHBvaW50IHN0YXRl IGlzIGtub3duIGEgcHJpb3JpLCBjb25maWcgc3RhdGUgbWFrZXMgYmV0dGVyDQo+PnNlbnNlLg0K Pj4gPiANCj4+ID4gVG8gcGljayB0aGUgZXhhbXBsZSBvZiBKdW5pcGVyJ3MgY29uZmlndXJhdGlv biwgaWYgT1NQRiBhbmQgZUJHUCB3ZXJlDQo+PnVzaW5nDQo+PiA+IEJGRCwgYm90aCBjYW4gY2hv b3NlIGRpZmZlcmluZyB0aW1lcnMuICBUaGlzIHJlcHJlc2VudHMgdHdvIHBpZWNlcyBvZg0KPj4g PiBjb25maWd1cmF0aW9uIHN0YXRlIGZvciB0aGUgc2FtZSBlbmRwb2ludHMuICBBZGRpdGlvbmFs bHksIG9ubHkgb25lDQo+PkJGRA0KPj4gPiBzZXNzaW9uIGlzIGZvcm1lZCB1c2luZyB0aGUgbW9z dCBhZ2dyZXNzaXZlIHRpbWVycy4NCj4+IA0KPj4gVGhhdCBpcyB3aGF0IHdlIGFyZSBzdWdnZXN0 aW5nIGFsc28uDQo+DQo+VGhlIGRpc3Rpbmd1aXNoaW5nIHBvaW50IGlzIGNvbmZpZ3VyYXRpb24g dnMuIG9wZXJhdGlvbmFsIHN0YXRlLiAgVGhlDQo+Y3VycmVudCBtb2RlbCBkb2Vzbid0IHBlcm1p dCBtb3JlIHRoYW4gb25lIHNldCBvZiBwYXJhbWV0ZXJzIHRvIGJlDQo+cHJvdmlzaW9uZWQgZXZl biBpZiB0aGUgaW1wbGVtZW50YXRpb24gbWF5IGNob29zZSB0byBpbnN0YW50aWF0ZSBleGFjdGx5 DQo+b25lDQo+c2Vzc2lvbi4NCg0KVGhpcyBjb3VsZCBiZSBzdXBwb3J0ZWQgd2l0aCBleHRlbnNp b25zIHRvIHRoZSBCRkQgbW9kZWwuDQoNClRoYW5rcywNCkFjZWUgDQo+DQo+PiA+IEkgcGFydGlh bGx5IHBvaW50IG91dCB0aGUgc2l0dWF0aW9uIG9mIG11bHRpcGxlIHRpbWVycyBzaW5jZSB0aGVy ZQ0KPj5oYXZlIGJlZW4NCj4+ID4gcHJpb3IgbGlzdCBkaXNjdXNzaW9ucyBvbiB0aGUgc2l0dWF0 aW9uIHdoZXJlIGNsaWVudHMgaGF2ZSBkaWZmZXJlbnQNCj4+dGltaW5nDQo+PiA+IHJlcXVpcmVt ZW50cy4gIEkgZG9uJ3QgdGhpbmsgd2UgaGFuZGxlIHRoaXMgb3BlcmF0aW9uYWxseSBpbiB0aGUg QkZEDQo+PiA+IHByb3RvY29sIGluIHRoZSBjbGVhbmVzdCBmYXNoaW9uIHJpZ2h0IG5vdyAtIHRo ZSBzZXNzaW9uIHdpbGwgZ28gdG8NCj4+RG93bg0KPj4gPiB3aGVuIHRoZSBhZ2dyZXNzaXZlIHRp bWVycyBmYWlsIGFuZCB0aGVyZSdzIG5vIGNsZWFuIHdheSB0bw0KPj5yZW5lZ290aWF0ZSB0bw0K Pj4gPiB0aGUgbGVzcyBhZ2dyZXNzaXZlIHRpbWVycy4NCj4+IA0KPj4gQSBCRkQgc2Vzc2lvbiB3 b3VsZCBmYWlsIG1vcmUgbGlrZWx5IGJlY2F1c2UgdGhlcmUgaXMgYSByZWFsIG5ldHdvcmsNCj4+ ZmFpbHVyZSB0aGFuIGJlY2F1c2UgdGhlIHRpbWVyIHdhcyBtb3JlIGFnZ3Jlc3NpdmUgdGhhbiB3 aGF0IElHUCBoYWQNCj4+cmVxdWVzdGVkLiANCj4NCj5QbGVhc2Ugbm90ZSB0aGF0IEkgcmFpc2Ug dGhpcyBwb2ludCBtb3N0bHkgYmVjYXVzZSBvZiBwcmlvciBkaXNjdXNzaW9uLg0KPkknbQ0KPndl bGwgYXdhcmUgb2YgdGhlIGhlYWRhY2hlcyB0aGlzIGN1cnJlbnRseSBjYXVzZXM6DQo+DQo+RGlm ZmVyZW50IHByb3RvY29scyBoYXZlIGRpZmZlcmVudCBzdXJ2aXZhYmlsaXR5IHJlcXVpcmVtZW50 cy4gIEFuIElHUCBtYXkNCj52ZXJ5IHdlbGwgd2FudCBzdWItc2Vjb25kIHRpbWVycywgcG90ZW50 aWFsbHkgZm9yIHJlcGFpciBiZWhhdmlvcnMuICBCR1ANCj5tYXkNCj53YW50IGZhc3QgZmFpbG92 ZXIsIGJ1dCBtYXkgYmUgZmluZSB3aXRoIHNlY29uZCBsZXZlbCBncmFudWxhcml0eS4gIFRoaXMN Cj5pcw0KPnBhcnRpY3VsYXJseSB0cnVlIHNpbmNlIHRoZSBjb3N0IG9mIHRvbyBhZ2dyZXNzaXZl bHkgZmxhcHBpbmcgQkdQIGlzIG9mDQo+c2lnbmlmaWNhbnRseSBncmVhdGVyIGltcGFjdCB0byB0 aGUgbmV0d29yayBhbmQgdGhlIHJvdXRlci4NCj4NCj5CdXQgbW92aW5nIHRvIHdoYXQgKmlzKiBy YXRoZXIgdGhhbiB3aGF0IHNob3VsZCBiZSwgaWYgdGhlcmUgYXJlIHR3bw0KPmRpZmZlcmVudCB0 aW1pbmcgc2V0dXBzIGZvciB0aGUgc2FtZSBlbmRwb2ludDogSWYgeW91IGRlcHJvdmlzaW9uIHRo ZSBtb3JlDQo+YWdncmVzc2l2ZSB0aW1lciwgdGhlIHNlc3Npb24gc2hvdWxkIGxpa2VseSByZW5l Z290aWF0ZSB0byB0aGUgbGVzcw0KPmFnZ3Jlc3NpdmUgb25lIHJhdGhlciB0aGFuIGRyb3AuDQo+ DQo+LS0gSmVmZg0KDQo= From nobody Tue Jun 20 07:18:23 2017 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 9133A12EC53; Tue, 20 Jun 2017 07:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6FbWBJ1EOK2; Tue, 20 Jun 2017 07:18:18 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7619F12EC9A; Tue, 20 Jun 2017 07:18:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2172; q=dns/txt; s=iport; t=1497968297; x=1499177897; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=aJYVyECjy3kDECbXw5OOoy9iLZPnyW51f6xTn4G7mzc=; b=Iogk+0RMEV2Cd136HxWmkgW6cBdivKcVc0IMOUypb8wClRvDnAFHulL+ 1BXOvn7AuwE+5YpCc69C0Ping66G4vEFyxktKz149dhnmeBJukIr+/RIQ +l1MAEtas5/01qi/tyInZYQmSCMgCX2NPjHKl05UxO1/BxfulEg2LdGhz A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DGAABsLUlZ/5xdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1iBbweDZIoZkX+VeIIRhiQCGoJHPxgBAgEBAQEBAQFrKIUZAQU?= =?us-ascii?q?jEUUQAgEIDgoCAiYCAgIwFRACBA4FiiysKYImi1sBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEggQuKZYRpgxKCYQEEnmECk2CSDpUMAR84gQp0FYVWHIFmdohMgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.39,364,1493683200"; d="scan'208";a="260204383" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jun 2017 14:18:15 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v5KEIFTZ012538 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 20 Jun 2017 14:18:15 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 20 Jun 2017 10:18:14 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Tue, 20 Jun 2017 10:18:14 -0400 From: "Acee Lindem (acee)" To: Jeffrey Haas CC: "Reshad Rahman (rrahman)" , Mahesh Jethanandani , Jeffrey Haas , OSPF WG List , "rtg-bfd@ietf. org" , "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Subject: Re: IETF OSPF YANG and BFD Configuration Thread-Topic: IETF OSPF YANG and BFD Configuration Thread-Index: AQHS6Syo68r6z3GylU2z1PR9VYBctaIsv2uAgAFSJgD//7wogA== Date: Tue, 20 Jun 2017 14:18:14 +0000 Message-ID: References: <38DEB571-2918-4464-B18A-71B24221772F@gmail.com> <47325462-2430-4197-AA8D-D3FEF74A834D@gmail.com> <20170619185715.GB22146@pfrc.org> <20170620142056.GB22550@pfrc.org> In-Reply-To: <20170620142056.GB22550@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 14:18:21 -0000 SmVmZiwgDQoNCk9uIDYvMjAvMTcsIDEwOjIwIEFNLCAiSmVmZnJleSBIYWFzIiA8amhhYXNAcGZy Yy5vcmc+IHdyb3RlOg0KDQo+QWNlZSwNCj4NCj5PbiBNb24sIEp1biAxOSwgMjAxNyBhdCAxMDox MDo0M1BNICswMDAwLCBBY2VlIExpbmRlbSAoYWNlZSkgd3JvdGU6DQo+PiBJIGRvbuKAmXQgcmVh bGx5IGZlZWwgdGhlcmUgaXMgYSBzdHJvbmcgcmVxdWlyZW1lbnQgdG8gc3VwcG9ydCBkaWZmZXJl bnQNCj4+IHRpbWVycyB2YWx1ZXMgcGVyIHByb3RvY29sIGV2ZW4gdGhvdWdoIHNldmVyYWwgaW1w bGVtZW50YXRpb25zIGFsbG93DQo+PiBkaWZmZXJlbnQgcHJvdG9jb2wgc3BlY2lmaWMgdmFsdWVz IHRvIGJlIGNvbmZpZ3VyZWQgKHdpdGggdmFyeWluZw0KPj4gYmVoYXZpb3JzKS4gDQo+PiANCj4+ IElmIHRoZXJlIHdlcmUgc3VjaCBhIHJlcXVpcmVtZW50LCBJIHdvdWxkIHRoaW5rIGl0IHdvdWxk IGJlIGJldHRlcg0KPj4gc2F0aXNmaWVkIGJ5IGV4dGVuZGluZyB0aGUgQkZEIG1vZGVsIHNlc3Np b24ga2V5IHdpdGggYW4gYWRkaXRpb25hbA0KPj4gaWRlbnRpZmllciwgZS5nLiwgPGludGVyZmFj ZS9kc3QtaXAvaW5zdGFuY2U+Lg0KPg0KPkkgc3VzcGVjdCBtdWx0aS1pbnN0YW5jaW5nIG1heSBi ZSB3aGVyZSB0aGlzIGNvbnZlcnNhdGlvbiBnb2VzLg0KPg0KPj4gSU1PLCB0aGlzIHdvdWxkIGJl DQo+PiBwcmVmZXJhYmxlIHRvIGFsbG93aW5nIHRoZSBkZXRhaWxzIG9mIEJGRCB0byBwZXJtZWF0 ZSBpbnRvIGFsbCB0aGUgb3RoZXINCj4+IHByb3RvY29sIG1vZGVscy4gVGhpcyB3b3VsZCByZXF1 aXJlIGNvbmZpZ3VyYXRpb24gb2YgdGhlIGluc3RhbmNlIHJhdGhlcg0KPj4gdGhhbiBhIGJvb2xl YW4gaW4gdGhlIHByb3RvY29scy4NCj4NCj5NeSBsaW5nZXJpbmcgY29uY2VybiBpcyB3aGV0aGVy IHRoZSBjbGllbnQgcHJvdG9jb2wgbWF5IGhhdmUgcHJlZmVyZW5jZXMNCj5hYm91dCB3aGF0IHNl c3Npb24gdG8gdXNlIHdoZW4gc3VjaCBtdWx0aS1pbnN0YW5jaW5nIGlzIHBlcm1pdHRlZC4NCj5N aW5pbWFsbHkgdGhpcyB3b3VsZCByZXF1aXJlIHNvbWUgc29ydCBvZiBZYW5nIHJlZmVyZW5jZSB0 byB0aGUgc3BlY2lmaWMNCj5pbnN0YW5jZS4NCg0KUmlnaHQgLSB0aGlzIGlzIHdoYXQgSSBqdXN0 IHNhaWQuDQo+DQo+QXMgSSdtIG5vdGluZyBpbiB0aGUgb3RoZXIgcmVzcG9uc2UsIGRvIHdlIHJl YWxseSBleHBlY3QgQkZEIFlhbmcgbW9kZWwNCj51c2VycyB0byBwcmUtcHJvdmlzaW9uIGV2ZXJ5 IHNpbmdsZSBPU1BGL0lTSVMgYWRqYWNlbmN5IGluIHRoZSBjb25maWcNCj5zdGFuemE/ICBMaWtl bHksIG5vLg0KDQpBZ3JlZWQuIA0KPg0KPldoYXQgSSB0ZW5kIHRvIGV4cGVjdCBpcyBhIHRlbXBs YXRlIGJlaW5nIHVzZWQgZm9yIGEgc2VydmljZSBwcm9maWxlLiAgV2UNCj5kb24ndCBjdXJyZW50 bHkgaGF2ZSBzdWNoIGEgdGhpbmcuDQoNCkFncmVlZC4gTXkgcG9pbnQgaXMgdGhhdCB0aGUgQkZE IHNwZWNpZmljIHBhcmFtZXRlcnMgc2hvdWxkIGluIHRoZSBCRkQNCm1vZGVsIHJhdGhlciB0aGFu IHRoZSBwcm90b2NvbCBtb2RlbHMuDQoNCkFjZWUNCj4NCj4tLSBKZWZmDQoNCg== From nobody Tue Jun 20 07:25:24 2017 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 68A4912ECA8; Tue, 20 Jun 2017 07:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejxTGR-cob2I; Tue, 20 Jun 2017 07:25:14 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F30512EC80; Tue, 20 Jun 2017 07:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6606; q=dns/txt; s=iport; t=1497968714; x=1499178314; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YdJOnKVcy2qF8nAhf1+DHh4kfv/D9tct5/0G4ZC4CTc=; b=gLO7yeAOgLfCBU95X9AWz7B+r1MBNh3oMPUwysCyYzOfBJOX+IQtbSFf 1MAUGDF7QGAZtZvZYxF5rBhtNLtmMm3LeR6IyWMKRKnsUn2MkPBNAsu8/ FotNKlvUzN71O4WH2fxyC4KyyKHsBc7nxeGqFhaeCKV9IlCLVQFDlKPjG c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DGAAAaL0lZ/5FdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgystgW8Hg2SKGZF/lXiCEYYkAhqCRz8YAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?BAQECASMREzIFBwQCAQgOAwQBAQECAiMDAgICMBQBCAgCBAENBQiKHAisKoImg?= =?us-ascii?q?z6IHQEBAQEBAQEBAQEBAQEBAQEBAQEBAR2BC4Vhg3iBDId7gmEFlxyHRQKTV4I?= =?us-ascii?q?RhUiKPpUMAR84gQp0FUmHDgF2iEwBgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.39,364,1493683200"; d="scan'208";a="438156439" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jun 2017 14:25:13 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v5KEPDoh028611 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 20 Jun 2017 14:25:13 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 20 Jun 2017 09:25:12 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Tue, 20 Jun 2017 09:25:12 -0500 From: "Les Ginsberg (ginsberg)" To: Jeffrey Haas , Mahesh Jethanandani CC: Jeffrey Haas , "Reshad Rahman (rrahman)" , OSPF WG List , "draft-ietf-ospf-yang@ietf.org" , "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" , "Acee Lindem (acee)" Subject: RE: IETF OSPF YANG and BFD Configuration Thread-Topic: IETF OSPF YANG and BFD Configuration Thread-Index: AQHS6c6lZ7x0VIOb/06pMKntEFyJQ6ItzFjg Date: Tue, 20 Jun 2017 14:25:12 +0000 Message-ID: References: <38DEB571-2918-4464-B18A-71B24221772F@gmail.com> <47325462-2430-4197-AA8D-D3FEF74A834D@gmail.com> <20170619185715.GB22146@pfrc.org> <0578CD07-8678-4FF2-939F-0EF6F68CE34A@gmail.com> <20170620141639.GA22550@pfrc.org> In-Reply-To: <20170620141639.GA22550@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.151.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 14:25:17 -0000 SmVmZiAtDQoNCklubGluZS4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBSdGctYmZkIFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg SmVmZnJleSBIYWFzDQo+IFNlbnQ6IFR1ZXNkYXksIEp1bmUgMjAsIDIwMTcgNzoxNyBBTQ0KPiBU bzogTWFoZXNoIEpldGhhbmFuZGFuaQ0KPiBDYzogSmVmZnJleSBIYWFzOyBSZXNoYWQgUmFobWFu IChycmFobWFuKTsgT1NQRiBXRyBMaXN0OyBkcmFmdC1pZXRmLW9zcGYtDQo+IHlhbmdAaWV0Zi5v cmc7IHJ0Zy1iZmRAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtYmZkLXlhbmdAaWV0Zi5vcmc7IEFjZWUg TGluZGVtDQo+IChhY2VlKQ0KPiBTdWJqZWN0OiBSZTogSUVURiBPU1BGIFlBTkcgYW5kIEJGRCBD b25maWd1cmF0aW9uDQo+IA0KPiBNYWhlc2gsDQo+IA0KPiBPbiBNb24sIEp1biAxOSwgMjAxNyBh dCAwMzoxMToyNVBNIC0wNzAwLCBNYWhlc2ggSmV0aGFuYW5kYW5pIHdyb3RlOg0KPiA+ID4gT24g SnVuIDE5LCAyMDE3LCBhdCAxMTo1NyBBTSwgSmVmZnJleSBIYWFzIDxqaGFhc0BwZnJjLm9yZz4g d3JvdGU6DQo+ID4gPiBXaGVyZSB3ZSBydW4gaW50byBzb21lIGlzc3VlcyBhcmUgdGhlIGNhc2Vz IGhpZ2hsaWdodGVkOiB3aGVuIHRoZQ0KPiA+ID4gc2Vzc2lvbnMgZG9uJ3Qgc2hhcmUgY29tbW9u IHByb3BlcnRpZXMsIGhvdyBzaG91bGQgdGhlIHByb3RvY29sIHBpY2sNCj4gPiA+IHdoYXQgQkZE IHNlc3Npb24gdG8gdXNlPw0KPiA+DQo+ID4gVGhlIGlzc3VlIHRoYXQgSSBoZWFyIG1vc3QgaXMg dGhlIHRpbWVyIGdyYW51bGFyaXR5LiBJcyB0aGVyZSBzb21ldGhpbmcgZWxzZT8NCj4gDQo+IFBv dGVudGlhbGx5IG1vZGUgKGFzeW5jIHZzLiBlY2hvKSBhbmQgYXV0aGVudGljYXRpb24uICBIb3dl dmVyLCBJIGJlbGlldmUNCj4gdGltZXIgZ3JhbnVsYXJpdHkgaXMgdGhlIGJpZ2dlc3Qgb25lLg0K PiANCj4gPiA+IFRoZSBjdXJyZW50IEJGRCB5YW5nIG1vZGVsIG9ubHkgcGVybWl0cyBhIHNpbmds ZSBJUCBzaW5nbGUtaG9wDQo+ID4gPiBzZXNzaW9uIHRvIGJlIGNvbmZpZ3VyZWQuICAoS2V5IGlz IGludGVyZmFjZS9kc3QtaXApICBUaGlzIG1lYW5zDQo+ID4gPiB0aGF0IGlmIGRpZmZlcmVudCBw YXJhbWV0ZXJzICp3ZXJlKiBkZXNpcmVkLCB0aGUgQkZEIG1vZGVsIHdvbid0DQo+ID4gPiBwZXJt aXQgaXQgdG9kYXkuICBIb3dldmVyLCBCRkQgc2Vzc2lvbnMgZm9yIG1hbnkgcHJvdG9jb2xzIHRl bmQgbm90DQo+ID4gPiB0byBiZSBjb25maWd1cmVkLCBidXQgbWF5IHNwcmluZyBmb3J0aCBmcm9t IHByb3RvY29sIHN0YXRlLCBzdWNoIGFzDQo+ID4gPiBJR1AgYWRqYWNlbmNpZXMuICBUaHVzLCBp dCdzIG5vdCAiY29uZmlndXJlZCIgLSBpdCdzIHNvbGVseQ0KPiA+ID4gb3BlcmF0aW9uYWwgc3Rh dGUuICBIb3dldmVyLCB0aGUgQkZEIHlhbmcgbW9kZWwgZG9lc24ndCByZWFsbHkgbWFrZQ0KPiBn b29kIHByb3Zpc2lvbiBmb3IgdGhhdCBhcyBhbiAib27igJ0uDQo+ID4NCj4gPiBUaGUgaWRlYSBp cyB0aGF0IGEgQkZEIHNlc3Npb24gaXMgY29uZmlndXJlZCBhIHByaW9yaSBhbmQgYmVmb3JlIGEg SUdQIHNlc3Npb24NCj4gaXMgY29uZmlndXJlZCB3aXRoIHRoZSBtb3N0IGFnZ3Jlc3NpdmUgdGlt ZXIuIElHUCBzZXNzaW9ucyB0aGVuIHJlZmVyIHRvIHRoZQ0KPiBCR1Agc2Vzc2lvbiBjb25maWd1 cmVkLiBJZiBhIElHUCBzZXNzaW9uIGlzIGFkZGVkIHRoYXQgcmVxdWlyZXMgYSBtb3JlDQo+IGFn Z3Jlc3NpdmUgdGltZXIsIHdlIHdvdWxkIGhhdmUgdG8gcmVuZWdvdGlhdGUgdGhlIG1vcmUgYWdn cmVzc2l2ZSB0aW1lcg0KPiB2YWx1ZS4NCj4gDQo+IENvbnNpZGVyIGEgYnJvYWRjYXN0IG5ldHdv cmsgc2VnbWVudCBzdWNoIGFzIEV0aGVybmV0Lg0KPiBDb25zaWRlciBhIGZldyBkb3plbiByb3V0 ZXJzIG9uIHN1Y2ggYSBzZWdtZW50Lg0KPiANCj4gSXMgaXQgeW91ciBleHBlY3RhdGlvbiB0aGF0 IGFuIElHUCB3b3VsZCByZXF1aXJlIGVhY2ggb2YgdGhvc2Ugcm91dGVycyB0byBiZQ0KPiBtYW51 YWxseSBjb25maWd1cmVkIGluIHRoZSBZYW5nIG1vZHVsZSBhIHByaW9yaT8gIFRoYXQgaXMsIGFm dGVyIGFsbCwgbXVjaCBvZg0KPiB0aGUgcG9pbnQgb2YgYW4gSUdQOiBhdXRvbWF0aWMgZGlzY292 ZXJ5Lg0KPiANCj4gPiA+IFdoZXJlIGFsbCBlbmRwb2ludCBzdGF0ZSBpcyBrbm93biBhIHByaW9y aSwgY29uZmlnIHN0YXRlIG1ha2VzIGJldHRlcg0KPiBzZW5zZS4NCj4gPiA+DQo+ID4gPiBUbyBw aWNrIHRoZSBleGFtcGxlIG9mIEp1bmlwZXIncyBjb25maWd1cmF0aW9uLCBpZiBPU1BGIGFuZCBl QkdQDQo+ID4gPiB3ZXJlIHVzaW5nIEJGRCwgYm90aCBjYW4gY2hvb3NlIGRpZmZlcmluZyB0aW1l cnMuICBUaGlzIHJlcHJlc2VudHMNCj4gPiA+IHR3byBwaWVjZXMgb2YgY29uZmlndXJhdGlvbiBz dGF0ZSBmb3IgdGhlIHNhbWUgZW5kcG9pbnRzLg0KPiA+ID4gQWRkaXRpb25hbGx5LCBvbmx5IG9u ZSBCRkQgc2Vzc2lvbiBpcyBmb3JtZWQgdXNpbmcgdGhlIG1vc3QgYWdncmVzc2l2ZQ0KPiB0aW1l cnMuDQo+ID4NCj4gPiBUaGF0IGlzIHdoYXQgd2UgYXJlIHN1Z2dlc3RpbmcgYWxzby4NCj4gDQo+ IFRoZSBkaXN0aW5ndWlzaGluZyBwb2ludCBpcyBjb25maWd1cmF0aW9uIHZzLiBvcGVyYXRpb25h bCBzdGF0ZS4gIFRoZSBjdXJyZW50DQo+IG1vZGVsIGRvZXNuJ3QgcGVybWl0IG1vcmUgdGhhbiBv bmUgc2V0IG9mIHBhcmFtZXRlcnMgdG8gYmUgcHJvdmlzaW9uZWQNCj4gZXZlbiBpZiB0aGUgaW1w bGVtZW50YXRpb24gbWF5IGNob29zZSB0byBpbnN0YW50aWF0ZSBleGFjdGx5IG9uZSBzZXNzaW9u Lg0KPiANCj4gPiA+IEkgcGFydGlhbGx5IHBvaW50IG91dCB0aGUgc2l0dWF0aW9uIG9mIG11bHRp cGxlIHRpbWVycyBzaW5jZSB0aGVyZQ0KPiA+ID4gaGF2ZSBiZWVuIHByaW9yIGxpc3QgZGlzY3Vz c2lvbnMgb24gdGhlIHNpdHVhdGlvbiB3aGVyZSBjbGllbnRzIGhhdmUNCj4gPiA+IGRpZmZlcmVu dCB0aW1pbmcgcmVxdWlyZW1lbnRzLiAgSSBkb24ndCB0aGluayB3ZSBoYW5kbGUgdGhpcw0KPiA+ ID4gb3BlcmF0aW9uYWxseSBpbiB0aGUgQkZEIHByb3RvY29sIGluIHRoZSBjbGVhbmVzdCBmYXNo aW9uIHJpZ2h0IG5vdw0KPiA+ID4gLSB0aGUgc2Vzc2lvbiB3aWxsIGdvIHRvIERvd24gd2hlbiB0 aGUgYWdncmVzc2l2ZSB0aW1lcnMgZmFpbCBhbmQNCj4gPiA+IHRoZXJlJ3Mgbm8gY2xlYW4gd2F5 IHRvIHJlbmVnb3RpYXRlIHRvIHRoZSBsZXNzIGFnZ3Jlc3NpdmUgdGltZXJzLg0KPiA+DQo+ID4g QSBCRkQgc2Vzc2lvbiB3b3VsZCBmYWlsIG1vcmUgbGlrZWx5IGJlY2F1c2UgdGhlcmUgaXMgYSBy ZWFsIG5ldHdvcmsgZmFpbHVyZQ0KPiB0aGFuIGJlY2F1c2UgdGhlIHRpbWVyIHdhcyBtb3JlIGFn Z3Jlc3NpdmUgdGhhbiB3aGF0IElHUCBoYWQgcmVxdWVzdGVkLg0KPiANCj4gUGxlYXNlIG5vdGUg dGhhdCBJIHJhaXNlIHRoaXMgcG9pbnQgbW9zdGx5IGJlY2F1c2Ugb2YgcHJpb3IgZGlzY3Vzc2lv bi4gIEknbSB3ZWxsDQo+IGF3YXJlIG9mIHRoZSBoZWFkYWNoZXMgdGhpcyBjdXJyZW50bHkgY2F1 c2VzOg0KPiANCj4gRGlmZmVyZW50IHByb3RvY29scyBoYXZlIGRpZmZlcmVudCBzdXJ2aXZhYmls aXR5IHJlcXVpcmVtZW50cy4gIEFuIElHUCBtYXkNCj4gdmVyeSB3ZWxsIHdhbnQgc3ViLXNlY29u ZCB0aW1lcnMsIHBvdGVudGlhbGx5IGZvciByZXBhaXIgYmVoYXZpb3JzLiAgQkdQIG1heQ0KPiB3 YW50IGZhc3QgZmFpbG92ZXIsIGJ1dCBtYXkgYmUgZmluZSB3aXRoIHNlY29uZCBsZXZlbCBncmFu dWxhcml0eS4gIFRoaXMgaXMNCj4gcGFydGljdWxhcmx5IHRydWUgc2luY2UgdGhlIGNvc3Qgb2Yg dG9vIGFnZ3Jlc3NpdmVseSBmbGFwcGluZyBCR1AgaXMgb2YNCj4gc2lnbmlmaWNhbnRseSBncmVh dGVyIGltcGFjdCB0byB0aGUgbmV0d29yayBhbmQgdGhlIHJvdXRlci4NCj4gDQpbTGVzOl0gVGhl IHJlYWwgaXNzdWVzIGhlcmUgYXJlIGZhbHNlIGZhaWx1cmVzIGFuZCBwcm9wZXIgdXNlIG9mIGRh bXBlbmluZy4gTm8gcHJvdG9jb2wgLSBub3QgZXZlbiBhbiBJR1AgLSB3YW50cyB0byBmbGFwIHVu bmVjZXNzYXJpbHkuIElmIHRpbWVycyBhcmUgc2V0IHNvIGFnZ3Jlc3NpdmVseSB0aGF0IGZhbHNl IGZhaWx1cmVzIGFyZSByZXBvcnRlZCB0aGlzIGlzIEJBRC4NCkV2ZW4gd29yc2UgaXMgZmFpbHVy ZSB0byBkYW1wZW4gc28gdGhhdCB3ZSBnZXQgbXVsdGlwbGUgZmFsc2UgZmFpbHVyZXMgaW4gYSBz aG9ydCBwZXJpb2Qgb2YgdGltZS4NCg0KQXJndWluZyB0aGF0IHRoZSByaWdodCB3YXkgdG8gc29s dmUgdGhpcyBwcm9ibGVtIGlzIHRvIGluY3JlYXNlIHRoZSBudW1iZXIgb2Ygc2Vzc2lvbnMgdXNp bmcgZGlmZmVyZW50IHRpbWVyIGdyYW51bGFyaXR5IHNlZW1zIGxpa2VseSB0byBtYWtlIGFueSBw cm9ibGVtcyB3b3JzZSBhcyB5b3UgaGF2ZSBub3cgaW5jcmVhc2VkIHRoZSBudW1iZXIgb2YgQkZE IHNlc3Npb25zIHdpdGggdGhlIGFzc29jaWF0ZWQgY29zdHMuDQoNCiAgIExlcw0KDQo+IEJ1dCBt b3ZpbmcgdG8gd2hhdCAqaXMqIHJhdGhlciB0aGFuIHdoYXQgc2hvdWxkIGJlLCBpZiB0aGVyZSBh cmUgdHdvDQo+IGRpZmZlcmVudCB0aW1pbmcgc2V0dXBzIGZvciB0aGUgc2FtZSBlbmRwb2ludDog SWYgeW91IGRlcHJvdmlzaW9uIHRoZSBtb3JlDQo+IGFnZ3Jlc3NpdmUgdGltZXIsIHRoZSBzZXNz aW9uIHNob3VsZCBsaWtlbHkgcmVuZWdvdGlhdGUgdG8gdGhlIGxlc3MgYWdncmVzc2l2ZQ0KPiBv bmUgcmF0aGVyIHRoYW4gZHJvcC4NCj4gDQo+IC0tIEplZmYNCg0K From nobody Tue Jun 20 07:50:16 2017 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 707421270B4; Tue, 20 Jun 2017 07:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cFNL6Hm9sqL; Tue, 20 Jun 2017 07:50:05 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A5EF612F9A8; Tue, 20 Jun 2017 07:50:05 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 4E5031E37E; Tue, 20 Jun 2017 10:58:56 -0400 (EDT) Date: Tue, 20 Jun 2017 10:58:56 -0400 From: Jeffrey Haas To: "Les Ginsberg (ginsberg)" Cc: Mahesh Jethanandani , Jeffrey Haas , "Reshad Rahman (rrahman)" , OSPF WG List , "draft-ietf-ospf-yang@ietf.org" , "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" , "Acee Lindem (acee)" Subject: Re: IETF OSPF YANG and BFD Configuration Message-ID: <20170620145856.GC22550@pfrc.org> References: <38DEB571-2918-4464-B18A-71B24221772F@gmail.com> <47325462-2430-4197-AA8D-D3FEF74A834D@gmail.com> <20170619185715.GB22146@pfrc.org> <0578CD07-8678-4FF2-939F-0EF6F68CE34A@gmail.com> <20170620141639.GA22550@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 14:50:07 -0000 Les, On Tue, Jun 20, 2017 at 02:25:12PM +0000, Les Ginsberg (ginsberg) wrote: > > Different protocols have different survivability requirements. An IGP may > > very well want sub-second timers, potentially for repair behaviors. BGP may > > want fast failover, but may be fine with second level granularity. This is > > particularly true since the cost of too aggressively flapping BGP is of > > significantly greater impact to the network and the router. > > > [Les:] The real issues here are false failures and proper use of dampening. No protocol - not even an IGP - wants to flap unnecessarily. If timers are set so aggressively that false failures are reported this is BAD. > Even worse is failure to dampen so that we get multiple false failures in a short period of time. > > Arguing that the right way to solve this problem is to increase the number of sessions using different timer granularity seems likely to make any problems worse as you have now increased the number of BFD sessions with the associated costs. I'm mildly amused you seem to think I'm not considering the cost of additional sessions in the scaling matrix. :-) I do think you're conflating the survivability requirements vs. timer granularity. However, I agree that the most commonly deployed form is to go for single session with the most stable aggressive timer. Again, the reason I raise this is there has been discussion regarding behavior for different client timing requirements. There are a few options for how this is likely to play out in terms of BFD protocol implementation. However, configuration and operational models tend to evolve much more slowly. (And I certainly don't need to tell you that.) Thus, I'm prodding at this space a bit to attempt to do some future proofing. As we noted earlier in thread, this likely at least encourages configuration to be multi-instanced, even if the session instantiation is not currently. Key changes aren't something we can readily do, so getting that part right early is necessary. The likely impact on current IGP module BFD configuration may be a later augmentation. Thus, as long as the likely implications are understood, there may be no further action needed at this time. Determining that is partially what this thread is attempting to shake out. -- Jeff From nobody Tue Jun 20 08:44:59 2017 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 D746B131BB6; Tue, 20 Jun 2017 08:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OVdT6y4HtVt; Tue, 20 Jun 2017 08:44:49 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87AD9131A74; Tue, 20 Jun 2017 08:40:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3762; q=dns/txt; s=iport; t=1497973236; x=1499182836; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=57ZayF0pdhGiZIL1XAt897Hcf97LXUJk4ZAq8uWRZjY=; b=HeOdEPUhvHW0bpgQCEDyZJ9dVICXKcxPJs+P2BhUibZX6h0UZAQhnTAy ZtqgElmVmWMM0e+/Gt+CmiWV6xdjVwJg0LkQ3hfz0MXCAkkPJIwzgrX5T xO2zzg0q2VOSkw4CwtnOG0qytzCPM+na7vdxMrtsIwnJXVrKXxUW7yrqr o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgCqQUlZ/5BdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1iBbweDZJwYmAmGJAIagkpCFQECAQEBAQEBAWsohRkBBSMREzI?= =?us-ascii?q?QAgEIDgoCAiYCAgIwFRACBAENBYosrAKCJoM+iBwBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEdgQuKZYRpgxKCYQEEnmECk2CSDpUMATUigQp0FYdXAXaITIENAQEB?= X-IronPort-AV: E=Sophos;i="5.39,364,1493683200"; d="scan'208";a="441055692" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jun 2017 15:40:29 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v5KFeTWl025689 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 20 Jun 2017 15:40:29 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 20 Jun 2017 11:40:28 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Tue, 20 Jun 2017 11:40:28 -0400 From: "Acee Lindem (acee)" To: Jeffrey Haas , "Les Ginsberg (ginsberg)" CC: Mahesh Jethanandani , Jeffrey Haas , "Reshad Rahman (rrahman)" , "OSPF WG List" , "draft-ietf-ospf-yang@ietf.org" , "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" Subject: Re: IETF OSPF YANG and BFD Configuration Thread-Topic: IETF OSPF YANG and BFD Configuration Thread-Index: AQHS6Syo68r6z3GylU2z1PR9VYBctaItArCAgAENr4CAAAJjAIAACW0A///IiAA= Date: Tue, 20 Jun 2017 15:40:28 +0000 Message-ID: References: <38DEB571-2918-4464-B18A-71B24221772F@gmail.com> <47325462-2430-4197-AA8D-D3FEF74A834D@gmail.com> <20170619185715.GB22146@pfrc.org> <0578CD07-8678-4FF2-939F-0EF6F68CE34A@gmail.com> <20170620141639.GA22550@pfrc.org> <20170620145856.GC22550@pfrc.org> In-Reply-To: <20170620145856.GC22550@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="utf-8" Content-ID: <3AFF546F4CA311429CCBEC7C6E4312F0@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 15:44:51 -0000 SGkgSmVmZiwgDQoNCk9uIDYvMjAvMTcsIDEwOjU4IEFNLCAiSmVmZnJleSBIYWFzIiA8amhhYXNA cGZyYy5vcmc+IHdyb3RlOg0KDQo+TGVzLA0KPg0KPk9uIFR1ZSwgSnVuIDIwLCAyMDE3IGF0IDAy OjI1OjEyUE0gKzAwMDAsIExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpIHdyb3RlOg0KPj4gPiBEaWZm ZXJlbnQgcHJvdG9jb2xzIGhhdmUgZGlmZmVyZW50IHN1cnZpdmFiaWxpdHkgcmVxdWlyZW1lbnRz LiAgQW4NCj4+SUdQIG1heQ0KPj4gPiB2ZXJ5IHdlbGwgd2FudCBzdWItc2Vjb25kIHRpbWVycywg cG90ZW50aWFsbHkgZm9yIHJlcGFpciBiZWhhdmlvcnMuDQo+PkJHUCBtYXkNCj4+ID4gd2FudCBm YXN0IGZhaWxvdmVyLCBidXQgbWF5IGJlIGZpbmUgd2l0aCBzZWNvbmQgbGV2ZWwgZ3JhbnVsYXJp dHkuDQo+PlRoaXMgaXMNCj4+ID4gcGFydGljdWxhcmx5IHRydWUgc2luY2UgdGhlIGNvc3Qgb2Yg dG9vIGFnZ3Jlc3NpdmVseSBmbGFwcGluZyBCR1AgaXMNCj4+b2YNCj4+ID4gc2lnbmlmaWNhbnRs eSBncmVhdGVyIGltcGFjdCB0byB0aGUgbmV0d29yayBhbmQgdGhlIHJvdXRlci4NCj4+ID4gDQo+ PiBbTGVzOl0gVGhlIHJlYWwgaXNzdWVzIGhlcmUgYXJlIGZhbHNlIGZhaWx1cmVzIGFuZCBwcm9w ZXIgdXNlIG9mDQo+PmRhbXBlbmluZy4gTm8gcHJvdG9jb2wgLSBub3QgZXZlbiBhbiBJR1AgLSB3 YW50cyB0byBmbGFwIHVubmVjZXNzYXJpbHkuDQo+PklmIHRpbWVycyBhcmUgc2V0IHNvIGFnZ3Jl c3NpdmVseSB0aGF0IGZhbHNlIGZhaWx1cmVzIGFyZSByZXBvcnRlZCB0aGlzDQo+PmlzIEJBRC4N Cj4+IEV2ZW4gd29yc2UgaXMgZmFpbHVyZSB0byBkYW1wZW4gc28gdGhhdCB3ZSBnZXQgbXVsdGlw bGUgZmFsc2UgZmFpbHVyZXMNCj4+aW4gYSBzaG9ydCBwZXJpb2Qgb2YgdGltZS4NCj4+IA0KPj4g QXJndWluZyB0aGF0IHRoZSByaWdodCB3YXkgdG8gc29sdmUgdGhpcyBwcm9ibGVtIGlzIHRvIGlu Y3JlYXNlIHRoZQ0KPj5udW1iZXIgb2Ygc2Vzc2lvbnMgdXNpbmcgZGlmZmVyZW50IHRpbWVyIGdy YW51bGFyaXR5IHNlZW1zIGxpa2VseSB0bw0KPj5tYWtlIGFueSBwcm9ibGVtcyB3b3JzZSBhcyB5 b3UgaGF2ZSBub3cgaW5jcmVhc2VkIHRoZSBudW1iZXIgb2YgQkZEDQo+PnNlc3Npb25zIHdpdGgg dGhlIGFzc29jaWF0ZWQgY29zdHMuDQo+DQo+SSdtIG1pbGRseSBhbXVzZWQgeW91IHNlZW0gdG8g dGhpbmsgSSdtIG5vdCBjb25zaWRlcmluZyB0aGUgY29zdCBvZg0KPmFkZGl0aW9uYWwgc2Vzc2lv bnMgaW4gdGhlIHNjYWxpbmcgbWF0cml4LiA6LSkNCj4NCj5JIGRvIHRoaW5rIHlvdSdyZSBjb25m bGF0aW5nIHRoZSBzdXJ2aXZhYmlsaXR5IHJlcXVpcmVtZW50cyB2cy4gdGltZXINCj5ncmFudWxh cml0eS4gIEhvd2V2ZXIsIEkgYWdyZWUgdGhhdCB0aGUgbW9zdCBjb21tb25seSBkZXBsb3llZCBm b3JtIGlzIHRvDQo+Z28NCj5mb3Igc2luZ2xlIHNlc3Npb24gd2l0aCB0aGUgbW9zdCBzdGFibGUg YWdncmVzc2l2ZSB0aW1lci4NCj4NCj5BZ2FpbiwgdGhlIHJlYXNvbiBJIHJhaXNlIHRoaXMgaXMg dGhlcmUgaGFzIGJlZW4gZGlzY3Vzc2lvbiByZWdhcmRpbmcNCj5iZWhhdmlvciBmb3IgZGlmZmVy ZW50IGNsaWVudCB0aW1pbmcgcmVxdWlyZW1lbnRzLiAgVGhlcmUgYXJlIGEgZmV3DQo+b3B0aW9u cw0KPmZvciBob3cgdGhpcyBpcyBsaWtlbHkgdG8gcGxheSBvdXQgaW4gdGVybXMgb2YgQkZEIHBy b3RvY29sDQo+aW1wbGVtZW50YXRpb24uDQo+SG93ZXZlciwgY29uZmlndXJhdGlvbiBhbmQgb3Bl cmF0aW9uYWwgbW9kZWxzIHRlbmQgdG8gZXZvbHZlIG11Y2ggbW9yZQ0KPnNsb3dseS4gIChBbmQg SSBjZXJ0YWlubHkgZG9uJ3QgbmVlZCB0byB0ZWxsIHlvdSB0aGF0LikgIFRodXMsIEknbQ0KPnBy b2RkaW5nDQo+YXQgdGhpcyBzcGFjZSBhIGJpdCB0byBhdHRlbXB0IHRvIGRvIHNvbWUgZnV0dXJl IHByb29maW5nLg0KPg0KPkFzIHdlIG5vdGVkIGVhcmxpZXIgaW4gdGhyZWFkLCB0aGlzIGxpa2Vs eSBhdCBsZWFzdCBlbmNvdXJhZ2VzDQo+Y29uZmlndXJhdGlvbg0KPnRvIGJlIG11bHRpLWluc3Rh bmNlZCwgZXZlbiBpZiB0aGUgc2Vzc2lvbiBpbnN0YW50aWF0aW9uIGlzIG5vdCBjdXJyZW50bHku DQo+S2V5IGNoYW5nZXMgYXJlbid0IHNvbWV0aGluZyB3ZSBjYW4gcmVhZGlseSBkbywgc28gZ2V0 dGluZyB0aGF0IHBhcnQgcmlnaHQNCj5lYXJseSBpcyBuZWNlc3NhcnkuDQo+DQo+VGhlIGxpa2Vs eSBpbXBhY3Qgb24gY3VycmVudCBJR1AgbW9kdWxlIEJGRCBjb25maWd1cmF0aW9uIG1heSBiZSBh IGxhdGVyDQo+YXVnbWVudGF0aW9uLiAgVGh1cywgYXMgbG9uZyBhcyB0aGUgbGlrZWx5IGltcGxp Y2F0aW9ucyBhcmUgdW5kZXJzdG9vZCwNCj50aGVyZSBtYXkgYmUgbm8gZnVydGhlciBhY3Rpb24g bmVlZGVkIGF0IHRoaXMgdGltZS4gIERldGVybWluaW5nIHRoYXQgaXMNCj5wYXJ0aWFsbHkgd2hh dCB0aGlzIHRocmVhZCBpcyBhdHRlbXB0aW5nIHRvIHNoYWtlIG91dC4NCg0KSW4gdGhlIElHUHMs IHdlIGhhdmUgYSBzZXBhcmF0ZSBCRkQgY29udGFpbmVyIGluIHRoZSBpbnRlcmZhY2UNCmNvbmZp Z3VyYXRpb24uIEN1cnJlbnRseSwgaXQgb25seSBjb250YWlucyB0aGUgYSBib29sZWFuLiBUaGlz IGNvdWxkDQplYXNpbHkgYmUgYXVnbWVudGVkIHRvIHJlZmVyZW5jZSB0aGUgYXBwcm9wcmlhdGUg Y29uc3RydWN0IGluIHRoZSBCRkQNCm1vZGVsLiANCg0KVGhhbmtzLA0KQWNlZSANCg0KDQo+DQo+ LS0gSmVmZg0KDQo= From nobody Tue Jun 20 10:50:48 2017 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 DA39B124BFA; Tue, 20 Jun 2017 10:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQ6JkXv70tsv; Tue, 20 Jun 2017 10:50:37 -0700 (PDT) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03935129496; Tue, 20 Jun 2017 10:50:18 -0700 (PDT) Received: by mail-pf0-x244.google.com with SMTP id s66so24827148pfs.2; Tue, 20 Jun 2017 10:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fvqjaSf0CDg1k1IH/2A7d2bNHAbmkf7gucUMy4lAVjE=; b=DyMRhNWCQoRjnJXOu0E97jmJ/ZoRp8qSQlOQLVM73LJMDy7zOgfCTQrdtXluKdwf1b x6IPo1UXUWfI9zTMAoJRk2APjGJRU/rGUXnBjYrQr3gZXrh3bpde+qOY4yHAsCfmhexJ uPxlwSRzNC8IYCpAWL+g8264i2I4QoGV8dS/U8vB9WWc99GfLK62UZo3XrfkhWYzrGwm Gdratc50gjUf4WpWq0a4Z74buq7B13ft5miCFwENoTKO3E/sf8QXvHIdPlx5aZClmOHX c4CPpme2pWbX+cphSGeXfzuyIC9jkw3hjRrtQa9XgMjTaDPaZHmXDPzlJ8l4hiLKAKk3 jlEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fvqjaSf0CDg1k1IH/2A7d2bNHAbmkf7gucUMy4lAVjE=; b=eBka5+tDA98sl7ec+7IHsxBcFFKRuohE20I10L4GG9ZowqCewqaX4u3k4RiYEyYL/F 8VFjELU4+tz4QvNB+BFNgIEobpB4xip/UnWY3OzGxwIVjaEcRoalfbLz7PSsaAiChGic 1Vbb2CyjOVDR8znqIAssVy1NNt58KkFHWqaXgaomgGYW1igwaT1LxJiTvO0+rRNQeAo9 KvxLsu1fVfftHeFlgVr6TuiI1+zeQMWTcfGqpcf4/Q/Ok7pzzVXv/4tLhyflvWrI+FOt /4mbras8XN/t5yt9YnKAzGHsYU6reHm45ZlgWab0EsUj1HnytzJMoGy4ZeUbSTB8G15I Hc7Q== X-Gm-Message-State: AKS2vOwvyq78qGUKslH/R61+yp4B/ZDHTmpf4eeWxh7dXEiufoU4LMm/ 3pAp943awaxI6Q== X-Received: by 10.101.89.2 with SMTP id f2mr32956081pgu.237.1497981017501; Tue, 20 Jun 2017 10:50:17 -0700 (PDT) Received: from sjc-mahesh-nitro7.cisco.com ([128.107.241.181]) by smtp.gmail.com with ESMTPSA id n26sm30487445pfj.114.2017.06.20.10.50.16 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 20 Jun 2017 10:50:16 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: IETF OSPF YANG and BFD Configuration From: Mahesh Jethanandani In-Reply-To: Date: Tue, 20 Jun 2017 10:50:15 -0700 Cc: Jeffrey Haas , "Les Ginsberg (ginsberg)" , Jeffrey Haas , "Reshad Rahman (rrahman)" , OSPF WG List , "draft-ietf-ospf-yang@ietf.org" , "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <93CD6650-AE40-4CD2-AE3F-F3FD0B287CD4@gmail.com> References: <38DEB571-2918-4464-B18A-71B24221772F@gmail.com> <47325462-2430-4197-AA8D-D3FEF74A834D@gmail.com> <20170619185715.GB22146@pfrc.org> <0578CD07-8678-4FF2-939F-0EF6F68CE34A@gmail.com> <20170620141639.GA22550@pfrc.org> <20170620145856.GC22550@pfrc.org> To: "Acee Lindem (acee)" X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 17:50:40 -0000 > On Jun 20, 2017, at 8:40 AM, Acee Lindem (acee) = wrote: >=20 > Hi Jeff,=20 >=20 > On 6/20/17, 10:58 AM, "Jeffrey Haas" wrote: >=20 >> Les, >>=20 >> On Tue, Jun 20, 2017 at 02:25:12PM +0000, Les Ginsberg (ginsberg) = wrote: >>>> Different protocols have different survivability requirements. An >>> IGP may >>>> very well want sub-second timers, potentially for repair behaviors. >>> BGP may >>>> want fast failover, but may be fine with second level granularity. >>> This is >>>> particularly true since the cost of too aggressively flapping BGP = is >>> of >>>> significantly greater impact to the network and the router. >>>>=20 >>> [Les:] The real issues here are false failures and proper use of >>> dampening. No protocol - not even an IGP - wants to flap = unnecessarily. >>> If timers are set so aggressively that false failures are reported = this >>> is BAD. >>> Even worse is failure to dampen so that we get multiple false = failures >>> in a short period of time. >>>=20 >>> Arguing that the right way to solve this problem is to increase the >>> number of sessions using different timer granularity seems likely to >>> make any problems worse as you have now increased the number of BFD >>> sessions with the associated costs. >>=20 >> I'm mildly amused you seem to think I'm not considering the cost of >> additional sessions in the scaling matrix. :-) >>=20 >> I do think you're conflating the survivability requirements vs. timer >> granularity. However, I agree that the most commonly deployed form = is to >> go >> for single session with the most stable aggressive timer. >>=20 >> Again, the reason I raise this is there has been discussion regarding >> behavior for different client timing requirements. There are a few >> options >> for how this is likely to play out in terms of BFD protocol >> implementation. >> However, configuration and operational models tend to evolve much = more >> slowly. (And I certainly don't need to tell you that.) Thus, I'm >> prodding >> at this space a bit to attempt to do some future proofing. >>=20 >> As we noted earlier in thread, this likely at least encourages >> configuration >> to be multi-instanced, even if the session instantiation is not = currently. >> Key changes aren't something we can readily do, so getting that part = right >> early is necessary. >>=20 >> The likely impact on current IGP module BFD configuration may be a = later >> augmentation. Thus, as long as the likely implications are = understood, >> there may be no further action needed at this time. Determining that = is >> partially what this thread is attempting to shake out. >=20 > In the IGPs, we have a separate BFD container in the interface > configuration. Currently, it only contains the a boolean. This could > easily be augmented to reference the appropriate construct in the BFD > model.=20 Let me work with Reshad to suggest what IGP could suggest to BFD in = their construct, and have BFP pick what it believes would be the right = set of parameters to be able to support most of the IGPs over the given = BFD session. Whether we add it in the current model or add it later as = an augmentation could then be decided separately. >=20 > Thanks, > Acee=20 >=20 >=20 >>=20 >> -- Jeff >=20 Mahesh Jethanandani mjethanandani@gmail.com From nobody Tue Jun 20 10:56:13 2017 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 75F58129484; Tue, 20 Jun 2017 10:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0S626UVNUs-6; Tue, 20 Jun 2017 10:56:00 -0700 (PDT) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6B37131596; Tue, 20 Jun 2017 10:55:59 -0700 (PDT) Received: by mail-ot0-x22e.google.com with SMTP id s7so95520212otb.3; Tue, 20 Jun 2017 10:55:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BENHcUVlEoXJg1Erg+OcNgztKg0R+1/VcaUBHrkPvys=; b=IwzS85eGF7Pig0Xs2Al6ESdSep2G6ERUUwUyV8QpR1Cw+wJO9dFstaTbTnjM+XiAxk HTy1XBOUfjvTGfVwvjD9L+BDXS2Tnq3FWvB+NIxxpFUjhhxC+7nq0zK9qs0sC5+FfM5F /uIsFcLqcWaQzG4BytL7vhfvVcA/z2ejVShZtTdLPDp0uRcJwFhroXwgZLCG77Kr9MJt DLfUt0WhPRZSpK3aLznFIPhsXsDMUM3s+Q08j8lX/eSMcVAxf8akqtOL37XTihayEqwI 7oPz7g2m/Pxi7MO3TpkHw7e1w6b+hfEB+iElzABZrSV0fiH9WFCEZq4yGKFamD9v/FY1 F8PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BENHcUVlEoXJg1Erg+OcNgztKg0R+1/VcaUBHrkPvys=; b=YbAZysMXEwrN1ApDw9N+4SBhrtPiHd0/os1VlsPQ1X7jtkVC27BSY/BdY31NMxKlu6 G+Zf07y//XK5CpO1W4knQg2WIIyvRI5sJEV7CksuUKxmty7hfKgZi7qCnm+V1h1XMWjQ CL98v5+OWYbSS65KSslsVhnTjtXrUzUS6ZUXylZx3NuqmNnyCGEwi2KS7DXRRICwM80w Ztq3yl8c9PBmPITEZoZgKZcxayl2IjpZI1hnQZ+yzGnQf5V2+mfCPqsibxz5dpMnY+zH bFnCPGe7kAEg6OxSJxwtxJapuNa4WSbk/miNUw6dSQAVZfPfl46Et5quEr8OTfGi96dr NExQ== X-Gm-Message-State: AKS2vOwFj0znWv6Xrg83GgIvSbj2f/6XS+JEsgW/lT7q8xHmO2w2MiPr SfSNpo9gEJiPoxDJKxNBYcBUpUdgVQ== X-Received: by 10.157.22.205 with SMTP id s13mr1215827ots.240.1497981359270; Tue, 20 Jun 2017 10:55:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.171 with HTTP; Tue, 20 Jun 2017 10:55:58 -0700 (PDT) In-Reply-To: <20170619185715.GB22146@pfrc.org> References: <38DEB571-2918-4464-B18A-71B24221772F@gmail.com> <47325462-2430-4197-AA8D-D3FEF74A834D@gmail.com> <20170619185715.GB22146@pfrc.org> From: Greg Mirsky Date: Tue, 20 Jun 2017 12:55:58 -0500 Message-ID: Subject: Re: IETF OSPF YANG and BFD Configuration To: Jeffrey Haas Cc: "Reshad Rahman (rrahman)" , Mahesh Jethanandani , "Acee Lindem (acee)" , Jeffrey Haas , OSPF WG List , "rtg-bfd@ietf. org" , "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Content-Type: multipart/alternative; boundary="001a1141cae8ccb407055267f65b" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 17:56:04 -0000 --001a1141cae8ccb407055267f65b Content-Type: text/plain; charset="UTF-8" Hi Jeff, I'd like to hear from others who are familiar with implementations of BFD that supports per protocol single-hop BFD multi-sessions between the same pair of BFD systems. RFC 5881 does allow per protocol single-hop sessions on the same interface, logical or physical, between the same pair of systems. But it is not clear, in my opinion, how BFD does demultiplexing if Your Discriminator == 0 per protocol (RFC 5881, section 3, last sentence) if systems use the same IP addresses. And hence the question, Even though it is allowed to have BFD single-hop sessions per application/protocol on the same interface between the same pair of systems, is this real, practical requirement? Or am I missing the point completely? Regards, Greg On Mon, Jun 19, 2017 at 1:57 PM, Jeffrey Haas wrote: > [Long delayed response.] > > Reshad picked up the key points: Some things may make sense in the > per-client (protocol) users of BFD, some things perhaps do not. And some > come down to questions for timer granularity. > > The OSPF and ISIS models both make use of BFD simply by providing a boolean > that says "I'm using BFD or not". > > Where we run into some issues are the cases highlighted: when the sessions > don't share common properties, how should the protocol pick what BFD > session > to use? > > The current BFD yang model only permits a single IP single-hop session > to be configured. (Key is interface/dst-ip) This means that if different > parameters *were* desired, the BFD model won't permit it today. However, > BFD sessions for many protocols tend not to be configured, but may spring > forth from protocol state, such as IGP adjacencies. Thus, it's not > "configured" - it's solely operational state. However, the BFD yang model > doesn't really make good provision for that as an "on". > > Where all endpoint state is known a priori, config state makes better > sense. > > To pick the example of Juniper's configuration, if OSPF and eBGP were using > BFD, both can choose differing timers. This represents two pieces of > configuration state for the same endpoints. Additionally, only one BFD > session is formed using the most aggressive timers. > > I partially point out the situation of multiple timers since there have > been > prior list discussions on the situation where clients have different timing > requirements. I don't think we handle this operationally in the BFD > protocol in the cleanest fashion right now - the session will go to Down > when the aggressive timers fail and there's no clean way to renegotiate to > the less aggressive timers. > > -- Jeff > > > > > > > On Fri, May 19, 2017 at 02:31:38AM +0000, Reshad Rahman (rrahman) wrote: > > We started off with the intent of having BFD parameters in the > applications/protocols which make use of BFD. For timer/multiplier this is > pretty straight-forward, although the discussion of what to do when not all > applications have the same BFD parameters for the same session (e.g. Go > with most aggressive etc). Then we started looking at authentication > parameters and having BFD authentication parms in OSPF/ISIS etc is not > intuitive. And what do we do if applications have different BFD > authentication parms. We concluded that the BFD authentication parms were > better off in BFD. And once we did that, the timer/multiplier followed.... > > > > I may not recall all the details/discussons, but I do recall that we > went back and forth on this and it took some time to make the decision. > > > > Regards, > > Reshad (as individual contributor). > > > > From: Mahesh Jethanandani mjethanandani@gmail.com>> > > Date: Thursday, May 18, 2017 at 5:34 PM > > To: "Acee Lindem (acee)" > > > Cc: Jeffrey Haas >, OSPF WG > List >, "draft-ietf-bfd-yang@ietf.org< > mailto:draft-ietf-bfd-yang@ietf.org>" mailto:draft-ietf-bfd-yang@ietf.org>>, "draft-ietf-ospf-yang@ietf.org > " >, "rtg-bfd@ietf.org bfd@ietf.org>" > > > Subject: Re: IETF OSPF YANG and BFD Configuration > > Resent-From: > > > Resent-To: >, > Reshad >, < > mjethanandani@gmail.com>, < > santosh.pallagatti@gmail.com>, < > gregimirsky@gmail.com> > > Resent-Date: Thursday, May 18, 2017 at 5:40 PM > > > > Resending with correct BFD WG address. > > > > On May 18, 2017, at 2:33 PM, Mahesh Jethanandani < > mjethanandani@gmail.com> wrote: > > > > Agree with Acee's assessment. After much debate, we decided that we > should leave BFD parameter configuration in the BFD model itself, and have > any IGP protocol reference the BFD instance in BFD itself. This makes sense > specially if multiple protocols fate-share the BFD session. > > > > Cheers. > > > > On May 18, 2017, at 12:27 PM, Acee Lindem (acee) acee@cisco.com>> wrote: > > > > Hi Jeff, > > > > At the OSPF WG Meeting in Chicago, you suggested that we may want to > provide configuration of BFD parameters within the OSPF model > (ietf-ospf.yang). We originally did have this configuration. However, after > much discussion and coordination with the BFD YANG design team, we agreed > to leave the BFD session parameters in BFD and only enable BFD within the > OSPF and IS-IS models. > > > > We did discuss the fact that vendors (notably Cisco IOS-XR and Juniper > JUNOS) do allow configuration within the IGPs. However, the consensus was > to leave the BFD configuration in the BFD model. The heuristics to > determine what parameters to use when the same BFD endpoint was configured > with different parameters in different protocols were proprietary and > somewhat of a hack. > > > > I may have not remembered all the details so I'd encourage others to > chime in. > > > > Thanks, > > Acee > > > > Mahesh Jethanandani > > mjethanandani@gmail.com > > > > > > > > > > Mahesh Jethanandani > > mjethanandani@gmail.com > > > > > > > --001a1141cae8ccb407055267f65b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeff,
I'd like to hear from others who are fami= liar with implementations of BFD that supports per protocol single-hop BFD = multi-sessions between the same pair of BFD systems. RFC 5881 does allow pe= r protocol single-hop sessions on the same interface, logical or physical, = between the same pair of systems. But it is not clear, in my opinion, how B= FD does demultiplexing if Your Discriminator =3D=3D 0 per protocol (RFC 588= 1, section 3, last sentence) if systems use the same IP addresses. And henc= e the question, Even though it is allowed to have BFD single-hop sessions p= er application/protocol on the same interface between the same pair of syst= ems, is this real, practical requirement?
Or am I missing the poi= nt completely?

Regards,
Greg
=

On Mon, Jun 19, 2= 017 at 1:57 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:
[Long delayed response.]

Reshad picked up the key points: Some things may make sense in the
per-client (protocol) users of BFD, some things perhaps do not.=C2=A0 And s= ome
come down to questions for timer granularity.

The OSPF and ISIS models both make use of BFD simply by providing a boolean=
that says "I'm using BFD or not".

Where we run into some issues are the cases highlighted: when the sessions<= br> don't share common properties, how should the protocol pick what BFD se= ssion
to use?

The current BFD yang model only permits a single IP single-hop session
to be configured.=C2=A0 (Key is interface/dst-ip)=C2=A0 This means that if = different
parameters *were* desired, the BFD model won't permit it today.=C2=A0 H= owever,
BFD sessions for many protocols tend not to be configured, but may spring forth from protocol state, such as IGP adjacencies.=C2=A0 Thus, it's no= t
"configured" - it's solely operational state.=C2=A0 However, = the BFD yang model
doesn't really make good provision for that as an "on".

Where all endpoint state is known a priori, config state makes better sense= .

To pick the example of Juniper's configuration, if OSPF and eBGP were u= sing
BFD, both can choose differing timers.=C2=A0 This represents two pieces of<= br> configuration state for the same endpoints.=C2=A0 Additionally, only one BF= D
session is formed using the most aggressive timers.

I partially point out the situation of multiple timers since there have bee= n
prior list discussions on the situation where clients have different timing=
requirements.=C2=A0 I don't think we handle this operationally in the B= FD
protocol in the cleanest fashion right now - the session will go to Down when the aggressive timers fail and there's no clean way to renegotiate= to
the less aggressive timers.

-- Jeff






On Fri, May 19, 2017 at 02:31:38AM +0000, Reshad Rahman (rrahman) wrote: > We started off with the intent of having BFD parameters in the applica= tions/protocols which make use of BFD. For timer/multiplier this is pretty = straight-forward, although the discussion of what to do when not all applic= ations have the same BFD parameters for the same session (e.g. Go with most= aggressive etc). Then we started looking at authentication parameters and = having BFD authentication parms in OSPF/ISIS etc is not intuitive. And what= do we do if applications have different BFD authentication parms. We concl= uded that the BFD authentication parms were better off in BFD. And once we = did that, the timer/multiplier followed....
>
> I may not recall all the details/discussons, but I do recall that we w= ent back and forth on this and it took some time to make the decision.
>
> Regards,
> Reshad (as individual contributor).
>
> From: Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>>
> Date: Thursday, May 18, 2017 at 5:34 PM
> To: "Acee Lindem (acee)" <acee@cisco.com<mailto:acee@cisco.com>>
> Cc: Jeffrey Haas <jhaas@junipe= r.net<mailto:jhaas@juniper= .net>>, OSPF WG List <ospf@ie= tf.org<mailto:ospf@ietf.org>>, "draft-ietf= -bfd-yang@ietf.org<mailto:draft-ietf-bfd-yang@ietf.org>" <draft-ietf-bfd-yang@ietf.org<mailto:draft-ietf-bfd-yan= g@ietf.org>>, "draft-ietf-ospf-yang@ietf.org<mailto:draft-ietf-ospf-yang@ietf.org>&= quot; <draft-ietf-ospf-= yang@ietf.org<mailto:draft-ietf-ospf-yang@ietf.org>>, "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>
> Subject: Re: IETF OSPF YANG and BFD Configuration
> Resent-From: <alias-bounc= es@ietf.org<mailto:al= ias-bounces@ietf.org>>
> Resent-To: <vero.zheng@hua= wei.com<mailto:vero.zh= eng@huawei.com>>, Reshad <rrahman@cisco.com<mailto:rrah<= wbr>man@cisco.com>>, <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>>, <santosh.pallagatti@gmail.com<m= ailto:santosh.pallagatti@gmail.com>>, <greg= imirsky@gmail.com<mailto:gregimirsky@gmail.com>>
> Resent-Date: Thursday, May 18, 2017 at 5:40 PM
>
> Resending with correct BFD WG address.
>
> On May 18, 2017, at 2:33 PM, Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>&g= t; wrote:
>
> Agree with Acee's assessment. After much debate, we decided that w= e should leave BFD parameter configuration in the BFD model itself, and hav= e any IGP protocol reference the BFD instance in BFD itself. This makes sen= se specially if multiple protocols fate-share the BFD session.
>
> Cheers.
>
> On May 18, 2017, at 12:27 PM, Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com>> wrote:
>
> Hi Jeff,
>
> At the OSPF WG Meeting in Chicago, you suggested that we may want to p= rovide configuration of BFD parameters within the OSPF model (ietf-ospf.yan= g). We originally did have this configuration. However, after much discussi= on and coordination with the BFD YANG design team, we agreed to leave the B= FD session parameters in BFD and only enable BFD within the OSPF and IS-IS = models.
>
> We did discuss the fact that vendors = (notably Cisco IOS-XR and Juniper JUNOS) do allow configuration within the = IGPs. However, the consensus was to leave the BFD configuration in the BFD = model. The heuristics to determine what parameters to use when the same BFD= endpoint was configured with different parameters in different protocols w= ere proprietary and somewhat of a hack.
>
> I may have not remembered all the details so I'd encourage others = to chime in.
>
> Thanks,
> Acee
>
> Mahesh Jethanandani
> mjethanandani@gmail.com= <mailto:mjethanandani@gm= ail.com>
>
>
>
>
> Mahesh Jethanandani
> mjethanandani@gmail.com= <mailto:mjethanandani@gm= ail.com>
>
>
>

--001a1141cae8ccb407055267f65b-- From nobody Tue Jun 20 11:04:12 2017 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 234E312948F; Tue, 20 Jun 2017 11:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZSjX7xti_PI; Tue, 20 Jun 2017 11:04:07 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FA1112946E; Tue, 20 Jun 2017 11:04:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5096; q=dns/txt; s=iport; t=1497981846; x=1499191446; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=arNTw0DULMgmUZ+JcHqZ9VWRJzXug9Wejq2S4TJRNRw=; b=fNswvNUfewye3R/K6LWfsgaeixxCql+2LUOv/ihQlxUX7vOZ4I5t3jtM 4mlsn60wXFIAAi+li6XHMEZls2fTZoq56ogb+idJv82wH7tYR0zCnE1/c fP1MPE7Z4/QXzRZcOkIORWOeBj5hiuvrvHnSjIzQUttOcpR/iezGYrr2i g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAgD8YklZ/4sNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1iBbweDZJwYiCyNTIIRhiQCGoJNQRYBAgEBAQEBAQFrKIUYAQE?= =?us-ascii?q?BAQIBIxETMhACAQgOCgICJgICAh8RFRACBA4FihQDDQisEYImgz6DeA2EFgEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBASCBC4plgleCEoMSgmEBBJ4mOwKOeYRnkg6LWokyASY?= =?us-ascii?q?CL4EKdBWHVwF2iEyBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.39,364,1493683200"; d="scan'208";a="442611311" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jun 2017 18:04:05 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v5KI45DJ009753 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 20 Jun 2017 18:04:05 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 20 Jun 2017 14:04:04 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Tue, 20 Jun 2017 14:04:04 -0400 From: "Acee Lindem (acee)" To: Mahesh Jethanandani CC: Jeffrey Haas , "Les Ginsberg (ginsberg)" , Jeffrey Haas , "Reshad Rahman (rrahman)" , OSPF WG List , "draft-ietf-ospf-yang@ietf.org" , "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" Subject: Re: IETF OSPF YANG and BFD Configuration Thread-Topic: IETF OSPF YANG and BFD Configuration Thread-Index: AQHS6Syo68r6z3GylU2z1PR9VYBctaItArCAgAENr4CAAAJjAIAACW0A///IiACAAGdVgP//wMUA Date: Tue, 20 Jun 2017 18:04:04 +0000 Message-ID: References: <38DEB571-2918-4464-B18A-71B24221772F@gmail.com> <47325462-2430-4197-AA8D-D3FEF74A834D@gmail.com> <20170619185715.GB22146@pfrc.org> <0578CD07-8678-4FF2-939F-0EF6F68CE34A@gmail.com> <20170620141639.GA22550@pfrc.org> <20170620145856.GC22550@pfrc.org> <93CD6650-AE40-4CD2-AE3F-F3FD0B287CD4@gmail.com> In-Reply-To: <93CD6650-AE40-4CD2-AE3F-F3FD0B287CD4@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="utf-8" Content-ID: <17B8D9BCFE0AF2479EA2FBA22BBB1CB9@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 18:04:10 -0000 DQoNCk9uIDYvMjAvMTcsIDE6NTAgUE0sICJNYWhlc2ggSmV0aGFuYW5kYW5pIiA8bWpldGhhbmFu ZGFuaUBnbWFpbC5jb20+IHdyb3RlOg0KDQo+DQo+PiBPbiBKdW4gMjAsIDIwMTcsIGF0IDg6NDAg QU0sIEFjZWUgTGluZGVtIChhY2VlKSA8YWNlZUBjaXNjby5jb20+IHdyb3RlOg0KPj4gDQo+PiBI aSBKZWZmLCANCj4+IA0KPj4gT24gNi8yMC8xNywgMTA6NTggQU0sICJKZWZmcmV5IEhhYXMiIDxq aGFhc0BwZnJjLm9yZz4gd3JvdGU6DQo+PiANCj4+PiBMZXMsDQo+Pj4gDQo+Pj4gT24gVHVlLCBK dW4gMjAsIDIwMTcgYXQgMDI6MjU6MTJQTSArMDAwMCwgTGVzIEdpbnNiZXJnIChnaW5zYmVyZykN Cj4+Pndyb3RlOg0KPj4+Pj4gRGlmZmVyZW50IHByb3RvY29scyBoYXZlIGRpZmZlcmVudCBzdXJ2 aXZhYmlsaXR5IHJlcXVpcmVtZW50cy4gIEFuDQo+Pj4+IElHUCBtYXkNCj4+Pj4+IHZlcnkgd2Vs bCB3YW50IHN1Yi1zZWNvbmQgdGltZXJzLCBwb3RlbnRpYWxseSBmb3IgcmVwYWlyIGJlaGF2aW9y cy4NCj4+Pj4gQkdQIG1heQ0KPj4+Pj4gd2FudCBmYXN0IGZhaWxvdmVyLCBidXQgbWF5IGJlIGZp bmUgd2l0aCBzZWNvbmQgbGV2ZWwgZ3JhbnVsYXJpdHkuDQo+Pj4+IFRoaXMgaXMNCj4+Pj4+IHBh cnRpY3VsYXJseSB0cnVlIHNpbmNlIHRoZSBjb3N0IG9mIHRvbyBhZ2dyZXNzaXZlbHkgZmxhcHBp bmcgQkdQIGlzDQo+Pj4+IG9mDQo+Pj4+PiBzaWduaWZpY2FudGx5IGdyZWF0ZXIgaW1wYWN0IHRv IHRoZSBuZXR3b3JrIGFuZCB0aGUgcm91dGVyLg0KPj4+Pj4gDQo+Pj4+IFtMZXM6XSBUaGUgcmVh bCBpc3N1ZXMgaGVyZSBhcmUgZmFsc2UgZmFpbHVyZXMgYW5kIHByb3BlciB1c2Ugb2YNCj4+Pj4g ZGFtcGVuaW5nLiBObyBwcm90b2NvbCAtIG5vdCBldmVuIGFuIElHUCAtIHdhbnRzIHRvIGZsYXAN Cj4+Pj51bm5lY2Vzc2FyaWx5Lg0KPj4+PiBJZiB0aW1lcnMgYXJlIHNldCBzbyBhZ2dyZXNzaXZl bHkgdGhhdCBmYWxzZSBmYWlsdXJlcyBhcmUgcmVwb3J0ZWQNCj4+Pj50aGlzDQo+Pj4+IGlzIEJB RC4NCj4+Pj4gRXZlbiB3b3JzZSBpcyBmYWlsdXJlIHRvIGRhbXBlbiBzbyB0aGF0IHdlIGdldCBt dWx0aXBsZSBmYWxzZSBmYWlsdXJlcw0KPj4+PiBpbiBhIHNob3J0IHBlcmlvZCBvZiB0aW1lLg0K Pj4+PiANCj4+Pj4gQXJndWluZyB0aGF0IHRoZSByaWdodCB3YXkgdG8gc29sdmUgdGhpcyBwcm9i bGVtIGlzIHRvIGluY3JlYXNlIHRoZQ0KPj4+PiBudW1iZXIgb2Ygc2Vzc2lvbnMgdXNpbmcgZGlm ZmVyZW50IHRpbWVyIGdyYW51bGFyaXR5IHNlZW1zIGxpa2VseSB0bw0KPj4+PiBtYWtlIGFueSBw cm9ibGVtcyB3b3JzZSBhcyB5b3UgaGF2ZSBub3cgaW5jcmVhc2VkIHRoZSBudW1iZXIgb2YgQkZE DQo+Pj4+IHNlc3Npb25zIHdpdGggdGhlIGFzc29jaWF0ZWQgY29zdHMuDQo+Pj4gDQo+Pj4gSSdt IG1pbGRseSBhbXVzZWQgeW91IHNlZW0gdG8gdGhpbmsgSSdtIG5vdCBjb25zaWRlcmluZyB0aGUg Y29zdCBvZg0KPj4+IGFkZGl0aW9uYWwgc2Vzc2lvbnMgaW4gdGhlIHNjYWxpbmcgbWF0cml4LiA6 LSkNCj4+PiANCj4+PiBJIGRvIHRoaW5rIHlvdSdyZSBjb25mbGF0aW5nIHRoZSBzdXJ2aXZhYmls aXR5IHJlcXVpcmVtZW50cyB2cy4gdGltZXINCj4+PiBncmFudWxhcml0eS4gIEhvd2V2ZXIsIEkg YWdyZWUgdGhhdCB0aGUgbW9zdCBjb21tb25seSBkZXBsb3llZCBmb3JtIGlzDQo+Pj50bw0KPj4+ IGdvDQo+Pj4gZm9yIHNpbmdsZSBzZXNzaW9uIHdpdGggdGhlIG1vc3Qgc3RhYmxlIGFnZ3Jlc3Np dmUgdGltZXIuDQo+Pj4gDQo+Pj4gQWdhaW4sIHRoZSByZWFzb24gSSByYWlzZSB0aGlzIGlzIHRo ZXJlIGhhcyBiZWVuIGRpc2N1c3Npb24gcmVnYXJkaW5nDQo+Pj4gYmVoYXZpb3IgZm9yIGRpZmZl cmVudCBjbGllbnQgdGltaW5nIHJlcXVpcmVtZW50cy4gIFRoZXJlIGFyZSBhIGZldw0KPj4+IG9w dGlvbnMNCj4+PiBmb3IgaG93IHRoaXMgaXMgbGlrZWx5IHRvIHBsYXkgb3V0IGluIHRlcm1zIG9m IEJGRCBwcm90b2NvbA0KPj4+IGltcGxlbWVudGF0aW9uLg0KPj4+IEhvd2V2ZXIsIGNvbmZpZ3Vy YXRpb24gYW5kIG9wZXJhdGlvbmFsIG1vZGVscyB0ZW5kIHRvIGV2b2x2ZSBtdWNoIG1vcmUNCj4+ PiBzbG93bHkuICAoQW5kIEkgY2VydGFpbmx5IGRvbid0IG5lZWQgdG8gdGVsbCB5b3UgdGhhdC4p ICBUaHVzLCBJJ20NCj4+PiBwcm9kZGluZw0KPj4+IGF0IHRoaXMgc3BhY2UgYSBiaXQgdG8gYXR0 ZW1wdCB0byBkbyBzb21lIGZ1dHVyZSBwcm9vZmluZy4NCj4+PiANCj4+PiBBcyB3ZSBub3RlZCBl YXJsaWVyIGluIHRocmVhZCwgdGhpcyBsaWtlbHkgYXQgbGVhc3QgZW5jb3VyYWdlcw0KPj4+IGNv bmZpZ3VyYXRpb24NCj4+PiB0byBiZSBtdWx0aS1pbnN0YW5jZWQsIGV2ZW4gaWYgdGhlIHNlc3Np b24gaW5zdGFudGlhdGlvbiBpcyBub3QNCj4+PmN1cnJlbnRseS4NCj4+PiBLZXkgY2hhbmdlcyBh cmVuJ3Qgc29tZXRoaW5nIHdlIGNhbiByZWFkaWx5IGRvLCBzbyBnZXR0aW5nIHRoYXQgcGFydA0K Pj4+cmlnaHQNCj4+PiBlYXJseSBpcyBuZWNlc3NhcnkuDQo+Pj4gDQo+Pj4gVGhlIGxpa2VseSBp bXBhY3Qgb24gY3VycmVudCBJR1AgbW9kdWxlIEJGRCBjb25maWd1cmF0aW9uIG1heSBiZSBhDQo+ Pj5sYXRlcg0KPj4+IGF1Z21lbnRhdGlvbi4gIFRodXMsIGFzIGxvbmcgYXMgdGhlIGxpa2VseSBp bXBsaWNhdGlvbnMgYXJlIHVuZGVyc3Rvb2QsDQo+Pj4gdGhlcmUgbWF5IGJlIG5vIGZ1cnRoZXIg YWN0aW9uIG5lZWRlZCBhdCB0aGlzIHRpbWUuICBEZXRlcm1pbmluZyB0aGF0DQo+Pj5pcw0KPj4+ IHBhcnRpYWxseSB3aGF0IHRoaXMgdGhyZWFkIGlzIGF0dGVtcHRpbmcgdG8gc2hha2Ugb3V0Lg0K Pj4gDQo+PiBJbiB0aGUgSUdQcywgd2UgaGF2ZSBhIHNlcGFyYXRlIEJGRCBjb250YWluZXIgaW4g dGhlIGludGVyZmFjZQ0KPj4gY29uZmlndXJhdGlvbi4gQ3VycmVudGx5LCBpdCBvbmx5IGNvbnRh aW5zIHRoZSBhIGJvb2xlYW4uIFRoaXMgY291bGQNCj4+IGVhc2lseSBiZSBhdWdtZW50ZWQgdG8g cmVmZXJlbmNlIHRoZSBhcHByb3ByaWF0ZSBjb25zdHJ1Y3QgaW4gdGhlIEJGRA0KPj4gbW9kZWwu IA0KPg0KPkxldCBtZSB3b3JrIHdpdGggUmVzaGFkIHRvIHN1Z2dlc3Qgd2hhdCBJR1AgY291bGQg c3VnZ2VzdCB0byBCRkQgaW4gdGhlaXINCj5jb25zdHJ1Y3QsIGFuZCBoYXZlIEJGUCBwaWNrIHdo YXQgaXQgYmVsaWV2ZXMgd291bGQgYmUgdGhlIHJpZ2h0IHNldCBvZg0KPnBhcmFtZXRlcnMgdG8g YmUgYWJsZSB0byBzdXBwb3J0IG1vc3Qgb2YgdGhlIElHUHMgb3ZlciB0aGUgZ2l2ZW4gQkZEDQo+ c2Vzc2lvbi4gV2hldGhlciB3ZSBhZGQgaXQgaW4gdGhlIGN1cnJlbnQgbW9kZWwgb3IgYWRkIGl0 IGxhdGVyIGFzIGFuDQo+YXVnbWVudGF0aW9uIGNvdWxkIHRoZW4gYmUgZGVjaWRlZCBzZXBhcmF0 ZWx5Lg0KDQpHaXZlbiB0aGF0IHRoZSBJR1AgbW9kZWxzIGFyZSBtb3JlIG1hdHVyZSBhbmQgd2ls bCBzb29uIGJlIHJlYWR5IGZvcg0KcHVibGljYXRpb24sIEkgdGhpbmsgaXQgaXMgYSBnaXZlbiB0 aGF0IHRoaXMgd2lsbCBiZSBkb25lIGluIGFuDQphdWdtZW50YXRpb24uIA0KDQpUaGFua3MsDQpB Y2VlIA0KDQoNCj4NCj4+IA0KPj4gVGhhbmtzLA0KPj4gQWNlZSANCj4+IA0KPj4gDQo+Pj4gDQo+ Pj4gLS0gSmVmZg0KPj4gDQo+DQo+TWFoZXNoIEpldGhhbmFuZGFuaQ0KPm1qZXRoYW5hbmRhbmlA Z21haWwuY29tDQo+DQoNCg== From nobody Tue Jun 20 11:51:29 2017 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 683271315E2; Tue, 20 Jun 2017 11:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XguJ3HBE7r1; Tue, 20 Jun 2017 11:51:19 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0D61315D8; Tue, 20 Jun 2017 11:51:19 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 0AF3F1E37E; Tue, 20 Jun 2017 15:00:10 -0400 (EDT) Date: Tue, 20 Jun 2017 15:00:09 -0400 From: Jeffrey Haas To: Greg Mirsky Cc: "Reshad Rahman (rrahman)" , Mahesh Jethanandani , "Acee Lindem (acee)" , Jeffrey Haas , OSPF WG List , "rtg-bfd@ietf. org" , "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Subject: Re: IETF OSPF YANG and BFD Configuration Message-ID: <20170620190009.GA2289@pfrc.org> References: <38DEB571-2918-4464-B18A-71B24221772F@gmail.com> <47325462-2430-4197-AA8D-D3FEF74A834D@gmail.com> <20170619185715.GB22146@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 18:51:21 -0000 Greg, On Tue, Jun 20, 2017 at 12:55:58PM -0500, Greg Mirsky wrote: > Hi Jeff, > I'd like to hear from others who are familiar with implementations of BFD > that supports per protocol single-hop BFD multi-sessions between the same > pair of BFD systems. RFC 5881 does allow per protocol single-hop sessions > on the same interface, logical or physical, between the same pair of > systems. But it is not clear, in my opinion, how BFD does demultiplexing if > Your Discriminator == 0 per protocol (RFC 5881, section 3, last sentence) > if systems use the same IP addresses. And hence the question, Even though > it is allowed to have BFD single-hop sessions per application/protocol on > the same interface between the same pair of systems, is this real, > practical requirement? > Or am I missing the point completely? Correct, 5881 procedures do not currently permit this. As I mentioned, we've had prior discussions about this being potentially problematic for clients that may have differing timing requirements. Part of the point of this exercise is to provide necessary future-proofing against the need to re-issue the Yang modules if such a mechanism is developed. (Somewhat analogous to the instructions to the design team that MPLS-TP was out of scope for the module, but that its structure shouldn't prevent its implementation in the future.) Thus far, two points have sprung from the discussion that are likely actionable: - The single-hop configuration in the current BFD module isn't suitable for use by the IGPs. Some form of wildcard of templating behavior is necessary. - Multiple clients that might desire to configure a session with different parameters are unable to do so today. This precludes some implementations that permit such configuration, potentially at protocol scope. It also doesn't fit the future-proofing thought. -- Jeff > > Regards, > Greg > > On Mon, Jun 19, 2017 at 1:57 PM, Jeffrey Haas wrote: > > > [Long delayed response.] > > > > Reshad picked up the key points: Some things may make sense in the > > per-client (protocol) users of BFD, some things perhaps do not. And some > > come down to questions for timer granularity. > > > > The OSPF and ISIS models both make use of BFD simply by providing a boolean > > that says "I'm using BFD or not". > > > > Where we run into some issues are the cases highlighted: when the sessions > > don't share common properties, how should the protocol pick what BFD > > session > > to use? > > > > The current BFD yang model only permits a single IP single-hop session > > to be configured. (Key is interface/dst-ip) This means that if different > > parameters *were* desired, the BFD model won't permit it today. However, > > BFD sessions for many protocols tend not to be configured, but may spring > > forth from protocol state, such as IGP adjacencies. Thus, it's not > > "configured" - it's solely operational state. However, the BFD yang model > > doesn't really make good provision for that as an "on". > > > > Where all endpoint state is known a priori, config state makes better > > sense. > > > > To pick the example of Juniper's configuration, if OSPF and eBGP were using > > BFD, both can choose differing timers. This represents two pieces of > > configuration state for the same endpoints. Additionally, only one BFD > > session is formed using the most aggressive timers. > > > > I partially point out the situation of multiple timers since there have > > been > > prior list discussions on the situation where clients have different timing > > requirements. I don't think we handle this operationally in the BFD > > protocol in the cleanest fashion right now - the session will go to Down > > when the aggressive timers fail and there's no clean way to renegotiate to > > the less aggressive timers. > > > > -- Jeff > > > > > > > > > > > > > > On Fri, May 19, 2017 at 02:31:38AM +0000, Reshad Rahman (rrahman) wrote: > > > We started off with the intent of having BFD parameters in the > > applications/protocols which make use of BFD. For timer/multiplier this is > > pretty straight-forward, although the discussion of what to do when not all > > applications have the same BFD parameters for the same session (e.g. Go > > with most aggressive etc). Then we started looking at authentication > > parameters and having BFD authentication parms in OSPF/ISIS etc is not > > intuitive. And what do we do if applications have different BFD > > authentication parms. We concluded that the BFD authentication parms were > > better off in BFD. And once we did that, the timer/multiplier followed.... > > > > > > I may not recall all the details/discussons, but I do recall that we > > went back and forth on this and it took some time to make the decision. > > > > > > Regards, > > > Reshad (as individual contributor). > > > > > > From: Mahesh Jethanandani > mjethanandani@gmail.com>> > > > Date: Thursday, May 18, 2017 at 5:34 PM > > > To: "Acee Lindem (acee)" > > > > Cc: Jeffrey Haas >, OSPF WG > > List >, "draft-ietf-bfd-yang@ietf.org< > > mailto:draft-ietf-bfd-yang@ietf.org>" > mailto:draft-ietf-bfd-yang@ietf.org>>, "draft-ietf-ospf-yang@ietf.org > > " > >, "rtg-bfd@ietf.org > bfd@ietf.org>" > > > > Subject: Re: IETF OSPF YANG and BFD Configuration > > > Resent-From: > > > > Resent-To: >, > > Reshad >, < > > mjethanandani@gmail.com>, < > > santosh.pallagatti@gmail.com>, < > > gregimirsky@gmail.com> > > > Resent-Date: Thursday, May 18, 2017 at 5:40 PM > > > > > > Resending with correct BFD WG address. > > > > > > On May 18, 2017, at 2:33 PM, Mahesh Jethanandani < > > mjethanandani@gmail.com> wrote: > > > > > > Agree with Acee's assessment. After much debate, we decided that we > > should leave BFD parameter configuration in the BFD model itself, and have > > any IGP protocol reference the BFD instance in BFD itself. This makes sense > > specially if multiple protocols fate-share the BFD session. > > > > > > Cheers. > > > > > > On May 18, 2017, at 12:27 PM, Acee Lindem (acee) > acee@cisco.com>> wrote: > > > > > > Hi Jeff, > > > > > > At the OSPF WG Meeting in Chicago, you suggested that we may want to > > provide configuration of BFD parameters within the OSPF model > > (ietf-ospf.yang). We originally did have this configuration. However, after > > much discussion and coordination with the BFD YANG design team, we agreed > > to leave the BFD session parameters in BFD and only enable BFD within the > > OSPF and IS-IS models. > > > > > > We did discuss the fact that vendors (notably Cisco IOS-XR and Juniper > > JUNOS) do allow configuration within the IGPs. However, the consensus was > > to leave the BFD configuration in the BFD model. The heuristics to > > determine what parameters to use when the same BFD endpoint was configured > > with different parameters in different protocols were proprietary and > > somewhat of a hack. > > > > > > I may have not remembered all the details so I'd encourage others to > > chime in. > > > > > > Thanks, > > > Acee > > > > > > Mahesh Jethanandani > > > mjethanandani@gmail.com > > > > > > > > > > > > > > > Mahesh Jethanandani > > > mjethanandani@gmail.com > > > > > > > > > > > From nobody Tue Jun 20 12:48:57 2017 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 3069F131622; Tue, 20 Jun 2017 12:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6l0ezlLtaJGz; Tue, 20 Jun 2017 12:48:53 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B3DC131618; Tue, 20 Jun 2017 12:48:53 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id p66so45724643oia.0; Tue, 20 Jun 2017 12:48:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bwQXcW3n7/8caX6sZl7O6C7zxk6sBqUMn0pQN+ShzqY=; b=Ri1tuDwg9Hsjahg/+MVVwSUU8Ki6bZQZdjs8P3FzqYIhLWgP6zcVxyHVO/FisHoq3f kWZMn6laTwFvTlp4aCVvQufOs9ywwbdz7StTV+papVMKfJbC7KN3dt2DrHpOf5U39zie xqBLqmjtca+G+U8ubhhM4ALssNcBzZeIFeYi8LI6EJAiPoENqZNy8IXKkesX9YGK65wA s5m8rgOm4js/53ztst2uH20aVNFjzt6i0jqZxNGiGEWxyYEER0NyoUHmYnh9eXRrJaKi s3NPplhBUiNOvUOFmlFGQylkB43DqDJbUzVZGaXojfd29n1FCDTsExeLE0s0eVNi2Qw3 FESw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bwQXcW3n7/8caX6sZl7O6C7zxk6sBqUMn0pQN+ShzqY=; b=sXqMqoqQwhowxh7HWPI8tlY9yPb9HrV+QUwwfGDA35ju/14+waU50kaiP6Of9aDv4+ CBJMwkVZJK6Hy1JxzwlxICbDpB0yRHU61oDGNpp212tJz9BKMrWoaPfZdDcxpzzTzie7 dPfg4IzaNPefNLJpcbkq76FZCxalZhpPIAfXn/wML/sBNxsmIdf8K8ACrvmOUBAnolNP eA1XiivdBF9EYD+71jSrH3cgXl93RCXVrVXSyJ+KvwrtkkNL1FIy7aSnpp434le2lC0w Bnz+/eXex1P0cKzTl2f1CxcWE8JIdRRWqL9r0DxlEY2s5OG8Xd3ypkG9CabgTfkOsR9U KwdQ== X-Gm-Message-State: AKS2vOy1XLrUCwNHwuLnw4w2bkqLz4g9ZjR5/f3v4msn7ajAA5s+qZx1 llvZ8f0nYSpfG4iYV2IFkvdiCX2I/g== X-Received: by 10.202.206.23 with SMTP id e23mr17277666oig.168.1497988132314; Tue, 20 Jun 2017 12:48:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.37.105 with HTTP; Tue, 20 Jun 2017 12:48:51 -0700 (PDT) In-Reply-To: <20170620190009.GA2289@pfrc.org> References: <38DEB571-2918-4464-B18A-71B24221772F@gmail.com> <47325462-2430-4197-AA8D-D3FEF74A834D@gmail.com> <20170619185715.GB22146@pfrc.org> <20170620190009.GA2289@pfrc.org> From: Greg Mirsky Date: Tue, 20 Jun 2017 14:48:51 -0500 Message-ID: Subject: Re: IETF OSPF YANG and BFD Configuration To: Jeffrey Haas Cc: "Reshad Rahman (rrahman)" , Mahesh Jethanandani , "Acee Lindem (acee)" , Jeffrey Haas , OSPF WG List , "rtg-bfd@ietf. org" , "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Content-Type: multipart/alternative; boundary="001a113ac7248124980552698abe" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 19:48:56 -0000 --001a113ac7248124980552698abe Content-Type: text/plain; charset="UTF-8" Hi Jeff, thank you for the great summary of the discussion, helps me to catch the wave. I'm skeptical that there's realistic scenario where two BFD systems will be requested to run multiple BFD single-hop session between them over the same interfaces (logical or physical). I believe that we should try to make models future proof but to the level that is reasonable, practical. Approach "if we can think of it, then we need to support it" may not be the one. RE: RFC 5881. I've referred to the following: ... any BFD packet from the remote machine with a zero value of Your Discriminator MUST be associated with the session bound to the remote system, interface, and protocol. Unless we add out-band bootstrapping of BFD sessions like with LSP Ping, I don't see how received BFD control packet with zero value in Your Discriminator may be bound to not just any one of several protocols that are trying to run BFD session on the same interface to the same remote system but to the right one, the one that corresponds to the protocol on whose behalf remote BFD peer sent the control packet. Hence my question Do we have implementation(s) that use this and are asking for BFD data model to accommodate them? Or we are just doing interesting intellectual exercise? Regards, Greg On Tue, Jun 20, 2017 at 2:00 PM, Jeffrey Haas wrote: > Greg, > > On Tue, Jun 20, 2017 at 12:55:58PM -0500, Greg Mirsky wrote: > > Hi Jeff, > > I'd like to hear from others who are familiar with implementations of BFD > > that supports per protocol single-hop BFD multi-sessions between the same > > pair of BFD systems. RFC 5881 does allow per protocol single-hop sessions > > on the same interface, logical or physical, between the same pair of > > systems. But it is not clear, in my opinion, how BFD does demultiplexing > if > > Your Discriminator == 0 per protocol (RFC 5881, section 3, last sentence) > > if systems use the same IP addresses. And hence the question, Even though > > it is allowed to have BFD single-hop sessions per application/protocol on > > the same interface between the same pair of systems, is this real, > > practical requirement? > > Or am I missing the point completely? > > Correct, 5881 procedures do not currently permit this. > As I mentioned, we've had prior discussions about this being potentially > problematic for clients that may have differing timing requirements. > > Part of the point of this exercise is to provide necessary future-proofing > against the need to re-issue the Yang modules if such a mechanism is > developed. (Somewhat analogous to the instructions to the design team that > MPLS-TP was out of scope for the module, but that its structure shouldn't > prevent its implementation in the future.) > > Thus far, two points have sprung from the discussion that are likely > actionable: > - The single-hop configuration in the current BFD module isn't suitable for > use by the IGPs. Some form of wildcard of templating behavior is > necessary. > - Multiple clients that might desire to configure a session with different > parameters are unable to do so today. This precludes some > implementations > that permit such configuration, potentially at protocol scope. It also > doesn't fit the future-proofing thought. > > > -- Jeff > > > > > Regards, > > Greg > > > > On Mon, Jun 19, 2017 at 1:57 PM, Jeffrey Haas wrote: > > > > > [Long delayed response.] > > > > > > Reshad picked up the key points: Some things may make sense in the > > > per-client (protocol) users of BFD, some things perhaps do not. And > some > > > come down to questions for timer granularity. > > > > > > The OSPF and ISIS models both make use of BFD simply by providing a > boolean > > > that says "I'm using BFD or not". > > > > > > Where we run into some issues are the cases highlighted: when the > sessions > > > don't share common properties, how should the protocol pick what BFD > > > session > > > to use? > > > > > > The current BFD yang model only permits a single IP single-hop session > > > to be configured. (Key is interface/dst-ip) This means that if > different > > > parameters *were* desired, the BFD model won't permit it today. > However, > > > BFD sessions for many protocols tend not to be configured, but may > spring > > > forth from protocol state, such as IGP adjacencies. Thus, it's not > > > "configured" - it's solely operational state. However, the BFD yang > model > > > doesn't really make good provision for that as an "on". > > > > > > Where all endpoint state is known a priori, config state makes better > > > sense. > > > > > > To pick the example of Juniper's configuration, if OSPF and eBGP were > using > > > BFD, both can choose differing timers. This represents two pieces of > > > configuration state for the same endpoints. Additionally, only one BFD > > > session is formed using the most aggressive timers. > > > > > > I partially point out the situation of multiple timers since there have > > > been > > > prior list discussions on the situation where clients have different > timing > > > requirements. I don't think we handle this operationally in the BFD > > > protocol in the cleanest fashion right now - the session will go to > Down > > > when the aggressive timers fail and there's no clean way to > renegotiate to > > > the less aggressive timers. > > > > > > -- Jeff > > > > > > > > > > > > > > > > > > > > > On Fri, May 19, 2017 at 02:31:38AM +0000, Reshad Rahman (rrahman) > wrote: > > > > We started off with the intent of having BFD parameters in the > > > applications/protocols which make use of BFD. For timer/multiplier > this is > > > pretty straight-forward, although the discussion of what to do when > not all > > > applications have the same BFD parameters for the same session (e.g. Go > > > with most aggressive etc). Then we started looking at authentication > > > parameters and having BFD authentication parms in OSPF/ISIS etc is not > > > intuitive. And what do we do if applications have different BFD > > > authentication parms. We concluded that the BFD authentication parms > were > > > better off in BFD. And once we did that, the timer/multiplier > followed.... > > > > > > > > I may not recall all the details/discussons, but I do recall that we > > > went back and forth on this and it took some time to make the decision. > > > > > > > > Regards, > > > > Reshad (as individual contributor). > > > > > > > > From: Mahesh Jethanandani > > mjethanandani@gmail.com>> > > > > Date: Thursday, May 18, 2017 at 5:34 PM > > > > To: "Acee Lindem (acee)" > > > > > Cc: Jeffrey Haas >, > OSPF WG > > > List >, " > draft-ietf-bfd-yang@ietf.org< > > > mailto:draft-ietf-bfd-yang@ietf.org>" > > mailto:draft-ietf-bfd-yang@ietf.org>>, "draft-ietf-ospf-yang@ietf.org > > > " > > >, "rtg-bfd@ietf.org > > bfd@ietf.org>" > > > > > Subject: Re: IETF OSPF YANG and BFD Configuration > > > > Resent-From: > > > > > Resent-To: >, > > > Reshad >, < > > > mjethanandani@gmail.com>, < > > > santosh.pallagatti@gmail.com>, < > > > gregimirsky@gmail.com> > > > > Resent-Date: Thursday, May 18, 2017 at 5:40 PM > > > > > > > > Resending with correct BFD WG address. > > > > > > > > On May 18, 2017, at 2:33 PM, Mahesh Jethanandani < > > > mjethanandani@gmail.com> wrote: > > > > > > > > Agree with Acee's assessment. After much debate, we decided that we > > > should leave BFD parameter configuration in the BFD model itself, and > have > > > any IGP protocol reference the BFD instance in BFD itself. This makes > sense > > > specially if multiple protocols fate-share the BFD session. > > > > > > > > Cheers. > > > > > > > > On May 18, 2017, at 12:27 PM, Acee Lindem (acee) > > acee@cisco.com>> wrote: > > > > > > > > Hi Jeff, > > > > > > > > At the OSPF WG Meeting in Chicago, you suggested that we may want to > > > provide configuration of BFD parameters within the OSPF model > > > (ietf-ospf.yang). We originally did have this configuration. However, > after > > > much discussion and coordination with the BFD YANG design team, we > agreed > > > to leave the BFD session parameters in BFD and only enable BFD within > the > > > OSPF and IS-IS models. > > > > > > > > We did discuss the fact that vendors (notably Cisco IOS-XR and > Juniper > > > JUNOS) do allow configuration within the IGPs. However, the consensus > was > > > to leave the BFD configuration in the BFD model. The heuristics to > > > determine what parameters to use when the same BFD endpoint was > configured > > > with different parameters in different protocols were proprietary and > > > somewhat of a hack. > > > > > > > > I may have not remembered all the details so I'd encourage others to > > > chime in. > > > > > > > > Thanks, > > > > Acee > > > > > > > > Mahesh Jethanandani > > > > mjethanandani@gmail.com > > > > > > > > > > > > > > > > > > > > Mahesh Jethanandani > > > > mjethanandani@gmail.com > > > > > > > > > > > > > > > > --001a113ac7248124980552698abe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeff,
thank you for the great summary of the discus= sion, helps me to catch the wave.
I'm skeptical that there= 9;s realistic scenario where two BFD systems will be requested to run multi= ple BFD single-hop session between them over the same interfaces (logical o= r physical). I believe that we should try to make models future proof but t= o the level that is reasonable, practical. Approach "if we can think o= f it, then we need to support it" may not be the one.
RE: RF= C 5881. I've referred to the following:
...=C2=A0any BFD packet from the remote ma= chine with a=C2=A0zero value of Your Discriminator MUST be associated with the session=C2= =A0bound to the= remote system, interface, and protocol.
Unless we add out-band bootstrap= ping of BFD sessions like with LSP Ping, I don't see how received BFD c= ontrol packet with zero value in Your Discriminator may be bound to not jus= t any one of several protocols that are trying to run BFD session on the sa= me interface to the same remote system but to the right one, the one that c= orresponds to the protocol on whose behalf remote BFD peer sent the control= packet. Hence my question Do we have implementation(s) that use this and a= re asking for BFD data model to accommodate them? Or we are just doing inte= resting intellectual exercise?

Regards,
Greg

On Tue, Jun 20, 2017 at 2:00 PM,= Jeffrey Haas <jhaas@pfrc.org> wrote:
Greg,

On Tue, Jun 20, 2017 at 12:55:58PM -0500, Greg Mirsky wrote:
> Hi Jeff,
> I'd like to hear from others who are familiar with implementations= of BFD
> that supports per protocol single-hop BFD multi-sessions between the s= ame
> pair of BFD systems. RFC 5881 does allow per protocol single-hop sessi= ons
> on the same interface, logical or physical, between the same pair of > systems. But it is not clear, in my opinion, how BFD does demultiplexi= ng if
> Your Discriminator =3D=3D 0 per protocol (RFC 5881, section 3, last se= ntence)
> if systems use the same IP addresses. And hence the question, Even tho= ugh
> it is allowed to have BFD single-hop sessions per application/protocol= on
> the same interface between the same pair of systems, is this real,
> practical requirement?
> Or am I missing the point completely?

Correct, 5881 procedures do not currently permit this.
As I mentioned, we've had prior discussions about this being potentiall= y
problematic for clients that may have differing timing requirements.

Part of the point of this exercise is to provide necessary future-proofing<= br> against the need to re-issue the Yang modules if such a mechanism is
developed.=C2=A0 (Somewhat analogous to the instructions to the design team= that
MPLS-TP was out of scope for the module, but that its structure shouldn'= ;t
prevent its implementation in the future.)

Thus far, two points have sprung from the discussion that are likely
actionable:
- The single-hop configuration in the current BFD module isn't suitable= for
=C2=A0 use by the IGPs.=C2=A0 Some form of wildcard of templating behavior = is
=C2=A0 necessary.
- Multiple clients that might desire to configure a session with different<= br> =C2=A0 parameters are unable to do so today.=C2=A0 This precludes some impl= ementations
=C2=A0 that permit such configuration, potentially at protocol scope.=C2=A0= It also
=C2=A0 doesn't fit the future-proofing thought.


-- Jeff

>
> Regards,
> Greg
>
> On Mon, Jun 19, 2017 at 1:57 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:
>
> > [Long delayed response.]
> >
> > Reshad picked up the key points: Some things may make sense in th= e
> > per-client (protocol) users of BFD, some things perhaps do not.= =C2=A0 And some
> > come down to questions for timer granularity.
> >
> > The OSPF and ISIS models both make use of BFD simply by providing= a boolean
> > that says "I'm using BFD or not".
> >
> > Where we run into some issues are the cases highlighted: when the= sessions
> > don't share common properties, how should the protocol pick w= hat BFD
> > session
> > to use?
> >
> > The current BFD yang model only permits a single IP single-hop se= ssion
> > to be configured.=C2=A0 (Key is interface/dst-ip)=C2=A0 This mean= s that if different
> > parameters *were* desired, the BFD model won't permit it toda= y.=C2=A0 However,
> > BFD sessions for many protocols tend not to be configured, but ma= y spring
> > forth from protocol state, such as IGP adjacencies.=C2=A0 Thus, i= t's not
> > "configured" - it's solely operational state.=C2=A0= However, the BFD yang model
> > doesn't really make good provision for that as an "on&qu= ot;.
> >
> > Where all endpoint state is known a priori, config state makes be= tter
> > sense.
> >
> > To pick the example of Juniper's configuration, if OSPF and e= BGP were using
> > BFD, both can choose differing timers.=C2=A0 This represents two = pieces of
> > configuration state for the same endpoints.=C2=A0 Additionally, o= nly one BFD
> > session is formed using the most aggressive timers.
> >
> > I partially point out the situation of multiple timers since ther= e have
> > been
> > prior list discussions on the situation where clients have differ= ent timing
> > requirements.=C2=A0 I don't think we handle this operationall= y in the BFD
> > protocol in the cleanest fashion right now - the session will go = to Down
> > when the aggressive timers fail and there's no clean way to r= enegotiate to
> > the less aggressive timers.
> >
> > -- Jeff
> >
> >
> >
> >
> >
> >
> > On Fri, May 19, 2017 at 02:31:38AM +0000, Reshad Rahman (rrahman)= wrote:
> > > We started off with the intent of having BFD parameters in t= he
> > applications/protocols which make use of BFD. For timer/multiplie= r this is
> > pretty straight-forward, although the discussion of what to do wh= en not all
> > applications have the same BFD parameters for the same session (e= .g. Go
> > with most aggressive etc). Then we started looking at authenticat= ion
> > parameters and having BFD authentication parms in OSPF/ISIS etc i= s not
> > intuitive. And what do we do if applications have different BFD > > authentication parms. We concluded that the BFD authentication pa= rms were
> > better off in BFD. And once we did that, the timer/multiplier fol= lowed....
> > >
> > > I may not recall all the details/discussons, but I do recall= that we
> > went back and forth on this and it took some time to make the dec= ision.
> > >
> > > Regards,
> > > Reshad (as individual contributor).
> > >
> > > From: Mahesh Jethanandani <mjethanandani@gmail.com<mailto:
> > mjethanandani@gmail.co= m>>
> > > Date: Thursday, May 18, 2017 at 5:34 PM
> > > To: "Acee Lindem (acee)" <acee@cisco.com<mailto:acee@cisco.com>>
> > > Cc: Jeffrey Haas <jh= aas@juniper.net<mailto:jhaas@juniper.net>>, OSPF WG
> > List <ospf@ietf.org<ma= ilto:ospf@ietf.org>>, "= ;draft-ietf-bfd-yang@ietf.o= rg<
> > mailto:draft-ietf= -bfd-yang@ietf.org>" <draft-ietf-bfd-yang@ietf.org<
> > mailto:draft-ietf= -bfd-yang@ietf.org>>, "draft-ietf-ospf-yang@ietf.org
> > <mailto:draft= -ietf-ospf-yang@ietf.org>" <draft-ietf-ospf-yang@ietf.org
> > <mailto:draft= -ietf-ospf-yang@ietf.org>>, "rtg-bfd@ietf.org<mailto:rtg- > > bfd@ietf.org>" <rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>
> > > Subject: Re: IETF OSPF YANG and BFD Configuration
> > > Resent-From: <a= lias-bounces@ietf.org<mailto:alias-bounces@ietf.org>>
> > > Resent-To: <vero= .zheng@huawei.com<mailto:vero.zheng@huawei.com>>,
> > Reshad <rrahman@cisco.com= <mailto:rrahman@cisco.com<= /a>>>, <
> > mjethanandani@gmail.co= m<mailto:mjethananda= ni@gmail.com>>, <
> > santosh.pallagatt= i@gmail.com<mailto:santosh.pallagatti@gmail.com>>, <
> > gregimirsky@gmail.com<mailto:gregimirsky@gmail= .com>>
> > > Resent-Date: Thursday, May 18, 2017 at 5:40 PM
> > >
> > > Resending with correct BFD WG address.
> > >
> > > On May 18, 2017, at 2:33 PM, Mahesh Jethanandani <
> > mjethanandani@gmail.co= m<mailto:mjethananda= ni@gmail.com>> wrote:
> > >
> > > Agree with Acee's assessment. After much debate, we deci= ded that we
> > should leave BFD parameter configuration in the BFD model itself,= and have
> > any IGP protocol reference the BFD instance in BFD itself. This m= akes sense
> > specially if multiple protocols fate-share the BFD session.
> > >
> > > Cheers.
> > >
> > > On May 18, 2017, at 12:27 PM, Acee Lindem (acee) <acee@cisco.com<mailto:
> > acee@cisco.com>> wrot= e:
> > >
> > > Hi Jeff,
> > >
> > > At the OSPF WG Meeting in Chicago, you suggested that we may= want to
> > provide configuration of BFD parameters within the OSPF model
> > (ietf-ospf.yang). We originally did have this configuration. Howe= ver, after
> > much discussion and coordination with the BFD YANG design team, w= e agreed
> > to leave the BFD session parameters in BFD and only enable BFD wi= thin the
> > OSPF and IS-IS models.
> > >
> > > We did discuss the fact that vendors (notably Cisco IOS-XR a= nd Juniper
> > JUNOS) do allow configuration within the IGPs. However, the conse= nsus was
> > to leave the BFD configuration in the BFD model. The heuristics t= o
> > determine what parameters to use when the same BFD endpoint was c= onfigured
> > with different parameters in different protocols were proprietary= and
> > somewhat of a hack.
> > >
> > > I may have not remembered all the details so I'd encoura= ge others to
> > chime in.
> > >
> > > Thanks,
> > > Acee
> > >
> > > Mahesh Jethanandani
> > > mjethanandani@gma= il.com<mailto:mjetha= nandani@gmail.com>
> > >
> > >
> > >
> > >
> > > Mahesh Jethanandani
> > > mjethanandani@gma= il.com<mailto:mjetha= nandani@gmail.com>
> > >
> > >
> > >
> >

--001a113ac7248124980552698abe-- From nobody Tue Jun 20 13:17:51 2017 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 A0C181315C5; Tue, 20 Jun 2017 13:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0h3cQc4NfA5D; Tue, 20 Jun 2017 13:17:49 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 186E6128B4E; Tue, 20 Jun 2017 13:17:49 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 1A20D1E37E; Tue, 20 Jun 2017 16:26:40 -0400 (EDT) Date: Tue, 20 Jun 2017 16:26:39 -0400 From: Jeffrey Haas To: Greg Mirsky Cc: "Reshad Rahman (rrahman)" , Mahesh Jethanandani , "Acee Lindem (acee)" , Jeffrey Haas , OSPF WG List , "rtg-bfd@ietf. org" , "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Subject: Re: IETF OSPF YANG and BFD Configuration Message-ID: <20170620202639.GF2289@pfrc.org> References: <38DEB571-2918-4464-B18A-71B24221772F@gmail.com> <47325462-2430-4197-AA8D-D3FEF74A834D@gmail.com> <20170619185715.GB22146@pfrc.org> <20170620190009.GA2289@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 20:17:51 -0000 On Tue, Jun 20, 2017 at 02:48:51PM -0500, Greg Mirsky wrote: > Hi Jeff, > thank you for the great summary of the discussion, helps me to catch the > wave. > I'm skeptical that there's realistic scenario where two BFD systems will be > requested to run multiple BFD single-hop session between them over the same > interfaces (logical or physical). I believe that we should try to make > models future proof but to the level that is reasonable, practical. > Approach "if we can think of it, then we need to support it" may not be the > one. > RE: RFC 5881. I've referred to the following: > ... any BFD packet from the remote machine with a zero value of Your > Discriminator MUST be associated with the session bound to the remote > system, interface, and protocol. > Unless we add out-band bootstrapping of BFD sessions like with LSP Ping, I > don't see how received BFD control packet with zero value in Your > Discriminator may be bound to not just any one of several protocols that > are trying to run BFD session on the same interface to the same remote > system but to the right one, the one that corresponds to the protocol on > whose behalf remote BFD peer sent the control packet. Hence my question Do > we have implementation(s) that use this and are asking for BFD data model > to accommodate them? Or we are just doing interesting intellectual exercise? The constant iteration regarding "intellectual exercise" is getting irritating. See prior comments. This distribution is too large to try to design the actual behavioral change. If you feel the need to pursue that thread, please reduce the scope of the cc: list. This will be my last reply to this topic on the expanded distro. To offer one example of how such a thing could be implemented, BFD authentication can be used with different parameters for each session. This provides the necessary split for demultiplexing. Such a hack is not unusual operations trick when running OSPF for (partially) disjoint domains on the same interface, although I suspect that the hack is no longer necessary with multi-instance techs. (This trick goes back to the 1990's.) -- Jeff From nobody Mon Jun 26 18:21:02 2017 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 7876A12EB9B for ; Mon, 26 Jun 2017 18:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFXhVLmdXVrP for ; Mon, 26 Jun 2017 18:20:58 -0700 (PDT) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57AFE1200FC for ; Mon, 26 Jun 2017 18:20:58 -0700 (PDT) Received: by mail-ot0-x22e.google.com with SMTP id r67so12702383ota.1 for ; Mon, 26 Jun 2017 18:20:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Bi2ZR0YUY2PxmD2pDCeQ61ma/wI07r4zllH+/WRkkVM=; b=EfkEmJR/rclZvPoJPJumR4HGkuk1bnPY1fw3xkbWid8sVVMCaSWn/cCcB08K4h8hRF tUzT+4iJ+dEkMwbJwNyCfXEmrPiacAcjUWi8IBDM/TiD7hXkBBz7uRfiHPWH9xAAiM+2 SrDt/uRQ4CdD34RJXQO9IeHom0uYvkkmvR4EEYDzPsDbGavXR3wrTA/Bx2cctmCDsqOh 18DkPCKQi/uGVBcLoj9c2682cyJLazost7SoUOHjaz/qmtqXIXF9hrykJVczDuTHAx2A YU2yz5phSQKk21FxS5SfFQvYCrPtvhI7VVGOwXg1c3z7TdawK+vn1qNpfxoT9F7BlXco b+zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Bi2ZR0YUY2PxmD2pDCeQ61ma/wI07r4zllH+/WRkkVM=; b=RMbr0gpiSCg4+RW9F8XxLx2MdfXYY3TKU82ReiREKOWRyLYO6U3qMr5i/N0YgNNpa+ lY0CwEZzKsWvsphGMUE0s8qrsr4NAhcYhBpYnPVfc1MVY++j0KjQgpgNgdgdxt8+jsIT VLEywBDCRymSJOZV7WPFMLExtHTxsdh7p37dqAFRrrkc+v0jY3j21NAbuTLZgKVq348d V5NZ/+WGKkuqwl8w2MSxdbVG+OGd+bUQz01kCXZxu/kcHsEw4rMGv9fkbQ6NvZ4vPqyB Y/IPrAAogIySnwzY7y53Velge/hZCbK+zlmJ/MEC+k/xx5PYfofXznw37ua2c0oL38a4 c0+w== X-Gm-Message-State: AKS2vOwRrWp4WWY3wtMury0Wthotcs9WM/Hu8BLMm1fqbq/uvppw4pd8 WuKrooEDU/q4czJFHvya75pKsTf7u9rL X-Received: by 10.157.53.102 with SMTP id l35mr1841646ote.52.1498526457436; Mon, 26 Jun 2017 18:20:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.171 with HTTP; Mon, 26 Jun 2017 18:20:57 -0700 (PDT) From: Greg Mirsky Date: Mon, 26 Jun 2017 20:20:57 -0500 Message-ID: Subject: Re: Adoption call for draft-tanmir-rtgwg-bfd-mc-lag-* (ends April 30, 2017) To: "rtg-bfd@ietf.org" , "Reshad Rahman (rrahman)" , Jeffrey Haas Content-Type: multipart/alternative; boundary="001a113df76e2e9f240552e6e18a" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 27 Jun 2017 01:21:00 -0000 --001a113df76e2e9f240552e6e18a Content-Type: text/plain; charset="UTF-8" Hi Jeff and Reshad, et. al, would like to thank all who took time to share their views on the drafts, problem, and the proposed solution. It would be of great help to us, authors, to understand which of three aspects of WG adoption call we should concentrate on improving: - clarity of the writing; - scope of the problem; - proposed solution. Regards, Greg Hi authors, We do not yet have consensus to adopt these 2 drafts as BFD WG documents. Regards, Reshad. On 2017-04-17, 6:55 PM, "Rtg-bfd on behalf of Jeffrey Haas" ; wrote: >Working Group, > >https://tools.ietf.org/html/draft-tanmir-rtgwg-bfd-mc-lag-ip-00 >https://datatracker.ietf.org/doc/draft-tanmir-rtgwg-bfd-mc-lag-mpls/ > >The authors of BFD on Multi-Chass Link Aggregation Group Interfaces for IP >and MPLS have requested BFD working group adoption for their drafts. > >These drafts were previously presented at IETF-96. > >Please note that IPR has been declare against these drafts. The IPR >declaration may be found from the datatracker links. > >Please indicate your support/lack of support to the mailing list. > >-- Jeff and Reshad > > --001a113df76e2e9f240552e6e18a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
Hi Jeff and Reshad, et. al,
<= pre class=3D"gmail-wordwrap" style=3D"box-sizing:border-box;overflow:auto;f= ont-size:13px;padding:0px;margin-top:0px;margin-bottom:10px;line-height:1.4= 2857;word-break:normal;word-wrap:normal;color:rgb(51,51,51);border:0px none= black;border-radius:4px;white-space:pre-wrap">would like to thank all who took time to share their views = on the drafts, problem, and the proposed solution. It would be of great hel= p to us, authors, to understand which of three aspects of WG adoption call = we should concentrate on improving:
  • clarity of the writing;
  • scope of the problem=
;
  • p=
roposed solution.
Regards,
Greg
Hi authors,

We do not yet have consensus to adopt these 2 drafts as BFD WG documents.

Regards,
Reshad.



On 2017-04-17, 6:55 PM, "Rtg-bfd on behalf of Jeffrey Haas"
<rtg-bfd-bounces@ietf.org on behalf of jhaas@pfrc.org>; wr=
ote:

>Working Group,
>
>https://tools.ietf.org/html/draft-tanmir-rtgwg-bfd-mc-lag-ip-00
>https://datatracker.ietf.org/doc/draft-tanmir-rtgwg-bfd-mc-lag-mp=
ls/
>
>The authors of BFD on Multi-Chass Link Aggregation Group Interfaces for=
 IP
>and MPLS have requested BFD working group adoption for their drafts.
>
>These drafts were previously presented at IETF-96.
>
>Please note that IPR has been declare against these drafts.  The IPR
>declaration may be found from the datatracker links.
>
>Please indicate your support/lack of support to the mailing list.
>
>-- Jeff and Reshad
>
>
--001a113df76e2e9f240552e6e18a-- From nobody Tue Jun 27 07:56:29 2017 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 3B92E129B41 for ; Tue, 27 Jun 2017 07:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2ZFaczZieEy for ; Tue, 27 Jun 2017 07:56:24 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9DD8129B1A for ; Tue, 27 Jun 2017 07:56:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11864; q=dns/txt; s=iport; t=1498575384; x=1499784984; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WHkmVs3EzvUcwZ6sdvDA7FblZ3MuRvjar7U9cGxQ49g=; b=Smp8pV9xjNNX3cHS4Yet+d3Qf0MJbYnu+Fhv/Xj/jzhec7MlJWTf1mp7 PgZtYuqKLLpGthOolxxrKqzW4PO79fbR+1GgN1mIXzemKCcqkuDzMi4Cc Y9iShAbKPpg/gf0KNhm9ry6yfVSTiFdb8zLIftL0QNyJmx7q/1ty9yNwT k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BbAQBocVJZ/5hdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgystY4EOB4NlihmRQ5B0hSuCES6FewIagmI/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRkGI1YQAgEIDjEDAgICMBQRAgQOBYlMZBCwOoImi1gBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEYBYMng0yBYAErC4JugTyGQTCCEh8FlyGHTgKHNIw1khSVIwEfOIE?= =?us-ascii?q?KdBVJEgGFCoF2dgEBiA2BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.39,401,1493683200"; d="scan'208,217";a="444742279" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2017 14:56:23 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v5REuNYx030334 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 27 Jun 2017 14:56:23 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 27 Jun 2017 10:56:22 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Tue, 27 Jun 2017 10:56:22 -0400 From: "Carlos Pignataro (cpignata)" To: Jeff Haas CC: "rtg-bfd@ietf.org" Subject: Re: WGLC for BFD Multipoint documents (ending July 14, 2017) Thread-Topic: WGLC for BFD Multipoint documents (ending July 14, 2017) Thread-Index: AQHS6TKRH3+h+CPmGE2vggvMdQNmVaI5G70A Date: Tue, 27 Jun 2017 14:56:22 +0000 Message-ID: <0B1CE01B-4FA3-4536-AF41-5DDC6F510C0D@cisco.com> References: <20170619193929.GE22146@pfrc.org> In-Reply-To: <20170619193929.GE22146@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.116.131] Content-Type: multipart/alternative; boundary="_000_0B1CE01B4FA34536AF415DDC6F510C0Dciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 27 Jun 2017 14:56:27 -0000 --_000_0B1CE01B4FA34536AF415DDC6F510C0Dciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SnVzdCBvbmUgY29tbWVudCBvbiB0aGVzZSB0d28gZG9jdW1lbnRzLCBpbiByZWdhcmRzIHRvIHRo ZSBzdGF0ZSB2YXJpYWJsZXM6DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWJmZC1tdWx0aXBvaW50LTEwI3NlY3Rpb24tNC40LjENCg0KNC40LjEuICBOZXcgU3RhdGUg VmFyaWFibGVzDQoNCiAgIEEgbnVtYmVyIG9mIHN0YXRlIHZhcmlhYmxlcyBhcmUgYWRkZWQgdG8g dGhlIGJhc2Ugc3BlY2lmaWNhdGlvbiBpbg0KICAgc3VwcG9ydCBvZiBNdWx0aXBvaW50IEJGRC4N Cg0KICAgICAgYmZkLlNlc3Npb25UeXBlDQoNCiAgICAgICAgIFRoZSB0eXBlIG9mIHRoaXMgc2Vz c2lvbi4gIEFsbG93YWJsZSB2YWx1ZXMgYXJlOg0KDQpDTVA6IEhvd2V2ZXIsIHRoaXMgc3RhdGUg KGJmZC5TZXNzaW9uVHlwZSkgdmFyaWFibGUgaXMgYWxyZWFkeSBkZWZpbmVkIGluIFNCRkQgUkZD IDc4ODA6DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3ODgwI3NlY3Rpb24tNi4x DQoNCjYuMS4gIE5ldyBTdGF0ZSBWYXJpYWJsZXMNCg0KICAgQSBuZXcgc3RhdGUgdmFyaWFibGUg aXMgYWRkZWQgdG8gdGhlIGJhc2Ugc3BlY2lmaWNhdGlvbiBpbiBzdXBwb3J0DQogICBvZiBTLUJG RC4NCg0KICAgbyAgYmZkLlNlc3Npb25UeXBlOiBUaGlzIGlzIGEgbmV3IHN0YXRlIHZhcmlhYmxl IHRoYXQgZGVzY3JpYmVzDQogICAgICB0aGUgdHlwZSBvZiBhIHBhcnRpY3VsYXIgc2Vzc2lvbi4N Cg0KDQpDTVA6IFNvLCBmb3IgZHJhZnQtaWV0Zi1iZmQtbXVsdGlwb2ludCwgSSBzdWdnZXN0IGEg cG9pbnRlciB0byBSRkMgNzg4MCB3aGVyZSBiZmQuU2Vzc2lvblR5cGUgaXMgZGVmaW5lZCBpbiB0 aGUgYWRkaXRpb24gb2YgbmV3IHZhbHVlcyB0byB0aGUgZXhpc3RpbmcgdmFyaWFibGUuDQoNCkNN UDogU2ltaWxhcmx5Og0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1i ZmQtbXVsdGlwb2ludC1hY3RpdmUtdGFpbC0wNCNzZWN0aW9uLTMuMy4xDQoNCiAgICAgIGJmZC5T ZXNzaW9uVHlwZQ0KDQogICAgICAgICBUaGUgdHlwZSBvZiB0aGlzIHNlc3Npb24gYXMgZGVmaW5l ZCBpbg0KICAgICAgICAgW0ktRC5pZXRmLWJmZC1tdWx0aXBvaW50XS4gIEEgbmV3IHZhbHVlIGlu dHJvZHVjZWQgaXM6DQoNCkNNUDogVGhlIHBvaW50ZXIgYWJvdmUgc2hvdWxkIGJlIHRvIFJGQyA3 ODgwIGFsc28sIGFuZDoNCg0KICAgICAgYmZkLlNpbGVudFRhaWwNCg0KQ01QOiBCdXQgdGhpcyBp cyBkZWZpbmVkIGluIGRyYWZ0LWlldGYtYmZkLW11bHRpcG9pbnQNCg0KaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmZkLW11bHRpcG9pbnQtMTAjc2VjdGlvbi00LjQuMQ0K DQogICAgICBiZmQuU2lsZW50VGFpbA0KDQpUaGFua3MhDQoNCuKAlCBDYXJsb3MuDQoNCg0KT24g SnVuIDE5LCAyMDE3LCBhdCAzOjM5IFBNLCBKZWZmcmV5IEhhYXMgPGpoYWFzQHBmcmMub3JnPG1h aWx0bzpqaGFhc0BwZnJjLm9yZz4+IHdyb3RlOg0KDQpXb3JraW5nIEdyb3VwLA0KDQpodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1iZmQtbXVsdGlwb2ludC0xMA0KaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmZkLW11bHRpcG9pbnQtYWN0aXZlLXRh aWwtMDQNCg0KDQpUaGUgQkZEIE11bHRpcG9pbnQgZG9jdW1lbnRzIGhhdmUgYmVlbiBzdGFibGUg Zm9yIHNvbWUgdGltZS4gIFByaW9yDQpkaXNjdXNzaW9uIGF0IG1lZXRpbmdzIGhhcyBzdWdnZXN0 ZWQgd2UgaGF2ZSBhbiBpbXBsZW1lbnRhdGlvbiBmb3IgdGhlIG1haW4NCnByb3RvY29sIGNvbXBv bmVudC4gIEFsc28gcGVyIHByaW9yIGRpc2N1c3Npb25zLCB3ZSBzcGxpdCB0aGUgYWN0aXZlLXRh aWwNCmNvbXBvbmVudCBvZiB0aGUgb3JpZ2luYWwgbXVsdGlwb2ludCBkb2N1bWVudCB0byBwZXJt aXQgaW1wbGVtZW50b3JzIHRvIG5vdA0KaGF2ZSB0byB3b3JyeSBhYm91dCBpbXBsZW1lbnRpbmcg YWN0aXZlLXRhaWwgcHJvY2VkdXJlcyBpZiB0aGV5IHdlcmVuJ3QNCmludGVyZXN0ZWQgaW4gdGhh dCBmZWF0dXJlLg0KDQpXZSBhcmUgc3RhcnRpbmcgYW4gZXh0ZW5kZWQgbGFzdCBjYWxsIG9uIHRo ZXNlIGRvY3VtZW50cy4gIFRoZSBXR0xDIHdpbGwNCmNvbmNsdWRlIG9uIEp1bHkgMTQuICBUaGlz IHByb3ZpZGVzIGFtcGxlIHRpbWUgZm9yIGxpc3QgZGlzY3Vzc2lvbi4gIElmDQpuZWNlc3Nhcnks IHRoZSBJRVRGLTk5IG1lZXRpbmcgbWF5IHByb3ZpZGUgZm9yIG9wcG9ydHVuaXRpZXMgdG8gY2xv c2UgYW55DQpjb250ZW50aW91cyB0ZWNobmljYWwgcG9pbnRzLiAgKEJGRCBpcyBub3QgY3VycmVu dGx5IHNjaGVkdWxlZCB0byBtZWV0LikNCg0KT25lIGl0ZW0gSSB3b3VsZCBsaWtlIHRvIGtpY2sg b2ZmIGlzIHRoZSBkb2N1bWVudCBzdGF0dXMgb2YgdGhlIGFjdGl2ZS10YWlsDQptZWNoYW5pc20u ICBBdCB0aGlzIHRpbWUsIG5vIG9uZSBoYXMgaW1wbGVtZW50ZWQgaXQgdGhhdCBJIGFtIGF3YXJl IG9mLg0KRGlzY3Vzc2lvbiB3aXRoIG91ciBBRCBzdWdnZXN0cyB0aGF0IHB1Ymxpc2hpbmcgdGhl IGRvY3VtZW50IHdpdGgNCkV4cGVyaW1lbnRhbCBzdGF0dXMgbWF5IGJlIHJlYXNvbmFibGUgdG8g cHJlc2VydmUgdGhlIHdvcmsgdGhhdCB3ZW50IGludG8NCnRoZSBwcm9wb3NhbC4NCg0KLS0gSmVm Zg0KDQoNCg== --_000_0B1CE01B4FA34536AF415DDC6F510C0Dciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSnVzdCBvbmUgY29tbWVudCBvbiB0 aGVzZSB0d28gZG9jdW1lbnRzLCBpbiByZWdhcmRzIHRvIHRoZSBzdGF0ZSB2YXJpYWJsZXM6DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1iZmQtbXVsdGlwb2ludC0x MCNzZWN0aW9uLTQuNC4xIiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1iZmQtbXVsdGlwb2ludC0xMCNzZWN0aW9uLTQuNC4xPC9hPjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+NC40LjEuICZuYnNw O05ldyBTdGF0ZSBWYXJpYWJsZXM8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPiZuYnNwOyAmbmJzcDtBIG51bWJlciBvZiBzdGF0ZSB2YXJpYWJsZXMgYXJlIGFkZGVk IHRvIHRoZSBiYXNlIHNwZWNpZmljYXRpb24gaW48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7 ICZuYnNwO3N1cHBvcnQgb2YgTXVsdGlwb2ludCBCRkQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBi ZmQuU2Vzc2lvblR5cGU8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgdHlw ZSBvZiB0aGlzIHNlc3Npb24uICZuYnNwO0FsbG93YWJsZSB2YWx1ZXMgYXJlOjwvZGl2Pg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5D TVA6IEhvd2V2ZXIsIHRoaXMgc3RhdGUgKGJmZC5TZXNzaW9uVHlwZSkgdmFyaWFibGUgaXMgYWxy ZWFkeSBkZWZpbmVkIGluIFNCRkQgUkZDIDc4ODA6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjNzg4MCNzZWN0aW9uLTYuMSIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzc4ODAjc2VjdGlvbi02LjE8L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj42LjEuICZuYnNwO05ldyBTdGF0 ZSBWYXJpYWJsZXM8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPiZu YnNwOyAmbmJzcDtBIG5ldyBzdGF0ZSB2YXJpYWJsZSBpcyBhZGRlZCB0byB0aGUgYmFzZSBzcGVj aWZpY2F0aW9uIGluIHN1cHBvcnQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO29m IFMtQkZELjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+Jm5ic3A7ICZuYnNwO28gJm5ic3A7YmZkLlNlc3Npb25UeXBlOiBUaGlzIGlzIGEg bmV3IHN0YXRlIHZhcmlhYmxlIHRoYXQgZGVzY3JpYmVzPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZu YnNwOyAmbmJzcDsgJm5ic3A7IHRoZSB0eXBlIG9mIGEgcGFydGljdWxhciBzZXNzaW9uLiZuYnNw OzwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Q01QOiBTbywg Zm9yIGRyYWZ0LWlldGYtYmZkLW11bHRpcG9pbnQsIEkgc3VnZ2VzdCBhIHBvaW50ZXIgdG8gUkZD IDc4ODAgd2hlcmUmbmJzcDtiZmQuU2Vzc2lvblR5cGUmbmJzcDtpcyBkZWZpbmVkIGluIHRoZSBh ZGRpdGlvbiBvZiBuZXcgdmFsdWVzIHRvIHRoZSBleGlzdGluZyB2YXJpYWJsZS48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkNNUDogU2lt aWxhcmx5OjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt YmZkLW11bHRpcG9pbnQtYWN0aXZlLXRhaWwtMDQjc2VjdGlvbi0zLjMuMSIgY2xhc3M9IiI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmZkLW11bHRpcG9pbnQtYWN0aXZl LXRhaWwtMDQjc2VjdGlvbi0zLjMuMTwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyBiZmQuU2Vzc2lvblR5cGU8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtUaGUgdHlwZSBvZiB0aGlzIHNlc3Npb24gYXMgZGVmaW5lZCBpbjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7W0ktRC5pZXRmLWJmZC1tdWx0 aXBvaW50XS4gJm5ic3A7QSBuZXcgdmFsdWUgaW50cm9kdWNlZCBpczo8L2Rpdj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Q01QOiBU aGUgcG9pbnRlciBhYm92ZSBzaG91bGQgYmUgdG8gUkZDIDc4ODAgYWxzbywgYW5kOjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgYmZkLlNpbGVudFRhaWw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkNNUDogQnV0IHRoaXMgaXMgZGVmaW5lZCBp biBkcmFmdC1pZXRmLWJmZC1tdWx0aXBvaW50PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmZkLW11bHRpcG9pbnQtMTAjc2Vj dGlvbi00LjQuMSIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtYmZkLW11bHRpcG9pbnQtMTAjc2VjdGlvbi00LjQuMTwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5i c3A7IGJmZC5TaWxlbnRUYWlsPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rcyE8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPuKAlCBDYXJsb3MuPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPk9uIEp1biAxOSwgMjAxNywgYXQgMzozOSBQTSwgSmVmZnJleSBIYWFzICZsdDs8YSBo cmVmPSJtYWlsdG86amhhYXNAcGZyYy5vcmciIGNsYXNzPSIiPmpoYWFzQHBmcmMub3JnPC9hPiZn dDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+V29ya2luZyBHcm91cCw8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1iZmQtbXVsdGlwb2ludC0xMCIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtYmZkLW11bHRpcG9pbnQtMTA8L2E+PGJyIGNsYXNzPSIiPg0KPGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmZkLW11bHRpcG9p bnQtYWN0aXZlLXRhaWwtMDQiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWJmZC1tdWx0aXBvaW50LWFjdGl2ZS10YWlsLTA0PC9hPjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZSBCRkQgTXVsdGlwb2ludCBkb2N1bWVu dHMgaGF2ZSBiZWVuIHN0YWJsZSBmb3Igc29tZSB0aW1lLiAmbmJzcDtQcmlvcjxiciBjbGFzcz0i Ij4NCmRpc2N1c3Npb24gYXQgbWVldGluZ3MgaGFzIHN1Z2dlc3RlZCB3ZSBoYXZlIGFuIGltcGxl bWVudGF0aW9uIGZvciB0aGUgbWFpbiA8YnIgY2xhc3M9IiI+DQpwcm90b2NvbCBjb21wb25lbnQu ICZuYnNwO0Fsc28gcGVyIHByaW9yIGRpc2N1c3Npb25zLCB3ZSBzcGxpdCB0aGUgYWN0aXZlLXRh aWw8YnIgY2xhc3M9IiI+DQpjb21wb25lbnQgb2YgdGhlIG9yaWdpbmFsIG11bHRpcG9pbnQgZG9j dW1lbnQgdG8gcGVybWl0IGltcGxlbWVudG9ycyB0byBub3Q8YnIgY2xhc3M9IiI+DQpoYXZlIHRv IHdvcnJ5IGFib3V0IGltcGxlbWVudGluZyBhY3RpdmUtdGFpbCBwcm9jZWR1cmVzIGlmIHRoZXkg d2VyZW4ndDxiciBjbGFzcz0iIj4NCmludGVyZXN0ZWQgaW4gdGhhdCBmZWF0dXJlLjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCldlIGFyZSBzdGFydGluZyBhbiBleHRlbmRlZCBsYXN0IGNh bGwgb24gdGhlc2UgZG9jdW1lbnRzLiAmbmJzcDtUaGUgV0dMQyB3aWxsPGJyIGNsYXNzPSIiPg0K Y29uY2x1ZGUgb24gSnVseSAxNC4gJm5ic3A7VGhpcyBwcm92aWRlcyBhbXBsZSB0aW1lIGZvciBs aXN0IGRpc2N1c3Npb24uICZuYnNwO0lmPGJyIGNsYXNzPSIiPg0KbmVjZXNzYXJ5LCB0aGUgSUVU Ri05OSBtZWV0aW5nIG1heSBwcm92aWRlIGZvciBvcHBvcnR1bml0aWVzIHRvIGNsb3NlIGFueTxi ciBjbGFzcz0iIj4NCmNvbnRlbnRpb3VzIHRlY2huaWNhbCBwb2ludHMuICZuYnNwOyhCRkQgaXMg bm90IGN1cnJlbnRseSBzY2hlZHVsZWQgdG8gbWVldC4pPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KT25lIGl0ZW0gSSB3b3VsZCBsaWtlIHRvIGtpY2sgb2ZmIGlzIHRoZSBkb2N1bWVudCBz dGF0dXMgb2YgdGhlIGFjdGl2ZS10YWlsPGJyIGNsYXNzPSIiPg0KbWVjaGFuaXNtLiAmbmJzcDtB dCB0aGlzIHRpbWUsIG5vIG9uZSBoYXMgaW1wbGVtZW50ZWQgaXQgdGhhdCBJIGFtIGF3YXJlIG9m LjxiciBjbGFzcz0iIj4NCkRpc2N1c3Npb24gd2l0aCBvdXIgQUQgc3VnZ2VzdHMgdGhhdCBwdWJs aXNoaW5nIHRoZSBkb2N1bWVudCB3aXRoPGJyIGNsYXNzPSIiPg0KRXhwZXJpbWVudGFsIHN0YXR1 cyBtYXkgYmUgcmVhc29uYWJsZSB0byBwcmVzZXJ2ZSB0aGUgd29yayB0aGF0IHdlbnQgaW50bzxi ciBjbGFzcz0iIj4NCnRoZSBwcm9wb3NhbC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQot LSBKZWZmPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_0B1CE01B4FA34536AF415DDC6F510C0Dciscocom_-- From nobody Wed Jun 28 11:27:15 2017 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 9A80F12EABD; Wed, 28 Jun 2017 11:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CSrOpvaYmYG; Wed, 28 Jun 2017 11:26:57 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B568124D6C; Wed, 28 Jun 2017 11:26:57 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id u62so35619561pgb.3; Wed, 28 Jun 2017 11:26:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=m6dsZ4qGYo8ZFqOGe5RQorx9Ysy+77k13V7l4vCxFfY=; b=moFCLadjqZcChqxN9e4Iuk0NhZx03Eu23BK9gV7RQwyvRypcPLoZ8BfE57K3DXjDMV T4WZ8Mc13pOo4CloS0ISBrRY0hLovb1mLalI3ToOwiF1/Q2Y0SNzwi6TNaWsphIIQ2ln D4gwRfO6zIovfpO2XdJy1ZUY2CoqzHCBZVzNODSG4+M6PUoGRJwmFuqmIADI+2CDuW6H n6AOE/948std0zHBEin2AgD3Tw2Dud7tFablXwZryAlfpt/R8bUYXdfzNuSQsxY2msUc 9/vp4v6K3HiK3WwCqZn86rmPRCRg80PiibwHPHc7yuTGwE24znCKswjA3rztM6mQDPeB 27/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=m6dsZ4qGYo8ZFqOGe5RQorx9Ysy+77k13V7l4vCxFfY=; b=MPaR6ml7lBItxjm5zQrtB4qFmrzhKaJms3EM4ubZmOMjzfUOLcfdKNKDIWAqzyjyNS rV6mk0bQGsaOt4WlpnREDGLIzwtQFEaT6y7//bKBMt2VKzZu4C2/AjMVqMi2Y4SKy6w8 i2ERSgdTk+ZS7gDrrzwbSPSCUqw40FQHYMVARFPWkxuugcd4bZFlKnHb97Q17va/pmes 9flwgQYo8g/GPD/eCmk3rOBUo8lW1Dogpu00ys4rO5+FHHfKYI7FdCwgXX3tfJR3Nbd7 p1XX3ZQuU7iyocqapSTVlxbUs4W8N7r4WCMkjoNBMqlw/fS4BzVDek+Ex97XiScbRgzq u0sQ== X-Gm-Message-State: AKS2vOzvXhXpZ75afq4woA5dvf9KSzUvxQ5qAAJArpexQreXOaglQc0u uHSEgc6tpgtm6eRtBNWF6/tQRXc4VQ== X-Received: by 10.84.128.67 with SMTP id 61mr13723310pla.246.1498674416015; Wed, 28 Jun 2017 11:26:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.163.236 with HTTP; Wed, 28 Jun 2017 11:26:55 -0700 (PDT) In-Reply-To: <149867388303.7659.15017194825402644385.idtracker@ietfa.amsl.com> References: <149867388303.7659.15017194825402644385.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Wed, 28 Jun 2017 11:26:55 -0700 Message-ID: Subject: Fwd: New Version Notification for draft-mirsky-mpls-p2mp-bfd-01.txt To: "mpls@ietf.org" , "rtg-bfd@ietf.org" , BESS Content-Type: multipart/alternative; boundary="94eb2c124e9e335cf90553095489" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 28 Jun 2017 18:27:00 -0000 --94eb2c124e9e335cf90553095489 Content-Type: text/plain; charset="UTF-8" Dear All, the draft considers use of p2mp BFD, a.k.a. BFD for multipoint networks, to MPLS network. One of use cases - monitoring p2mp MPLS LSP to distribute EVPN BUM traffic. Appreciate your comments, questions, suggestions. Regards, Greg ---------- Forwarded message ---------- From: Date: Wed, Jun 28, 2017 at 11:18 AM Subject: New Version Notification for draft-mirsky-mpls-p2mp-bfd-01.txt To: Gregory Mirsky A new version of I-D, draft-mirsky-mpls-p2mp-bfd-01.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-mirsky-mpls-p2mp-bfd Revision: 01 Title: BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP Document date: 2017-06-28 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-mirsky-mpls-p2mp- bfd-01.txt Status: https://datatracker.ietf.org/doc/draft-mirsky-mpls-p2mp-bfd/ Htmlized: https://tools.ietf.org/html/draft-mirsky-mpls-p2mp-bfd-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-mirsky-mpls- p2mp-bfd-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-mirsky-mpls-p2mp- bfd-01 Abstract: This document describes procedures for using Bidirectional Forwarding Detection (BFD) for multipoint networks to detect data plane failures in Multiprotocol Label Switching (MPLS) point-to-multipoint (p2mp) Label Switched Paths (LSPs). It also describes applicability of out- band solutions to bootstrap a BFD session in this environment. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --94eb2c124e9e335cf90553095489 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,
the draft considers use of p2mp BFD, a.k.a. = BFD for multipoint networks, to MPLS network. One of use cases - monitoring= p2mp MPLS LSP to distribute EVPN BUM traffic.

App= reciate your comments, questions, suggestions.

Reg= ards,
Greg

--= -------- Forwarded message ----------
From: <in= ternet-drafts@ietf.org>
Date: Wed, Jun 28, 2017 at 11:18 A= M
Subject: New Version Notification for draft-mirsky-mpls-p2mp-bfd-01.tx= t
To: Gregory Mirsky <gregim= irsky@gmail.com>



A new version of I-D, draft-mirsky-mpls-p2mp-bfd-01.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mirsky-mpls-p2mp-bfd Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BFD for Multipoint Networks over P= oint-to-Multi-Point MPLS LSP
Document date:=C2=A0 2017-06-28
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-mirsky-mpls= -p2mp-bfd-01.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-mirsky-mpls-p2mp-bfd/=
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:/= /tools.ietf.org/html/draft-mirsky-mpls-p2mp-bfd-01
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-mirsky-mpls-p2mp-b= fd-01
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-mirsky-mpls-p2mp= -bfd-01

Abstract:
=C2=A0 =C2=A0This document describes procedures for using Bidirectional For= warding
=C2=A0 =C2=A0Detection (BFD) for multipoint networks to detect data plane f= ailures
=C2=A0 =C2=A0in Multiprotocol Label Switching (MPLS) point-to-multipoint (p= 2mp)
=C2=A0 =C2=A0Label Switched Paths (LSPs).=C2=A0 It also describes applicabi= lity of out-
=C2=A0 =C2=A0band solutions to bootstrap a BFD session in this environment.=




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--94eb2c124e9e335cf90553095489-- From nobody Wed Jun 28 12:11:01 2017 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 A0BB5129461; Wed, 28 Jun 2017 12:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCrbXkk8-25S; Wed, 28 Jun 2017 12:10:42 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE293128768; Wed, 28 Jun 2017 12:10:42 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id u62so36113215pgb.3; Wed, 28 Jun 2017 12:10:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=PuwEvRwMGd84eH5WjS4GuuHnfwHPP+Cpe7h7ezdl3uc=; b=MflwajqFM5jIOtqLexDgRU9hEF5777viYXz4DszE2WVLKlYb6cmtcU6/3iEq+oSbNm 0W3vo0Cprq7RtENejEyrlCBu0w8vy3BHBdJZl64NpOogcyEyS+EMDcFqjOfkPPGHoyx0 bPJyt1i4OldOjfiMcfvsxZftE/x54arM3ODP/TSyAAWOhkZlCqT3tVHWYkDJl71wF1oi 70s6cMnG7MHZWPOEd0RwMso4I6fkP13iFh+yVwh9a/BgTG+J3/uuYMbBZG0mkawiR2Ru 9HeiUo+94Gm4Y7r+A58cYwtf9mQhYVYrW3lfGJdhveymmP3xKQuGBTrl6hxtXVH1GPyl UTkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=PuwEvRwMGd84eH5WjS4GuuHnfwHPP+Cpe7h7ezdl3uc=; b=g+UeYZX+WVisB29YfbOtwlaNLjmeN+6SC4MC77kMycusUrUP9pfWJN3NeKGrBAhbMZ Bo6H4R569K7U9A3ntJc1f/vjY+zIAWfSWwzp3oWVu+MDrwq1Kb/kaUy1gnDr3ahiMXlp ERlybmzKsa397m2ruQLmQkXMYl7zy/RZ3CwKCUfVWc72nQB2s6sxvkOvZwVaJIMC37Im zyDXRmHsE/T9tlyYC4Xjl2dcMhKJ5EebqdrRHQKffmAlT50r9fApPE1/cD3ORo2YcwY5 IHHnMoLERLm0YfwZudRv0lysD7Pu9VIHsY+pmSQm7w3eYtBDHIjL2SSXTC9q0a1PsWSu shmg== X-Gm-Message-State: AKS2vOy9XTHIBuuIpgSAWmhwRuvg3Y4rBJkqdtX1GqcQVLrnNBCKyXgs Wy5FCSS8o0PIcggEE/9Qg4S9/rmJVg== X-Received: by 10.98.158.139 with SMTP id f11mr12323179pfk.208.1498677042066; Wed, 28 Jun 2017 12:10:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.163.236 with HTTP; Wed, 28 Jun 2017 12:10:41 -0700 (PDT) In-Reply-To: <149867673562.7527.14166881461895121047.idtracker@ietfa.amsl.com> References: <149867673562.7527.14166881461895121047.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Wed, 28 Jun 2017 12:10:41 -0700 Message-ID: Subject: Fwd: New Version Notification for draft-mirsky-bfd-mpls-demand-01.txt To: "mpls@ietf.org" , "rtg-bfd@ietf.org" , spring@ietf.org Content-Type: multipart/alternative; boundary="94eb2c115c10b9ba0b055309f00a" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 28 Jun 2017 19:10:45 -0000 --94eb2c115c10b9ba0b055309f00a Content-Type: text/plain; charset="UTF-8" Dear All, the update addresses comment from Mankamana Mishra. The draft discusses use of BFD in Demand mode over p2p MPLS LSP. Your comments, questions, and suggestions are always welcome and greatly appreciated. Regards, Greg ---------- Forwarded message ---------- From: Date: Wed, Jun 28, 2017 at 12:05 PM Subject: New Version Notification for draft-mirsky-bfd-mpls-demand-01.txt To: Gregory Mirsky A new version of I-D, draft-mirsky-bfd-mpls-demand-01.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-mirsky-bfd-mpls-demand Revision: 01 Title: BFD in Demand Mode over Point-to-Point MPLS LSP Document date: 2017-06-28 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-mirsky-bfd-mpls-d emand-01.txt Status: https://datatracker.ietf.org/doc/draft-mirsky-bfd-mpls-dema nd/ Htmlized: https://tools.ietf.org/html/draft-mirsky-bfd-mpls-demand-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-mirsky-bfd-mpls -demand-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-mirsky-bfd-mpls-dem and-01 Abstract: This document describes procedures for using Bidirectional Forwarding Detection (BFD) in Demand mode to detect data plane failures in Multiprotocol Label Switching (MPLS) point-to-point Label Switched Paths. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --94eb2c115c10b9ba0b055309f00a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,
the update addresses comment from Mankamana = Mishra.
The draft discusses use of BFD in Demand mode over p2p MP= LS LSP.
Your comments, questions, and suggestions are always welc= ome and greatly appreciated.

Regards,
Gr= eg

---------- Forwarded message --= --------
From: <= internet-draf= ts@ietf.org>
Date: Wed, Jun 28, 2017 at 12:05 PM
Subjec= t: New Version Notification for draft-mirsky-bfd-mpls-demand-01.txtTo: Gregory Mirsky <gregimirsky@gmail.com>



A new version of I-D, draft-mirsky-bfd-mpls-demand-01.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mirsky-bfd-mpls-demand<= br> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BFD in Demand Mode over Point-to-P= oint MPLS LSP
Document date:=C2=A0 2017-06-28
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-mirsky-bf= d-mpls-demand-01.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-mirsky-bfd-mpls-demand/=
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https= ://tools.ietf.org/html/draft-mirsky-bfd-mpls-demand-01
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-mirsky-bfd-mpls-= demand-01
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-mirsky-bfd-mpls= -demand-01

Abstract:
=C2=A0 =C2=A0This document describes procedures for using Bidirectional For= warding
=C2=A0 =C2=A0Detection (BFD) in Demand mode to detect data plane failures i= n
=C2=A0 =C2=A0Multiprotocol Label Switching (MPLS) point-to-point Label Swit= ched
=C2=A0 =C2=A0Paths.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--94eb2c115c10b9ba0b055309f00a-- From nobody Wed Jun 28 17:03:38 2017 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B8912EA94; Wed, 28 Jun 2017 17:03:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtg-bfd@ietf.org Subject: I-D Action: draft-ietf-bfd-optimizing-authentication-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149869461687.6623.11275953193810775381@ietfa.amsl.com> Date: Wed, 28 Jun 2017 17:03:36 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 00:03:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection of the IETF. Title : Optimizing BFD Authentication Authors : Mahesh Jethanandani Ashesh Mishra Ankur Saxena Manav Bhatia Filename : draft-ietf-bfd-optimizing-authentication-03.txt Pages : 8 Date : 2017-06-28 Abstract: This document describes an optimization to BFD Authentication as described in Section 6.7 of BFD [RFC5880]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bfd-optimizing-authentication-03 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-optimizing-authentication-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-optimizing-authentication-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 30 12:56:00 2017 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01DB912E957; Fri, 30 Jun 2017 12:55:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtg-bfd@ietf.org Subject: I-D Action: draft-ietf-bfd-yang-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149885255897.4584.3006333522740435620@ietfa.amsl.com> Date: Fri, 30 Jun 2017 12:55:59 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 19:55:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection of the IETF. Title : YANG Data Model for Bidirectional Forwarding Detection (BFD) Authors : Reshad Rahman Lianshu Zheng Mahesh Jethanandani Santosh Pallagatti Greg Mirsky Filename : draft-ietf-bfd-yang-06.txt Pages : 59 Date : 2017-06-30 Abstract: This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bfd-yang-06 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-yang-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-yang-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/