[GROW] Re: Ketan Talaulikar's Discuss on draft-ietf-grow-bmp-bgp-rib-stats-14: (with DISCUSS and COMMENT)

["Srivastava, Mukul" <[e-mail]>]

Sorry I sent this too soon.

I see that some stats in section 3.2 doesn’t specify clearly if that is for adj-rib-in-pre or adj-rib-in-post.
We can clarify that. My current though is that most of those stats are for adj-rib-in-pre .

Similarly, in section 3.3, there are some stats which doesn’t say if that is for adj-rib-out-pre or adj-rib-out-post. We can clarify that. My current thought is that most of those stats are for adj-rib-out-post.


Thanks

Mukul

From: Srivastava, Mukul <[e-mail]>
Date: Thursday, November 20, 2025 at 3:49 PM
To: [e-mail] <[e-mail]>, Ketan Talaulikar <[e-mail]>, [e-mail] [e-mail] <[e-mail]>
Cc: linchangwang (RD) <[e-mail]>, The IESG <[e-mail]>, [e-mail] <[e-mail]>,
<[e-mail]>
Subject: Re: Ketan Talaulikar's Discuss on draft-ietf-grow-bmp-bgp-rib-stats-14: (with DISCUSS and COMMENT)

There shouldn’t be any need for demuxing problem for pre/post rib-in/rib-out/local-rib stats in this draft.

There are different stats type defined for pre-policy-rib-in, pre-policy-rib-out and pre-policy-rib-out. I don’t see any one stats type overloaded between them. The stats type details specifies which monitoring type this is applicable to.

For local-rib stats, the peer header (that precedes the stats message PDU) has peer-type which is set to 3, indicating it is a local rib-peer. Peer-address is also zero filled. This can be used for demuxing.

