Hi all, I agree with the operational concern raised in the thread. A Peer Down / Peer Up on a BMP filter update leaves the BGP session up, but it forces the collector to discard the affected RIB view and re-learn it. With a full table or many VPN instances, that is a large blast radius.
The filter option is already in place for the Loc-RIB. RFC 9069 Section 6.1.2 defines Loc-RIB filtering, and Section 4.2 defines the F flag; Junos implements the filter with the route-filter under route-monitoring loc-rib. Attaching or removing the route-filter sends a Peer Down Notification followed by a Peer Up Notification for the Loc-RIB peer, then re-sends the whole filtered Loc-RIB in new Route Monitoring messages. The BMP TCP session stays established and the BGP sessions are obviously not touched. This is the Peer Down / Peer Up bounce of RFC 9069 Section 6.1.3, and the draft uses the same mechanism for Adj-RIB-In and Adj-RIB-Out. When the policy contents change while the route-filter remains attached, Junos sends only the deltas, with no peer reset. Section 6.1.3 asks for a bounce on any change to filtering, so this can be considered a deviation, but it is the most efficient behavior for the collector. If the working group wants the same behavior for Adj-RIB-In and Adj-RIB-Out, the Section 4 MUST in the draft has to allow it. The Loc-RIB Route Monitoring messages carry the RFC 9069 F flag: 1 while the filter is attached, 0 when removed. The draft's F flag is the right direction. It gives Adj-RIB-In and Adj-RIB-Out the same filtered/unfiltered indication that RFC 9069 gives the Loc-RIB. A similar filter option for the two RIB views makes sense. The sender should follow the behavior we observed for the Loc-RIB: a Peer Down / Peer Up when the filter is attached or detached, and incremental updates when the filter contents change. That gives the collector a clear resynchronization point on attach or detach, and avoids a full re-ingest on a content change. Best regards, Antoine Keranflech Le mar. 20 oct. 2026 à 03:05, Zhuangshunwan via GROW <[email protected]> a écrit : > > 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]> > Para: "Camilo Cardona"<[email protected]>, "grow"<[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]> > 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]> > Para: <[email protected]> > CC: <[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] > To unsubscribe send an email to [email protected] > > > > > > _______________________________________________ > GROW mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > > > > _______________________________________________ > GROW mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
