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

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

Hi Shunwan, Nan,

I have read rel-enhancement-03 against the base REL document, and sync-options-and-state.
Four points on rel-enhancement, one on sync-options (hope that’s ok with you).


1.  FlowSpec-Validation-Fail is three failures in one code point :
------------------------------------------------------------------------------

Section 6 of [RFC8955] makes validation three conditions that must all hold:

  *
 A destination prefix is present, the originator matches the best-match unicast route, and there is no more-specific from a different AS.
  *
The second is the common one in practice:
     *
 a controller-injected mitigation rule that is not the best-path originator
     *
and it is the first thing an operator needs to know when a scrubbing rule silently does not take effect.

TBD4 says validation failed without saying which.

  *
Three code points, or one code point with a one-octet reason, would carry most of the value.
  *
Also, [RFC8956] is a normative reference but Section 2 cites only [RFC8955]; worth saying the code points apply to both.


2.  Validity of a path is not validity of a policy :
------------------------------------------------------

TBD5 and TBD6 cite Section 5 of [RFC9256], which is candidate path validity.
Operationally the ticket is raised on Section 2.10, policy validity :

  *
 a policy is invalid when no candidate path is valid, and with Section 8.2 drop-upon-invalid that is when traffic stops.

Today a collector cannot tell that from the real failure, so it will alarm on non-events or miss the one that matters.


3.  Exceeded-Spec-Limit covers two limits :
---------------------------------------------------

TBD7 covers exceeding the maximum number of SR Policies or Segment Lists.

  *
One is remedied by removing policies or raising a platform limit,
  *
the other by simplifying paths within a policy.
  *
Carrying which limit was hit, and its value, makes the event actionable.


4.  Alarming needs a clear condition :
---------------------------------------------

Section 4 says the events "can be used for real-time alarming" and also that they "do not define a corresponding recovery indication".
Those pull against each other. [RFC8632] settles the distinction:

   "An alarm is a state for a specific resource (note that an alarm is not a
    notification)."

A Redirect-to-VRF-Fail that never clears leaves the collector holding a condition it cannot age out.
We should call out this condition and potential rectification.


5.  On the all-or-none framing
------------------------------------------------------------------------------------------

We agree on the diagnosis, and it is worth recording while the last call is open.
You wrote that the alternative is "forcing heavy full-session bounces".
That is Section 4 of draft-ietf-grow-bmp-adj-ribs-filtered-00:

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

I believe, that draft is in WG Last Call until 5 August, and sync-options seem to avoiding   that kind of disruption.
Two active drafts require opposite behavior for the same event and neither cites the other. What’s your say on this ?

One refinement on the claim.

  *
Both messages are sender to collector, which keeps BMP unidirectional and is right.
     *
It also means Monitoring Options declares what the sender is already configured to monitor rather than letting a collector request a subset
  *
Definitely adds-up against the bandwidth constraint I raised on 1 August,
     *
since a collector that knows the scope can size itself and can tell a missing prefix from an unmonitored one.
  *
But it is notification, not negotiation, and the Introduction should say so.
  *
Operators reading "synchronize specific RIB views" will expect to be able to ask for them.

If a collector-driven request is intended later, then lets call out explicitly.

Please let me know, if we can proceed here with above or its variations. Please do suggest variations/alterations.

Thanks,
Saumya

