Hi all,
Thanks to Antoine, and Zhunwan for their opinion.
We did wanted to stay consistent with the local-rib (i.e. RFC9069), but if
Junos' implementation already does this, it makes sense to project it to the
document. We'll prepare a new version including this.
Thanks,
Camilo C
De: Zhuangshunwan <[email protected]>
Para: "Antoine Keranflec'h"<[email protected]>
CC: "Camilo Cardona"<[email protected]>, "grow"<[email protected]>
Fecha: mar, 20 oct 2026 08:14:09 -0500
Asunto: RE: [GROW] Re: I-D Action: draft-ietf-grow-bmp-adj-ribs-filtered-01.txt
Hi Antoine, Camilo, and GROW WG,
Thanks, Antoine, for bringing up the RFC 9069 Loc-RIB implementation context
and highlighting the Junos operational behavior. That is a very convincing and
practical perspective.
We strongly agree with Antoine's proposed compromise:
1. Initial Attach / Detach of a Filter:
Sending a Peer Down / Peer Up notification provides a clean resynchronization
boundary for the collector to acknowledge a macro-level mode switch.
2. Modifications to Filter Policy Contents:
Sending incremental updates (deltas) without resetting the peer state avoids
the severe blast radius (CPU/memory spikes and false alarms) on the collector
when updating rules for large RIB views.
Aligning Adj-RIB-In and Adj-RIB-Out behavior with this operational reality
makes complete sense. We suggest the authors relax/modify the strict "MUST"
requirement in Section 4 of the draft to allow incremental updates for filter
content changes.
Looking ahead, abusing Peer Down/Up as a signal for policy/view changes is a
workaround for the lack of explicit synchronization/notification primitives in
base BMP. For long-term architectural evolution, the WG could consider
leveraging more dedicated mechanisms to handle non-disruptive synchronization
and event signaling, such as:
- draft-geng-grow-bmp-rr-sync (BMP Extension for Non-Disruptive RIB View
Synchronization)
- draft-sp-grow-bmp-gen (Generic Event Notification (GEN) for BMP)
We would be glad to support refining the text in
draft-ietf-grow-bmp-adj-ribs-filtered along these lines.
Best Regards,
Shunwan
-----Original Message-----
From: Antoine Keranflec'h < mailto:[email protected] >
Sent: Tuesday, October 20, 2026 8:35 PM
To: Zhuangshunwan < mailto:[email protected] >
Cc: Camilo Cardona < mailto:[email protected] >; grow < mailto:[email protected]
>
Subject: Re: [GROW] Re: I-D Action:
draft-ietf-grow-bmp-adj-ribs-filtered-01.txt
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 < mailto:[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 < mailto:[email protected] >
> Sent: Tuesday, October 20, 2026 4:25 AM
> To: Zhuangshunwan < mailto:[email protected] >
> Cc: grow < mailto:[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 < mailto:[email protected] >
> Para: "Camilo Cardona"< mailto:[email protected] >, "grow"<
> 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 < mailto:[email protected] >
> Sent: Friday, October 16, 2026 11:02 PM
> To: grow < 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: < mailto:[email protected] >
> Para: < mailto:[email protected] >
> CC: < 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-fil
> tered-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 -- mailto:[email protected]
> To unsubscribe send an email to mailto:[email protected]
>
>
>
>
>
> _______________________________________________
> GROW mailing list -- mailto:[email protected]
> To unsubscribe send an email to mailto:[email protected]
>
>
>
>
>
> _______________________________________________
> GROW mailing list -- mailto:[email protected]
> To unsubscribe send an email to mailto:[email protected]
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
