Dear Prasad, Mukul, Yisong, Changwang and Jinming, Thank you for bringing this to my attention Prasad. I haven't started the document shepherding since not all remarks and comments from the working group last call has been addressed yet.
However I like to give a first feedback to some of the discussions below since I believe it should be discussed as early as possible. I understand from reviewing https://datatracker.ietf.org/doc/html/rfc7854#section-4.8 https://datatracker.ietf.org/doc/html/rfc8671#section-6.2 https://datatracker.ietf.org/doc/html/rfc9069#section-5.6 That the BMP statistics are bound by the BMP per peer header with the L indicating with 0 and 1, Pre- or Post-Policy and O flags always set to 0 and the statistics type defining wherever they are Adj-RIB In or Out. Looking at draft-ietf-grow-bmp-bgp-rib-stats-08, I see that all statistics can be attributed to either Adj-RIB In or Out depending wherever there are in section 2.1 or 2.2. Therefore I would expect by reading https://datatracker.ietf.org/doc/html/rfc8671#section-6.2 that the metrics are reported with O flag set to 0 and the metrics exported represent the value for their respective RIB and with L flag wherever Pre or Post-Policy. Where https://datatracker.ietf.org/doc/html/rfc8671#section-6.2 statistics only be attributed to Adj-RIB In and https://datatracker.ietf.org/doc/html/rfc9069#section-5.6 to Local RIB. Is my interpretation correct? Looking at https://www.rfc-editor.org/errata/eid7703, which is an errata changing normatively the specification of RFC 7854, which in my opinion is not allowed, then the L flag can be used to distinguish between Pre- and Post-Policy for route-monitoring only, therefore the L flag is not applicable to statistics. Looking at Swsscom's network, I see 20'000 nodes reporting BMP, 72 nodes for one operating system not complying to https://datatracker.ietf.org/doc/html/rfc8671#section-6.2, having O flag set to 1 and 457 nodes having L bit set complying to https://datatracker.ietf.org/doc/html/rfc7854#section-4.2 but not to https://www.rfc-editor.org/rfc/inline-errata/rfc7854.html. My suggestion is to revoke errata 7703 as it violates IETF policy. GROW chairs, please review. I agree with Prasad that some of the statistics would be interesting to cover Local RIB as well for network operators, however the scope of the document according to the abstract is Adj-RIB In/Out. I believe the working group needs to decide wherever the scope should be extended to Local RIB or not. Regarding item 2, Statistics dependent on feature Configuration. I agree with Prasad's input that mentioned statistics should only be exported when the corresponding BGP features are enabled. I found no normative text in RFC 7854, 8671 and 9069 which made that clear because those counters did not represent BGP optional features. Taking https://datatracker.ietf.org/doc/html/rfc7950#section-5.6.2 as an example from YANG, I believe this matches with what Prasad was suggesting and is best practice. From a network analytics perspective, that’s the application which consumes the BMP data, it would be confusing to receive metrics for not enabled BGP features. Since this is the first document specifying statistics for optional BGP features, a normative text saying that only statistics are exported when those features are enabled makes sense to me. The feedback on item 5, Additional Statistics, I did not understand. Best wishes Thomas From: Narasimha Prasad S N (snprasad) <[email protected]> Sent: Tuesday, September 30, 2025 2:24 PM To: Graf Thomas, SCS-INI-NET-VNC-E2E <[email protected]> Subject: FW: [Feedback]FW: [GROW] WGLC RESTART - draft-ietf-grow-bmp-bgp-rib-stats (ends 01/Aug/2025) ... FW: [GROW] Re: Working Group Last Call (WGLC) for draft-ietf-grow-bmp-bgp-rib-stats (start 18/May/2025 end 1/Jun/2025) Be aware: This is an external email. + Thomas explicitly (as you are the document shepard 😊). Thank you. From: Narasimha Prasad S N (snprasad) Sent: 30 September 2025 17:27 To: 'Mukul Srivastava' <[email protected]<mailto:[email protected]>>; '[email protected]' <[email protected]<mailto:[email protected]>>; 'linchangwang' <[email protected]<mailto:[email protected]>> Cc: GROW WG <[email protected]<mailto:[email protected]>>; <[email protected]<mailto:[email protected]>> <[email protected]<mailto:[email protected]>> Subject: RE: [Feedback]FW: [GROW] WGLC RESTART - draft-ietf-grow-bmp-bgp-rib-stats (ends 01/Aug/2025) ... FW: [GROW] Re: Working Group Last Call (WGLC) for draft-ietf-grow-bmp-bgp-rib-stats (start 18/May/2025 end 1/Jun/2025) Including grow WG + chairs as we are close to publication. It will be good to clarify/address below in the draft. Thanks From: Narasimha Prasad S N (snprasad) Sent: 11 August 2025 18:09 To: Mukul Srivastava <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; linchangwang <[email protected]<mailto:[email protected]>> Subject: RE: [Feedback]FW: [GROW] WGLC RESTART - draft-ietf-grow-bmp-bgp-rib-stats (ends 01/Aug/2025) ... FW: [GROW] Re: Working Group Last Call (WGLC) for draft-ietf-grow-bmp-bgp-rib-stats (start 18/May/2025 end 1/Jun/2025) Hi Mukul, Please see inline for [snnp] From: Mukul Srivastava <[email protected]<mailto:[email protected]>> Sent: 07 August 2025 19:37 To: Narasimha Prasad S N (snprasad) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; linchangwang <[email protected]<mailto:[email protected]>> Subject: Re: [Feedback]FW: [GROW] WGLC RESTART - draft-ietf-grow-bmp-bgp-rib-stats (ends 01/Aug/2025) ... FW: [GROW] Re: Working Group Last Call (WGLC) for draft-ietf-grow-bmp-bgp-rib-stats (start 18/May/2025 end 1/Jun/2025) Prasad Pls see my response inline with [MS] tag. Thanks Mukul Juniper Business Use Only From: Narasimha Prasad S N (snprasad) <[email protected]<mailto:[email protected]>> Date: Thursday, August 7, 2025 at 1:24 AM To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, Mukul Srivastava <[email protected]<mailto:[email protected]>>, linchangwang <[email protected]<mailto:[email protected]>> Subject: [Feedback]FW: [GROW] WGLC RESTART - draft-ietf-grow-bmp-bgp-rib-stats (ends 01/Aug/2025) ... FW: [GROW] Re: Working Group Last Call (WGLC) for draft-ietf-grow-bmp-bgp-rib-stats (start 18/May/2025 end 1/Jun/2025) [External Email. Be cautious of content] Hi Authors, I had shared this feedback on the draft, couple of months back around the time the previous WGLC was issued, can you please review and respond if they could be adopted into the draft and share any implementation details per below. Thank you, Prasad -----Original Message----- From: Narasimha Prasad S N (snprasad) Sent: 23 July 2025 14:21 To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: [GROW] WGLC RESTART - draft-ietf-grow-bmp-bgp-rib-stats (ends 01/Aug/2025) ... FW: [GROW] Re: Working Group Last Call (WGLC) for draft-ietf-grow-bmp-bgp-rib-stats (start 18/May/2025 end 1/Jun/2025) -----Original Message----- From: Narasimha Prasad S N (snprasad) <[email protected]<mailto:[email protected]>> Sent: 30 May 2025 09:33 To: Paolo Lucente <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: [GROW] Re: Working Group Last Call (WGLC) for draft-ietf-grow-bmp-bgp-rib-stats (start 18/May/2025 end 1/Jun/2025) Hi, Have the following feedback / comments, please review and accommodate them (apologies for joining the conversation late) 1. Statistics dependant on Monitored RIB-View(s): * Operators can enable or disable RIB-view modes on the routers to manage monitoring. * Please clarify that statistics will only be transmitted if the corresponding RIB-views are actively monitored, and not all statistics will be sent always. [MS] – This is implementation/vender specific details. The draft just describes the details about what the counters mean. This is inline with base BMP RFC 7854 which is being extended by this draft. [snnp] It is important for the draft to clarify that statistics need to be sent only when a particular RIB-view is being monitored. Rest may be implementation specific. It won’t hurt to add Operation/Implementation aspects in the draft for clarity so both sides know what to expect. * Please map these statistics to the more specific RIB-views - to include the Pre and Post modes on top of Adj-RIB-In/Out. Some statistics seem relevant for the Local-RIB view as well. [MS] – All counters as described in this draft are related to rib-in and rib-out. Where applicable they clearly mention if that is applicable to pre or post. [snnp] Some are Local-RIB specific, after the best-path is run. I met couple of customers who were confused as well. 2. Statistics dependant on feature Configuration: * Many of the statistics are available and would make sense only when the corresponding configurations are enabled (eg: GR, LLGR, RPKI etc) * Please add text to clarify that statistics only for configurated features would be sent [MS] Again this is implementation/vender specific details. [snnp] Let us guide the implementors and operators please by standardizing and calling out that all statistics need not be sent all the time but only when the features are enabled, this way they won’t expect statistics with zero values to be send if feature is disabled. 3. Statistics Type 27 / 28 clarifications - * "Number of routes in per-AFI/SAFI marked as stale by any configuration" * I think is meant to be specific to Graceful Restart (GR) and does not include Long-Lived Graceful Restart (LLGR), as there is a separate statistic defined for LLGR. * The text could be "marked as stale by GR events" instead of "any configuration" perhaps, as it is the GR events in the presence of GR configuration that would lead to marking of stale routes. * The stale routes are transient, I guess it is the stale route count when the GR event occurs, and the corresponding routes get marked stale before the replay happens from peer. [MS ] – Type 27 is for GR as the text mentions – "Stale refers to a path which has been declared stale by the BGP Graceful Restart mechanism”. We can update the text “by any configuration". [snnp] ok, please also clarify LLGR, GR aspects for Stats 27/28. * The text from the draft after RFC4724 text below could be deleted, it is a bit confusing in this context: * "Stale refers to a path which has been declared stale by the BGP Graceful Restart mechanism as described in Section 4.1 of [RFC4724], such as the routes filtered by a remote peer through application of policies during a graceful restart." [MS] – I don’t see it as confusing. * Please consider making the updates to both GR/LLGR text (stats 28) per above [MS] – Type 28 is for LLGR case as states in text – “Number of routes in per-AFI/SAFI marked as stale by Long-Lived Graceful Restart (LLGR).” 4. Statistics updating the previous RFC stats * For any stat types updating the previously defined stat types (Eg: stat 7 with stat 18), please add text that only the updated stats type defined in this draft needs to be sent and not both [MS] – Again, this is implementation/vender specific details. [snnp] The part where we clarify what needs to be sent is standard and keeps all implementation uniform and helps operators expect right thing. So please consider adding this for clarity. 5. Additional Statistics: Consider including the following four statistics for completeness, as they were defined in the other draft that was merged with this one (unless authors decided to remove it for a specific reason): * Routes rejected due to reaching the Received-Route Threshold * Routes rejected due to reaching the Received-Route Threshold per AFI-SAFI * Routes rejected due to reaching the license-customized Received-Route Threshold * Routes rejected due to reaching the license-customized Received-Route Threshold per AFI-SAFI [MS] – Probably we can park this for next draft. 6. Use Cases: Please consider adding use cases for these statistics, briefly describing how network operators plan to utilize them? We have the following broad categories of statistics, and it might be beneficial to cover how each category is used: * Per RIB-view table route sizes * Accepted/Rejected/Selected route counts * Different route-selection-type counts (stale, primary, backup, etc.) * RPKI-related statistics (validated, invalidated, not found) * Threshold-related statistics and others Additionally, how often would the operators prefer to receive these statistics (e.g., every three minutes)? Please consider making some recommendations here, that will be beneficial for scale deployments. [MS] – The frequency of stats would depend upon use case/scale. I don’t think draft should make any recommendation. [snnp] Operational considerations may be ? 7. Implementation Notes: Are there specific insights that implementers can share from their experience? * What scale/functional profile was tested? * Was memory and CPU monitored with and without statistics? * Did you observe any impact of statistics at higher scale? * What was the frequency of the statistics updates? * Any other relevant information that could be shared ? [MS] – Section 5 talks about it. [snnp] I checked Section 5, these details aren’t present. Implementation notes are removed before it becomes RFC, so sharing here would suffice Thanks. Prasad Thank you /snnp (Prasad) -----Original Message----- From: Paolo Lucente <[email protected]<mailto:[email protected]>> Sent: 18 May 2025 23:21 To: [email protected]<mailto:[email protected]> [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: [GROW] Working Group Last Call (WGLC) for draft-ietf-grow-bmp-bgp-rib-stats (start 18/May/2025 end 1/Jun/2025) This email begins a two-week WGLC on: Definition For New BGP Monitoring Protocol (BMP) Statistics Types https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-bgp-rib-stats/08/__;!!NEt6yMaO-gk!GwMVo4JpVWfLMVOl8H4o_xULefuitTJkAdzCIq-g1SGpO7o8w59zMbit31jUKEC2OITReQNH6tfkJQ$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-grow-bmp-bgp-rib-stats/08/__;!!NEt6yMaO-gk!GwMVo4JpVWfLMVOl8H4o_xULefuitTJkAdzCIq-g1SGpO7o8w59zMbit31jUKEC2OITReQNH6tfkJQ$> 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). """ Please take time to review this draft and post comments by Jun 1st 2025. Questions, suggestions, supportive comments, and objections are welcomed. In parallel there will be another email shortly for the IPR poll. Paolo GROW co-chair _______________________________________________ GROW mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> _______________________________________________ GROW mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
