[GROW] Re: WG Last Call: draft-ietf-grow-bmp-adj-ribs-filtered-00 (Ends 2026-08-05)

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

Hi @Job Snijders<mailto:[e-mail]>, and GROW -WG,

I support publication of adj-ribs-filtered. The mechanism is small and
it fills a real gap: RFC 9069 marks a filtered Loc-RIB and there has
been no equivalent for Adj-RIB-In or Adj-RIB-Out.

Five things I would like considered before it goes.

Two I sent to the list on 29 July, and can be found via the archive linked below:
https://mailarchive.ietf.org/arch/msg/grow/fkvLZblmMQXHh0zcVb4-NyM8zQ0/

  1. Section 4 requires Stats counts to reflect the filtered RIB, but
     does not require F itself to be set consistently across message
     types.
    An implementation can meet the letter of that sentence and
     still leave a collector unable to correlate.

  2. The unfiltered baseline stops being observable.
    RFC 7854 Section 4.8,

  *
  keeps "rejected by inbound policy" and "routes in  Adj-RIBs-In" as separate statistics;
  *
  this draft adds a third removal axis and reports only the remainder.

     That is fine for RIB reconstruction and awkward for capacity work.

I offered proposed text for both and let me know, I can adjust it.


3.  The session bounce conflicts with a companion draft
---------------------------------------------------------------------

Section 4 of this document says:
   “Also, should any characteristic of the filtering change, the sender
    MUST trigger a Peer Down then followed by a new Peer Up."

Section 3.1 of draft-geng-grow-bmp-sync-options-and-state-03 defines a
Monitoring Options PDU whose Flags field carries a bit that
   "Indicates whether the options are enabled or disabled"
per RIB type, per pre-policy and post-policy, over a list of (AFI,
SAFI).
Enabling or disabling an (AFI, SAFI) is a change in a
characteristic of the filtering, so this document requires a bounce
for it.  That draft's Introduction at least triggers the work as resolving RIB
view inconsistency without disruptive resolution, which is the
opposite requirement for the same event.

A sender implementing both is therefore required to bounce a peer for
a change the companion draft exists to signal in-session,
and a collector implementing both cannot tell whether
the absence of a Peer Down means

  *
the scope did not change or
  *
means the sender used the other mechanism.

I think the bounce is structural rather than deliberate:
F is a Peer flag, peer flags live in the per-peer header,
and there is no way to change one for an established peer without re-announcing the peer.
That is a reasonable place to have arrived at, and it is worth the WG
noticing that the consequence is now written down in two documents
that disagree.

I am not suggesting this draft wait on that one.

  *
 A sentence in Section 5 recording the operational cost of the bounce, and
that a lighter-weight indication may be defined in future work, would leave
future scope of discussion without creating a dependency.
  *
The two sets of authors resolving the precedence between them would be better still.


4.  A free-text string cannot carry what Section 4 needs
---------------------------------------------------------------------

Section 5 recommends that the VRF/Table Name TLV be

   "Specified to a meaningful string that can help discriminate the
    nature of filtering"

The reason the F flag is being added is so that a receiver does not
assume a stream carries everything.
The receiver's next question is always the same:

  *
is this prefix absent because it was withdrawn,
  *
or because it was filtered out.

A human-readable label does not answer that programmatically,
 and the consumers that most need the answer are automated.

Section 3.1 of the companion draft already carries the structured form
of exactly this :

  *
 per RIB type, per pre/post-policy,
  *
an enabled/disabled list of (AFI, SAFI).

Standardizing the string form here while the structured form sits in a
companion draft leaves collectors implementing both.

  *
A forward reference, with the scope description left to that work,
  *
would avoid it without holding this document .


5.  Related to Section 6
---------------------------------------------------------------------

Section 6 states that it "is not believed that this document adds any
additional security considerations."

The document's own purpose is to let a sender emit a partial view.

  *
Where the flag is absent, unset or lost, a collector treats a partial
feed as complete, and the analyses built on BMP feeds that would be
misled by that route-leak detection and origin validation among them
are the ones where a wrong answer matters most.
  *
That seems worth a sentence, together with whatever the authors expect a collector to do when it cannot establish whether a feed is complete.

Thanks,
Saumya

From: Job Snijders via Datatracker <[e-mail]>
Date: Wednesday, 22 July 2026 at 7:57 PM
To: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: [GROW] WG Last Call: draft-ietf-grow-bmp-adj-ribs-filtered-00 (Ends 2026-08-05)

This message starts a WG Last Call for:
draft-ietf-grow-bmp-adj-ribs-filtered-00

This Working Group Last Call ends on 2026-08-05

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 a light way to
   inform a collector station that a Adj-Rib-In / Adj-Rib-Out data feed
   is being filtered.

File can be retrieved from:
https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-grow-bmp-adj-ribs-filtered-00.txt__;!!NpxR!lsid-e762bkUs_d0G6WAWNT_6hNq6gnYk05zAorVvBajCP5ZdWV1DnsfG8nGXxf3aNhfOHgsetKACH_R$

Please review and indicate your support or objection to proceed with the
publication of this document by replying to this email keeping [e-mail]
in copy. Objections should be explained and suggestions to resolve them are
highly appreciated.

Authors, and WG participants in general, are reminded of the Intellectual
Property Rights (IPR) disclosure obligations described in BCP 79 [1].
Appropriate IPR disclosures required for full conformance with the provisions
of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.
Sanctions available for application to violators of IETF IPR Policy can be
found at [3].

Thank you.

[1] https://urldefense.com/v3/__https://datatracker.ietf.org/doc/bcp78/__;!!NpxR!lsid-e762bkUs_d0G6WAWNT_6hNq6gnYk05zAorVvBajCP5ZdWV1DnsfG8nGXxf3aNhfOHgsekbkwNsE$
[2] https://urldefense.com/v3/__https://datatracker.ietf.org/doc/bcp79/__;!!NpxR!lsid-e762bkUs_d0G6WAWNT_6hNq6gnYk05zAorVvBajCP5ZdWV1DnsfG8nGXxf3aNhfOHgsei2E1R6o$
[3] https://urldefense.com/v3/__https://datatracker.ietf.org/doc/rfc6701/__;!!NpxR!lsid-e762bkUs_d0G6WAWNT_6hNq6gnYk05zAorVvBajCP5ZdWV1DnsfG8nGXxf3aNhfOHgsemTy7pep$

The IETF datatracker status page for this Internet-Draft is:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-adj-ribs-filtered/__;!!NpxR!lsid-e762bkUs_d0G6WAWNT_6hNq6gnYk05zAorVvBajCP5ZdWV1DnsfG8nGXxf3aNhfOHgsel-Iz9ki$

There is also an HTMLized version available at:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-adj-ribs-filtered-00__;!!NpxR!lsid-e762bkUs_d0G6WAWNT_6hNq6gnYk05zAorVvBajCP5ZdWV1DnsfG8nGXxf3aNhfOHgseixLQ97O$

_______________________________________________
GROW mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]