[GROW] Re: draft-ietf-grow-bmp-adj-ribs-filtered-00: F flag consistency across message types, and the unfiltered baseline

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

Hi Camilo,

Keeping the stats messages at their existing semantics is the safer choice.
if an implementation cannot preserve the contract, it should not send them.

One point is worth a capture in next version:

  *
If an implementation suppresses a stats message because it cannot represent it faithfully,
a collector sees the same silence as from an implementation that simply has no stats to report
or does not support the type.
  *
The draft should say which reading applies so that implementations do not diverge.

Suggested sentence:

   An implementation that cannot maintain the standard semantics of a Statistics
   Report message under this specification MUST NOT send that message. Absence of a
   Statistics Report is therefore not, on its own, an indication of the state of the
   filter, and collectors MUST NOT infer one from it.

Please let me know your views on above. Happy to send this as a PR if need be.

Thanks,
Saumya.

From: Camilo Cardona <[e-mail]>
Date: Monday, 3 August 2026 at 7:53 PM
To: Dikshit, Saumya <[e-mail]>; Dikshit, Saumya <saumya.dikshit=[e-mail]>; Paolo Lucente , <[e-mail]>; Camilo Cardona , <[e-mail]>; Srivastava, Mukul <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: draft-ietf-grow-bmp-adj-ribs-filtered-00: F flag consistency across message types, and the unfiltered baseline

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" <[e-mail]>
Date: Monday, 3 August 2026 at 03:57
To: "Dikshit, Saumya" <saumya.dikshit=[e-mail]>, "Paolo Lucente ," <[e-mail]>, "Camilo Cardona ," <[e-mail]>, "Srivastava, Mukul" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
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 <saumya.dikshit=[e-mail]>
Date: Thursday, 30 July 2026 at 1:16 AM
To: Paolo Lucente , <[e-mail]>; Camilo Cardona , <[e-mail]>; Srivastava, Mukul <[e-mail]>
Cc: [e-mail] <[e-mail]>
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