It will be awesome to have some one seeing this and responding on this ? Thanks, Saumya.
From: Dikshit, Saumya <[email protected]> Date: Wednesday, 16 September 2026 at 4:02 PM To: Dikshit, Saumya <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: review request: BMP statistics scoping and interoperability Hi Thomas, Paolo and the WG members It will be great to hear from anyone and everyone on this to take it further. Hope you got a chance to go over the below email and the reference documents shared. Thanks, Saumya. From: Dikshit, Saumya <[email protected]> Date: Friday, 4 September 2026 at 5:49 PM To: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]> Subject: [GROW] Re: review request: BMP statistics scoping and interoperability Hi Thomas, Thank you for raising this in the thread. I have replied inline below to the specific points. [SAUMYA] Yes, that is the underlying point. The newer statistics are not only AFI/SAFI-scoped; they may also be scoped to finer-grained contexts such as RD or policy-specific route state as mentioned in few of my drafts the group. I agree that the scoping needs to be made explicit, and that is exactly the concern. I also agree with the BMP point that per-peer header in RFC 7854 does not carry AFI/SAFI scoping, which is why RFC 9972 carries that information in the Stat Data encoding instead. In summary, the telemetry models are sorted but scoping isn’t. This is the broader concern I am trying to capture in https://datatracker.ietf.org/doc/draft-dikshit-nmop-telemetry-identifier-scoping/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-dikshit-nmop-telemetry-identifier-scoping/__;!!NpxR!hbaXEwfxNSw8k5ROuNd6-T6b9rR4A4mFaKq-cYzReDodeNlF7EyAVsHRLJy9x5Qu9vEQb-xqqqbK8BPCsK2vk4wYjQvL4NmepA$>. The draft it is calling out : * general interoperability requirement * exported identifiers and statistics should state the scope in which they are unique and meaningful, * and the conditions under which they may be compared with values from other contexts. * Applicability to BMP, IPFIX, YANG-based telemetry, sampled metrics, counters, and other telemetry exports where the semantics depend on instance-specific context. * Firming up on the fact, that the key requirement is not simply “encode the value,” but “define the comparability domain.” * Explicit receive side concern: it should not have to infer from local context or assumptions that two values are comparable when the specification does not say so. * Without that explicit scope information, we risk creating a dataset that looks internally consistent but is semantically inconsistent across domains. * It also matches the operational checks: * when export values are mixed across scopes, the result can be misleading dashboards, incorrect aggregation, and false conclusions about network behavior. Still working on the draft and expect to refine the wording and examples further, but the core point is that scope and comparability need to be explicit, not implicit. It will be great to have you, Paolo and all to review and contribute to it and if it can be made a starting point in this direction. >>>> 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? [SAUMYA] That’s right. Yes, that is the underlying direction. The newer statistics are not only AFI/SAFI-scoped, but are also being considered at finer-grained scopes such as RD-specific instances or policy-changed route state. This is where the whole thing started where I am struggling with the scoping and interpretation of those values and seeing the need to be stated explicitly so that a collector or decoder knows what the statistic means in different scopes. ” >>>> Did I understood the problem space well enough? Would you agree on such an >>>> approach? [SAUMYA] Yes, I am surely in sync with you. Just wrapping up on the note if you, Paolo and all can review and contribute to https://datatracker.ietf.org/doc/draft-dikshit-nmop-telemetry-identifier-scoping/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-dikshit-nmop-telemetry-identifier-scoping/__;!!NpxR!hbaXEwfxNSw8k5ROuNd6-T6b9rR4A4mFaKq-cYzReDodeNlF7EyAVsHRLJy9x5Qu9vEQb-xqqqbK8BPCsK2vk4wYjQvL4NmepA$>. and if it can be made a starting point in this direction. Either way, I am interested in taking this further and eventually to closure. Because I am an already enrolled consumer to this warranted consistency on collector side. Best Regards, Saumya. From: [email protected] <[email protected]> Date: Friday, 4 September 2026 at 11:06 AM To: Dikshit, Saumya <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: RE: review request: BMP statistics scoping and interoperability Dear Saumya and Paolo, The BMP per-peer header https://datatracker.ietf.org/doc/html/rfc7854#section-4.2<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc7854*section-4.2__;Iw!!NpxR!hbaXEwfxNSw8k5ROuNd6-T6b9rR4A4mFaKq-cYzReDodeNlF7EyAVsHRLJy9x5Qu9vEQb-xqqqbK8BPCsK2vk4wYjQtOz8kLhA$> does not contain AFI or SAFI scoping which is needed for BMP statistics https://datatracker.ietf.org/doc/html/rfc7854#section-4.8<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc7854*section-4.8__;Iw!!NpxR!hbaXEwfxNSw8k5ROuNd6-T6b9rR4A4mFaKq-cYzReDodeNlF7EyAVsHRLJy9x5Qu9vEQb-xqqqbK8BPCsK2vk4wYjQtAknyAMQ$> 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<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc9972*section-3.1__;Iw!!NpxR!hbaXEwfxNSw8k5ROuNd6-T6b9rR4A4mFaKq-cYzReDodeNlF7EyAVsHRLJy9x5Qu9vEQb-xqqqbK8BPCsK2vk4wYjQvDs3V2vw$> 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<https://urldefense.com/v3/__https://www.iana.org/assignments/bmp-parameters__;!!NpxR!hbaXEwfxNSw8k5ROuNd6-T6b9rR4A4mFaKq-cYzReDodeNlF7EyAVsHRLJy9x5Qu9vEQb-xqqqbK8BPCsK2vk4wYjQtMLtJpkA$> 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<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-netana-nmop-message-broker-bmp-telemetry-ms__;!!NpxR!hbaXEwfxNSw8k5ROuNd6-T6b9rR4A4mFaKq-cYzReDodeNlF7EyAVsHRLJy9x5Qu9vEQb-xqqqbK8BPCsK2vk4wYjQuq8L25mA$>, 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
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
