[Idr] Re: WG LC on changes for draft-ietf-idr-bgp-model-20 (6/26 to 7/10/2026)

[Maria Matejka <[e-mail]>]

Howdy!

First of all, thanks for fixing the neighbor key.

On Sat, Jun 27, 2026 at 12:37:52AM +0000, Susan Hares wrote:

> This is a WG LC on the post-WG LC changes on draft-ietf-idr-bgp-model-20.txt from 6/26 to 7/10/2026.

I'm confused by this formulation but I was busy anyway with other
things. Also, a WG LC for such a long document would be nicer a little
bit longer than 14 days, so that one could read it once again from top
to bottom.

Was this a WG LC for the whole document?

Generally, to quote Ondřej Zajíček when we discussed the BGP YANG
earlier, it looks like a lot of implementation details is leaking into
the API, but if the community wants this, whatever.

For example, the whole neighbor group concept is implementation
specific (, and it is kinda orthogonal to a templating mechanism expected
by RFC 8342 (NMDA), sec. 5.1.3 and 5.1.4, and actively prepared in
https://datatracker.ietf.org/doc/html/draft-tt-netmod-yang-config-templates
I'm not convinced that all that specification complexity with neighbor
groups is really needed.

Here are some notes for sec. 7.1 to 7.3.3 (incl.), more will follow
later. Notes are below the YANG excerpts.

## Sec. 7.1

    feature damping {
      description
	"Weighted route dampening is supported.";
    }

Could we please use damping or dampening but not both?

    feature route-refresh {
      description
	"Support for the BGP Route Refresh capability.";
      reference
	"RFC 2918: Route Refresh Capability for BGP-4.";
    }

Enhanced (RFC 7313) is an update, ergo not referenced here?

    typedef rr-cluster-id-type {
      ...
	type yang:dotted-quad;
      ...
	 option 2: IP address";
    }

Probably IPv4 address, to be precise.

## Sec. 7.2

The large community type looks gnarly and could have been defined as a
set of three items but whatever, this is gonna be replaced by a standin
in CBOR anyway, and therefore I don't care.

## Sec. 7.3.1

    leaf identifier {
         type yang:dotted-quad;
         0description
           "BGP Identifier of the router - an unsigned 32-bit,
            non-zero integer that should be unique within an AS.
            The value of the BGP Identifier for a BGP speaker is
            determined upon startup and is the same for every local
            interface and BGP peer.";
         reference
           "RFC 6286: AS-Wide Unique BGP ID for BGP-4. Section 2.1";
       }

What about an analogous type to rr-cluster-id-type, as RFC 6286
specifies it as uint32?

    container neighbors {
      description
        "Configuration for BGP neighbors.";

Configuration but then things inside that are config false. That confuses me.

    leaf local-address {
      type inet:ip-address;
      config false;
      description
        "The local IP address of this entry's BGP connection.";
    }

... like here for example. Maybe that should be "Read-only active
configuration for BGP neighbors."?

    leaf local-restarting {
      type boolean;
      config false;
      description
        "This flag indicates whether the local neighbor is
         currently restarting. The flag is cleared after all
         NLRI have been advertised to the peer, and the
         End-of-RIB (EOR) marker has been cleared.";
    }

Does this mean "the local node / session / connection is restarting?"
For me, a neighbor is not the local node. RFC 4724 uses the term Speaker.
Also just several items below, in `leaf session-state`, the term
Neighbor is used for the remote one only.

    action clear {
      if-feature "ibt:clear-statistics";
      description
        "Clear statistics action command.
         Execution of this command should result in all the
         counters to be cleared and set to 0.";

I'm not completely sure but do I interpret correctly that
container queues, which are gauge32, are not counter, and therefore not
cleared? This may deserve a clarification, what exactly is cleared.

    output {
      leaf clear-finished-at {
        type yang:date-and-time;
        description
          "Time when the clear action command completed.";
      }
    }

What is the semantics of action completed? For the clear-neighbors
action with notification, does it mean notification queued, sent, or
also routes from that peer flushed? For operation-soft, that is probably
when the last route was re-sent, and for operation-soft-inbound its when
the request was sent, or when all the routes are received?
(This deserves clarification of the description.)

Also, "soft" and "soft-inbound" is very … non-descriptive and
unsystematic if the action is named "clear". More suitable names may be
e.g. "resend" and "refresh", or at least "soft-outbound" and
"soft-inbound"? Or even "reexport" and "reimport", to match with other
places like "import-policy" and "export-policy". (This is bikeshedding.)

## Sec. 7.3.2

Is this expected to be configuration or status? From the usage of
`bgp-capabilities-common`, it is status only. Or is it intended to be
also imported from elsewhere to allow fine-grained tampering with
capabilities sent?

Also the `derived-from-or-self` construction looks unnecessarily
complicated, but the longer I'm looking at it, the more it seems to me
nicer than the augmenting approach chosen e.g. by the routing base RFC
which is kinda lasagna. I'm quite OK with this approach.

## Sec. 7.3.3

    grouping bgp-neighbor-use-multiple-paths
    grouping global-group-use-multiple-paths

This looks like a specific implementation feature without RFC coverage
and with no reference to an existing document. While BIRD does indeed
implement something resembling that, the overall semantics is unclear.

    container route-flap-damping

This deserves an explicit reference to RFC 2439.

    leaf-list send-community {
      if-feature "ibct:send-communities";
      type identityref {
        base "ibct:send-community-feature";
      }
      description
        "When supported, this tells the router to propagate any
         prefixes that are attached to these community-types.";
    }

This reads incomprehensible to me. How is a prefix attached to
a community type?

    leaf advertise-inactive-routes {
      type boolean;
      default "false";
      description
        "Advertise inactive routes to external peers.  The default
         is to only advertise active routes.";
      reference
        "I-D.ietf-idr-best-external: Advertisement of the best
         external route in BGP.";
    }

This looks weird. Why do we include a feature from a draft last updated
14 years ago? Also, the referenced draft has no definition of an
"active route", and therefore the semantics of this is unknown to me.

    grouping route-selection-options

While I'm quite sure why these are here, it would be nice to have
a reference here, informing the reader / implementor that these are
indeed knobs to violate RFC 4271 sec. 9.1 in a way so common that
actually most implementations do offer these knobs.

    leaf replace-peer-as {
      type boolean;
      default "false";
      description
        "Replace occurrences of the peer's AS in the AS_PATH with
         the local autonomous system number";
    }

This is the only of "AS_PATH manipulation configuration", while
`allow-own-as` is an import validation knob and `disable-peer-as-filter`
is an export validation knob. I'm not convinced that grouping these
three into grouping neighbor-group-as-path-options is semantically
sound.

    choice send {
      description
        "Choice of sending the max. number of paths or to send
         all.";
      case max {
        leaf max {
          type uint8;
          description
            "The maximum number of paths to advertise to neighbors
             for a single NLRI";
        }
      }

What is the semantics of this? When we were requested to implement this
kind of limiting in BIRD, we found a bunch of questions to consider,
most notably what to do when the maximum is hit and then one route gets
withdrawn. Shall we fill in another one? And how to choose which routes
get sent?

I'm not convinced that we should have a standard configuration knob
for a non-standard feature with unclear definition.

Also, eligible-prefix-policy lacks any explanation that this is actually
an additional knob not specified in RFC 7911, and probably a little bit
more explicit semantics.

    container dynamic-peers {
      list dynamic-peer-list {
        key "prefix";

While one may intuitively understand how this works, I would, again,
like to see a more detailed explanation of the semantics of dynamic
peers. I know that it's quite a common feature but it's not specified
formally and there is yet again a risk of semantic confusion between
implementations.




-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.