Re: IETF OSPF YANG and BFD Configuration

Jeffrey Haas <jhaas@pfrc.org> Tue, 20 June 2017 14:50 UTC

Return-Path: <jhaas@slice.pfrc.org>
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 <jhaas@pfrc.org>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: Mahesh Jethanandani <mjethanandani@gmail.com>, Jeffrey Haas <jhaas@juniper.net>, "Reshad Rahman (rrahman)" <rrahman@cisco.com>, OSPF WG List <ospf@ietf.org>, "draft-ietf-ospf-yang@ietf.org" <draft-ietf-ospf-yang@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "draft-ietf-bfd-yang@ietf.org" <draft-ietf-bfd-yang@ietf.org>, "Acee Lindem (acee)" <acee@cisco.com>
Subject: Re: IETF OSPF YANG and BFD Configuration
Message-ID: <20170620145856.GC22550@pfrc.org>
References: <D5436DE8.AF5B7%acee@cisco.com> <38DEB571-2918-4464-B18A-71B24221772F@gmail.com> <47325462-2430-4197-AA8D-D3FEF74A834D@gmail.com> <D5438DD9.298FE6%rrahman@cisco.com> <20170619185715.GB22146@pfrc.org> <0578CD07-8678-4FF2-939F-0EF6F68CE34A@gmail.com> <20170620141639.GA22550@pfrc.org> <d4d161f4a91d4a479ed71affca9170c6@XCH-ALN-001.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <d4d161f4a91d4a479ed71affca9170c6@XCH-ALN-001.cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/p6N8O_LasowoaewyMM8RhXH_egU>
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: 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