Hi @Job Snijders<mailto:[email protected]>, 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 <[email protected]> Date: Wednesday, 22 July 2026 at 7:57 PM To: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> 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 [email protected] 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 -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
