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

[t petch <[e-mail]>]

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.

uses base-cfg-parms
is currently unconditional so software written to 9127 can expect the 
grouping to be there.  Software written to 9127-bis may choose to not 
support the feature and so the grouping need not be there.  If the 
leaves were mandatory then this would be a breach of the RFC7950 update 
rules and not allowed; but the leaves are not mandatory for any reason 
that I can see (although I have not checked how the bfd-types module is 
used in the work of other WG) so I am unclear whether or not this is a 
permitted update.

I think that this is one for the NETMOD list to consider.

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. I also think that RFC9127 would need to stay current for 
the sake of existing software.

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 -----
>
> .
>