Advanced BGP Monitoring Protocol (BMP) Statistics Types
draft-ietf-grow-bmp-bgp-rib-stats-17

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-grow-bmp-bgp-rib-stats and RFC 9972, changed IESG state to RFC Published)

[Ballot comment]
# COMMENTS
# ========

My comments and discuss were appropriately addressed with the v17 draft

Many thanks for this document,

Kind Regards,
Gunter Van de Velde
RTG AD

[Ballot comment]
Thanks to the authors and the WG for their work on this document.

Also thanks for your patience and the discussion on the points raised in my previous ballot and the updates to the document.

Some of the points raised had wider implications that this specific document. My thanks to the authors and the WG for the discussions and their decision to tackle them via other documents.

[Ballot discuss]
Thanks to the authors and the WG for this document.

Note: this ballot has been updated for v16 of the document. The previous number of points is retained. Points that have been addressed are deleted.

Please find below certain points that I would like to discuss.

Semantics of routes, paths, primary, and backup.

Section 2 of this document says:
Primary route: A route to a prefix that is considered the best route by the BGP decision process [RFC4271] and actively used for forwarding traffic to that prefix.
Backup route: A backup route is eligible for route selection, but it is not selected as the primary route and is also installed in the Loc-RIB. It is not used until all primary routes become unreachable. Backup routes are used for fast convergence in the event of failures.

Consider an BGP route for destination prefix x/y is a multipath:
x/y via BGP NH1 (path1) (best)
    via BGP NH2 (path2) (multipath - say ECMP)
    via BGP NH3 (path3) (backup)
    via BGP NH4 (path4) (valid but not best/multipath/backup)
    via BGP NH5 (path5) (invalid - for whatsover reason)

This is a single route. The best/multipath/backup/valid/invalid/etc are qualifiers of its paths. Except for two stats that refer to paths (stale and suppressed), everything is referring to routes. I would like to discuss the semantics of route vs path. It seems to me like some of the stats are for paths and not routes.

In general, I think the use of the terms primary/backup which are related to forwarding plane aspects can be confusing. Instead, perhaps using terms that are more suitable for BGP Loc-RIB would be better? I've suggested some of them above for consideration. Also refer to draft-ietf-grow-bmp-path-marking-tlv - the terms of stats should be aligned across the BMP documents?

Furthermore, there is a wrong assumption that backup paths are only activated when all primary paths are down. This is very much implementation dependent. Some implementations have a 1:1 provisioning of primary/backup - where the backup would get used when its specific primary goes down - this draws on the FRR notion in the forwarding planes. Refer to the definition in draft-ietf-grow-bmp-path-marking-tlv

These clarifications have implications on several of the stats as they are defined currently.

Section 3 has the following text and Section 4 introduces a table that brings up an interesting aspect.

"This section defines different statistics type for Adj-RIB-In and Adj-RIB-Out monitoring type. Some of these statistics are also applicable to Loc-RIB; refer to Section 4 for more details."

For types 24 through 28, they are applicable for both Adj-RIB-In and Loc-RIB. How does one know what is being reported? Can this be clarified? Seems like this is the first document introducing such overloaded types but I don't find the reason why this is being done. There is also a sort of duplication for same stat being both global as well as per afi/safi - is there any guidance on whether only one of them needs to be supported (this way avoiding the race conditions and discrepancies in their totaling)?

It is important to clarify these aspects if this is going to set a precedent/guidance for other similar stats in BMP in future documents?

[Ballot discuss]
Thanks to the authors and the WG for this document.

Note: this ballot has been updated for v15 of the document. The previous number of points is retained. Points that have been addressed are deleted.

Please find below certain points that I would like to discuss.

Semantics of routes, paths, primary, and backup.

Section 2 of this document says:
Primary route: A route to a prefix that is considered the best route by the BGP decision process [RFC4271] and actively used for forwarding traffic to that prefix.
Backup route: A backup route is eligible for route selection, but it is not selected as the primary route and is also installed in the Loc-RIB. It is not used until all primary routes become unreachable. Backup routes are used for fast convergence in the event of failures.

Consider an BGP route for destination prefix x/y is a multipath:
x/y via BGP NH1 (path1) (best)
    via BGP NH2 (path2) (multipath - say ECMP)
    via BGP NH3 (path3) (backup)
    via BGP NH4 (path4) (valid but not best/multipath/backup)
    via BGP NH5 (path5) (invalid - for whatsover reason)

