[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 with KT2.


On Tue, Dec 2, 2025 at 11:42 PM Jeffrey Haas <[e-mail]> wrote:

> Ketan,
>
>
> > On Dec 2, 2025, at 6:25 AM, Ketan Talaulikar <[e-mail]>
> wrote:
> > > 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.
>
> (I could swear I've spelled this out in detail before, but yet again...)
>

KT2> My apologies for missing that but your summary below is very helpful.


>
> It's all the way at the top in 1.1.  Routes pair destinations with path
> attributes.  For 4271, we only can send a single instance of a destination
> (it's the key).
>
> So, the property I keep coming back to complain about is discussing
> "route" in the sense that a destination is used in, or NLRI.
>
> RFC 7911 is what introduces add-paths.  Here, we don't cleanly establish
> the definition of a path, but we define it by functionality.
>
> Multipath completely remains undefined procedurally.  And that's sort of
> perverse considering we are deep in a different thread discussing how
> link-bandwidth is used to load balance for multipath procedures. :-)  There
> were a few drafts previously that tried to formalize things, but they never
> progressed.  Addressing that strange gap may be appropriate for 4271-bis.
>
> The reason I continue to be pedantic in my responses here is that grow has
> already accidentally created long-standing BGP terminology via BMP.  The
> current 5 logical RIB view isn't a 4271 thing. :-)  So, we need to be
> careful to not let casual use here become another accidental "defined by
> use" document.
>
> For clarity:
> Destination: The destination in the appropriate address family combination
> (afi/safi) that a key in a RIB.  (This is where we'll likely revisit things
> for the RIB-key conversation for 4271-bis)
> NLRI: In practice, the encoding of a destination and potentially other
> destination-specific attributes in a BGP UPDATE PDU, some of which may be a
> key in the RIB, some of which are not.  The original meaning of "network
> layer" reachability has degraded over time where we no longer are talking
> strictly about OSI Layer 3 in the things we carry in BGP.
> Route: A pairing of a destination and a set of path attributes.
> Path: An instance of a route received from or sent to a BGP speaker.
>

KT2> Agree - this is my (and perhaps the general?) understanding as well.
There is one wrinkle about Loc-RIB (and the RIB) and how the terms Route
and Path are correlated there (factoring multipath and its variants like
best/backup)


>
> And while there's more than a little room to argue whether we should be
> having this discussion in this relatively straight forward bit of BMP, our
> underlying discussion is tied to the unresolved points of what exactly a
> given RIB stat is intending to represent in the protocol or the
> implementation.  Unfortunately, clarity for the stats may force us to put
> some of these definitions in the document if it's otherwise unclear.
>

KT2> I agree.


>
> [The latter portion fo the response covering "we need consistency" is I
> think understood. However, I think the authors need some closure on
> terminology to do that.]
>
>
> >
> > > 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?
>
> My main worry on discontinuous contents is mostly based on seeing what
> sort of bugs more than one vendor ends up with in the field when we're not
> careful about such things.  So, it's not a primary consideration, but it's
> absolutely a secondary one.
>
> And I don't think there's a good answer if it's agreed to do the split.
>
> > > 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?
>
> If it were solely my choice, I'd recommend not keeping the aggregate stats
> as afi/safi 0/0.  This is for the reasons posted above.  We're only saving
> a few octets in the PDU to separately encode it.
>
> Let's see what other wisdom the WG has based on implementation for the
> protocol and the consumption of it has to offer.
>

KT2> There are multiple ways to go about this and I will leave it to the
WG. Just looking for clarity - in this document or the other one - before
we send this towards publication.

Thanks,
Ketan


>
> -- Jeff
>
>