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

[Mahesh Jethanandani <[e-mail]>]

And a fix for it lives in GitHub at the following location. Will post the draft once we have received all the comments.

https://github.com/mjethanandani/rfc9127-bis/pull/7

> On Dec 7, 2021, at 6:31 AM, Jeffrey Haas <[e-mail]> wrote:
> 
> 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] <mailto:[e-mail]>> wrote:
>> 
>> Should RFC9127-bis obsolete RFC9127?
>> 
>> Regards,
>> Reshad.
>> 
>> On Tuesday, December 7, 2021, 08:43:44 AM EST, Jeffrey Haas <[e-mail] <mailto:[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 <http://rsync.ietf.org/>::internet-drafts
>> 
>> 
>> ----- End forwarded message -----
>> 
> 


Mahesh Jethanandani
[e-mail]