This is a single route. The best/multipath/backup/valid/invalid/etc are qualifiers of its paths. Except for two stats that refer to paths (stale and suppressed), everything is referring to routes. I would like to discuss the semantics of route vs path. It seems to me like some of the stats are for paths and not routes.

In general, I think the use of the terms primary/backup which are related to forwarding plane aspects can be confusing. Instead, perhaps using terms that are more suitable for BGP Loc-RIB would be better? I've suggested some of them above for consideration. Also refer to draft-ietf-grow-bmp-path-marking-tlv - the terms of stats should be aligned across the BMP documents?

Furthermore, there is a wrong assumption that backup paths are only activated when all primary paths are down. This is very much implementation dependent. Some implementations have a 1:1 provisioning of primary/backup - where the backup would get used when its specific primary goes down - this draws on the FRR notion in the forwarding planes. Refer to the definition in draft-ietf-grow-bmp-path-marking-tlv

These clarifications have implications on several of the stats as they are defined currently.

Section 3 has the following text and Section 4 introduces a table that brings up an interesting aspect.

"This section defines different statistics type for Adj-RIB-In and Adj-RIB-Out monitoring type. Some of these statistics are also applicable to Loc-RIB; refer to Section 4 for more details."

For types 24 through 28, they are applicable for both Adj-RIB-In and Loc-RIB. How does one know what is being reported? Can this be clarified? Seems like this is the first document introducing such overloaded types but I don't find the reason why this is being done. There is also a sort of duplication for same stat being both global as well as per afi/safi - is there any guidance on whether only one of them needs to be supported (this way avoiding the race conditions and discrepancies in their totaling)?

It is important to clarify these aspects if this is going to set a precedent/guidance for other similar stats in BMP in future documents?

==Pending minor changes

* Delete "A prefix can have more than one primary path."

* Change "Backup routes MAY be utilized either" to "Backup routes may be utilized, for example, "

* Move the text starting with "Note that the terms "Producer" and "Collector" are " to the terminology section. Please make also: s/Note that the/The

[Ballot discuss]
[Updated ballot 20Nov2025]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-grow-bmp-bgp-rib-stats-15

# The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-grow-bmp-bgp-rib-stats-14.txt

# Many thanks for the RTGDIR review from Bruno and the shepherd writeup from Job.

# Thanks for great work resolving 3 DISCUSS items and all my COMMENTS with the v15 update.

# DISCUSS
# =======

#1# [Updated] BCP14 language is used in section 5. and i realized there may of been a miscommunication. The newly introduced section 5.1. discusses formal operational aspects of the BMP implementation, and it seems appropriate to have BCP14 language to formalize this. The section 5.2. discusses the operator operational aspects of the BMP usage and the BCP14 there seems inappropriate from formal protocol behavior. I understand that the intent of this language in 5.2. is to stress operator importance. Potentially add a clarification in the "1.1. Requirements Language" section clarifying that the BCP14 is used to stress importance for operators but are not required as formal implementation requirement.

#2# [Updated] accurately gauge descriptions. Discussion on what is primary/backup path/route exactly means is unclear. The draft states for example:

"
Primary route: A BGP route to a prefix that is considered the best route by the BGP decision process [RFC4271]. A prefix can have more than one primary route.

Backup route: A backup route is eligible for route selection, but it is not selected as the primary route and is also installed in the Loc-RIB. Backup routes are used for fast convergence in the event of failures.
"

There is unclarity between what is primary route, bgp best path selected and active route. The BGP process yields only a single BGP path, but multiple routes (-more as only the BGP single best path) can be yielded into actively forwarding traffic (ECMP or uECMP).

The backup route, may be used for FRR, but that is not always true. Maybe slghtly soften the text.

I align with Ketan's DISCUSS (his first discuss item) on accurate understanding for these terminology.

#3# [Resolved] some gauges seem duplicates from prior existing gauges. Section 5.1 addresses this concern. 

#4# [resolved] section 3 is named "3. Statistics Definition" renamed to "3. RIB Monitoring Statistics" and a new section "3.1. Statistics Format" is introduced to resolve the discuss

#5# [resolved] unclear "Value" description for gauges was resolved by the new section "3.1. Statistics Format"

[Ballot comment]
# COMMENTS
# ========

My comments were appropriatly addressed with the v15 draft

Many thanks for this document,

Kind Regards,
Gunter Van de Velde
RTG AD

