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

From: Jeffrey Haas <[email-masked]>
Date: Tue, 7 Dec 2021 08:43:28 -0500

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 [email-masked] -----

Date: Tue, 07 Dec 2021 04:26:39 -0800
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
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 -----

---

From: Reshad Rahman <[email-masked]>
Date: Tue, 7 Dec 2021 14:14:50 +0000 (UTC)

Should RFC9127-bis obsolete RFC9127?
Regards,Reshad.
    On Tuesday, December 7, 2021, 08:43:44 AM EST, Jeffrey Haas <[email-masked]> wrote:  
 
 Working Group,

---

The history:

 : Updates since RFC 9127
 : 

-- Jeff

----- Forwarded message from [email-masked] -----

Abstract:

----- End forwarded message -----

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 7 Dec 2021 09:31:29 -0500

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 <[email-masked]> wrote:
> 
> Regards,
> Reshad.
> ----- Forwarded message from [email-masked] <mailto:[email-masked]> -----
> 
> From: [email-masked] <mailto:[email-masked]>
> To: [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>
> https://datatracker.ietf.org/doc/draft-ietf-bfd-rfc9127-bis/ <https://datatracker.ietf.org/doc/draft-ietf-bfd-rfc9127-bis/>
> 
> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-rfc9127-bis-00 <https://datatracker.ietf.org/doc/html/draft-ietf-bfd-rfc9127-bis-00>
> 
>

---

From: t petch <[email-masked]>
Date: Tue, 7 Dec 2021 17:22:41 +0000

> 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

  ---
> .

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 7 Dec 2021 12:31:32 -0500

Tom,

On Tue, Dec 07, 2021 at 05:22:41PM +0000, t petch wrote:
> 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

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 7 Dec 2021 14:49:48 -0800

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 <[email-masked]> wrote:
> 
>> On Dec 7, 2021, at 9:14 AM, Reshad Rahman <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> On Tuesday, December 7, 2021, 08:43:44 AM EST, Jeffrey Haas <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> Working Group,
>> 
>> Internet-Drafts are also available by rsync at rsync.ietf.org <http://rsync.ietf.org/>::internet-drafts
>> 
>> 

Mahesh Jethanandani
[email-masked]

---

From: t petch <[email-masked]>
Date: Wed, 8 Dec 2021 09:30:02 +0000

> issue are the only ones besides the RIP module we're expected to have

All the instances of the text string '9127' that appear in the I-D 
9127-bis and most of which need to be changed to the text string 'XXXX'. 
  I stopped counting when I got to forty.

Also, I think that having two RFC with identical names and a very slight 
difference in technical content is likely to induce errors ie a revised 
title is needed such as 'YANG Data Model for Bidirectional Forwarding 
Direction - Enhanced' or Revised or Augmented or MkII or some such.  And 
yes, that is another forty changes.

The IANA Considerations are now a nonsense; I think that IANA need 
consulting on what they want to do about whatever happens and 9127-bis 
revising accordingly.

And then there are all the things that I have yet to think about -  give 
me time:-)

Tom Petch

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 8 Dec 2021 07:58:13 -0500

Tom,

On Wed, Dec 08, 2021 at 09:30:02AM +0000, t petch wrote:
> 9127-bis and most of which need to be changed to the text string
> 'XXXX'.  I stopped counting when I got to forty.

Thanks for clarifying.  I've opened a new issue in the github for this.
(Issue #8)  I had originally thought you'd meant instances in the
RFC series.

> Also, I think that having two RFC with identical names and a very
> slight difference in technical content is likely to induce errors ie
> a revised title is needed such as 'YANG Data Model for Bidirectional
> Forwarding Direction - Enhanced' or Revised or Augmented or MkII or
> some such.  And yes, that is another forty changes.

I'm personally of mixed opinion on this one.

The YANG modules, the thing of main importance here, all contain version
strings in their filenames.

Similarly, the modules get a revision clause that cover the changes.  The
description for what is currently listed as revision 2021-12-01 currently
says "RFC 9127-bis".  This could perhaps use better text.  Any specific
suggestions?

> consulting on what they want to do about whatever happens and
> 9127-bis revising accordingly.

Issue #9 has been opened to track this.  I believe this is mostly a simle
matter of requesting IANA to update the previous registrations to point to
the RFC-to-be.

> And then there are all the things that I have yet to think about -
> give me time:-)

