Re: IETF OSPF YANG and BFD Configuration

Jeffrey Haas <jhaas@pfrc.org> Tue, 20 June 2017 14:12 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 CA75012EC57; Tue, 20 Jun 2017 07:12: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 MJ-UG4aBlnil; Tue, 20 Jun 2017 07:12:06 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC3112EC16; Tue, 20 Jun 2017 07:12:06 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id EF7251E37E; Tue, 20 Jun 2017 10:20:56 -0400 (EDT)
Date: Tue, 20 Jun 2017 10:20:56 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Acee Lindem (acee)" <acee@cisco.com>
Cc: "Reshad Rahman (rrahman)" <rrahman@cisco.com>, Mahesh Jethanandani <mjethanandani@gmail.com>, Jeffrey Haas <jhaas@juniper.net>, OSPF WG List <ospf@ietf.org>, "rtg-bfd@ietf. org" <rtg-bfd@ietf.org>, "draft-ietf-bfd-yang@ietf.org" <draft-ietf-bfd-yang@ietf.org>, "draft-ietf-ospf-yang@ietf.org" <draft-ietf-ospf-yang@ietf.org>
Subject: Re: IETF OSPF YANG and BFD Configuration
Message-ID: <20170620142056.GB22550@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> <D56DC1C7.B5A8F%acee@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <D56DC1C7.B5A8F%acee@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/OzFQlnwv89ar7DDLcZAJ5Rx4D54>
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:12:08 -0000

Acee,

On Mon, Jun 19, 2017 at 10:10:43PM +0000, Acee Lindem (acee) wrote:
> I don’t really feel there is a strong requirement to support different
> timers values per protocol even though several implementations allow
> different protocol specific values to be configured (with varying
> behaviors). 
> 
> If there were such a requirement, I would think it would be better
> satisfied by extending the BFD model session key with an additional
> identifier, e.g., <interface/dst-ip/instance>.

I suspect multi-instancing may be where this conversation goes.

> IMO, this would be
> preferable to allowing the details of BFD to permeate into all the other
> protocol models. This would require configuration of the instance rather
> than a boolean in the protocols.

My lingering concern is whether the client protocol may have preferences
about what session to use when such multi-instancing is permitted.
Minimally this would require some sort of Yang reference to the specific
instance.

As I'm noting in the other response, do we really expect BFD Yang model
users to pre-provision every single OSPF/ISIS adjacency in the config
stanza?  Likely, no.

What I tend to expect is a template being used for a service profile.  We
don't currently have such a thing.

> Acee 

-- Jeff