[Ballot comment]
The long bulleted lists are challenging to parse for a reader. You might consider grouping items with a common structure and then discussing them as a class rather than having every bullet repeat the same information. Further, you might consider reformatting the table-as-figure into an actual table.

Generally anywhere an RFC says "SHOULD consider" would be more clearly stated as simply "SHOULD" -- this is a recommended behavior, but operators might decide against it in certain situations.

===NITS FOLLOW===
- 5.1: 3x "This statistics" => "These statistics" or "Such statistics"

[Ballot discuss]
Thanks to the authors and the WG for this document.

Please find below certain points that I would like to discuss.

Semantics of routes, paths, primary, and backup.

Section 2 of this document says:
Primary route: A route to a prefix that is considered the best route by the BGP decision process [RFC4271] and actively used for forwarding traffic to that prefix.
Backup route: A backup route is eligible for route selection, but it is not selected as the primary route and is also installed in the Loc-RIB. It is not used until all primary routes become unreachable. Backup routes are used for fast convergence in the event of failures.

Consider an BGP route for destination prefix x/y is a multipath:
x/y via BGP NH1 (path1) (best)
    via BGP NH2 (path2) (multipath - say ECMP)
    via BGP NH3 (path3) (backup)
    via BGP NH4 (path4) (valid but not best/multipath/backup)
    via BGP NH5 (path5) (invalid - for whatsover reason)

This is a single route. The best/multipath/backup/valid/invalid/etc are qualifiers of its paths. Except for two stats that refer to paths (stale and suppressed), everything is referring to routes. I would like to discuss the semantics of route vs path. It seems to me like some of the stats are for paths and not routes.

In general, I think the use of the terms primary/backup which are related to forwarding plane aspects can be confusing. Instead, perhaps using terms that are more suitable for BGP Loc-RIB would be better? I've suggested some of them above for consideration. Also refer to draft-ietf-grow-bmp-path-marking-tlv - the terms of stats should be aligned across the BMP documents?

Furthermore, there is a wrong assumption that backup paths are only activated when all primary paths are down. This is very much implementation dependent. Some implementations have a 1:1 provisioning of primary/backup - where the backup would get used when its specific primary goes down - this draws on the FRR notion in the forwarding planes. Refer to the definition in draft-ietf-grow-bmp-path-marking-tlv

These clarifications have implications on several of the stats as they are defined currently.

Section 3 has the following text and Section 4 introduces a table that brings up an interesting aspect.

"This section defines different statistics type for Adj-RIB-In and Adj-RIB-Out monitoring type. Some of these statistics are also applicable to Loc-RIB; refer to Section 4 for more details."

For types 24 through 28, they are applicable for both Adj-RIB-In and Loc-RIB. How does one know what is being reported? Can this be clarified? Seems like this is the first document introducing such overloaded types but I don't find the reason why this is being done. There is also a sort of duplication for same stat being both global as well as per afi/safi - is there any guidance on whether only one of them needs to be supported (this way avoiding the race conditions and discrepancies in their totaling)?

It is important to clarify these aspects if this is going to set a precedent/guidance for other similar stats in BMP in future documents?


Section 5 - Operational considerations - is not entirely operational considerations.
There is reference to "implementations" in several places and it is not clear if this is on the router side or the collector/monitoring side - this needs to be clarified so that expectations on either side implementations are clear.

As an example: "Implementations MUST track discontinuities and log this information." - which side is this for?

Several aspects are not really operational consideration but implementation considerations. Please consider a "Procedures" section for documenting some of those aspects.

As an example, how is this text an operational consideration "Some statistics are dependent on feature configurations, such as GR, LLGR, and RPKI, so the corresponding statistics are only sent when these features are enabled. This statistics include Type 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 39, 40, 41, 42, and 43."

Another example is "A BMP implementation MUST ignore unrecognized stat types upon receipt and MUST exclude unsupported stat types upon transmission." ... this is a normative protocol behavior that is burried in the Operational Considerations section.

"Operators MAY consider rate-limiting statistic updates to minimize performance impact on control-plane processes." - why is this not at least a SHOULD and perhaps even a MUST?

[Ballot comment]
I note that the WGLC for this document was not cross-posted to the IDR WG for soliciting review as required by the GROW WG charter. I hope this can be avoided going forward.

I support the DISCUSS positions of both Eric and Gunter. Some of their points are related to the points that I have raised in my ballot as well.

I also have some comments/suggestions that I hope will help improve the document.

