> On Sep 22, 2022, at 3:07 PM, Robert Raszuk <[email protected]> wrote: > > Hi Jeff, > > State compression for route-monitoring messages in BMP is common. > > If you wanted perfect state, you would use route-mirroring mode, if the > implementation supported it. > > And why not use the churn counter.
If your implementation supported such a thing. Most implementations keep per-peer in/out updates + messages for supporting the BGP MIB. Those help. Per-prefix churn requires you to maintain at least some level of route state for that path. That sort of state is kept as part of route flap damping, but RFD isn't as popular as it once was. (For good reasons.) > > I could see it being quite useful even without BMP running at all. > And once available, sending it via BMP message would be pretty trivial. Very noisy, likely just contributing to saturating the pipe. If it was put into the stats reports, you'd get stats reports in roughly the same amount as your RIB activity. For stuff that can be hooked to rib-in state, the TLV feature can let you get the stuff as annotations... but the noise level of it probably doesn't help the analysis case terribly well. > > I could think of three such counters: > > - "Number of received paths for a given net during the session" > - "Number of received withdraws for a given net during the session" Per-prefix state won't scale nicely as stats report, and doesn't fit into one of the five logical rib views. > - "Number of next hop metric changes for registered next hops" This one potentially scales well and would fit into a stats report. -- Jeff
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
