Hi Saumya, Sorry for jumping into the thread. Thank you for bringing this up and sharing such a valuable perspective. I completely agree with your observation. Having a unified, generic TLV/flag for filtering-indication—rather than defining fragmented mechanisms across different drafts like draft-geng-grow-bmp-rel-enhancement and bmp-adj-ribs-filtered—makes a lot of sense. It aligns well with the goal of achieving true telemetry completeness and ensures long-term protocol consistency and ease of implementation.
I am definitely interested in this direction and would love to see a short contribution or text proposal from you outlining how this generic mechanism could look. Looking forward to reading your draft! Best regards, Shunwan From: Dikshit, Saumya <[email protected]> Sent: Saturday, July 25, 2026 2:35 PM To: gengnan <[email protected]>; Reshad Rahman <[email protected]> Cc: Grow <[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]
