Re: [OSPF] IETF OSPF YANG and BFD Configuration

"Acee Lindem (acee)" <> Tue, 20 June 2017 15:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D746B131BB6; Tue, 20 Jun 2017 08:44:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.523
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4OVdT6y4HtVt; Tue, 20 Jun 2017 08:44:49 -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 87AD9131A74; Tue, 20 Jun 2017 08:40:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; 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-AV: E=Sophos;i="5.39,364,1493683200"; d="scan'208";a="441055692"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jun 2017 15:40:29 +0000
Received: from ( []) by (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 ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 20 Jun 2017 11:40:28 -0400
Received: from ([]) by ([]) 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 <>, "" <>, "" <>, "" <>
Thread-Topic: IETF OSPF YANG and BFD Configuration
Thread-Index: AQHS6Syo68r6z3GylU2z1PR9VYBctaItArCAgAENr4CAAAJjAIAACW0A///IiAA=
Date: Tue, 20 Jun 2017 15:40:28 +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: Tue, 20 Jun 2017 15:44:51 -0000

Hi Jeff, 

On 6/20/17, 10:58 AM, "Jeffrey Haas" <> wrote:

>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
>> > 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
>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
>for how this is likely to play out in terms of BFD protocol
>However, configuration and operational models tend to evolve much more
>slowly.  (And I certainly don't need to tell you that.)  Thus, I'm
>at this space a bit to attempt to do some future proofing.
>As we noted earlier in thread, this likely at least encourages
>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.

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


>-- Jeff