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]>; [email protected]; linchangwang <[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]>
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
