Hi Camilo and GROW WG, Thanks for the quick response.
While filter configuration changes might not happen frequently, treating them as rare events that justify a synthetic Peer Down/Up notification presents two major concerns: 1. High Impact of Single-Event Disruption (Blast Radius): Even if a filter is changed infrequently (e.g., during routine operations or maintenance), forcing a Peer Down/Up cycle on a session carrying BGP Full Tables (1M+ prefixes) or thousands of VPN instances creates a massive burst of processing burden on the collector. The collector must purge and re-ingest millions of routes, causing CPU spikes, database churn, and false session-down alerts in monitoring dashboards. In large-scale carrier networks, operational procedures strictly prohibit mechanisms that induce such high blast radius for simple configuration updates. 2. Real-World Use Cases Requiring Dynamic/Frequent Filter Adjustments: In modern automated networks, export filtering is increasingly driven by dynamic control platforms rather than static human configuration: a) Automated DDoS Mitigation & Traffic Scrubbing: When an attack occurs, automated security systems dynamically update BMP export filters on edge routers to monitor specific subnets or flow profiles under attack, and relax these filters once the event subsides. This creates dynamic, event-driven filter modifications. b) On-Demand Network Troubleshooting: During active incidents or routing anomaly isolation, operators temporarily expand or narrow down BMP export filters (e.g., scoping to specific BGP Communities, VRFs, or AS-PATHs) to troubleshoot issues without overwhelming the collector with all RIB data. Once the issue is resolved, the filter is removed. c) Multi-Tenant & Controller-Driven Traffic Engineering: In SDN-managed BGP/MPLS or SRv6 networks, controller platforms frequently adjust monitoring policies (e.g., enabling Adj-Rib-In monitoring only for specific high-priority VPNs or prefixes during traffic re-routing). Instead of treating export policy changes as session tear-downs, a more graceful mechanism (such as sending a specific notification or flag update indicating a filter update without invalidating the peer state) would prevent false alarms and collector instability. We would be happy to collaborate on defining a lighter-weight signaling mechanism for filter updates. Best Regards, Shunwan From: Camilo Cardona <[email protected]> Sent: Tuesday, October 20, 2026 4:25 AM To: Zhuangshunwan <[email protected]> Cc: grow <[email protected]> Subject: Re: [GROW] Re: I-D Action: draft-ietf-grow-bmp-adj-ribs-filtered-01.txt Hi Shunwan, At this point we are really thinking of filtering modifications as something that is not performed frequently. Could you provide some context on use cases where filtering would need to be modified frequntly enough that the peerdown/up approach becomes a practical problem? Thanks, Camilo Cardona De: Zhuangshunwan via GROW <[email protected]<mailto:[email protected]>> Para: "Camilo Cardona"<[email protected]<mailto:[email protected]>>, "grow"<[email protected]<mailto:[email protected]>> Fecha: sáb, 17 oct 2026 02:12:56 -0500 Asunto: [GROW] Re: I-D Action: draft-ietf-grow-bmp-adj-ribs-filtered-01.txt 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]<mailto:[email protected]>> Sent: Friday, October 16, 2026 11:02 PM To: grow <[email protected]<mailto:[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]<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]
