Generating those could be done by running RFD in "informational mode" ie. without applying actual dampening.
As far as saturating the pipe - I do not see how that would happen if implementation would be sending such counters every X minutes. I will look how easy/hard is to provide it in our BGP code base. However question for this thread is if there is any interest to extend BMP to send them to BMP receiver(s) ? Thx, R. On Thu, Sep 22, 2022 at 10:13 PM Jeffrey Haas <jh...@pfrc.org> wrote: > > > On Sep 22, 2022, at 3:07 PM, Robert Raszuk <rob...@raszuk.net> 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 GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
