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

[Jeffrey Haas <[e-mail]>]

Tom,

On Tue, Dec 07, 2021 at 05:22:41PM +0000, t petch wrote:
> On 07/12/2021 13:43, Jeffrey Haas 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.
> 
> I am not clear that this is a valid update to a YANG module as per
> RFC7950; if not, then the name of the YANG module must be changed,
> not just its revision date.

This was our motivation to run this immediately by the yang doctors.
They've reviewed and appear to approve of this effort.

They recognize this is a violation of the intent of that RFC, but also given
the timing that this is probably the best fix.

> If it is valid, then the -bis will need quite a lot of updates to
> make it legal e.g. almost every instance of 9127 - something in
> excess of 40 - becomes XXXX.

Sorry, what instances of 9127 are you talking about?  The RFC just shipped.
The items in the RFC Editor cluster that have been paused because of this
issue are the only ones besides the RIP module we're expected to have
current impact.

> I also think that RFC9127 would need to
> stay current for the sake of existing software.

The RFC shipped weeks ago.
Any implementation that did the pre-RFC version of it that didn't support
the leaves that are being made conditional on the feature already had to do
deviations.

If you have a pointer to an implementation of RFC 9127 as a counter point,
the YANG doctors would certainly be interested in that input.

-- Jeff


> 
> Tom Petch
> 
> 
>  ---
> >
> >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] -----
> >
> >Date: Tue, 07 Dec 2021 04:26:39 -0800
> >From: [e-mail]
> >To: [e-mail]
> >Cc: [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/
> >
> >There is also an htmlized version available at:
> >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 -----
> >
> >.
> >