Addition of BFD sessions subtree under interface in openconfig-bfd.yang

[Pull-eckermann]

Creation of a BFD single-hop session subtree at interface level, so that BFD sessions can be created besides routing protocols, as stated in RFC-9127.

Change Scope

• Creation of BFD sessions subtree at interface level, witch allows the configuration of single-hop BFD sessions under the specified interface with well specified local-address and remote-address , outside the multiple BFD clients scope. Multiple BFD sessions can be created in the same interface.
• This change is backwards compatible.

Platform Implementations

• IPInfusion OcNOS implementation: OcNOS BFD yang model ipi-bfd-interface.yang. Please refer to the bfd-interface-sessions-top grouping. Also, CLI configuration example can be faund in the BFD Configuration Guide
• RFC 9127 implementation: The RFC 9127 specifies at section 2.6 the yang.tree of the subtree for single-hop BFD sessions configuration that allows the creation of the sessions attached to a interface, represented as a list key. This was a inspiration for this pull-request. Also the actual OpenCOnfig model does not allow configuration of BFD sessions outside the multiple BFD clients scope, but this RFC states that it should be possible.

[robshakir]

Thanks for the well-formed submission. Generally, looks reasonable to me, assuming I understand the context (question below).

There's one implementation listed here -- are there others that allow static non-protocol-related single hop sessions to be configured?

We should probably clarify what happens if both the per-protocol BFD enabled leaves are used as well as this configuration.

[Pull-eckermann]

Thanks for the well-formed submission. Generally, looks reasonable to me, assuming I understand the context (question below).

There's one implementation listed here -- are there others that allow static non-protocol-related single hop sessions to be configured?

We should probably clarify what happens if both the per-protocol BFD enabled leaves are used as well as this configuration.

Q1: yes, after some search I've found a CLI configuration example for Huawei system at this link in section Configuring Single-Hop BFD.
Also, in the huawei-bfd.yang file we can see that this type of configuration is allowed in the static and auto-generated scenarios. THis can be find in "choice multicast-or-unicast-ip" for the unicast case, or in the "choice auto-session-link-type" for ip case. This configuration allows the creation of a static single-hop specifying the interface, source and destination address.

Q2: Probably system checks for two concurrent sessions if source and dest addresses are the same and if so, prioritize the session that was firstly established.

[wenovus]

/gcbrun

[OpenConfigBot]

No major YANG version changes in commit 72c371e

[wenovus]

/gcbrun

[robshakir]

Couple of small changes, and then LGTM.

Leaving to @dplore to ensure last-call process.

[robshakir]

Since we're adding a feature here, let's make this be a minor release - i.e., this should be 0.4.0.

[robshakir]

We've generally used enabled as this leaf's name -- and have zero called admin-down, so let's go for some consistency here and use enabled.

[earies]

This was also raised some time ago whether or not this should have been corrected for those that veered but current stats look like:

$ find . -name "*.yang" | xargs grep -E "leaf enable(d?) {" | awk '{print $3}' | sort | uniq -c
     15 enable
     51 enabled

[robshakir]

Suggested change

	session";
	session.";

[robshakir]

Suggested change

	session";
	session.";

[LimeHat]

@Pull-eckermann could you please elaborate on the original problem statement?

Creation of a BFD single-hop session subtree at interface level, so that BFD sessions can be created besides routing protocols, as stated in RFC-9127.

Creation of BFD sessions subtree at interface level, witch allows the configuration of single-hop BFD sessions under the specified interface with well specified local-address and remote-address ,

I would disagree with that interpretation of the RFC9127 and BFD protocol behavior for a number of reasons.

Firstly, the protocol behavior is defined in RFCs 5880-5882.

RFC5880, section 3.1:

Addressing and Session Establishment

   A BFD session is established based on the needs of the application
   that will be making use of it.  It is up to the application to
   determine the need for BFD, and the addresses to use -- there is no
   discovery mechanism in BFD. 

RFC5881 tells us that the session must be associated with a protocol:

   In this application, there will be only a single BFD session between
   two systems over a given interface (logical or physical) for a
   particular protocol.  The BFD session must be bound to this
   interface.  As such, both sides of a session MUST take the "Active"
   role (sending initial BFD Control packets with a zero value of Your
   Discriminator), and any BFD packet from the remote machine with a
   zero value of Your Discriminator MUST be associated with the session
   bound to the remote system, interface, and protocol.

RFC5882 tells us that the protocol is expected to bootstrap the session:

 The service interface with BFD is straightforward.  The application
   supplies session parameters (neighbor address, time parameters,
   protocol options), and BFD provides the session state, of which the
   most interesting transitions are to and from the Up state.  The
   application is expected to bootstrap the BFD session, as BFD has no
   discovery mechanism.

In addition,

2. RFC9127 talks about the configuration of source & destination addresses primarily in the context of multihop and microbfd sessions (see sections 2.1.1-2.1.3)
3. Section 2.1 of RFC9127 states that these configuration parameters are designed so that BFD clients (such as routing protocols) can program the BFD module via the API call using the model. This is not typically used in OC.

Also, probably you want to use RFC9314 instead of 9127 as a reference.

To summarize, while technically the rfc9127 yang model does not prevent the creation of the config as you describe, I don't believe it is designed for the purpose you stated.
Is there any other normative reference that allows the creation of independent BFD sessions that are not tied to any protocol or function the way you describe it?

To me, it seems that you're trying to "standardize" a non-standard implementation that requires a fixed provisioning of the destination IP via this pull request.

I disagree with the proposal in its current form.