Hello Saumya,
Thanks, there is indeed something to fix in the draft regarding the iteration with the stats message. Stats with already standard semantics should not be modified by this flag, so if the implementation cannot maintain its contract it should refrain from sending them. We will deal with it in the next version. Thanks, Camilo Cardona From: "Dikshit, Saumya" <[email protected]> Date: Monday, 3 August 2026 at 03:57 To: "Dikshit, Saumya" <[email protected]>, "Paolo Lucente ," <[email protected]>, "Camilo Cardona ," <[email protected]>, "Srivastava, Mukul" <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: draft-ietf-grow-bmp-adj-ribs-filtered-00: F flag consistency across message types, and the unfiltered baseline It will be great to hear from you on below email. Thanks, Saumya. From: Dikshit, Saumya <[email protected]> Date: Thursday, 30 July 2026 at 1:16 AM To: Paolo Lucente , <[email protected]>; Camilo Cardona , <[email protected]>; Srivastava, Mukul <[email protected]> Cc: [email protected] <[email protected]> Subject: [GROW] draft-ietf-grow-bmp-adj-ribs-filtered-00: F flag consistency across message types, and the unfiltered baseline Hi Paolo, Camilo, Mukul, Two small comments on adj-ribs-filtered-00, both arising from the thread on draft-geng-grow-bmp-rel-enhancement. Mukul suggested on-list that the first belongs in operational considerations, so I am writing it up here rather than leaving it in that thread. 1. F is not required to be consistent across message types ----------------------------------------------------------- Section 4 says: "In Stats messages, counts MUST reflect the filtered RIB numbers and not the original RIB ones." It does not say the F flag itself must be set in the Per-Peer Header of those Stats messages. As written, an implementation can satisfy the letter of that sentence by adjusting the counts while leaving F unset on the Stats side, which leaves a collector unable to correlate the two. The rule is arguably implied already by the requirement that "should any characteristic of the filtering change, the sender MUST trigger a Peer Down then followed by a new Peer Up." since that pins filtering to the session. But it is not stated. 2. The unfiltered baseline becomes unobservable ------------------------------------------------ Given the Section 4 MUST, a collector receiving a filtered session can no longer determine the pre-filter RIB size. That is the right answer for a collector reconstructing the RIB, which has to reconcile against what it received. It is the wrong answer for a collector using BMP for capacity, which can no longer tell whether the peer holds a hundred routes or a million, nor assess max-prefix headroom. RFC 7854 Section 4.8 keeps those two questions apart for inbound policy, reporting both what was removed and what remains: "Stat Type = 0: (32-bit Counter) Number of prefixes rejected by inbound policy" "Stat Type = 7: (64-bit Gauge) Number of routes in Adj-RIBs-In" adj-ribs-filtered introduces a third, orthogonal removal axis and reports only the remainder, with no equivalent of Stat Type 0. Proposed text ------------- Section 4, after the existing Stats sentence: The Peer F Flag MUST be set consistently in the Per-Peer Header of every BMP message type sent for that peer for the lifetime of the session, including Route Monitoring and Statistics Report messages. An implementation MUST NOT report F=1 in one message type and F=0 in another for the same peer. Section 5, new paragraph: The unfiltered RIB size is not recoverable from a filtered session. Operators requiring the pre-filter baseline, for example to assess max-prefix headroom, need to obtain it by other means such as a separate unfiltered session. . Is that text welcome, and in which form? Happy to write it up however you prefer. Thanks, Saumya
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