1) Type = 37: (64-bit Gauge) Current number of routes in per-AFI/SAFI post-policy Adj-RIB-In not found by verifying route origin AS number through the ROA of RPKI [RFC6811]. The value is structured as: 2-byte AFI, 1-byte SAFI, followed by a 64-bit Gauge.

The phrase 'not found by verifying ...' is confusing. I assume this refers to routes that didn't find any match in the RPKI cache? If so, please clarify.
This also applies to type 43.

2) Type = 39: (64-bit Gauge) Current number of routes refused to be sent by exceeding the maximum AS_PATH length supported by the local configuration.

The phrase 'refused to be sent ...' is confusing. Perhaps you mean routes that were not sent because ...
This also applies to type 40.

[Ballot comment]
I also support Gunter's DISCUSS and Deb's COMMENT that this would have been much easier to read if this were an update of RFC7854.

[Ballot comment]
I support both Eric and Gunter's discusses. 

It seems like it might be easier (and more clear) if this was an update to RFC 7854.

[Ballot discuss]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-grow-bmp-bgp-rib-stats-14

# The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-grow-bmp-bgp-rib-stats-14.txt

# Many thanks for the RTGDIR review from Bruno and the shepherd writeup from Job.

# Did i miss seeing a cross posting to IDR/BESS to understand if the various suggested gauges definitions are accurately described and understood from protocol perspective.

# DISCUSS
# =======

#1# the section "5.  Operational Considerations" seems to document a mix of operational considerations (non BCP14 language required) and GMP protocol formal procedures (BCP14 language is required). Can these two be untangled. It will make it easier for implementors to do the correct implementation.

#2# In general i found the descriptions of most of the gauges for the newly proposed statistics types not very accurately described. See my ""COMMENT"" section for input and overview. Too lengthy in the overview DISCUSS section

#3# some gauges seem duplicates from prior existing gauges. Not sure we need two times the same gauge in different code-points. seems sub-optimal and error prone.

#4# section 5 is named "Statistics Definition" and that seems not aa well described title. Can this be something that better describes the content? for example "RIB monitoring type statistics"

#5# it was unclear to me that what the document specifies is that the gauge that is formalized in this document is not simply a single dimensional gauge alone, but that the value transferred by BMP is a combination of "AFI + SAFI + gauge". I think i missed seeing that explicitly mentioned in the document.  Adding lengths (in general introduction section maybe to avoid repetition) of each field would help making sure implementations interop well.

[Ballot comment]
# comments
# ========

19   This document defines new statistics type to monitor BMP Adj-RIB-In
20   and Adj-RIB-Out Routing Information Bases (RIBs).

GV> in the abstract is mentioned that the document defines new statistics (but later is mentioned it are guages)

86   This document defines new gauges for BMP statistics message. 

GV> The above does not fully align with what is written in the abstract, I suspect you want to say:

"
This document defines gauges for new BMP statistics messages.
"

107   *  Pre-policy Adj-RIB-In: The result before applying the inbound
108       policy to an Adj-RIB-In.  Note that this aligns with the pre-
109       policy Adj-RIB-In concept specified in Section 2 of [RFC7854].

GV> Why is the text from RFC7854 not re-used? is there need for a new explicit definition?
GV> RFC7854 says:

"
  o  Adj-RIB-In: As defined in [RFC4271], "The Adj-RIBs-In contains
      unprocessed routing information that has been advertised to the
      local BGP speaker by its peers."  This is also referred to as the
      pre-policy Adj-RIB-In in this document.
"

127   *  Primary route: A route to a prefix that is considered the best
128       route by the BGP decision process [RFC4271] and actively used for
129       forwarding traffic to that prefix.

GV> is this accurate? is it not the BGP route that is selected by BGP for being forwarded to its peers?
There may be ECMP or uECMP routes actively used

131   *  Backup route: A backup route is eligible for route selection, but
132       it is not selected as the primary route and is also installed in
133       the Loc-RIB.  It is not used until all primary routes become
134       unreachable.  Backup routes are used for fast convergence in the
135       event of failures.

GV> here is the concept of "all primary routes" used, indicating more as a single best route. Is this not contradicting the prior bullet point?

137 3.  Statistics Definition

GV> This title seems rather undescriptive. What about calling this section:

"
RIB monitoring type statistics
"

145   *  Type = 18: (64-bit Gauge) Current number of routes in pre-policy
146       Adj-RIB-In.  This gauge is similar to stats type 7 defined in
147       [RFC7854] and makes it explicitly for the pre-policy Adj-RIB-In.

