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]
