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 < 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-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 -- 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]