GV> It is written that this is similar as stats type 7, but when looking at the definitions in section 2 it is exactly the same.
pre-existing stats type 7 is exactly the same as the proposed stats type 18. Do we need type 18?

149   *  Type = 19: (64-bit Gauge) Current number of routes in per-Address
150       Family Identifier (AFI)/Subsequent Address Family Identifier
151       (SAFI) pre-policy Adj-RIB-In.  This gauge is similar to stats type
152       9 defined in Section 4.8 of [RFC7854] and makes it explicitly for
153       the pre-policy Adj-RIB-In.  The value is structured as: 2-byte
154       AFI, 1-byte SAFI, followed by a 64-bit Gauge.

GV> same observation as the prior item. The newly suggested type 19 is exactly the same as type 9. Do we need this new gauge?
GV> what exactly is the "value"? Can the structure of the field be more clarified? how how is the field encoded? it seems more as a single dimensional 64 bit gauge.

GV> first time usage of the AFI/SAFI in this document and adding a reference can be handy. Also maybe a list of AFI/SAFI this is intended for if this is only for a subset of them.

159   *  Type = 21: (64-bit Gauge) Current number of routes in per-AFI/SAFI
160       post-policy Adj-RIB-In.  The value is structured as: 2-byte AFI,
161       1-byte SAFI, followed by a 64-bit Gauge.

GV> what exactly is the "value"? Can the structure of the field be more clarified? how how is the field encoded? it seems more as a single dimensional 64 bit gauge.

163   *  Type = 22: (64-bit Gauge) Current number of routes in per-AFI/SAFI
164       rejected by inbound policy.  This gauge is different from stats
165       type 0 defined in Section 4.8 of [RFC7854].  The stats type 0 is a
166       32-counter which is a monotonically increasing number and doesn't
167       represent the current number of routes rejected by an inbound
168       policy due to ongoing configuration changes.  The value is
169       structured as: 2-byte AFI, 1-byte SAFI, followed by a 64-bit
170       Gauge.

GV> If over time more and more routes are rejected, then how can the number of rejected routes go ever go down? its an increasing number.
Unless there is assumption that there is accounting for the changing number of routes received/withdrawn by a peer and it is the number of routes that were rejected from the number of routes received. This may need more accurate definition of what exactly is being measured and what reference is used.

172   *  Type = 23: (64-bit Gauge) Current Number of routes in per-AFI/SAFI
173       accepted by inbound policy.  The value is structured as: 2-byte
174       AFI, 1-byte SAFI, followed by a 64-bit Gauge.  Some
175       implementations, or configurations in implementations, may discard
176       routes that do not match policy and thus the accepted count (type
177       23) and the Adj-RIB-In counts (type 21) will be identical in such
178       cases.

GV> not sure what is the text starting with "Some implementations, or ..." helps
with the formal definition of the field. It is useful from operational
perspective, but it convolutes the formal part of the definition of the field itself. Maybe move to operational implication section

180   *  Type = 24: (64-bit Gauge) Current Number of routes in per-AFI/SAFI
181       selected as primary route.  The value is structured as: 2-byte
182       AFI, 1-byte SAFI, followed by a 64-bit Gauge.

GV> the primary route is the route forwarding traffic? does this include all ECMP and uECMP paths.
BGP will only fwd the best BGP Path, but it may use more as a single path for forwarding

184   *  Type = 25: (64-bit Gauge) Current Number of routes in per-AFI/SAFI
185       selected as a backup route.  The value is structured as: 2-byte
186       AFI, 1-byte SAFI, followed by a 64-bit Gauge.

GV> does this include all routes that are not the BGP best path or only the routes that are not used for forwarding?
What makes a route a "backup" route.

195   *  Type = 27: (64-bit Gauge) Current Number of routes in per-AFI/SAFI
196       marked as stale by Graceful Restart (GR) events.  The value is
197       structured as: 2-byte AFI, 1-byte SAFI, followed by a 64-bit
198       Gauge.  'Stale' refers to a path which has been declared stale by
199       the BGP GR mechanism as described in Section 4.1 of [RFC4724].

GV> GR events happen when a CPM moves from a primary unit to a standby unit/process.
Such involves significant processing. Hence i wonder how mush operational value this
brings, or if would make the GR event worse then it already is.