The feedback and its impact on document quality is appreciated.

-- Jeff

---

From: t petch <[email-masked]>
Date: Wed, 8 Dec 2021 16:24:27 +0000

> matter of requesting IANA to update the previous registrations to point to

Wrong!

RFC9127 set up an IANA-maintained module and provided the initial 
entries and handed control over to IANA.  That is done, dusted, finished 
with.  You cannot provide initial entries again, they are there in IANA. 
You cannot provide the instructions - they have already been given to 
IANA.   (Something similar has happened previously with other WG and the 
result is a mess, a chain of RFC which you have to trace back and end up 
concluding that this is impossible to understand; indeed there is an I-D 
with the IESG at present where several AD have said they cannot 
comprehend how the registry got into the state it is in - I can!).

There is nothing to be changed as a result of what is currently proposed 
in 9127-bis; the IANA registry, the instructions about it change not a 
whit so this I-D must do nothing.  A helpful note explaining why section 
2.11 has been removed (as it must be) and an IANA Considerations saying 
that this I-D, unlike RFC9127, makes no change to the IANA-maintained 
module (as indeed it cannot as it is IANA-maintained!).  It is all very 
simple and logical.

Tom Petch

---

From: Reshad Rahman <[email-masked]>
Date: Wed, 8 Dec 2021 17:12:16 +0000 (UTC)

On Wednesday, December 8, 2021, 11:24:58 AM EST, t petch <[email-masked]> wrote:

Wrong!

<RR> If that is the case, then does that mean obsoleting 9127 is not the right thing to do?
Regards,Reshad.

Tom Petch

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 8 Dec 2021 12:47:48 -0500

Tom,

On Wed, Dec 08, 2021 at 04:24:27PM +0000, t petch wrote:
> entries and handed control over to IANA.  That is done, dusted,
> finished with.  You cannot provide initial entries again, they are
> there in IANA. You cannot provide the instructions - they have
> already been given to IANA.

This is for iana-bfd-types, which we're not touching.  Dropping it out of
the 9127-bis draft text is certainly the easy fix here.  

As I think through what I think you're highlighting as the consequences
here, it seems like you're leading toward the idea that a full re-issue is
not the proper idea to address the issue we're discussing.

> There is nothing to be changed as a result of what is currently
> proposed in 9127-bis; the IANA registry, the instructions about it
> change not a whit so this I-D must do nothing.  A helpful note
> explaining why section 2.11 has been removed (as it must be) and an
> IANA Considerations saying that this I-D, unlike RFC9127, makes no
> change to the IANA-maintained module (as indeed it cannot as it is
> IANA-maintained!).  It is all very simple and logical.

If we were doing a re-issue of the existing modules in the same RFC,
requesting IANA to update the various registries that refer to the owning
RFC would likely be appropriate.  

That said, where I think you're leading the discussion is that the simplest
fix may be to simply re-issue the ietf-bfd-types module since that's our
only change?

-- Jeff

---

From: t petch <[email-masked]>
Date: Thu, 9 Dec 2021 17:04:24 +0000

