Dear Saumya and Paolo, The BMP per-peer header https://datatracker.ietf.org/doc/html/rfc7854#section-4.2 does not contain AFI or SAFI scoping which is needed for BMP statistics https://datatracker.ietf.org/doc/html/rfc7854#section-4.8 if statistics are scoped for AFI/SAFI. However the per-peer header does contain a peer distinguisher for BGP observations within a single VRF.
https://datatracker.ietf.org/doc/html/rfc9972#section-3.1 introduces AFI/SAFI in the encoding of the "Stat Data". This introduces a new requirement that a decoder needs to be aware of how the "Stat Data" is encoded. Unfortunately that is described in the IANA registry https://www.iana.org/assignments/bmp-parameters in the "description" field, which is far from being ideal. I haven't fully read draft-dikshit-grow-bmp-rd-scoped-rib-stats, draft-saum-grow-bmp-afi-safi-evpn and draft-smc-grow-bmp-route-change-stats but I assume that new statistics are being introduced which besides AFI/SAFI are also scoped to RD's and BGP attributes changed by route-policies. Correct? As a network operator and co-author of https://datatracker.ietf.org/doc/html/draft-netana-nmop-message-broker-bmp-telemetry-ms, I agree with Saumya's point that semantics on statistics scoping needs improvements. A BMP data collector MUST be able, the same as for IPFIX, find in the BMP IANA registry what the data type (schema) for a statistic is and how the statistics are scoped. Ideally, the data encoded and schema (key, value) SHOULD be separated. I would support a document which updates the "BMP Statistics Types" IANA registry by introducing "data type" and "scope" and in a future BMP version a separation between the data encoded and schema. Than the workflow for a data collector is clear. Prior to transformation (making data available to the human or agent consumer), it needs to obtain for each stats data their schema and semantics definition from IANA "BMP Statistics Types" registry. Did I understood the problem space well enough? Would you agree on such an approach? Best wishes Thomas From: Dikshit, Saumya <[email protected]> Sent: Thursday, September 3, 2026 5:21 PM To: Paolo Lucente <[email protected]>; [email protected] Cc: [email protected]; Graf Thomas, SCS-INI-NET-VNC-E2E <[email protected]>; [email protected] Subject: Re: review request: BMP statistics scoping and interoperability Be aware: This is an external email. Hi Paolo, Thanks for supporting/raising this. I agree that the statistics work in BMP is valuable, but the real question is not whether the data is useful, it is whether the semantics and scoping are clear enough for collectors and operators to interpret it consistently. In my experience, BMP statistics are useful for operational validation and troubleshooting, especially when we need to compare route-change or RIB-related behavior across instances, detect deviations, and reason about policy-induced churn. The main pain point is that the same class of object can be scoped differently across drafts (AFI/SAFI, RD, EVPN instance, or policy-driven context), and a collector needs a shared understanding of what is comparable and what is not. Working on the AIOPs telemetry analysis side I really think it’s worth following up actively. I will be among the first ones to consume it at least 😊 Best Regards, Saumya. From: Paolo Lucente <[email protected]<mailto:[email protected]>> Date: Wednesday, 2 September 2026 at 5:14 AM To: Dikshit, Saumya <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: Re: review request: BMP statistics scoping and interoperability Hi Saumya, All, I think your proposal to make a "super draft" around statistics instead of doing sparse efforts here and there - which for once they are sparse but they are also difficult to track and put together in one framework - has definitely some merit. The details can be worked out along the way. I wanted to take this opportunity for a side consideration, this did emerge actually from a recent conversation Camilo and myself had around the F flag draft: we are collectively putting lots of effort and attention to statistics in BMP but how important and, even more importantly, how used are they? So, especially among operators / BMP users reading, could we do something as basic as a show of hands (of course the more elaboration the better) in this sense? Are you using statistics? Yes/no? If into elaborating more: for what use-case(s), ie. just storing them for analysis, some sort of validation, else? Paolo On 17/8/26 15:08, Dikshit, Saumya wrote: > > Hello All , > > I would like feedback on a BMP statistics issue that appears to be > missing from the current discussion. > > There are several ways to represent the same class of object in BMP > today: per-instance gauge values scoped by AFI/SAFI, RD, EVPN instance, > or route-change policy. > A collector that wants to support all of these may end up needing > multiple incompatible parsers for essentially the same operational concept. > This is already being discussed in parallel emails chains and this the > gap I am trying to address with the following drafts: > > * > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-saumthimma-evpn-ip-binding-__;!!NpxR!hzcFm7W4fz4oHgX7p6ztvIYK_fCtMdQJx5LGiioElS2PMZNN-iO1A09Z4FEu_7NTYRxGLZcOzSDexg$ > sync/ > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-saumthimma-evpn-ip-__;!!NpxR!hzcFm7W4fz4oHgX7p6ztvIYK_fCtMdQJx5LGiioElS2PMZNN-iO1A09Z4FEu_7NTYRxGLZfG6W0tQg$ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-saumthimma-evpn-ip-__;!!NpxR!hzcFm7W4fz4oHgX7p6ztvIYK_fCtMdQJx5LGiioElS2PMZNN-iO1A09Z4FEu_7NTYRxGLZfG6W0tQg$%0b>> binding-sync/> > * > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-dikshit-grow-bmp-rd-scoped-__;!!NpxR!hzcFm7W4fz4oHgX7p6ztvIYK_fCtMdQJx5LGiioElS2PMZNN-iO1A09Z4FEu_7NTYRxGLZdl6yEabA$ > rib-stats/ > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-dikshit-grow-bmp-__;!!NpxR!hzcFm7W4fz4oHgX7p6ztvIYK_fCtMdQJx5LGiioElS2PMZNN-iO1A09Z4FEu_7NTYRxGLZcTYsrQTg$ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-dikshit-grow-bmp-__;!!NpxR!hzcFm7W4fz4oHgX7p6ztvIYK_fCtMdQJx5LGiioElS2PMZNN-iO1A09Z4FEu_7NTYRxGLZcTYsrQTg$%0b>> rd-scoped-rib-stats/> > * > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-smc-grow-bmp-route-change-__;!!NpxR!hzcFm7W4fz4oHgX7p6ztvIYK_fCtMdQJx5LGiioElS2PMZNN-iO1A09Z4FEu_7NTYRxGLZeVJl8Lsg$ > stats/ > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-smc-grow-bmp-route-__;!!NpxR!hzcFm7W4fz4oHgX7p6ztvIYK_fCtMdQJx5LGiioElS2PMZNN-iO1A09Z4FEu_7NTYRxGLZcoNKwf2Q$ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-smc-grow-bmp-route-__;!!NpxR!hzcFm7W4fz4oHgX7p6ztvIYK_fCtMdQJx5LGiioElS2PMZNN-iO1A09Z4FEu_7NTYRxGLZcoNKwf2Q$%0b>> change-stats/> > > > This is an ask for review comments on the direction: > > * > whether a common instance-scoped / RD-scoped BMP statistics > structure is the right approach, and whether the statistics > ecosystem needs a shared pattern before these extensions proliferate. > > > I would especially value feedback from people working on: > > - BMP statistics > - BMP data models > - EVPN and VPN RIB reporting > - route-change and policy-driven telemetry > > If the WG thinks a common pattern is useful, I would be happy to align > the drafts around that structure. > If not, It would be great to know about it now, than discovering it later. > > Thanks. > Saumya Dikshit
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
