Hi Camilo, Paolo, Mukul, and GROW WG, Thank you for updating the draft to version -01 and simplifying the statistics treatment.
However, we have serious operational concerns regarding a specific requirement currently stated in the draft: "If a change to BMP export filtering changes the set of routes reported for a RIB view, the sender MUST send a Peer Down Notification followed by a Peer Up Notification before reporting the changed RIB view." Basing export filtering adjustments on Peer Down / Peer Up notifications introduces significant operational and performance issues in real-world large-scale networks: 1. Unintended Flapping and Interference Across Address Families: A single BGP session often carries multiple AFI/SAfIs (e.g., IPv4 Unicast, IPv6 Unicast, BGP-VPN, etc.). If a filtering policy changes for only one specific address family, forcing a Peer Down and Peer Up notification for the entire BGP session will unnecessarily disrupt and resynchronize unaffected address families, leading to false alarms and state inconsistency at the monitoring station (BMS). 2. Severe Performance and Memory Burden on Collectors: In production environments, a single BGP session can easily maintain hundreds of thousands or even millions of routing entries. Triggering a Peer Down and Peer Up cycle due to a minor filtering adjustment forces the collector (Server) to first flush all existing routes and then re-add millions of entries. This causes unnecessary CPU spikes, memory churn, and potential processing backpressure on the monitoring station. 3. False Semantic Interpretation of BGP Session Status: BMP Peer Down and Peer Up notifications fundamentally represent the lifecycle of the underlying monitored BGP session itself. Emulating session flaps simply because of export filter updates misleads operators and automated assurance systems into believing the actual BGP peer relationship has dropped and re-established, masking true network health events. Proposal: Instead of abusing Peer Down / Peer Up mechanisms for filter policy adjustments, we suggest exploring alternative, more granular approaches (or clarifying that adjustments should be handled gracefully without tearing down the peer session context, similar to how dynamic capability or soft-reconfiguration mechanisms work). We would appreciate the authors' and the working group's thoughts on this. Best Regards, Shunwan From: Camilo Cardona <[email protected]> Sent: Friday, October 16, 2026 11:02 PM To: grow <[email protected]> Subject: [GROW] Re: I-D Action: draft-ietf-grow-bmp-adj-ribs-filtered-01.txt Hello grow, We submitted a new version of draft-ietf-grow-bmp-adj-ribs-filtered. The main change of this version relates to an email Paolo Lucente sent in this group a while ago: there is no coordinated treatment of BMP statistics across the different RIBs and new TLVs. Each one is doing its own thing, and it is hard to steer this without global coordiation that should also include what operators actually use from BMP statistics. Since this is a document that is, on purpose, simple, we don't want to propose anything different or solve the above problem. We therefore decided to simplify everything related to BMP statistics and make the F flag consistent with the already standardized O flag over the same RIBs. The draft now proposes not modifying any BMP statistics semantics at all: the F flag is unset in Statistics Report messages and should be ignored. More global and coordinated work can modify this in the future, if needed. Besides that, we clarified some of the text, made explicit that describing the filters is outside the scope of the document (added the BMP YANG draft as an informative reference for this); removed unneeded draft dependencies; and updated the Security Considerations. Thanks, Camilo & Paolo & Mukul De: <[email protected]<mailto:[email protected]>> Para: <[email protected]<mailto:[email protected]>> CC: <[email protected]<mailto:[email protected]>> Fecha: jue, 15 oct 2026 18:31:39 -0500 Asunto: [GROW] I-D Action: draft-ietf-grow-bmp-adj-ribs-filtered-01.txt Internet-Draft draft-ietf-grow-bmp-adj-ribs-filtered-01.txt is now available. It is a work item of the Global Routing Operations (GROW) WG of the IETF. Title: Filtering Adj-Rib-In and Adj-Rib-Out to BMP receivers Authors: Paolo Lucente Camilo Cardona Mukul Srivastava Name: draft-ietf-grow-bmp-adj-ribs-filtered-01.txt Pages: 5 Dates: 2026-10-15 Abstract: Filtering RIBs in BMP (BGP Monitoring Protocol) can be desirable for several use-cases like, for example, limiting the amount of data a collector station has to process or allow a sender to export only a certain afi/safi of interest. This document defines an indicator to inform a collector station that a Adj-Rib-In or Adj-Rib-Out data feed is being filtered at the BMP exporter. This document updates RFC 7854. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-adj-ribs-filtered/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-adj-ribs-filtered-01 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-grow-bmp-adj-ribs-filtered-01 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts _______________________________________________ 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]