BMP local-rib rfc, RFC 9069 (https://datatracker.ietf.org/doc/html/rfc9069<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc9069__;!!NpxR!hPgYyiF-IPDdq102g5H5UGkn8E71BJ25J7ZfR1sOIVe342i5oDmX5Lk7j6aFb7vWxfDXQFF7HcSBcg5C4pNuFPpHvCCN$>)
5.1. <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc9069*section-5.1__;Iw!!NpxR!hPgYyiF-IPDdq102g5H5UGkn8E71BJ25J7ZfR1sOIVe342i5oDmX5Lk7j6aFb7vWxfDXQFF7HcSBcg5C4pNuFObkbaq3$> Per-Peer Header<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc9069*name-per-peer-header-2__;Iw!!NpxR!hPgYyiF-IPDdq102g5H5UGkn8E71BJ25J7ZfR1sOIVe342i5oDmX5Lk7j6aFb7vWxfDXQFF7HcSBcg5C4pNuFH7INkjL$>

Peer Type: Set to 3 to indicate Loc-RIB Instance Peer

Peer Address: Zero-filled.


Thanks

Mukul

From: [e-mail] <[e-mail]>
Date: Thursday, November 20, 2025 at 7:51 AM
To: Ketan Talaulikar <[e-mail]>, [e-mail] [e-mail] <[e-mail]>
Cc: linchangwang (RD) <[e-mail]>, The IESG <[e-mail]>, [e-mail] <[e-mail]>,
<[e-mail]>, Srivastava, Mukul <[e-mail]>
Subject: RE: Ketan Talaulikar's Discuss on draft-ietf-grow-bmp-bgp-rib-stats-14: (with DISCUSS and COMMENT)

Hi Ketan, WG,

I’d like to zoom into this one and kindly ask the WG to comment on this as this is beyond the initial scope set for draft-ietf-grow-bmp-bgp-rib-stats:

=
KT> Thank you for the new section 3.1 - it partially addresses my comment. You have clarified about the demuxing based on the Peer Type for Loc-RIB. However, there is nothing like that available for Adj-RIB-In/Adj-RIB-Out and their variants (pre/post policy). This results in a large multiplication of essentially the same stat type for all those views - only the Loc-RIB stands out as a sore exception with its own unique "peer-type" context at the top-level header. Is this the design blueprint that the WG wants to follow for defining BMP Stats? That is the larger question that I am asking the WG to discuss. There is no issue with the global and per-afi/safi definitions (the recent clarifications are welcome) - the point is whether this is another guidance now for all stat types to be now of two variants - global and per-afi/safi?

KT> I am basically looking for some design, guidance and consistency in how stats are being introduced in BMP. Bringing this up in the context of this document for this set of authors is perhaps unfortunate - this question is really to the WG as a whole. And a follow-up question is where would the WG like to document this guidance/design approach - this document or somewhere else?
=

Ketan, demuxing (pre/post) Adj-RIB-In/Adj-RIB-Out may be done using the per-peer flags in RFC7854/RFC8671:

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |V|L|A|O| Resv  |
   +-+-+-+-+-+-+-+-+

   *  The L flag, if set to 1, indicates that the message reflects
      the post-policy Adj-RIB-In (i.e., its path attributes reflect
      the application of inbound policy).  It is set to 0 if the
      message reflects the pre-policy Adj-RIB-In.  Locally sourced
      routes also carry an L flag of 1.

   *  The O flag indicates Adj-RIB-In if set to 0 and Adj-RIB-Out if set
      to 1.

However, there use for stats is not allowed. Specifically, RFC8671 says:

   The Statistics Report message has a Stat Type field to indicate the
   statistic carried in the Stat Data field.  Statistics report messages
   are not specific to Adj-RIB-In or Adj-RIB-Out and MUST have the O
   flag set to zero.  The O flag SHOULD be ignored by the BMP receiver.

Likewise, erratum [GROW] [Technical Errata Reported] RFC7854 (7703)<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/grow/g1d3cJhNMuSnchQiqX0lkQCnQkk/__;!!NpxR!nLyRWc9TopmUYhEnBbR_bVjiEwkD6pqQgtw7uPaGC2il8-3-wL6VIy57B0Rj8fR7I7rDQ3kPLNbG888FRAC2IxbsjNJ01A4$> (verified) says:

   *  The L flag, if set to 1, indicates that the message reflects
      the post-policy Adj-RIB-In (i.e., its path attributes reflect
      the application of inbound policy).  It is set to 0 if the
      message reflects the pre-policy Adj-RIB-In.  Locally sourced
      routes also carry an L flag of 1.  See Section 5 for further
      detail.  This flag has significance only when used with Route
      Monitoring messages.
I see at least that in [1] the WG discussed some options on the matter with a preference for defining explicit types as a function of the stat scope (current draft-ietf-grow-bmp-bgp-rib-stats design). Grouping stats per type would have a cost to factorize the same per-peer header if distinct scopes are to be sent, btw.

@GROW, please share your thoughts. Thanks.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/grow/kmLAh34FJNBQaa94soAAkKKdELg/<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/grow/kmLAh34FJNBQaa94soAAkKKdELg/__;!!NpxR!nLyRWc9TopmUYhEnBbR_bVjiEwkD6pqQgtw7uPaGC2il8-3-wL6VIy57B0Rj8fR7I7rDQ3kPLNbG888FRAC2Ixbsz2uNG6w$>

De : Ketan Talaulikar <[e-mail]>
Envoyé : jeudi 20 novembre 2025 11:42
À : Srivastava, Mukul <[e-mail]>
Cc : linchangwang (RD) <[e-mail]>; The IESG <[e-mail]>; [e-mail]; <[e-mail]> <[e-mail]>; [e-mail] [e-mail] <[e-mail]>; BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Objet : Re: Ketan Talaulikar's Discuss on draft-ietf-grow-bmp-bgp-rib-stats-14: (with DISCUSS and COMMENT)


Hi Mukul/Changwang,

Thanks for your responses. Please check in line below for my follow-up and clarifications.

I am also top-posting one point related to the new text updates. Sec 3.1 "The AFI/SAFI are used to identify network layer protocols and associated routing information. " ... not sure what network layer protocols are identified here. I would suggest just deleting that sentence since it is not necessary.

Please also include the clarification text from Jeff Haas indicating that only those AFI/SAFIs that have something to report need be included in the BMP messages. That may be important for collector implementations.


On Thu, Nov 20, 2025 at 5:09 AM Srivastava, Mukul <[e-mail]<mailto:[e-mail]>> wrote:
Forwarding changwang response to wider audience for visibility.

Ketan,

Please review -15 version published and see if some of the comments has been addressed.
My response [MS] in inline.


Thanks
Mukul

From: linchangwang (RD) <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, November 19, 2025 at 7:53 AM
To: Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Srivastava, Mukul <[e-mail]<mailto:[e-mail]>>
Subject: Re: OFFLIST Re: Ketan Talaulikar's Discuss on draft-ietf-grow-bmp-bgp-rib-stats-14: (with DISCUSS and COMMENT)
Hi Ketan,

See the reply from [Changwang] below.


----------------------------------------------------------------------

DISCUSS:

----------------------------------------------------------------------



Thanks to the authors and the WG for this document.



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



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

[MS] My understanding is all the stats is for routes and noth paths. Pls point out which stats you think is for the paths .

KT> To start with, primary/backup are characteristics of 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?

 [MS] I agree that the primary and backup are confusing and no matter how much we want to clarify in this document, it may still be confusion. Also this is not the right document to define such terms.

If you know any standard which clarifies these terms (Primary/Backup), we can open to reference it and update our document accordingly.  I would propose to define these stats as active/inactive route stats. Primary route —> Active route. Backup route —> Inactive route stats. I feel active and inactive routes may be less confusion to most people. I am also open to move this out of the spec for future work.

KT> It is a problem if this spec is published without the semantics being specified correctly and clearly. It affects interoperability and in some ways defeats the purpose. It is a question for the WG whether it wants to clarify/correct the stats defined in previous RFCs and whether they refer to paths or routes (I haven't reviewed them closely - but many of them indeed refer to routes). And these terms are not very complex and are well understood. I have already pointed to https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-path-marking-tlv/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-path-marking-tlv/__;!!NpxR!nLyRWc9TopmUYhEnBbR_bVjiEwkD6pqQgtw7uPaGC2il8-3-wL6VIy57B0Rj8fR7I7rDQ3kPLNbG888FRAC2Ixbs_lh7biM$> which is a WG document. Use/leverage that. I will argue that this aspect needs to be clarified in this document to apply to the stats in it and also to guide future stats. I can see things falling apart the moment there is a request for getting stats for multipath, ADD-PATHS, etc. Let us clarify it in this document.




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.



[Changwang] Please review the modifications to the document attached earlier. For "prefix," "router," and "path," no clear references are currently available. When a prefix has multiple paths, each path is considered a route.

KT> Where is that stated? And the context (or view) is also important. Consider the example that I gave above for Loc-RIB and also consider ADD-PATHS with Adj-RIB-In/Out.


As defined in RFC 9069, Stat Type = 8: (64-bit Gauge) Number of routes in Loc-RIB. In the Loc-RIB, multiple equivalent next hops from multiple neighbors may exist for routes. In this context, the description refers to "routes," and under multipath conditions, multiple paths should also be counted.

KT> I am missing something here. The following is what I see in RFC9069 - https://www.rfc-editor.org/rfc/rfc9069.html#section-5.6<https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9069.html*section-5.6__;Iw!!NpxR!nLyRWc9TopmUYhEnBbR_bVjiEwkD6pqQgtw7uPaGC2il8-3-wL6VIy57B0Rj8fR7I7rDQ3kPLNbG888FRAC2Ixbsl-y8xNg$> ... I read that stat to indicate the number of prefixes with at least one valid path (which is what is called routes).


•         Stat Type = 8: (64-bit Gauge) Number of routes in Loc-RIB.

•         Stat Type = 10: Number of routes in per-AFI/SAFI Loc-RIB. The value is structured as: 2-byte AFI, 1-byte SAFI, followed by a 64-bit Gauge.


Therefore, the statistics for the "primary route" in this document correspond to the statistics of the "selected path" you listed.

Regarding the "backup path," it is not the case that it only becomes active after all primary paths fail. Inappropriate descriptions have been removed.

Please review the current modifications to see if there are any issues. If you have better suggestions, I would appreciate them. Thank you.

KT> First, primary/backup is about path attributes and not routes. Please look at https://www.ietf.org/archive/id/draft-ietf-grow-bmp-path-marking-tlv-04.html#section-3.1<https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-grow-bmp-path-marking-tlv-04.html*section-3.1__;Iw!!NpxR!nLyRWc9TopmUYhEnBbR_bVjiEwkD6pqQgtw7uPaGC2il8-3-wL6VIy57B0Rj8fR7I7rDQ3kPLNbG888FRAC2IxbsvsZY22I$> - can you use that? I find those definitions much better. Sadly, they are placed in the IANA considerations section which is not appropriate and they should be in the normative text of the draft.






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



[Changwang] Section 3.1 adds a description of the statistics format and explains how the LOC-RIB is encapsulated. Additionally, Section 5.1 includes: "When these statistics apply to the Loc-RIB view, the Peer Type in the Per-Peer Header of the corresponding BMP Statistics Report Message MUST be set to 3."



[MS] As Changwang mentioned above, I hope how this stats would be reported for Loc-RIB peer is clear in our latest document.

I don’t see any issue with duplication for same stat being used for both global as well as per afi/safi. This spec defines the stats which if implemented, will provide a total count (sum across afi/safi) and individual afi/safi count view to the collector. Vendors can chose what they want to implement. I don’t think we can provide any guidance what should be implemented. That is vender’s implementation detail.

KT> Thank you for the new section 3.1 - it partially addresses my comment. You have clarified about the demuxing based on the Peer Type for Loc-RIB. However, there is nothing like that available for Adj-RIB-In/Adj-RIB-Out and their variants (pre/post policy). This results in a large multiplication of essentially the same stat type for all those views - only the Loc-RIB stands out as a sore exception with its own unique "peer-type" context at the top-level header. Is this the design blueprint that the WG wants to follow for defining BMP Stats? That is the larger question that I am asking the WG to discuss. There is no issue with the global and per-afi/safi definitions (the recent clarifications are welcome) - the point is whether this is another guidance now for all stat types to be now of two variants - global and per-afi/safi?

KT> I am basically looking for some design, guidance and consistency in how stats are being introduced in BMP. Bringing this up in the context of this document for this set of authors is perhaps unfortunate - this question is really to the WG as a whole. And a follow-up question is where would the WG like to document this guidance/design approach - this document or somewhere else?




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

[MS] The latest version address this.

KT> I find the use of the term "operators" strange. How about BMP Stats producer and collector? They are both implementations. It is not so that operators have to build their own collectors - they may be using some off the shelf or open source collector implementations as well? To me, the split into sections 5.1 and 5.2 are strange and not what I was asking for. My point was that several of these were implementation considerations - some on the producer and some on the collector side.

KT> The latest version puts the onus on the routers producing BMP Stats - "Implementations MUST track discontinuities and log this information." OK. So routers will generate syslogs. How easy would it be for the collectors to retrieve this information via syslogs and correlate with what they are getting from the BMP feed. I would have expected this to get signaled or indicated within the BMP feed itself? I haven't checked myself but I would expect there to be something already within BMP for such situations?


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

 [MS] I see this as an operation consideration for implementing this stats at producer side.

KT> They seem more like protocol procedures and implementation considerations to me.




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.

 [MS] I agree and we can remove this statement.

KT> I didn't ask for the removal of the statement and I am glad that it has been moved into the new section 3.1 where it is more apt. Just one part - excluding the unsupported stat types upon transmission - is obvious (what else can it do). Perhaps remove that part? But otherwise good with this. Thanks.




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

[MS] This can be updated to “should"



[Changwang] Divide Chapter 5 into 5.1 and 5.2, where 5.1 corresponds to the generation and processing of statistics, and 5.2 corresponds to the implementation.

KT> Please see my previous comments. This is not what I had asked for and is more confusing at least for me.










----------------------------------------------------------------------

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.



[Changwang] Modified in the new version..

KT> Thank you. All good here.

Thanks,
Ketan









Thanks,

Changwang


发件人: Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
发送时间: 2025年11月19日 20:22
收件人: linchangwang (RD) <[e-mail]<mailto:[e-mail]>>
抄送: [e-mail]<mailto:[e-mail]>; Srivastava, Mukul <[e-mail]<mailto:[e-mail]>>
主题: Re: OFFLIST Re: Ketan Talaulikar's Discuss on draft-ietf-grow-bmp-bgp-rib-stats-14: (with DISCUSS and COMMENT)

温馨提示： 此邮件来自公司外部，请核实发件人信息，慎点链接与附件。This is an external email. Please verify the sender's information and proceed with caution when clicking links or downloading attachments.

Hi Changwang,

This is hard for me to check/review without a discussion as I don't understand the authors' position on the points that I've raised. I can take a look at the changes as we conclude our discussions on the individual points.

Thanks,
Ketan


On Wed, Nov 19, 2025 at 5:32 PM linchangwang <[e-mail]<mailto:[e-mail]>> wrote:

Hi Ketan,





Thank you for your prompt and insightful review and suggestions.



Mukul and I have revised the document according to your feedback. Please refer to the attached file for details.



The document has not been submitted yet.



Could you please review it in advance to see if there are any additional comments? Thank you.





Thanks,

Changwang


发件人: Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
发送时间: 2025年11月19日 15:48
收件人: [e-mail]<mailto:[e-mail]>
抄送: The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
主题: Re: Ketan Talaulikar's Discuss on draft-ietf-grow-bmp-bgp-rib-stats-14: (with DISCUSS and COMMENT)


Thanks Med.

Hi Authors/WG,

Right now, we have duplication of stat types for global and per afi/safi. We also have the same stat being duplicated for different "views" in some cases and in other cases the same stat being demuxed based on the mode. All of this is happening in this document.

The part about guidance for further stats is for the WG to document its design practice/approach that can guide further stats. This way, there is a consistent approach (keeping the existing/old stats aside perhaps). Unlike other documents, this one is very much focussed on stats and seemed to me like a good place for the WG to put in place guidance.

And this is just me asking the authors and WG to discuss if these aspects have been considered and if not, then should they be as part of this document?

Thanks,
Ketan


On Wed, Nov 19, 2025 at 12:34 PM <[e-mail]<mailto:[e-mail]>> wrote:
Hi Ketan,

My comment was to clarify that there is no demuxing issue with using the same type as we do have a new peer type defined for Loc-RIB in RFC9069 (under the per peer header). I agree that it would be helpful to include a brief reminder of how this is expected to work, though.

The other points you mentioned are good ones to discuss. Thanks.

Cheers,
Med

De : Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Envoyé : mardi 18 novembre 2025 18:16
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>
Cc : The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Objet : Re: Ketan Talaulikar's Discuss on draft-ietf-grow-bmp-bgp-rib-stats-14: (with DISCUSS and COMMENT)


Hi Med,

By setting precedent, I was referring to the same stat type being used in different modes/views. RFC9069#section-5.6 does define stat types only for Loc-RIB? So, looking for some clarification on how the same type can be used for different views and if this was the recommended approach going forward instead of having different stat types for the same thing in different views.

You have also misread or misunderstood what I have said about the per afi/safi thing.

I'll wait for the authors to respond.

Thanks,
Ketan

On Tue, Nov 18, 2025 at 10:13 PM <[e-mail]<mailto:[e-mail]>> wrote:
Hi Ketan,

I trust the authors will follow soon.

One quick comment on your second discuss point: this is does not set a precedent. Please refer to rfc9069#section-5.6 and more generally to that RFC for Loc-RIB matters.

Also, per per-AFI/SAFI is not specific to this spec (see the base spec). The Ops section includes some aspects to control which stats to send, but I think that can me tweaked for better clariy.

Cheers,
Med

> -----Message d'origine-----
> De : Ketan Talaulikar via Datatracker <[e-mail]<mailto:[e-mail]>>
> Envoyé : mardi 18 novembre 2025 17:03
> À : The IESG <[e-mail]<mailto:[e-mail]>>
> Cc : [e-mail]<mailto:[e-mail]>; grow-
> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> Objet : Ketan Talaulikar's Discuss on draft-ietf-grow-bmp-bgp-rib-
> stats-14: (with DISCUSS and COMMENT)
>
>
> Ketan Talaulikar has entered the following ballot position for
> draft-ietf-grow-bmp-bgp-rib-stats-14: Discuss
>
> When responding, please keep the subject line intact and reply to
> all email addresses included in the To and CC lines. (Feel free to
> cut this introductory paragraph, however.)
>
>
> ------------------------------------------------------------------
> DISCUSS:
> ------------------------------------------------------------------
>
> Thanks to the authors and the WG for this document.
>
> Please find below certain points that I would like to discuss.
>
> <discuss-1> 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.
>
> <discuss-2> 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?
>
> <discuss-3> 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?
>
>
> ------------------------------------------------------------------
> ----
> 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.
>
>

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.
-------------------------------------------------------------------------------------------------------------------------------------
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from New H3C, which is
intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender
by phone or email immediately and delete it!

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.