Re: Working Group Last Call on BFD YANG model, RFC 9127-bis ending 20 December, 2021

[Jeffrey Haas <[e-mail]>]

Obsoletes is probably the best status.

(For the Working Group)
Mahesh is tracking this work in github:
https://github.com/mjethanandani/rfc9127-bis/ <https://github.com/mjethanandani/rfc9127-bis/>

I've opened an issue for this.

-- Jeff


> On Dec 7, 2021, at 9:14 AM, Reshad Rahman <[e-mail]> wrote:
> 
> Should RFC9127-bis obsolete RFC9127?
> 
> Regards,
> Reshad.
> 
> On Tuesday, December 7, 2021, 08:43:44 AM EST, Jeffrey Haas <[e-mail]> wrote:
> 
> 
> Working Group,
> 
> While some explanation is required, the request to the Working Group is very
> simple: Please review this minor update to the recently published BFD YANG
> module and offer your comments whether we should head to rapid publication.
> 
> This last call ends 20 December.
> 
> ---
> 
> The history:
> This module defines a YANG grouping, "client-cfg-parms".  The intent of that
> grouping is to provide a common user experience in IETF YANG modules that
> want to use BFD.  It provides a consistent set of leaf nodes that can be
> used by those client protocols so you don't have to remember whether 
> it's "enable" or "enabled", what a multiplier is called, and where the
> timers live.
> 
> This grouping is currently present in the RIP YANG model.  It is also in the
> RFC Editor's queue for the PIM, OSPF, and ISIS modules.  The BGP model
> intends to use this grouping.
> 
> A small issue was noted shortly after publication that even though the
> grouping is correct, its structure in RFC 9127 was awkward for
> implementations that do not use per-client configuration of BFD parameters.
> 
> Using the YANG tree for ietf-bfd-mpls included in the module from the -bis,
> consider the following:
>           |  +--rw enabled?                          boolean
>           |  +--rw local-multiplier?                multiplier
>           |  +--rw (interval-config-type)?
>           |  |  +--:(tx-rx-intervals)
>           |  |  |  +--rw desired-min-tx-interval?    uint32
>           |  |  |  +--rw required-min-rx-interval?  uint32
>           |  |  +--:(single-interval) {single-minimum-interval}?
>           |  |    +--rw min-interval?              uint32
> 
> There are two commonly deployed styles of BFD provisioning in the industry:
> - Fully centralized.  In this case, BFD clients only need to indicate that
>   they have "enabled" BFD to be used in that case.  The sessions are
>   configured at global scope.  (E.g. "protocols bfd")
> - Per-client configuration.  In this case, the client will also want to
>   indicate that it supports local configuration of parameters such as the
>   multiplier, and intervals.
> 
> In the current structure of RFC 9127, an implementation that uses fully
> centralized mode will need to create a YANG deviation for each use of BFD's
> client-cfg-parms.  While this was considered acceptable during the original
> drafting of the grouping in the BFD YANG module, current practices have
> evolved.
> 
> The fix, and the very small change to RFC 9127 in this -bis, is to add a new
> YANG feature, "client-base-cfg-parms", and take the client configuration
> parameters and predicate it on that feature.
> 
> This small change permits all of the client YANG modules listed above to
> inherit this feature behavior with no changes to those client modules.
> 
> The following section from 9127-bis states the change as well:
> 
> : Updates since RFC 9127
> : 
> :    This version of the draft updates the 'ietf-bfd-types' module to
> :    define a new feature called 'client-base-cfg-parms and a 'if-feature'
> :    statement that conditionally includes definition of parameters such
> :    as 'multiplier' or 'desired-min-tx-interval'.  The feature statement
> :    allows YANG implementations of protocol such as OSPF, ISIS, PIM and
> :    BGP, to support both a model where such parameters are not needed,
> :    such as when multiple BFD sessions are supported over a given
> :    interface, as well as when they need to be defined per session.
> 
> -- Jeff
> 
> ----- Forwarded message from [e-mail] <mailto:[e-mail]> -----
> 
> Date: Tue, 07 Dec 2021 04:26:39 -0800
> From: [e-mail] <mailto:[e-mail]>
> To: [e-mail] <mailto:[e-mail]>
> Cc: [e-mail] <mailto:[e-mail]>
> Subject: I-D Action: draft-ietf-bfd-rfc9127-bis-00.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Bidirectional Forwarding Detection WG of the IETF.
> 
>         Title          : YANG Data Model for Bidirectional Forwarding Detection (BFD)
>         Authors        : Reshad Rahman
>                           Mahesh Jethanandani
>                           Lianshu Zheng
>                           Santosh Pallagatti
>                           Greg Mirsky
>     Filename        : draft-ietf-bfd-rfc9127-bis-00.txt
>     Pages          : 70
>     Date            : 2021-12-06
> 
> Abstract:
>   This document defines a YANG data model that can be used to configure
>   and manage Bidirectional Forwarding Detection (BFD).
> 
>   The YANG modules in this document conform to the Network Management
>   Datastore Architecture (NMDA) (RFC 8342).
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bfd-rfc9127-bis/ <https://datatracker.ietf.org/doc/draft-ietf-bfd-rfc9127-bis/>
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-rfc9127-bis-00 <https://datatracker.ietf.org/doc/html/draft-ietf-bfd-rfc9127-bis-00>
> 
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
> 
> 
> ----- End forwarded message -----
>