Hi Nan,
That's fair, and I think you're right. Going back through bmp-rel there is a
stronger reason than the one you gave: the Log Action registry is route-scoped.
All four existing code points describe why a particular prefix was logged ,
"1 = Config. Prefix is being logged due to a configuration
statement."
"3 = Crossed Warning Bound. Prefix is over the warning threshold of
the maximum number of prefixes that can be received from a BGP
neighbor."
and the registry itself sits under "Route Event Logging TLVs", carried in a
REL message whose Event Subjects are NLRIs in a BGP Update PDU.
"The event stream is incomplete" is a property of the session, not of any
prefix.
Hence, it doesn't really fit there which ever draft allocates the code point,
rel-enhancement included.
Your point that it should cover all BMP event types gets to the same place but
from the other direction.
One thing that may be useful wherever this ends up. bmp-rel Section 3.2.2
already reaches for a route-scoped code point to describe a
device-level condition. After describing BMP being preempted under load and
implementations discarding internal state defensively, it says:
"The Health Event Type enables reporting of such and other
conditions through REL messages. A REL Health event with Event
Reason "Log Action" and Log Action code "Unstable" (2) can convey
this situation."
but Section 3.5.2 defines code 2 as:
"2 = Route unstable. Optional data contains a 4 bytes value
representing the observed timeframe in seconds, followed by a 4
bytes value indicating the amount of times the event occurred
within the timeframe."
The shape I was after already exists, a timeframe plus an occurrence count at
Health Event Type scope, but it's reached today by borrowing a code point
defined in terms of routes.
That seems worth sorting out in the unified framework rather than leaving
Health events to reuse route semantics.
Hello Paolo, Camilo
Other than above, Section 3.2.2 calls the code point "Unstable" while Section
3.5.2 calls it "Route unstable".
Worth aligning the two at some point.
I'd rather raise the suppression indication once, in the right place, than keep
it going in this thread.
Could you please point me at the unified event reporting framework discussion,
a draft name or the thread, and
I'll take it there scoped across event types as you suggest.
Thanks a lot Nan !!! I am sure, we will have many more data-points to
collab-over 😊
Best regards,
Saumya
From: gengnan <[email protected]>
Date: Thursday, 30 July 2026 at 9:18 AM
To: Dikshit, Saumya <[email protected]>
Cc: Grow <[email protected]>; [email protected] <[email protected]>; [email protected]
<[email protected]>; Zhuangshunwan <[email protected]>
Subject: RE: [GROW] Re: Question on draft-geng-grow-bmp-rel-enhancement
Hi Saumya,
> Hi Nan rel-enhancement is already allocating Log Action code points
> (TBD5-TBD7), so would it make sense to add one there:
> * TBD8 = Events-Suppressed. This event indicates that the
> reporting device is locally filtering or rate-limiting routing
> event reporting, and that the event stream is therefore
> incomplete. Optional data contains a 4 bytes value representing
> the observed timeframe in seconds, followed by a 4 bytes value
> indicating the number of events suppressed within that
> timeframe.
Thanks for the proposal.
The current rel-enhancement draft follows with the framework of bmp-rel. Since
the WG is discussing a unified event reporting framework, personally I think an
event filter or suppressed marker is better addressed there.
If such a marker is needed, it should take all types of BMP events into
consideration, not only REL-enhancement or "Routing and Validation Event".
Best,
Nan
From: Dikshit, Saumya <[email protected]>
Sent: Thursday, July 30, 2026 3:41 AM
To: Zhuangshunwan <[email protected]>; Srivastava,
Mukul <[email protected]>; gengnan <[email protected]>; Reshad Rahman
<[email protected]>
Cc: Grow <[email protected]>
Subject: Re: [GROW] Re: Question on draft-geng-grow-bmp-rel-enhancement
Hi Shunwan,
Answering both your notes together, and correcting one thing I said on 26 July.
F cannot be reused for REL events
---------------------------------
I suggested rel-enhancement could say events reuse the Peer F Flag.
draft-ietf-grow-bmp-rel-06 Section 3.3 rules that out - it redefines
the flags field for REL rather than inheriting the RFC 7854 one:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|V|A| Reserved |
+-+-+-+-+-+-+-+-+
"The remaining bits are reserved for future use. They MUST be
transmitted as 0 and their values MUST be ignored on receipt."
So an F bit set there is non-conformant on send and discarded on
receipt. Section 3 also makes the Per-Peer Header "mandatory or
optional depending on the Event Type", so for Health events there may
be no peer header to carry a flag at all.
Your original instinct for a separate indication on the event side was
right,
Text Update
----------------------------------------
Having said that, I do not think events need anything invented either.
bmp-rel Section 3.2.2 already describes almost exactly this situation -
BMP preempted under load, implementations discarding internal state
defensively - and concludes:
Hi Nan rel-enhancement is already allocating Log Action code points
(TBD5-TBD7), so would it make sense to add one there:
* TBD8 = Events-Suppressed. This event indicates that the
reporting device is locally filtering or rate-limiting routing
event reporting, and that the event stream is therefore
incomplete. Optional data contains a 4 bytes value representing
the observed timeframe in seconds, followed by a 4 bytes value
indicating the number of events suppressed within that
timeframe.
The data format deliberately mirrors the existing "Route unstable" (2)
code point, which already carries a timeframe and an occurrence count.
That needs no change to bmp-rel, no new TLV type and no peer flag
Reshad - would the Log Action code point above close your original
question?
Thanks,
Saumya
From: Zhuangshunwan
<[email protected]<mailto:[email protected]>>
Date: Wednesday, 29 July 2026 at 3:01 PM
To: Dikshit, Saumya <[email protected]<mailto:[email protected]>>;
Srivastava, Mukul <[email protected]<mailto:[email protected]>>;
gengnan <[email protected]<mailto:[email protected]>>; Reshad Rahman
<[email protected]<mailto:[email protected]>>
Cc: Grow <[email protected]<mailto:[email protected]>>
Subject: RE: [GROW] Re: Question on draft-geng-grow-bmp-rel-enhancement
Hi Saumya,
I have a question regarding the following point you raised:
Section 4 says "In Stats messages, counts MUST reflect the filtered RIB numbers
and not the original RIB ones," but it stops short of stating that the F flag
itself be set consistently in the Stats message's Peer Header for that same
session.
To make sure I'm following correctly, let me walk through a quick scenario:
Suppose Peer 1 (a BMP client) receives two types of routes from its neighbor,
tagged with Community 1 and Community 2 respectively. There are N1 routes with
Community 1 and N2 routes with Community 2.
Now, suppose Peer 1 applies an outbound filtering policy, sending only the N1
routes (tagged with Community 1) to the BMP server via Route Monitoring (RM)
Adj-RIB-In messages. Naturally, these BMP RM messages will have the F Flag set.
According to Section 4, for Stats messages, "counts MUST reflect the filtered
RIB numbers and not the original RIB ones." This means Peer 1 should report a
count of N1 to the BMP server via Stat Type 7 (Number of routes in Adj-RIBs-In).
My question is: Does this mean the BMP server no longer needs to know the
total/original count (N1 + N2) present in Peer 1's actual Adj-RIB-In?
Or is there a scenario where the server still needs visibility into the
unfiltered baseline? I’d love to hear your thoughts on this.
Best regards,
Shunwan
From: Dikshit, Saumya
<[email protected]<mailto:[email protected]>>
Sent: Sunday, July 26, 2026 6:24 PM
To: Srivastava, Mukul
<[email protected]<mailto:[email protected]>>;
gengnan <[email protected]<mailto:[email protected]>>; Reshad Rahman
<[email protected]<mailto:[email protected]>>
Cc: Grow <[email protected]<mailto:[email protected]>>
Subject: [GROW] Re: Question on draft-geng-grow-bmp-rel-enhancement
Hi Mukul,
That's a helpful clarification, thank you.
It's good to be reminded that F flag lives in the shared Peer Header rather
than being RM-specific, so it's structurally available to Stats messages too.
Looking at the current adj-ribs-filtered-00 text again with that in mind, I
think it actually pins down exactly the gap:
• Section 4 says "In Stats messages, counts MUST reflect the filtered RIB
numbers and not the original RIB ones," but it stops short of stating that the
F flag itself be set consistently in the Stats message's Peer Header for that
same session.
• So as written, an implementation could arguably satisfy the letter of the
text by adjusting the counts while leaving F unset (or inconsistent) on the
Stats side
o This is exactly the inconsistency you flagged as unhelpful for correlation.
Would it make sense to tighten this into an explicit MUST, something like:
• "The Peer F Flag MUST be set consistently across all BMP message types that
share this Peer Header for the lifetime of the session (Route Monitoring, Stats
Report, Route Mirroring).
• An implementation MUST NOT report F=1 in one message type while reporting F=0
(or omitting the equivalent filtered-count adjustment) in another, for the same
peer."
Since you're already a co-author on adj-ribs-filtered, that
operational-consideration addition (Section 5, or as a normative bullet in
Section 4) seems like the cleanest, lowest-overhead fix and no new TLV needed
for the RIB/Stats side at all.
That said, it doesn't fully close Reshad/Nan's original question:
adj-ribs-filtered-00 only talks about Adj-RIB-In/Out and Stats messages and
says nothing about routing-event messages
(draft-geng-grow-bmp-rel-enhancement's actual subject). On that note, would it
make sense for rel-enhancement to explicitly say event messages reuse this same
Peer F Flag bit (with the same cross-message consistency rule above), rather
than defining a separate mechanism?
• That would give collectors one consistent signal to check across RM, Stats,
and event messages, with a single small text addition on each side rather than
a new generic flag.
Your thoughts Nan, Reshad, Mukul on this ?
Happy to help draft the exact text for either document if useful.
Thanks,
Saumya
From: Srivastava, Mukul
<[email protected]<mailto:[email protected]>>
Date: Saturday, 25 July 2026 at 8:50 PM
To: Dikshit, Saumya <[email protected]<mailto:[email protected]>>;
gengnan <[email protected]<mailto:[email protected]>>; Reshad Rahman
<[email protected]<mailto:[email protected]>>
Cc: Grow <[email protected]<mailto:[email protected]>>
Subject: Re: [GROW] Re: Question on draft-geng-grow-bmp-rel-enhancement
Hello Saumya
>>>>>> If a router locally rate-limits or drops events (per the mitigation text
>>>>>> in draft-geng-grow-bmp-rel-enhancement) and separately reports gauges
>>>>>> such as the ones in
* draft-ietf-grow-bmp-bgp-rib-stats (RFC 9972) or
* the policy-driven counters in draft-smc-grow-bmp-route-change-stats,
a collector has no way to know that an observed gauge delta might not be fully
explained by the event stream it received it may look like an unexplained jump.
—
[MS] - The BMP stats messages have BMP peer header. The filter flag is part of
the BMP peer header. If the filter flag is not set in stats message, while
the other msg had filter flag set, then the collector should use caution and
know that the data it received was filtered while the stats count is not
filtered.
I would assume for ideal operation, the router should have flag set/unset for
all events/data/stats message for a session. Inconsistency in this flag state
between different messages, will not help in meaningful correlation at
collector.
I think we should add this in the operational consideration for filtered
drafts, if it isn’t present already.
Thanks
Mukul
From: Dikshit, Saumya
<[email protected]<mailto:[email protected]>>
Date: Saturday, July 25, 2026 at 2:37 AM
To: gengnan
<[email protected]<mailto:[email protected]>>;
Reshad Rahman <[email protected]<mailto:[email protected]>>
Cc: Grow <[email protected]<mailto:[email protected]>>
Subject: [GROW] Re: Question on draft-geng-grow-bmp-rel-enhancement
Hi Nan, Reshad,
I was going through the draft and couldn’t help bringing up another angle,
(though not-unrelated) to the email chain discussion :
The same blind spot effects statistics consumers, not just event-log consumers.
If a router locally rate-limits or drops events (per the mitigation text in
draft-geng-grow-bmp-rel-enhancement) and separately reports gauges such as the
ones in
* draft-ietf-grow-bmp-bgp-rib-stats (RFC 9972) or
* the policy-driven counters in draft-smc-grow-bmp-route-change-stats,
a collector has no way to know that an observed gauge delta might not be fully
explained by the event stream it received it may look like an unexplained jump.
Rather than defining filtering-indication independently for events (in this
draft) and for RIB streams (bmp-adj-ribs-filtered), would it make sense to
define one small, generic TLV/flag, that any BMP consumer event, RM, or SR
message can check? This would definitely help in achieving "telemetry
completeness"
More than happy and willing to sketch this as a short contribution if there's
appetite, as we hit a related need while defining the per-peer gauges in
draft-smc-grow-bmp-route-change-stats.
Thanks,
Saumya.
From: gengnan
<[email protected]<mailto:[email protected]>>
Date: Thursday, 23 July 2026 at 3:39 PM
To: Reshad Rahman <[email protected]<mailto:[email protected]>>
Cc: Grow <[email protected]<mailto:[email protected]>>
Subject: [GROW] Re: Question on draft-geng-grow-bmp-rel-enhancement
Hi Reshad,
As stated in Section 3 of draft-ietf-grow-bmp-adj-ribs-filtered:
> ... be informative to the rest of the system that they should not make
> decisions assuming that this stream is transmitting all the information about
> it.
The same logic seems to apply to event reporting. If critical events are
filtered locally without any signal to the collector, monitoring systems may
draw incorrect conclusions based on incomplete data. It would therefore be
valuable to consider a mechanism to convey this filtering state for events.
Best,
Nan
From: Reshad Rahman
<[email protected]<mailto:[email protected]>>
Sent: Thursday, July 23, 2026 1:43 AM
To: Grow <[email protected]<mailto:[email protected]>>
Subject: [GROW] Question on draft-geng-grow-bmp-rel-enhancement
Hi,
Appropriate caution SHOULD be taken when picking routing events to
report, as next-hop related updates may produce heavy message loads
during network instability. Mitigation measures SHOULD be deployed
on both reporting and receiving sides. For example, local endpoints
can apply event filtering controls, while receivers maintain
corresponding processing mechanisms to handle potential high-volume
event bursts gracefully.
During the meeting today the text above was highlighted by Nan (based on
feedback from Prasad). I have no issue with the feedback and text, but is there
any indication of filtering sent to the collector?
draft-ietf-grow-bmp-adj-ribs-filtered which was presented earlier adds a Peer F
flag for Adj-Rib-In/Out, IIUC that doesn't cover events in
draft-geng-grow-bmp-rel-enhancement? IMO we want indication of filtering for
"critical" events.
Regards,
Reshad.
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