201   *  Type = 28: (64-bit Gauge) Current Number of routes in per-AFI/SAFI
202       marked as stale by Long-Lived Graceful Restart (LLGR).  The value
203       is structured as: 2-byte AFI, 1-byte SAFI, followed by a 64-bit
204       Gauge.  'Stale' refers to a path which has been declared stale by
205       the BGP LLGR mechanism as described in Section 4.3 of [RFC9494].

GV> see prior comments

211   *  Type = 30: (64-bit Gauge) Current Number of routes per-AFI/SAFI
212       left until reaching the received route threshold which corresponds
213       to the upper bound of accepted routes per Section 6.7 of
214       [RFC4271].  The value is structured as: 2-byte AFI, 1-byte SAFI,
215       followed by a 64-bit Gauge.

GV> Is this accurate? multiprotocol extensions are described in RFC4760 and not in RFC4271.
It is unclear how this counter referencing rfc4271 is to be applied to rfc4760 when
multiple afi/safi may be received from a single peer.

217   *  Type = 31: (64-bit Gauge) Current Number of routes left until
218       reaching a license-customized route threshold.  This value is
219       affected by whether a customized license exists, and when the
220       customized license is installed.

GV> This may be a soft threshold and in addition may be enforced outside the router knowledge.

222   *  Type = 32: (64-bit Gauge) Current Number of routes in per-AFI/SAFI
223       left until reaching a license-customized route threshold.  This
224       value is affected by whether a customized license exists for the
225       relevant address family, and when the customized license is
226       installed.  The value is structured as: 2-byte AFI, 1-byte SAFI,
227       followed by a 64-bit Gauge.

GV> This may be a soft threshold and in addition may be enforced outside the router knowledge.

264   *  Type = 39: (64-bit Gauge) Current number of routes refused to be
265       sent by exceeding the maximum AS_PATH length supported by the
266       local configuration.

GV> can this be more accurate described? Is it "refused to be sent" or simply "not sent" because route AS_PATH is longer as max AS_PATH length towards the peer?

268   *  Type = 40: (64-bit Gauge) Current number of routes in per-AFI/SAFI
269       refused to be sent by exceeding the maximum AS_PATH length
270       supported by the local configuration.  The value is structured as:
271       2-byte AFI, 1-byte SAFI, followed by a 64-bit Gauge.

GV> See prior comment. I do not think 'refused' is the most accurate word to use.... maybe filtered is a better term to use?

328 5.  Operational Considerations

GV> Some of the definitions earlier have operational concerns included and are maybe better added to the operational implication section.

330   This document defines new gauges for BMP statistics messages.  The

GV> i think more accurate would be that the document specifies gauges for "new BMP statistics".

333   implementation-dependent.  Implementations SHOULD determine
334   appropriate report generation and delivery strategies, including
335   configurable timing intervals and threshold values.  The mechanism
336   for controlling the reporting of new gauges SHOULD be consistent with
337   that of existing types.  Implementations SHOULD also support per-
338   router configuration of statistic subsets for collection and
339   reporting.

GV> Why is this uppercase SHOULD? Is there a procedure that breaks? lowercase seems sufficient as its documenting good behavior.

341   Some statistics are dependent on feature configurations, such as GR,
342   LLGR, and RPKI, so the corresponding statistics are only sent when
343   these features are enabled.  This statistics include Type 24, 25, 26,

GV> From operational perspective sending BGP Stats during a GR may impact the GR event due to additional processing and dynamics.
That is an operational concern.

351   Certain statistics may have logical relationships (e.g., per-AFI/SAFI
352   counts summing to global totals).  Implementations MAY perform
353   consistency checks but MUST NOT assume strict dependencies (due to
354   potential race conditions or partial failures).  Discrepancies (e.g.,
355   sum(per-AFI/SAFI) != global count) SHOULD be logged as warnings but
356   MUST NOT disrupt protocol operation.

GV> not convinced these need to be BCP14 language. is BCP14 language required?

358   For backward compatibility, and absent policy otherwise, it is
359   RECOMMENDED that monitored routers capable of generating both (Type 7
360   and Type 18) or (Type 9 and Type 19) BMP statistics SHOULD transmit
361   both corresponding types simultaneously.  This allows monitoring
362   stations to process either format according to their needs without
363   disrupting existing implementations that rely on Type 7 or Type 9.

GV> In what way are The new types different from the prior types. its the exact same value representing the exact same property.

369   Counters may reset due to session restart, manual clearance, or
370   overflow.  Implementations MUST track discontinuities and log this
371   information.

