[GROW] Re: Question on draft-geng-grow-bmp-rel-enhancement

["Dikshit, Saumya" <[e-mail]>]

Hi Mukul,

Thanks. The Peer Down/Peer Up pointer is the piece I had missed, and I agree it is needed for middle of session changes.

One distinction I would like to callout as it gives certain *temporal* consistency:

  *
the filtering characteristics cannot change within the life of a session.
     *
What it does not yet give is *cross-message-type* consistency
        *
that F be set the same way in the Stats Report peer header as in the Route Monitoring peer header for that same session.
  *
Those properties can be made distinct, and the current Section 4 text constrains only the counts ("counts MUST reflect the filtered RIB numbers and not the original RIB ones"), not the flag.
This as you mentioned would require paraphrasing.

One more thing on Section 4 with your RFC 9069 comparison in mind, I came upon something I do not think the Peer Down/Peer Up rule closes. So please take a look at this:

  *
RFC 9069's F flag sits in the Loc-RIB Instance Peer Type flags registry, where the peer has exactly one RIB.
  *
"Is this stream filtered?” therefore has one unambiguous answer, and RFC 9069 never needed to say anything about consistency across message types.

adj-ribs-filtered places F at recommended value 4 in the "BMP Peer Flags for Peer Types 0 through 2" registry, where the same peer carries two RIBs distinguished by the O flag. For Route Monitoring that works cleanly: O selects the direction and F qualifies it. For Stats Report it does not, because a single Stats message can carry counters for both directions at once:
  - Stat Types 7 and 9   - Adj-RIB-In (RFC 7854)
  - Stat Types 14 to 17  - pre- and post-policy Adj-RIB-Out (RFC 8671)
and all under one peer header carrying one F bit.  If an implementation filters Adj-RIB-In but not Adj-RIB-Out,  there is no correct value of F for that message. F=1 overstates the filtering, F=0 understates it, and the Peer Down/Peer Up rule does not help because nothing changed mid-session.

That brings back to the usage of “F”:

  *
is the intent that F in a Stats message means "at least one of the RIBs represented here is filtered", or that filtering must be all-or-nothing across directions for the lifetime of a session?
  *
Either is workable, but the draft probably has to pick one and say so.

I would separate it from what I read Reshad as asking, which is a runtime question.

  *
Section 4 of rel-enhancement-03 already contemplates runtime filtering explicitly - "local endpoints can apply event filtering controls" - and
  *
Section 6 does define a fixed set to filter from, namely the seven code points requested in the BMP Log Action TLV Registry
     *
(Redirect-to-VRF-Fail, Redirect-to-Nexthop-Fail, Redirect-to-SR-Policy-Fail, FlowSpec-Validation-Fail, Invalid-Candidate-Path, Invalid-Segment-List, Exceeded-Spec-Limit).

 A collector that sees no Redirect-to-VRF-Fail events cannot distinguish "none occurred" from "that type is suppressed at the source”. Which is the same inference problem that Section 3 of adj-ribs-filtered describes for RIBs. That said, I agree with you that this does not warrant a new mechanism. If REL messages carry the standard per-peer header, then reusing this same F bit, with the cross-message consistency rule above, is the minimal fix and costs each document one paragraph.

Hi Nan
 Does REL use the standard per-peer header? rel-enhancement-03 does not reference it, so I may be assuming a structure that is not actually there. If REL messages do not carry a peer header, then the signal has to live somewhere else and the answer changes.

Please do let know , I will be more than happy to draft some text with your due approval

Thanks,
Saumya


From: Srivastava, Mukul <mukul.srivastava=[e-mail]>
Date: Tuesday, 28 July 2026 at 8:57 PM
To: Dikshit, Saumya <[e-mail]>; gengnan <[e-mail]>; Reshad Rahman <[e-mail]>
Cc: Grow <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [GROW] Re: Question on draft-geng-grow-bmp-rel-enhancement

Hi Saumya


>>>>> " 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.

[MS] - The draft has below statement in section 4 -

"

Also should any characteristic of the filtering change, the sender MUST trigger a Peer Down then followed by a new Peer Up.

"
This intends to say that if filtering changed for any reason, we should start afresh. This indirectly means all session should have uniform “F” flag setting. I am ok to add some explicit statement, as you suggested to clarify this. The current statement matches BMP local-rib RFC 9069 where route filtering flag as first introduced.



>>> 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).

[MS] - IMO, the filtering flag is not application for rel/log messages. There is no fixed set of the routing events pre-defined, out of which, a router may intend to filter out some. So, these messages are different from route-motoring or stats messages.

The original comment in the email below was to be cautious to select what should be send as logging event to the BMP station. If some events (like next-hop change) are chatty that shouldn’t be logged, meaning we shouldn’t define an logging event type to report next-hop churn.

Thanks
Mukul

From: Dikshit, Saumya <saumya.dikshit=[e-mail]>
Date: Sunday, July 26, 2026 at 6:24 AM
To: Srivastava, Mukul <[e-mail]>; gengnan <[e-mail]>; Reshad Rahman <[e-mail]>
Cc: Grow <[e-mail]>
Subject: Re: [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
     *
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 <mukul.srivastava=[e-mail]>
Date: Saturday, 25 July 2026 at 8:50 PM
To: Dikshit, Saumya <[e-mail]>; gengnan <[e-mail]>; Reshad Rahman <[e-mail]>
Cc: Grow <[e-mail]>
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 <saumya.dikshit=[e-mail]>
Date: Saturday, July 25, 2026 at 2:37 AM
To: gengnan <gengnan=[e-mail]>; Reshad Rahman <[e-mail]>
Cc: Grow <[e-mail]>
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 <gengnan=[e-mail]>
Date: Thursday, 23 July 2026 at 3:39 PM
To: Reshad Rahman <[e-mail]>
Cc: Grow <[e-mail]>
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 <reshad=[e-mail]>
Sent: Thursday, July 23, 2026 1:43 AM
To: Grow <[e-mail]>
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.