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!

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.

§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.  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.

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.

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.

§2.3 It's not clear if this is intended to be a vector based on the bit 
combinations or not.

§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".  

§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.

§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.

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.



-- Jeff


> On Aug 12, 2025, at 3:27 PM, Dikshit, Saumya 
> <[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]

Reply via email to