From: Zhuangshunwan <[e-mail]>
Date: Monday, 3 August 2026 at 6:49 AM
To: Dikshit, Saumya <[e-mail]>; Srivastava, Mukul <mukul.srivastava=[e-mail]>; Srivastava, Mukul Kumar <[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,

Thanks for sharing these practical insights on deployment scenarios and bandwidth constraints.

You raised a very valid point: in real-world scenarios (such as EVPN or L3VPN environments), tenant/host routes can be massive compared to underlay routes, and filtering what actually matters is crucial to avoid overloading the collector's bandwidth and processing capacity.

This is precisely one of the key problems our draft (draft-geng-grow-bmp-sync-options-and-state) aims to address. Instead of an "all-or-none" approach or forcing heavy full-session bounces, our proposed mechanism allows operators to precisely target and synchronize specific RIB views or address families (like focusing only on the critical tenant routes) incrementally and lightweightly.

We look forward to hearing your comprehensive thoughts and feedback whenever you're ready!

Best regards,
Shunwan

From: Dikshit, Saumya <[e-mail]>
Sent: Saturday, August 1, 2026 7:02 PM
To: Zhuangshunwan <[e-mail]>; Srivastava, Mukul <mukul.srivastava=[e-mail]>; Srivastava, Mukul <[e-mail]>; gengnan <[e-mail]>; Reshad Rahman <[e-mail]>
Cc: Grow <[e-mail]>; [e-mail]
Subject: Re: [GROW] Re: Question on draft-geng-grow-bmp-rel-enhancement

Hi Shunwan,

I will surely look at draft you pointed me too. Let me also respond to you on a comprehensive and holistic approach.

Meanwhile, for a real deployment scenario, the bandwidth to cloud based collector will be either be insufficient for single or all. For example, in a typical VPN deployments, the host/tenant routes shall be humongous in comparison to underlay routes (miniscule) for a campus/datacenter evpn deployments. Similar goes for l3vpn. And the routes that shall matter most for tracking shall be tenant routes. Hope that answers for none or all. Though logically nobody stopping you to cover all bases.

Let me know your thoughts, while I dig in further on your suggestions.

Thanks,
Saumya.

________________________________
From: Zhuangshunwan <[e-mail]<mailto:[e-mail]>>
Sent: Friday, July 31, 2026 1:53:30 pm
To: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>; Srivastava, Mukul <mukul.srivastava=[e-mail]<mailto:mukul.srivastava=[e-mail]>>; Srivastava, Mukul <[e-mail]<mailto:[e-mail]>>; gengnan <[e-mail]<mailto:[e-mail]>>; Reshad Rahman <[e-mail]<mailto:[e-mail]>>
Cc: Grow <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: [GROW] Re: Question on draft-geng-grow-bmp-rel-enhancement


Hi Saumya,

Thank you for sharing your perspective and the alternative design considerations.

While relying on a full session bounce (Peer Down / Peer Up) aligns with traditional BGP operational habits where a down event impacts all address families, doing so in BMP can be quite disruptive in modern, large-scale multi-AF deployments—especially when a filter change only targets a single specific address family (e.g., modifying IPv4 filtering while leaving IPv6 completely untouched).

Regarding the three points you raised:

1.  Forcing "all or none" publication or relying entirely on the collector to absorb everything can introduce unnecessary bandwidth overhead and heavy processing burdens on the collector side, particularly when dealing with massive routing tables.

2.  Using wildcards is an interesting angle, but we still need a clean, non-destructive signaling mechanism to tell the collector when a targeted slice of data is being refreshed or adjusted due to a policy change.

Instead of keeping things heavy with full session bounces or shifting all complexities to the collector, we would like to invite you to take a look at draft-geng-grow-bmp-sync-options-and-state (specifically the BMP Route-Refresh message and sync options).
This draft provides a lightweight, incremental, and targeted mechanism to synchronize specific RIB views and address families without tearing down the underlying BMP session. It cleanly solves the ambiguity of route withdrawals and filter changes without the heavy overhead of a session bounce.
If you find this approach reasonable, we would love to collaborate with you and invite you to join us in driving this forward in the GROW working group!
Looking forward to your thoughts.

Best regards,
Shunwan  (on behalf of the co-authors of draft-geng-grow-bmp-sync-options-and-state)

From: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>
Sent: Friday, July 31, 2026 12:37 PM
To: Srivastava, Mukul <mukul.srivastava=[e-mail]<mailto:mukul.srivastava=[e-mail]>>; Zhuangshunwan <[e-mail]<mailto:[e-mail]>>; Srivastava, Mukul <[e-mail]<mailto:[e-mail]>>; gengnan <[e-mail]<mailto:[e-mail]>>; Reshad Rahman <[e-mail]<mailto:[e-mail]>>
Cc: Grow <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [GROW] Re: Question on draft-geng-grow-bmp-rel-enhancement

Hi @Srivastava, Mukul<mailto:mukul.srivastava=[e-mail]>, @[e-mail]<mailto:[e-mail]>

In a typical deployment, or with BGP operations, a bgp peer down shall impact routes of all AFs published over that peers. So deletion is implicit.
Few bullets:

-Shall we mandate publishing all or none  from the device (per bgp peering) based on filter.
- leave to discretion on collector side on what to absorb from all published.
- for optimal publishing, can we use wild cards to call out all routes across all AFs.

Thanks,
Saumya.

________________________________
From: Srivastava, Mukul <mukul.srivastava=[e-mail]<mailto:mukul.srivastava=[e-mail]>>
Sent: Friday, July 31, 2026 1:11:14 am
To: Zhuangshunwan <[e-mail]<mailto:[e-mail]>>; Srivastava, Mukul <[e-mail]<mailto:[e-mail]>>; Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>; gengnan <[e-mail]<mailto:[e-mail]>>; Reshad Rahman <[e-mail]<mailto:[e-mail]>>
Cc: Grow <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [GROW] Re: Question on draft-geng-grow-bmp-rel-enhancement


Hi Shunwan

Considering you example - Assuming a BMP session is advertising v4 and v6 AF to a station. Then a local filter policy was changed on the router to send only V4 prefixes to the collector.

If we don’t want to bounce the session and stop sending any update on v6 prefixes,  then collector has no clue what happened to those v6 prefixes.

If you chose to withdraw those v6 prefixes which were previously advertised, then collector has no clue if the routes where really deleted at the router or this withdrawal is because of the local filter policy change. We can invent complex solution like informing collector about the policy change or some other indication, so the collector knows that those v6 prefixed are being withdrawn due to filter policy change. Things are get complex easily.

In any production network, I can’t imagine that such filter configuration change will be frequent. So, bouncing session provides clean option. Sure it comes with the overhead that you mentioned.

I think there were some draft (might have expired) to refresh specific address from a BMP producer.

Thanks
Mukul

From: Zhuangshunwan <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, July 29, 2026 at 7:14 AM
To: Srivastava, Mukul <mukul.srivastava=[e-mail]<mailto:mukul.srivastava=[e-mail]>>; Dikshit, Saumya <saumya.dikshit=[e-mail]<mailto:saumya.dikshit=[e-mail]>>; gengnan <[e-mail]<mailto:[e-mail]>>; Reshad Rahman <[e-mail]<mailto:[e-mail]>>
Cc: Grow <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: [GROW] Re: Question on draft-geng-grow-bmp-rel-enhancement

Hi Mukul,

Thank you for bringing this statement to my attention. I have a few questions regarding the text 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."

Given that a BGP session is established over a single underlying TCP connection and typically carries multiple address families (AFI/SAFI) simultaneously—such as IPv4 Unicast (afi=1, safi=1) and IPv6 Unicast (afi=2, safi=1)—I have some concerns:
If a filtering policy change applies only to a specific address family (e.g., IPv4 Unicast), wouldn't triggering a Peer Down (followed by a Peer Up) unnecessarily disrupt and impact other unaffected address families (e.g., IPv6 Unicast) sharing the same session?

Additionally, is there an existing mechanism or proposal where a BMP message can be triggered to notify and refresh only the specific address family affected by the filter change (e.g., afi=1, safi=1), without interfering with other address families?

I would love to hear your thoughts on this.

Best regards,
Shunwan


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