Hi Jeff, Please see In line with tag [saumya]
> On Aug 13, 2025, at 1:24 PM, Dikshit, Saumya <[email protected]> wrote: > 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 ? >As you're noticing, we're all "volunteers" here at IETF. So, you can ask >around. When the responses aren't as prompt as you like, "asking harder" >isn't helpful - no one owes responses. In many cases, individuals support >various mail list activities or even meeting >week stuff on a best effort >basis. [saumya] I will publish 01 version by adding more details and counters and attend to your comments and then seek review for EVPN as well. How about sharing it in other groups like BESS, NVO3 >Starting with internal EVPN experts is a way to begin. > A general note: IETF lists are often quieter in August due to European > holidays. [saumya] Keeping my fingers crossed > §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 ? > Current statistics types in BMP are very simple. With the AFI/SAFI stuff, we > have a very light amount of "structured data" that has begun to be used. > Your proposal is an example of an attempt to push that even deeper. [saumya] As I said. I can revert to scalar. It’s more of mechanical thing to spread them out flat. For example, a separate counter for: route type-1, in-rib, pre-policy, gauge count > The high level headache had with the protocol is that those fields weren't > originally specified for structured data. As a result, a receiving > implementation has to "know" how to decode things. It's not self-describing. > Even something as simple as making such stats TLVs would go a step that > direction. Or even something like an embedded CBOR struct. (I've made some > people cringe.) > The use case for such structured data, and "does this belong in BMP" is how > the conversations start. [saumya] This data surely belong to BMP, as it helps monitoring, troubleshooting the networks with BGP deployments in-depth. DC and enterprise shall definitely benefit by including EVPN with BMP. > > 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 > I'd recommend the packet diagrams as well. Long experience at IETF suggests > that normative text without those leads to implementation bugs. :-) [saumya] If I can flatten them out, this may not be required > > §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://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-yang-07__;!!NpxR!hrYt5hRojbPRktQPcFPX-CPz7H86bD8vBZSngPXuuvVWws1Jn9BuwjWnX4M_-etMy6JdkDmIhpIS_Q$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-yang-07__;!!NpxR!hrYt5hRojbPRktQPcFPX-CPz7H86bD8vBZSngPXuuvVWws1Jn9BuwjWnX4M_-etMy6JdkDmIhpIS_Q$> > . That shall surely help in refining this draft. >I think you'll find it good methodology to start with "what would this look >like in YANG" and then move to "BMP does well for aggregated statistics". [saumya] I went over the expired draft. I see some counters indicating packets hitting the EVPN routes. >If you find that there's still some motivation to want to expose these per-X >stats, this might motivate either a conversation on those more structured *AT >SCALE* stats, or even new BMP message types. [saumya] We need consensus on this, post discussions/reviews. Not sure how it pans out 😊 > ... or that BMP isn't the right fit. [saumya] BMP is definitely one of the placeholders, if not the only placeholder for defining these stats. > §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. >Periodicity and scale lead to fun conversations about encouraging on-change. >Basically, if you have a huge amount of data and you're blasting it every 30 >seconds, you eventually have clients that stop being able to keep up. If the >data is semi static, you create a lot of work. on-change reduces the work on the consumer at the risk of a noisier system when it's very chatty at scale. Right now, BMP is mostly periodic reports. So, this is another set of operational axes to consider for "is BMP a good fit for this". [saumya] on the stats/telemetry ingestion-server side, it’s up to the logic that generates actionable alerts/insights. At least I know about some implementations, which can do a delta calculation on the stats and states and take action Thanks, Saumya.
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
