Add Bfd diagnostic code for when neighbor signaled session down.

[AnilKR123]

Change Scope

I have added a Bfd diagnostic code for when neighbor signals session down. This is specified in RFC5880 but is absent from the public model.

From RFC5880:

 A diagnostic code specifying the local system's reason for the
  last change in session state.  Values are:

     0 -- No Diagnostic
     1 -- Control Detection Time Expired
     2 -- Echo Function Failed
     3 -- Neighbor Signaled Session Down
     4 -- Forwarding Plane Reset
     5 -- Path Down
     6 -- Concatenated Path Down
     7 -- Administratively Down
     8 -- Reverse Concatenated Path Down

[dplore]

To keep this as a non-breaking change, the original ordering of the enums must be preserved. You can only add enums to the list.

[dplore]

I realize the enum value won't match the value in a packet on the wire, but that is not required.

[AnilKR123]

I moved NEIGHBOR_DOWN to the end of the enums list.

Thanks.

[AnilKR123]

I would like to propose deprecating the bfd-diagnostic-code enum and creating a new enum, perhaps called rfc5880-bfd-diagnostic-code. The bfd-diagnostic-code enum is missing “Neighbor Signaled Session Down” diag, as specified in RFC5880:

A diagnostic code specifying the local system's reason for the
last change in session state. Values are:

 0 -- No Diagnostic
 1 -- Control Detection Time Expired
 2 -- Echo Function Failed
 3 -- Neighbor Signaled Session Down
 4 -- Forwarding Plane Reset
 5 -- Path Down
 6 -- Concatenated Path Down
 7 -- Administratively Down
 8 -- Reverse Concatenated Path Down

The objection to adding this diagnostic code to enum value 3 is that it would be a breaking change. However adding it to the end of the enum would not only make Neighbor Down not compliant, but also all of the enum values after 3 differ in relation to the RFC. This adds operational complexity since clients now need a parser to map between the RFC codes and OC public codes.

By adding a new enum for the diag codes, we could support the RFC compliant values. And each vendor can decide which leaf they want to support for now.

[dplore]

/gcbrun

[OpenConfigBot]

No major YANG version changes in commit b3229cb

[dplore]

OC Operator opinion is that it's more important to have a vendor neutral model where all vendors consistently implement the same OpenConfig model and there is only one way to model the BFD state. It's also viewed as more churn to refactor the model than to add the enum to the end, even though it doesn't match the packets on the wire. So this PR change is approved as is.

Last call for Feb 25, 2025.

[dplore]

/gcbrun

[dplore]

@AnilKR123 one misc check is failing, can you fix it please?

openconfig-bfd.yang: file updated but openconfig-version string not updated: "0.3.0"

[AnilKR123]

Hi @dplore, I have fixed the issue by bumping the version number. Thanks.

[dplore]

/gcbrun