Re: [OSPF] IETF OSPF YANG and BFD Configuration

"Acee Lindem (acee)" <> Mon, 19 June 2017 22:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 62A16129329; Mon, 19 Jun 2017 15:10:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.522
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4NAeNl0p9HEO; Mon, 19 Jun 2017 15:10:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 522EB1200CF; Mon, 19 Jun 2017 15:10:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; 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-AV: E=Sophos;i="5.39,363,1493683200"; d="scan'208";a="439813834"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jun 2017 22:10:45 +0000
Received: from ( []) by (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 ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 19 Jun 2017 18:10:44 -0400
Received: from ([]) by ([]) 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" <>, "" <>, "" <>
Thread-Topic: IETF OSPF YANG and BFD Configuration
Thread-Index: AQHS6Syo68r6z3GylU2z1PR9VYBctaIsv2uA
Date: Mon, 19 Jun 2017 22:10:43 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [OSPF] IETF OSPF YANG and BFD Configuration
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Jun 2017 22:10:49 -0000

Hi Jeff, 

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

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., <interface/dst-ip/instance>. 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.


On 6/19/17, 2: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
>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
>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
>To pick the example of Juniper's configuration, if OSPF and eBGP were
>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
>prior list discussions on the situation where clients have different
>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 <<>>,
>> 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
>> Mahesh Jethanandani