bgp: bgp/neighbor/neighbors/negotiated-capabiliteis duplication

[sha90w]

When we have a BGP session with both ipv4-unicast and ipv4-unicast families in the YANG, we will have the following negotiated-capabilities state with duplicated mp-bgp lines:

  "negotiated-capabilities": [
       "iana-bgp-types:mp-bgp",
       "iana-bgp-types:mp-bgp",
       "iana-bgp-types:asn32",
       "iana-bgp-types:route-refresh"
   ]

As I understand, this happens because we have a field in the struct Neighbor defined as:

pub capabilities_nego: BTreeSet<NegotiatedCapability>,

where

pub enum NegotiatedCapability {
    MultiProtocol { afi: Afi, safi: Safi },
    FourOctetAsNumber,
    AddPath,
    RouteRefresh,
    EnhancedRouteRefresh,
}

So here we have an enum member for Multiprotocol defined with afi and safi parameters, but on the other side, in the Yang model (ietf-bgp-capabilities@2023-07-05.yang), the negotiated-capabilities are defined as a leaf-list of bt:bgp-capability:

identity mp-bgp {
    base bgp-capability;
    description
      "Multi-protocol extensions to BGP";
    reference
      "RFC 4760: Multiprotocol Extentions for BGP-4.";
  }

where it's impossible to specify exact afi/safi.

I did some investigation and understand that negotiated AFI/SAFIs in the Yang model should be signaled not in the negotiated-capabilities list, but in the operational neighbor/afi/safis/ state. But the model for the AFI/SAFI state was not standardised yet. I found a draft https://www.ietf.org/archive/id/draft-ietf-idr-bgp-model-18.html (unfortunately expired) where we can see:

 grouping bgp-neighbor-afi-safi-list {
    description
      "List of address-families associated with the BGP neighbor";
    list afi-safi {
      key "name";
      description
        "AFI, SAFI configuration available for the neighbor or
         group";
      uses mp-afi-safi-config;
      leaf active {
        type boolean;
        config false;
        description
          "This value indicates whether a particular AFI-SAFI has
           been successfully negotiated with the peer. An AFI-SAFI
           may be enabled in the current running configuration, but
           a session restart may be required in order to negotiate
           the new capability.";
      }

1. Should we change the definition of the NegotiatedCapability enum, removing the afi and safi fields from the Multiprotocol member, to prevent duplication in the Yang state for negotiated-capabilities?
2. Should we add augmentation to have an active leaf on the AFI/SAFI state to have the possibility to retrieve the negotiation state of address families?

[rwestphal]

identity mp-bgp {
    base bgp-capability;
    description
      "Multi-protocol extensions to BGP";
    reference
      "RFC 4760: Multiprotocol Extentions for BGP-4.";
  }

where it's impossible to specify exact afi/safi.

@sha90w One possible solution would be to add new identities based on "mp-bgp", such as "mp-bgp-ipv4-unicast", which would allow us to keep the leaf-list. But I'm not sure whether this would be a good idea, as there are many valid AFI/SAFI combinations.

I did some investigation and understand that negotiated AFI/SAFIs in the Yang model should be signaled not in the negotiated-capabilities list, but in the operational neighbor/afi/safis/ state. But the model for the AFI/SAFI state was not standardised yet. I found a draft https://www.ietf.org/archive/id/draft-ietf-idr-bgp-model-18.html (unfortunately expired) where we can see:

We currently implement version -17 of that draft, and not much has changed since then: https://author-tools.ietf.org/iddiff?url1=draft-ietf-idr-bgp-model-17&url2=draft-ietf-idr-bgp-model-18&difftype=--html

 grouping bgp-neighbor-afi-safi-list {
    description
      "List of address-families associated with the BGP neighbor";
    list afi-safi {
      key "name";
      description
        "AFI, SAFI configuration available for the neighbor or
         group";
      uses mp-afi-safi-config;
      leaf active {
        type boolean;
        config false;
        description
          "This value indicates whether a particular AFI-SAFI has
           been successfully negotiated with the peer. An AFI-SAFI
           may be enabled in the current running configuration, but
           a session restart may be required in order to negotiate
           the new capability.";
      }

1. Should we change the definition of the NegotiatedCapability enum, removing the afi and safi fields from the Multiprotocol member, to prevent duplication in the Yang state for negotiated-capabilities?

That's not possible as the AFI/SAFI information is necessary in other parts of the code.

2. Should we add augmentation to have an active leaf on the AFI/SAFI state to have the possibility to retrieve the negotiation state of address families?

The IETF BGP model is currently under heavy activity in this repo: https://github.com/mjethanandani/ietf-bgp-yang/issues

I'd suggest opening an issue there and seeing what the module authors think!