Re: [OSPF] IETF OSPF YANG and BFD Configuration

Mahesh Jethanandani <> Mon, 19 June 2017 22:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0CF221200CF; Mon, 19 Jun 2017 15:11:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2pbljjKxfvUP; Mon, 19 Jun 2017 15:11:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D3C521294D8; Mon, 19 Jun 2017 15:11:28 -0700 (PDT)
Received: by with SMTP id v74so10475848oie.2; Mon, 19 Jun 2017 15:11:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id e132mr6573587oic.9.1497910288187; Mon, 19 Jun 2017 15:11:28 -0700 (PDT)
Received: from ( []) by with ESMTPSA id w193sm5461617oie.37.2017. (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\))
From: Mahesh Jethanandani <>
In-Reply-To: <>
Date: Mon, 19 Jun 2017 15:11:25 -0700
Cc: Reshad Rahman <>, "Acee Lindem (acee)" <>, Jeffrey Haas <>, OSPF WG List <>, "" <>, "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Jeffrey Haas <>
X-Mailer: Apple Mail (2.3124)
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:11:32 -0000

> On Jun 19, 2017, at 11:57 AM, 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 issue that I hear most is the timer granularity. Is there something else?

> 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.
> 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.

> 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. 

> -- 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

Mahesh Jethanandani