Thanks a ton Jeff for an honest review. Please see inline. Thanks, Saumya.
From: Jeffrey Haas <[email protected]> Date: Wednesday, 13 August 2025 at 6:06 PM To: Dikshit, Saumya <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [GROW] New Version Notification for draft-saum-grow-bmp-afi-safi-evpn-00.txt Saumya, I'm not an evpn expert, so here's some comments from a BGP high level review. Note that this isn't a thorough review. That said, as a first -00, not bad! [saumya] Thanks for honest feedback, and I am all ears and eyes for absorbing them. Any suggestions on the process of having it reviewed from EVPN perspective as well ? Even though the draft is starting everything with 64-bit gauges, consider just carrying the types with the definitions even if it seems redundant. This matches style in other documents, but it also deals with the case where the draft eventually gets something else sprinkled in. [saumya] Ack. I started with that, then thought of calling it out at the beginning, unlike the “mothership draft”. §2.1 -consolidated types across multiple views. This isn't generally helpful to operators to squish these all together. There's also the question about the structure. If the intention is to have a vector of <evpn-type, rib-view, type/view gauge count>, the current style is to have separate views per code point. The proposal to have a per-view type even of <evpn-type, gauge count> does make sense. [saumya] As I get it, it is suggested to have a flat (scalar) structure for counters, for ease of usage for operators. No vectors/tuples to consolidate them into one ? It'll be interesting to see if the WG prefers such typed routes to be rolled under a single statistic code point or split into separate ones. Such a split gets to be multiplicatively larger, but there's room. [saumya] Let me call it out as an option in the next version Also, I'd be generally careful about limiting it to current types. Simply noting that it is encoding the route type and that it maps directly to the IANA registered route type future proofs this. [saumya] Makes perfect sense. Hence I have kept 8-bits to be on safer side, hence it covers for 256 types. For fields defining bits, it's easier to provide the traditional RFC bit diagram. This removes the question about what "first" bit means - high order or low order. [saumya] Noted. Will use high/low order instead §2.3 It's not clear if this is intended to be a vector based on the bit combinations or not. [saumya] It’s vector based. Calling out the numbers for either layer-2 or layer-3 multihoming segments. Since there are two options I can split them into two separate scalar ones as well. §2.4 This item seems to be drifting away from the simpler aggregate statistics BMP has traditionally liked to advertise. The contents here seem likely to be clear from a YANG module for EVPN. I suspect some of the BMP client implementors will have opinions about whether they'd want to see this sort of thing streamed as a "statistic". [saumya] this one is surely useful while gauging the impact of segment failure on subset of tenant bridge-domains and/or vrfs. Also an implicit indicator of designated forwarder re-election impact. I would definitely back it up. Since you brought up the reference to YANG module of EVPN, let me cross check on https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-yang-07 . That shall surely help in refining this draft. §2.4 also helps illustrate timeliness desires for such streaming statistics. While on-change style statistics can certainly be done in BMP, periodic publishing is what tends to be done. The use case here starts to motivate on-change type discussions which changes the consumption model. [saumya] we can still stick to periodic publishing for this counter, unless there is a requirement to alert upon an event via the stats. Let me check on existing counters. §2.5 introduces another "per-X" gauge with similar considerations. §2.7 - the "route-map" has a few considerations: - You'd want to define the bit mappings if you're going to use a bit map. - You're already approaching 16 and will run out of bits for extension - And far more messily.. route attributes modified by policy on what, exactly? The last sentence discusses it in the context of "this is a count of whether this attribute has been modified and how often the modification is done". I think you'll find that this is a bit overloaded in terms of view (rib-in/rib-out) but has interactions with receiving view to inter-RIB leak (EVI to global protocol) and that it's simply very hard statistics to keep correctly. [saumya] I am completely with you for the complexity part. I kept it so that it can be discussed further. I was thinking on the lies If we can keep it open ended for vendors beyond few well known attributes typically. Or in a wider spectrum align it with pre-post policy counters in the mothership draft. We can also have a pointer to those counters as well. I'd strongly suggest some discussion on how useful such a policy statistic might be given its impact on additional statistics that would need to be kept. §3 IANA considerations - You'll find you need to keep registries for any new fields you create for the types for extension purposes. [saumya] Ack. -- Jeff On Aug 12, 2025, at 3:27 PM, Dikshit, Saumya <[email protected]<mailto:[email protected]>> wrote: Hello Grow, Kindly review and contribute to this draft. This is also initiate discussions to define few counters which are specific to a subset of AFI/SAFI. And I gave a first cut shot at L2VPN-EVPN. Thanks, Saumya. From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Date: Wednesday, 13 August 2025 at 12:51 AM To: Dikshit, Saumya <[email protected]<mailto:[email protected]>>, Dikshit, Saumya <[email protected]<mailto:[email protected]>> Subject: New Version Notification for draft-saum-grow-bmp-afi-safi-evpn-00.txt A new version of Internet-Draft draft-saum-grow-bmp-afi-safi-evpn-00.txt has been successfully submitted by Saumya Dikshit and posted to the IETF repository. Name: draft-saum-grow-bmp-afi-safi-evpn Revision: 00 Title: EVPN-Specific BMP RIB Statistics Extensions Date: 2025-08-12 Group: Individual Submission Pages: 7 URL: https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-saum-grow-bmp-afi-safi-evpn-00.txt__;!!NpxR!kPzgTZ1TkGQcL1Kiy9kl5l6gDcBKJIpVQ59GHkhDqSzzGJDpeNXgVJ6tItPu4Uw_B1nsU-n5d-SF3gC8caErzlJWKoM$<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-saum-grow-bmp-afi-safi-evpn-00.txt__;!!NpxR!kPzgTZ1TkGQcL1Kiy9kl5l6gDcBKJIpVQ59GHkhDqSzzGJDpeNXgVJ6tItPu4Uw_B1nsU-n5d-SF3gC8caErzlJWKoM$> Status: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-saum-grow-bmp-afi-safi-evpn/__;!!NpxR!kPzgTZ1TkGQcL1Kiy9kl5l6gDcBKJIpVQ59GHkhDqSzzGJDpeNXgVJ6tItPu4Uw_B1nsU-n5d-SF3gC8caErFLXtP_I$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-saum-grow-bmp-afi-safi-evpn/__;!!NpxR!kPzgTZ1TkGQcL1Kiy9kl5l6gDcBKJIpVQ59GHkhDqSzzGJDpeNXgVJ6tItPu4Uw_B1nsU-n5d-SF3gC8caErFLXtP_I$> HTMLized: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-saum-grow-bmp-afi-safi-evpn__;!!NpxR!kPzgTZ1TkGQcL1Kiy9kl5l6gDcBKJIpVQ59GHkhDqSzzGJDpeNXgVJ6tItPu4Uw_B1nsU-n5d-SF3gC8caErVpBUGBk$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-saum-grow-bmp-afi-safi-evpn__;!!NpxR!kPzgTZ1TkGQcL1Kiy9kl5l6gDcBKJIpVQ59GHkhDqSzzGJDpeNXgVJ6tItPu4Uw_B1nsU-n5d-SF3gC8caErVpBUGBk$> Abstract: This document defines EVPN-specific BMP statistics types that extend the generic BMP RIB statistics defined in draft-ietf-grow-bmp-bgp- rib-stats. It includes counters for EVPN multihoming for both layer-2 and layer-3 (IP aliasing), dynamic IVRL, route-map application on routes, and EVPN route-type visibility for all route- types from 1 to 8. The Border Gateway Protocol Monitoring Protocol (BMP) provides a convenient interface for obtaining BGP-related data. This document extends BMP RIB statistics to include EVPN-specific counters and metrics, enabling enhanced visibility into EVPN route processing and behavior. This document registers new EVPN BMP statistic type identifiers in the BMP Statistics Type registry. These identifiers are used to represent EVPN-specific counters in BMP messages. The IETF Secretariat _______________________________________________ GROW mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
