Re: IETF OSPF YANG and BFD Configuration

Mahesh Jethanandani <mjethanandani@gmail.com> Tue, 20 June 2017 17:50 UTC

Return-Path: <mjethanandani@gmail.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 DA39B124BFA; Tue, 20 Jun 2017 10:50:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 hQ6JkXv70tsv; Tue, 20 Jun 2017 10:50:37 -0700 (PDT)
Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03935129496; Tue, 20 Jun 2017 10:50:18 -0700 (PDT)
Received: by mail-pf0-x244.google.com with SMTP id s66so24827148pfs.2; Tue, 20 Jun 2017 10:50:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fvqjaSf0CDg1k1IH/2A7d2bNHAbmkf7gucUMy4lAVjE=; b=DyMRhNWCQoRjnJXOu0E97jmJ/ZoRp8qSQlOQLVM73LJMDy7zOgfCTQrdtXluKdwf1b x6IPo1UXUWfI9zTMAoJRk2APjGJRU/rGUXnBjYrQr3gZXrh3bpde+qOY4yHAsCfmhexJ uPxlwSRzNC8IYCpAWL+g8264i2I4QoGV8dS/U8vB9WWc99GfLK62UZo3XrfkhWYzrGwm Gdratc50gjUf4WpWq0a4Z74buq7B13ft5miCFwENoTKO3E/sf8QXvHIdPlx5aZClmOHX c4CPpme2pWbX+cphSGeXfzuyIC9jkw3hjRrtQa9XgMjTaDPaZHmXDPzlJ8l4hiLKAKk3 jlEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fvqjaSf0CDg1k1IH/2A7d2bNHAbmkf7gucUMy4lAVjE=; b=eBka5+tDA98sl7ec+7IHsxBcFFKRuohE20I10L4GG9ZowqCewqaX4u3k4RiYEyYL/F 8VFjELU4+tz4QvNB+BFNgIEobpB4xip/UnWY3OzGxwIVjaEcRoalfbLz7PSsaAiChGic 1Vbb2CyjOVDR8znqIAssVy1NNt58KkFHWqaXgaomgGYW1igwaT1LxJiTvO0+rRNQeAo9 KvxLsu1fVfftHeFlgVr6TuiI1+zeQMWTcfGqpcf4/Q/Ok7pzzVXv/4tLhyflvWrI+FOt /4mbras8XN/t5yt9YnKAzGHsYU6reHm45ZlgWab0EsUj1HnytzJMoGy4ZeUbSTB8G15I Hc7Q==
X-Gm-Message-State: AKS2vOwvyq78qGUKslH/R61+yp4B/ZDHTmpf4eeWxh7dXEiufoU4LMm/ 3pAp943awaxI6Q==
X-Received: by 10.101.89.2 with SMTP id f2mr32956081pgu.237.1497981017501; Tue, 20 Jun 2017 10:50:17 -0700 (PDT)
Received: from sjc-mahesh-nitro7.cisco.com ([128.107.241.181]) by smtp.gmail.com with ESMTPSA id n26sm30487445pfj.114.2017.06.20.10.50.16 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 20 Jun 2017 10:50:16 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: IETF OSPF YANG and BFD Configuration
From: Mahesh Jethanandani <mjethanandani@gmail.com>
In-Reply-To: <D56EB8CF.B5E9E%acee@cisco.com>
Date: Tue, 20 Jun 2017 10:50:15 -0700
Cc: Jeffrey Haas <jhaas@pfrc.org>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <93CD6650-AE40-4CD2-AE3F-F3FD0B287CD4@gmail.com>
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> <20170620145856.GC22550@pfrc.org> <D56EB8CF.B5E9E%acee@cisco.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/g98bbKD5c3sPag0oT3RXMBKgyo0>
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 17:50:40 -0000

> On Jun 20, 2017, at 8:40 AM, Acee Lindem (acee) <acee@cisco.com>; wrote:
> 
> Hi Jeff, 
> 
> On 6/20/17, 10:58 AM, "Jeffrey Haas" <jhaas@pfrc.org>; wrote:
> 
>> 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.
> 
> 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
> model. 

Let me work with Reshad to suggest what IGP could suggest to BFD in their construct, and have BFP pick what it believes would be the right set of parameters to be able to support most of the IGPs over the given BFD session. Whether we add it in the current model or add it later as an augmentation could then be decided separately.

> 
> Thanks,
> Acee 
> 
> 
>> 
>> -- Jeff
> 

Mahesh Jethanandani
mjethanandani@gmail.com