On 08/12/2021 17:47, Jeffrey Haas wrote:
>>>> The IANA Considerations are now a nonsense; I think that IANA
>>>> need consulting on what they want to do about whatever happens
>>>> and 9127-bis revising accordingly.
>>>
>>> Issue #9 has been opened to track this.  I believe this is mostly
>>> a simle matter of requesting IANA to update the previous
>>> registrations to point to the RFC-to-be.
>>
>> Wrong!
>>
> This is for iana-bfd-types, which we're not touching.  Dropping it
> out of the 9127-bis draft text is certainly the easy fix here.
>
> As I think through what I think you're highlighting as the
> consequences here, it seems like you're leading toward the idea that
> a full re-issue is not the proper idea to address the issue we're
> discussing.
>
>> explaining why section 2.11 has been removed (as it must be) and
>> an IANA Considerations saying that this I-D, unlike RFC9127, makes
>> no change to the IANA-maintained module (as indeed it cannot as it
>> is IANA-maintained!).  It is all very simple and logical.
>
> requesting IANA to update the various registries that refer to the
> owning RFC would likely be appropriate.
>
> That said, where I think you're leading the discussion is that the
> simplest fix may be to simply re-issue the ietf-bfd-types module
> since that's our only change?

Well, no.  I thought about that and because RFC9127 has seven modules
and five of them import bfd-types then that is five import statements
that should be changed to point to RFC XXXX, not RFC9127, five modules 
that if
not updated will mislead in that the message will then be that these five
modules have not been tested with 9127-bis, only with RFC9127; that is
what the reference statement on the import means and I doubt if we can
guess what tooling does what with that information in the wild (and 
since this has been hanging around for several years, there may be many 
who have proceeded on the basis of the I-D that led to RFC9127).

So my take is that those five modules need to be updated and 9127-bis is 
the place to do so.

iana-bfd-types by contrast is done and dusted, handed over to IANA
and further IETF intervention can only confuse IMHO.  So in 9127-bis, s.2.11
should be retained, to keep the section numbering consistent, but should say
"RFC9127 contained the initial values for the IANA-Maintained module
iana-bfd-types in this section.  This module is now under the control of
IANA.  The current version of the module may be obtained from the IANA 
website."

Likewise
"5.1 RFC9127 created an IANA-maintained module iana-bfd-types which is
now maintained by IANA; details of how this module is updated can be 
found on
the IANA website.  IANA is not requested to take any action with respect
to this module.  The reference for this module on the IANA website 
remains RFC9127"

s.5 remove the two entries for iana-bfd-types; update the others to 
point to 9127-bis or 'XXXX' as I keep saying.

Normally, when an RFC creates a module for IANA to maintain, then plenty 
of people go on accessing the RFC because ...  Here we have a rare 
opportunity to keep them on the straight and narrow by removing the 
module from 9127-bis making them go look where they should have looked 
in the first place.

Tom Petch

> -- Jeff .

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 9 Dec 2021 16:58:49 -0500

Tom,

On Thu, Dec 09, 2021 at 05:04:24PM +0000, t petch wrote:
> that should be changed to point to RFC XXXX, not RFC9127, five
> modules that if
> since this has been hanging around for several years, there may be
> many who have proceeded on the basis of the I-D that led to
> RFC9127).
> 
> So my take is that those five modules need to be updated and
> 9127-bis is the place to do so.

I follow your argument.

I have doubts about it as a requirement rather than a nice to have.

If it is a requirement to update every single set of yang modules that
maintain a non-revision specific import statement but with a softer textual
reference, then we have a massive "shake the tree" problem for even trivial
updates.

That shake the tree exercise is understood for by revision, and I know that
discussion is ongoing in IETF to figure out how we best resolve everything.

I'll prod the YANG doctors on this point in a separate thread offlist.

Beyond that, I acknowledge your points and effective roadmap for updating
the document as being a valid one.  That said, I'm only the document
shepherd rather than an authors.  Let's see if they have further inputs.

-- Jeff

---

From: t petch <[email-masked]>
Date: Fri, 10 Dec 2021 16:47:05 +0000

> reference, then we have a massive "shake the tree" problem for even trivial

Jeff

