[GROW] Re: Ketan Talaulikar's Discuss on draft-ietf-grow-bmp-bgp-rib-stats-16: (with DISCUSS)

[Ketan Talaulikar <[e-mail]>]

Hi Jeff,

Please check inline below for responses.


On Tue, Dec 2, 2025 at 2:50 AM Jeffrey Haas <[e-mail]> wrote:

> Ketan,
>
> > On Dec 1, 2025, at 11:37 AM, Ketan Talaulikar <[e-mail]>
> wrote:
> >
> > I agree with the suggestion to move types 24 and 25 (Primary/Backup
> route counts) from this document to draft-ietf-grow-bmp-path-marking-tlv.
> This will allow the Working Group to fully deliberate the semantics of
> "route" vs. "path," especially concerning Add-Paths and multipath aspects.
>
> If so, and if H3C has shipped the code as they note in §9.2, let's make
> sure the IANA considerations reserves these fields.
>

KT> Absolutely, if there are implementations, then the IANA registry should
just move the pointer for these types from this document to the
path-marking document i.e., we don't lose the allocations.


>
> >
> > Assuming this is the chosen path:
> >
> > 1. Do Types 26, 27, and 28, which also refer to a path, also need to be
> moved to the path-marking document for consistency?
> > 2. For clarity across all BMP stats, does the document confirm that
> "route" is functionally equivalent to "prefix/destination"? My
> interpretation of existing stats suggests this is the case.
>
> ... and this would be problematic vs. 4271.  Can we stop using route in
> that sense?
>
> If the sense is an instance of a route, call it a path and make sure path
> is cleanly defined.
>

KT> Per my reading of RFC4271 (and it is not literal but the essence that I
take from section 3.1), if we are counting "routes" we are counting the
destination/prefix entries and if we are counting paths we are counting the
path attributes received from various peers for those
destinations/prefixes. I note that we didn't have additional paths or
multipaths in RFC4271 - there is one best path. I don't find the mention of
"an instance of a route" or something like that though and please point me
to something like that if I've missed it.



>
> >
> > a) Statistic View Clarity: Do all statistic descriptions accurately
> indicate the view (Adj-RIB-In, Adj-RIB-Out, Loc-RIB)? The document is
> sometimes ambiguous. Specifically, Types 22, 23, and 26 through 34 do not
> explicitly state Adj-RIB-In, and Types 38, 39, and 40 do not explicitly
> state Adj-RIB-Out. The descriptions should reflect the scope since the
> Section 4 table is not being registered with IANA.
>
> The grid in §4 covers scoping appropriately.  Is your desire here that the
> descriptive clauses also have the scoping added to them?  The section
> header covers some of this implicitly.
>

KT> Yes, the description to cover the view that the stat applies to such
that it also gets in the description of the corresponding entry in the IANA
registry as well. This would help bring clarity - especially if the stat
were applicable to multiple views.


>
> At least part of the criticism is that if we want the scope to be clear,
> it has to be in :
> Section 3 and potentially be redundant vs. the section header.
> Section 4 in the grid, which is a good short cut.
> Section 8 for IANA, which will probably be used as inputs for things like
> manageability interfaces.
>

KT> IANA for sure for the reasons you mention. Section 3 is editorial and
I'll leave it to the authors on how they bring that out. Section 4 table is
new for a BMP draft - and it is missing pre/post policy flavors - I will
leave this to the WG discussion that is beyond this document.


>
>
>
>
> >
> > b) Loc-RIB Scoping: Types 26, 27, 28, 31, and 32 are applicable to the
> Loc-RIB. Should new, dedicated stat types be defined for the Loc-RIB view
> to maintain consistency with previous RFC conventions, or should the
> existing type descriptions be updated to capture the Loc-RIB view as well
> explicitly?
>
> The headache is really "what do you do when a given statistic applies to
> more than one view?"
>
> 30,31 for example apply to rib-in as well as loc-rib.  Were you arguing to
> decompose section 3 into another block of "rib-in plus loc-rib?"  For this
> document, that would address the clarity in the section, but at the cost of
> adding discontinuities in the listing of the assignments in section 3.
>

KT> The section titles can be updated. Is "discontinuity" really a thing to
worry about here?


>
>
>
>
> >
> > c) Global vs. Per-AFI/SAFI Types: Are both global and per-AFI/SAFI types
> defined for all applicable statistics? Why are some types (e.g., 26, 27,
> 28) defined as per-AFI/SAFI only, without an accompanying global type?
>
> Addressing Paolo's comment, picking a designated afi 0/safi 0 as "global"
> probably would have been nice, but there's now running code covering these
> things.
>
> Covering your broader point, there's always been a bit of a disconnect in
> management-land as to what to do about aggregate statistics.  The total
> "global" number is the sum of the per-afi-safi - when do we have global vs.
> not?  Examples of where such aggregates cause trouble are "RIB copies/route
> leaking".  This can lead implementations to say "I received X,Y,Z counts of
> those AFI/SAFI" but have a number of route instances that misalign to
> X+Y+Z.
>
> The answer is likely "pick a style and let's try to be consistent with it
> henceforth".  At the very least we made statistics in BMP cheap so we can
> learn from experience.
>

KT> I agree. Can we pick such a style in this document and follow it in
other documents?

Thanks,
Ketan



>
>
>
> -- Jeff
>
>