RE: IETF OSPF YANG and BFD Configuration

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Tue, 20 June 2017 14:25 UTC

Return-Path: <ginsberg@cisco.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 68A4912ECA8; Tue, 20 Jun 2017 07:25:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 ejxTGR-cob2I; Tue, 20 Jun 2017 07:25:14 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F30512EC80; Tue, 20 Jun 2017 07:25:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6606; q=dns/txt; s=iport; t=1497968714; x=1499178314; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YdJOnKVcy2qF8nAhf1+DHh4kfv/D9tct5/0G4ZC4CTc=; b=gLO7yeAOgLfCBU95X9AWz7B+r1MBNh3oMPUwysCyYzOfBJOX+IQtbSFf 1MAUGDF7QGAZtZvZYxF5rBhtNLtmMm3LeR6IyWMKRKnsUn2MkPBNAsu8/ FotNKlvUzN71O4WH2fxyC4KyyKHsBc7nxeGqFhaeCKV9IlCLVQFDlKPjG c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DGAAAaL0lZ/5FdJa1cGQEBAQEBAQEBAQEBBwEBAQEBgystgW8Hg2SKGZF/lXiCEYYkAhqCRz8YAQIBAQEBAQEBayiFGAEBAQECASMREzIFBwQCAQgOAwQBAQECAiMDAgICMBQBCAgCBAENBQiKHAisKoImgz6IHQEBAQEBAQEBAQEBAQEBAQEBAQEBAR2BC4Vhg3iBDId7gmEFlxyHRQKTV4IRhUiKPpUMAR84gQp0FUmHDgF2iEwBgQwBAQE
X-IronPort-AV: E=Sophos;i="5.39,364,1493683200"; d="scan'208";a="438156439"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jun 2017 14:25:13 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v5KEPDoh028611 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 20 Jun 2017 14:25:13 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 20 Jun 2017 09:25:12 -0500
Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Tue, 20 Jun 2017 09:25:12 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Jeffrey Haas <jhaas@pfrc.org>, Mahesh Jethanandani <mjethanandani@gmail.com>
CC: 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
Thread-Topic: IETF OSPF YANG and BFD Configuration
Thread-Index: AQHS6c6lZ7x0VIOb/06pMKntEFyJQ6ItzFjg
Date: Tue, 20 Jun 2017 14:25:12 +0000
Message-ID: <d4d161f4a91d4a479ed71affca9170c6@XCH-ALN-001.cisco.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>
In-Reply-To: <20170620141639.GA22550@pfrc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [128.107.151.16]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/badtfQtaoaJW-L9NNByW1w-aji8>
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:25:17 -0000

Jeff -

Inline.

> -----Original Message-----
> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas
> Sent: Tuesday, June 20, 2017 7:17 AM
> To: Mahesh Jethanandani
> Cc: Jeffrey Haas; Reshad Rahman (rrahman); OSPF WG List; draft-ietf-ospf-
> yang@ietf.org; rtg-bfd@ietf.org; draft-ietf-bfd-yang@ietf.org; Acee Lindem
> (acee)
> Subject: Re: IETF OSPF YANG and BFD Configuration
> 
> Mahesh,
> 
> On Mon, Jun 19, 2017 at 03:11:25PM -0700, Mahesh Jethanandani wrote:
> > > On Jun 19, 2017, at 11:57 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
> > > 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?
> 
> Potentially mode (async vs. echo) and authentication.  However, I believe
> timer granularity is the biggest one.
> 
> > > 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.
> 
> Consider a broadcast network segment such as Ethernet.
> Consider a few dozen routers on such a segment.
> 
> Is it your expectation that an IGP would require each of those routers to be
> manually configured in the Yang module a priori?  That is, after all, much of
> the point of an IGP: automatic discovery.
> 
> > > 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.
> 
> The distinguishing point is configuration vs. operational state.  The current
> model doesn't permit more than one set of parameters to be provisioned
> even if the implementation may choose to instantiate exactly one session.
> 
> > > 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.
> 
> Please note that I raise this point mostly because of prior discussion.  I'm well
> aware of the headaches this currently causes:
> 
> 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.

   Les

> But moving to what *is* rather than what should be, if there are two
> different timing setups for the same endpoint: If you deprovision the more
> aggressive timer, the session should likely renegotiate to the less aggressive
> one rather than drop.
> 
> -- Jeff