GV> This document specifies gauges, not counters. Is this accurate usage of words?
is BCP14 language correct? seems not to be about formal protocol procedure

373   Operators MAY consider rate-limiting statistic updates to minimize
374   performance impact on control-plane processes.  Operators SHOULD
375   enable only necessary statistics to reduce memory and CPU overhead.

GV> lowercase should/may seems sufficient


Many thanks for this document,

Kind Regards,
Gunter Van de Velde
RTG Area Director

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-grow-bmp-bgp-rib-stats-13
CC @evyncke

Thank you for the work put into this document.

Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Job Snijders for the shepherd's write-up including the WG consensus *and* the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

### Section 3.3

There is no section 3.3 to list the types for Loc-RIB, the reader has to wait until section 4 to see this mentioned in the "summary", which is NOT a summary as it specifies the available value for Loc-RIB. I.e., add a section 3.3 listing the type numbers available for Loc-RIB.

[Ballot comment]

## COMMENTS (non-blocking)

### Section 1

Mostly cosmetic but the 1st sentence of the 2nd paragraph has little value, the 2nd sentence seems to be enough.

### Section 3.1

It is a matter of taste of course, but I would have preferred to have the statistic types presented as "name (type = #, format) longer description" as starting with the type number is cumbersome for the reader.

I also failed to understand the logic of sending only one (as opposed to the latest version of this I-D) type when two are available (e.g., for types 7 & 18), should there be some recommendations ?

### Section 7

Please use the exact URI of https://www.iana.org/assignments/bmp-parameters/bmp-parameters.xhtml#statistics-types

### Section 10.2

