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 <jh...@pfrc.org> 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 <res...@yahoo.com >> <mailto:res...@yahoo.com>> wrote: >> >> Should RFC9127-bis obsolete RFC9127? >> >> Regards, >> Reshad. >> >> On Tuesday, December 7, 2021, 08:43:44 AM EST, Jeffrey Haas <jh...@pfrc.org >> <mailto:jh...@pfrc.org>> 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 internet-dra...@ietf.org >> <mailto:internet-dra...@ietf.org> ----- >> >> Date: Tue, 07 Dec 2021 04:26:39 -0800 >> From: internet-dra...@ietf.org <mailto:internet-dra...@ietf.org> >> To: i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org> >> Cc: rtg-bfd@ietf.org <mailto:rtg-bfd@ietf.org> >> 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 mjethanand...@gmail.com
