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

[Jeffrey Haas <[e-mail]>]

https://github.com/mjethanandani/ietf-bgp-yang/issues/496

Maria,

Thanks for responding.

> On Jul 13, 2026, at 09:27, Maria Matejka <maria.matejka=[e-mail]> wrote:
> 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?

See response from Ketan.

> 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.

Your implementation may not want it.
A significant portion of the deployed implementations do this.

The challenge for doing general purpose modeling for IETF is reasonably accommodating implementations.  For your case, perhaps, the group is an irritation that flattens out.

Then again, route-server implementations are... weird.  (Saying as someone who used to work on the Merit route-server daemon.)

> 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.1feature damping {
> description
> "Weighted route dampening is supported.";
> }
> Could we please use damping or dampening but not both?

Damping will be the update since it's the proper English for the feature.  (The history of those who want to use "dampen" make for fun historical reading.)

> 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?

It's a different feature, and not what we're putting in this rev of the model.  The goal is not to be protocol comprehensive, it was to pick a minimal core subset while enabling the later extensions.




> typedef rr-cluster-id-type {
> ...
> type yang:dotted-quad;
> ...
> option 2: IP address";
> }
> Probably IPv4 address, to be precise.

The RFC 6286 reference helps to say no.  Much older BGP had a restriction that this was probably going to be a routable IPv4 address.  These days it's basically everything other than 0.0.0.0.


> 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.

See previous discussion on the matter.

> Sec. 7.3.1leaf 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?

Not completely unreasonable, but very late in asking.  Added to the issue for discussion.

> container neighbors {
> description
> "Configuration for BGP neighbors.";
> Configuration but then things inside that are config false. That confuses me.

Fair point and easy fix.

> 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.”?

For IETF YANG, config and op state are permitted to be mixed.  But as you point out, the fix is to update the container's description to be correct about its mix.

> 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, inleaf session-state, the term Neighbor is used for the remote one only.

Local BGP speaker is the intent.  Added to issue for audit.

> 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.

The intention is all statistics so the description can be clarified.

> 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.)

For this one, I think the answer is to not be overly proscriptive.  What this will mean, as you highlight, will vary somewhat based on circumstance and implementation.

> 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.)

The bike shed is blue.  I'm also not fond of these names, but their usage was defined at a time that might exceed the age of our younger working group participants.

> Sec. 7.3.2
> Is this expected to be configuration or status?

Both.

> From the usage of bgp-capabilities-common, it is status only

IETF YANG models permit config and op state to live in the same nodes.  The access mechanism determines the outcome (get-config vs. get, e.g.)

> 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.

Not having Xpath pasta (the generic form of your lasagna) might have been nice, but it's what the language started from.  Among other things it'd make the discussion about how to do subscription filters for elements within the model nicer.  But that's a conversation over libations.

> Sec. 7.3.3grouping 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.

You are absolutely correct, but where "specific implementation" covers the majority of the planet's commercial implementations and multiple open source ones.

While doing a lot of the feature selection for the draft some years ago, the question had been opened as to what do we do about features that are commonly deployed but not appropriately documented.  In some cases the goal was to resurrect zombie documents (e.g. best-external) to close documentation. In others, perhaps close it as part of other draft or RFC 4271-bis work (which is moving again).  

For multipath in particular, there's been multiple efforts to "standardize" the feature.  They've all failed.  The feature is heavily deployed.  So, the choice was to include the feature and see what the future may bring.


> While BIRD does indeed implement something resembling that, the overall semantics is unclear.

The expectation is largely that vendors at least have a common container to put their related features in.  It's the best we could do.

> container route-flap-damping
> This deserves an explicit reference to RFC 2439.

Agreed.

> 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?

Agreed that this is in error.  The purpose of the feature is to control the propagation of the communities themselves rather than scope the routes. (Reviewing the git blame for this should be fun.)

> 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?

See prior comments.  Heavily deployed, zombie reference.

> 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.

It'd be nice.  There are no such things.  A few of them will likely serve as inputs to 4271-bis.

> 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.

And what exactly would you recommend for this trash-dump feature?  The current choice was "make sure related features have a place to go in future augmentations".

> 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?

Agreed on the ambiguity.  And there's no standard on such a thing.  And yet, the knob is commonly deployed.


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

Welcome to my complaints 10 years ago.

> 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.

For this one, I believe the description is clear.  I agree that 7911 doesn't provide an operational considerations that would suggest what the feature does in a standards-based fashion.

But again, it's well deployed.

> 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.

The YANG is probably fine.  I would interpret this as "add something to the documentation discussing it".

Added to the issue:
https://github.com/mjethanandani/ietf-bgp-yang/issues/496

> –
> Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
> _______________________________________________
> Idr mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]