As indicated by the idnits tool, s/Informational References/*Informative* References/

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-grow-bmp-bgp-rib-stats-12. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which we must complete.

In the BMP Statistics Types registry in the BGP Monitoring Protocol (BMP) Parameters registry group located at:

https://www.iana.org/assignments/bmp-parameters/

twenty-six existing temporary registrations will be made permanent and their references changed to [ RFC-to-be ] as follows:

Stat Type = 18 Description = Number of routes currently in pre-policy Adj-RIB-In.
Stat Type = 19 Description = Number of routes currently in per-AFI/SAFI pre-policy Adj-RIB-In.
Stat Type = 20 Description = Number of routes currently in post-policy Adj-RIB-In.
Stat Type = 21 Description = Number of routes currently in per-AFI/SAFI post-policy Adj-RIB-In.
Stat Type = 22 Description = Number of routes currently in per-AFI/SAFI rejected by inbound policy.
Stat Type = 23 Description = Number of routes currently in per-AFI/SAFI accepted by inbound policy.
Stat Type = 24 Description = Number of routes currently in per-AFI/SAFI selected as primary route.
Stat Type = 25 Description = Number of routes currently in per-AFI/SAFI selected as a backup route.
Stat Type = 26 Description = Number of routes currently in per-AFI/SAFI suppressed by configured route damping policy.
Stat Type = 27 Description = Number of routes currently in per-AFI/SAFI marked as stale by GR events.
Stat Type = 28 Description = Number of routes currently in per-AFI/SAFI marked as stale by LLGR.
Stat Type = 29 Description = Number of routes currently left until reaching the received route threshold.
Stat Type = 30 Description = Number of routes currently per-AFI/SAFI left until reaching the received route threshold.
Stat Type = 31 Description = Number of routes currently left until reaching a license-customized route threshold.
Stat Type = 32 Description = Number of routes currently in per-AFI/SAFI left until reaching a license-customized route threshold.
Stat Type = 33 Description = Number of routes currently rejected due to exceeding the length threshold of AS-PATH.
Stat Type = 34 Description = Number of routes currently in per-AFI/SAFI rejected due to exceeding the length threshold of AS-PATH.
Stat Type = 35 Description = Number of routes currently in per-AFI/SAFI post-policy Adj-RIB-In invalidated after verifying route origin AS number through the ROA of RPKI.
Stat Type = 36 Description = Number of routes currently in per-AFI/SAFI post-policy Adj-RIB-In validated after verifying route origin AS number through the ROA of RPKI.
Stat Type = 37 Description = Number of routes currently in per-AFI/SAFI post-policy Adj-RIB-In not found after verifying route origin AS number through the ROA of RPKI.
Stat Type = 38 Description = Number of routes currently in per-AFI/SAFI rejected by outbound policy.
Stat Type = 39 Description = Number of routes currently refused to be sent by exceeding the length threshold of AS-PATH.
Stat Type = 40 Description = Number of routes currently in per-AFI/SAFI refused to be sent by exceeding the length threshold of AS-PATH.
Stat Type = 41 Description = Number of routes currently in per-AFI/SAFI post-policy Adj-RIB-Out invalidated after verifying route origin AS number through the ROA of RPKI.
Stat Type = 42 Description = Number of routes currently in per-AFI/SAFI post-policy Adj-RIB-Out validated after verifying route origin AS number through the ROA of RPKI.
Stat Type = 43 Description = Number of routes currently in per-AFI/SAFI post-policy Adj-RIB-Out not found after verifying route origin AS number through the ROA of RPKI.

We understand that this is the only action required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-10-24):

From: The IESG
To: IETF-Announce
CC: draft-ietf-grow-bmp-bgp-rib-stats@ietf.org, grow-chairs@ietf.org, grow@ietf.org, job@sobornost.net, mohamed.boucadair@orange.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Advanced BGP Monitoring Protocol (BMP) Statistics Types) to Proposed Standard


The IESG has received a request from the Global Routing Operations WG (grow)
to consider the following document: - 'Advanced BGP Monitoring Protocol (BMP)
Statistics Types'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-10-24. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  RFC 7854 defines different BGP Monitoring Protocol (BMP) statistics
  message types to observe events that occur on a monitored router.
  This document defines new statistics type to monitor BMP Adj-RIB-In
  and Adj-RIB-Out Routing Information Bases (RIBs).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-bgp-rib-stats/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/6783/



The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-ietf-rtgwg-bgp-pic: BGP Prefix Independent Convergence (None - Internet Engineering Task Force (IETF) stream)

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There was ample of support in GROW to proceed to RFC publication, no opposition was voiced.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was no controversy.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No threats of appeal or extreme discontent were made.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Section 5 of the -08 draft contains an RFC7942 "Implementation Status" section, listing two reputable vendors.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The document is self-contained within GROW

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is straight-forward and needed. The document specifies a number of new BMP Statistics Types, which in order to be useful to the wider community benefit from being documented using the IETF process.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

I'm not sure that's needed

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard. This is a document specifically to foster interopability and change-control resides with GROW/IETF.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, authors responded - https://mailarchive.ietf.org/arch/msg/grow/60Gxl7sYVim26hCwRgzxMGTgu5I/

However an IPR disclosure was shared: https://mailarchive.ietf.org/arch/msg/grow/DpTgH1OIbizYeBwooYKk5gJ_QEY/

After making the WG aware of this disclosure another round of WGLC was inititated: https://mailarchive.ietf.org/arch/msg/grow/sXxuPw4qBEdn7JSAR3gSsx3oWEU/ to which many participants positively responded

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The 4 authors wish to be listed.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No issues there

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

All looks good

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are publicly available

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

N/A

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

Nope

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

Nope

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The majority of this document is a request to IANA to register certain codepoints. IANA already registered these via the IANA Early Allocation procedure, so what's already there is probably clear enough.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A - the allocation all are "Standards Action"

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There was ample of support in GROW to proceed to RFC publication, no opposition was voiced.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was no controversy.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No threats of appeal or extreme discontent were made.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Section 5 of the -08 draft contains an RFC7942 "Implementation Status" section, listing two reputable vendors.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The document is self-contained within GROW

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is straight-forward and needed. The document specifies a number of new BMP Statistics Types, which in order to be useful to the wider community benefit from being documented using the IETF process.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

I'm not sure that's needed

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard. This is a document specifically to foster interopability and change-control resides with GROW/IETF.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, authors responded - https://mailarchive.ietf.org/arch/msg/grow/60Gxl7sYVim26hCwRgzxMGTgu5I/

However an IPR disclosure was shared: https://mailarchive.ietf.org/arch/msg/grow/DpTgH1OIbizYeBwooYKk5gJ_QEY/

After making the WG aware of this disclosure another round of WGLC was inititated: https://mailarchive.ietf.org/arch/msg/grow/sXxuPw4qBEdn7JSAR3gSsx3oWEU/ to which many participants positively responded

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The 4 authors wish to be listed.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No issues there

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

All looks good

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are publicly available

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

N/A

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

Nope

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

Nope

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The majority of this document is a request to IANA to register certain codepoints. IANA already registered these via the IANA Early Allocation procedure, so what's already there is probably clear enough.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A - the allocation all are "Standards Action"

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/