I think you read too  much into what I say.  In the general case, there 
is no need to go back and update reference clauses in import statements; 
they tell us what the module was then tested with and that should not be 
changed unless and until e.g. more testing is done or a problem is 
found.  And the rules in RFC7950 should ensure that updates to an 
imported module never cause a well-written importing module to fail.

This is different.  The update in 9127-bis is widely needed, based on 
what you have reported about deviations, and so it matters that the 
other modules involved, be they bfd, pim, bgp or whatever, record the 
fact that they work with the new bfd-types in 9127-bis.

So here it matters that the modules that care about the changes import 
bfd-types from 'XXXX' and do not go on referencing 9127.  (What happens 
with RIP is interesting - I think that that RFC should never have been 
published!)

By contrast, if 6991bis were to become RFCyyyy, then I would not update 
a single one of the hundreds of modules that import from RFC6991 unless 
and until they are updated to use some value that is in 6991bis and not 
in RFC6991 at which point the reference needs updating to RFCyyyy.

Tom Petch

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 10 Dec 2021 14:01:36 -0500

Tom,

I think we're going too deep into the weeds here for the BFD list in terms
of the impact of this piece of the discussion.  I'd suggest continuing it on
the thread started with the yang doctors.  Once there is consensus on it, we
can take it back here as actions for suggested updates to the BFD document.

On Fri, Dec 10, 2021 at 04:47:05PM +0000, t petch wrote:
> I think you read too  much into what I say.  

I have only your words to go on.  When you use phrases like "guess what
tooling does with that information in the wild", it's reasonable to think
you have a strong concern.  You finish by saying we had five modules that
"need to be updated".  It's not clear why - hence asking the broader
audience what their own interpretation of the rules are.

> In the general case,
> there is no need to go back and update reference clauses in import
> statements; they tell us what the module was then tested with and
> that should not be changed unless and until e.g. more testing is
> done or a problem is found.  And the rules in RFC7950 should ensure
> that updates to an imported module never cause a well-written
> importing module to fail.

That was my take on the issue.  But that lead me to question why we had need
to update the other modules simply to update the reference.

> This is different.  The update in 9127-bis is widely needed, based
> on what you have reported about deviations, and so it matters that
> the other modules involved, be they bfd, pim, bgp or whatever,
> record the fact that they work with the new bfd-types in 9127-bis.

I don't know that is the case.

It is a valid, but perverse option to have support for the new feature and
still deviate away the nodes.

Deviating away the nodes when the feature is not supported is likely still
valid.  I don't find anything in the definition in RFC 7950 §7.20.3 that
specifies interaction with if-feature.

I believe the reasonable expectations are:
1. If you implement solely RFC 9127, and you don't support the per-client
configuration nodes, your implementation can deal with this solely by
issuing deviations on the importing modules.  This is where we had started
this exercise some years ago.
2. If you implement what comes after RFC 9127, regardless of whether you get
a new copy of the full non-IANA maintained module set or an update to just
the ietf-bfd-types module, you don't need the deviations if you don't need
the feature.  The shipping vendor would remove the deviations as part of
their bundle.

The implication you're trying to raise is that it's impossible to update a
module that is cited in a specific RFC without implying scarily that Things
May Break.  I don't think that's the intent.

> By contrast, if 6991bis were to become RFCyyyy, then I would not
> update a single one of the hundreds of modules that import from
> RFC6991 unless and until they are updated to use some value that is
> in 6991bis and not in RFC6991 at which point the reference needs
> updating to RFCyyyy.

How is this any different than an IANA maintained module where the intent is
stuff is added as the protocol is maintained?

If your implementation pulls in a new version of the impacted module, your
implementation has a need to deal with the impacts.  For operational state,
this isn't an issue because it'd not start using a new value without
changes.  For configuration state, the implementor had better make sure that
they either support changes that result from using that new version or issue
the appropriate deviation.

-- Jeff