Re: [yang-doctors] Dealing with BFD RFC 9127 client-cfg-parms for PIM, OSPF, ISIS and other BFD clients on some platforms

["Rob Wilton (rwilton)" <[e-mail]>]

YANG Doctors,

We unfortunately have a bug in the BFD YANG Model that has just been published in RFC 9127.  Because this RFC has only just been published the expectation is that are no implementations of it yet.

The local-multiplier and interval-config-type configuration shown in the tree diagram below should be under an if-feature (explanation in the email below).  Adding an if-feature is classified as a change that is not allowed under RFC 7950 section 11.  The proposal is to quickly bis RFC 9127 and modify the BFD YANG Model to add in the two missing if-feature statements.  Although this violates the MUST statement in RFC 7950, I believe that this is pragmatically the right thing to do currently and is in line with the current direction of the versioning work in Netmod (if that work achieves consensus).

Note, we considered an alternative approach of deprecate these nodes and put those leaves under a new if-feature predicated container but doing this to a newly published module seems excessive.

Hence, are any of the YANG doctors opposed to the proposed approach of making the non-backwards-compatible change and just fixing the BFD YANG module?

We would like to please conclude on this quickly since the 3 protocol YANG modules (PIM, OSPF, ISIS) are all in Auth48 and we do not want to unduly delay publishing them.  Hence, if you have objections then please can you send them by Friday 12th November.  Emails supporting this approach would also be welcome.

Thank for your input.

Regards,
Rob


-----Original Message-----
From: Jeffrey Haas <[e-mail]> 
Sent: 04 November 2021 20:32
To: Rob Wilton (rwilton) <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; <[e-mail]> <[e-mail]>rg>; Reshad Rahman <[e-mail]>om>; Mahesh Jethanandani <[e-mail]>
Subject: Dealing with BFD RFC 9127 client-cfg-parms for PIM, OSPF, ISIS and other BFD clients on some platforms

[Many of you have gotten this in different contexts.  This email is at the ADs' request to make sure we're all on the same page.]

Background:
BFD is an IETF "plumbing protocol".  Much like other bits of YANG plumbing such as the routing-config model and the policy model, there's an incentive to consistently implement configuration state in each of the consumers of the feature.  Since the YANG set of modules from IETF is IETF's "CLI", consistency of user-experience is also helpful. 

The YANG grouping, client-cfg-parms in RFC 9127, was intended to provide this in any BFD client users. Many of those are IETF protocols that have YANG modules in progress.

Because implementors do things more than one way, there are two common models by which BFD is used:
- A "centralized" model, think "protocol bfd", where BFD sessions and their parameters are provisioned.  Client users simply say "bfd enabled" in their own configuration stanzas.  Cisco is an example of this model.
- Per-client users.  In this model, each client protocol configures BFD use AND also the session parameters such as timing.  Juniper is an example of this model.

Using the ISIS model as an example of how this grouping expands:

          +--rw bfd {bfd}?
          |  +--rw enable?                           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

In the centralized model, only the "enable" leaf is needed.  The other three leaves (max two depending on how the interval-config-type feature manifests) are only needed by the implementations supporting per-client configuration.

Problem Statement:
While resuming work on the BGP model, I noted that the above.  The concern I had was "what had we decided with regard to support each of these models?  Since it's been quite some time since this work was done in BFD, I'd forgotten the discussion and in somewhat of a panic, contacted Acee as an author of one of the impacted models to figure out what we should do.

I have a vague memory that this topic had come up in one of the last IETFs we were able to gather and my memory was that simply using per-vendor deviations on the per-client nodes was sufficient.  However, the popularity - or lack thereof - of deviations has changed over time.

Acee had proposed an update to the client use of the BFD configuration state to predicate the per-client leaves on an "if-feature".  His original proposal did this if-feature by moving the BFD base-cfg-parms grouping into a container.  

While discussing this with Rob, we realized that this was also a structural change of BFD in each of the impacted YANG models, which was problematic.  Minimally, we'd want the Working Groups to look at the changes to see if it's okay or not.  From discussions with Mahesh on BGP, another suggestion is to preserve the existing BFD structure, but add the necessary if-feature to the impacted local-multiplier leaf and the interval-config-type choice.  Acee seemed to think this might be reasonable.

The open question is how to keep the pipeline for RFCs moving quickly.  We have two options that have gotten discussion:

1. Update RFC 9127 with a quick -bis.  
Pros: Ship the existing Cluster 236 drafts with the work simply implementing "use client-cfg-parms", so no changes there.  Fix once in BFD, everyone benefits.
Cons: Rob and Alvaro raise an issue that the necessary change in the BFD model may violate YANG module maintenance rules.  Given how recent this RFC has shipped, this might be an exceptional case.  Also, there's apparently work in netmod about relaxing some of the restrictions we've created for ourselves.  This email is partially to seed some of that conversation.  

2. Take the expanded groupings and paste them with the necessary fix into each of the impacted models and -bis RFC 9127 at a less frantic pace.
Pros: Frees cluster 236 documents from further entanglement from a MISREF.  Doesn't depend on the IESG agreeing that adding a if-feature in 9127-bis is a no-no or not.
Cons: Copy and paste makes its own headaches.  If we do need to revise BFD, it might be a goal that we have positive impact on all impacted IETF BFD clients.

Observation: As long as we stay structurally the same in both options, a consistent user experience is maintained.  I'm personally okay with that aside from the maintenance issue.

My preference is option 1.  Get the -bis published and through our processes ASAP.

As noted in the attached diff to 9127, the core potion of a -bis document is trivial.  We'd just need some additional text to explain why we did the -bis.

-- Jeff