Re: IETF OSPF YANG and BFD Configuration

"Reshad Rahman (rrahman)" <rrahman@cisco.com> Fri, 19 May 2017 02:36 UTC

Return-Path: <rrahman@cisco.com>
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 822081293EB; Thu, 18 May 2017 19:36:34 -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, 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, 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 TCh4rr04vwZd; Thu, 18 May 2017 19:36:32 -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 9F25812940F; Thu, 18 May 2017 19:31:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11012; q=dns/txt; s=iport; t=1495161100; x=1496370700; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sV1z6ySG6zZBJ7knkjb45+MxVcetM1ku5YPmUjuy0iQ=; b=V4+qnCDd7Uag4ca1xYHgwNv/iWBqcIQsciO+vidgGJzaeqtkXK5Gq5vu w//aXSFkyxb+DFBlrCVcdUnoB4YFH9OY6wYKiFH1Zqc+r/kkvn2jOPKCE +Ee5tdSZZVY0mzKMR+yclYCIzZZrGt22veNcFzA2FAYmWGtpy7Pacm/SS Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAADHWB5Z/4gNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5ngW4HjX+RbogniBeFOIIPhiQChXA/GAECAQEBAQEBAWsohRg?= =?us-ascii?q?BAQEBA3kQAgEIDgMDAQIoByERFAkIAgQBDQWKCwMVsH2HNA2DWgEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAR2GX4FdgxyCVIIvBoVMBZBqhgqGZDsBjkiEU5Fuiy+JFgE?= =?us-ascii?q?fOIEKcBVGhHccgWN2hyWBDQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.38,361,1491264000"; d="scan'208,217";a="427935104"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 May 2017 02:31:39 +0000
Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v4J2VdcK020230 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 19 May 2017 02:31:39 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 18 May 2017 21:31:38 -0500
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1210.000; Thu, 18 May 2017 21:31:38 -0500
From: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>, "Acee Lindem (acee)" <acee@cisco.com>
CC: Jeffrey Haas <jhaas@juniper.net>, OSPF WG List <ospf@ietf.org>, "draft-ietf-bfd-yang@ietf.org" <draft-ietf-bfd-yang@ietf.org>, "draft-ietf-ospf-yang@ietf.org" <draft-ietf-ospf-yang@ietf.org>, "rtg-bfd@ietf. org" <rtg-bfd@ietf.org>
Subject: Re: IETF OSPF YANG and BFD Configuration
Thread-Topic: IETF OSPF YANG and BFD Configuration
Thread-Index: AQHS0B8wmci/wURKg06fgHPFpmH9rqH68JcAgAAP/gA=
Date: Fri, 19 May 2017 02:31:38 +0000
Message-ID: <D5438DD9.298FE6%rrahman@cisco.com>
References: <D5436DE8.AF5B7%acee@cisco.com> <38DEB571-2918-4464-B18A-71B24221772F@gmail.com> <47325462-2430-4197-AA8D-D3FEF74A834D@gmail.com>
In-Reply-To: <47325462-2430-4197-AA8D-D3FEF74A834D@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.1.161129
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.247.144]
Content-Type: multipart/alternative; boundary="_000_D5438DD9298FE6rrahmanciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/kU0oaOkXc_Bj3P3wSsUFpLRq2LQ>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 May 2017 02:36:34 -0000

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<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@juniper.net<mailto:jhaas@juniper.net>>, OSPF WG List <ospf@ietf.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-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: <alias-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>>, <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>>, <santosh.pallagatti@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.com<mailto: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<mailto: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<mailto:mjethanandani@gmail.com>




Mahesh Jethanandani
mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>