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 internet-dra...@ietf.org -----
Date: Tue, 07 Dec 2021 04:26:39 -0800
From: internet-dra...@ietf.org
To: i-d-annou...@ietf.org
Cc: 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/
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 -----
.
