When I wrote route-refresh, that was from the router/sender side, not BMP receiver sending a route-refresh. BMP is still write-only.
There are use-cases for re-syncing the RIB to the BMP receiver. Some of the methods today are to clear the peer, request a route-refresh in, or to reset the BMP feed. This is a bit intrusive to the router (sender) and BMP receiver. Having to go to the router to request a refresh to the BMP server, IMO, is still okay. The problem is that control knobs for refresh are at the BGP peer level, not BMP. For Adj-RIB-In Pre-Policy, it makes sense to do that on the peer, but for Post-Policy, Adj-RIB-Out and Local-RIB, it doesn’t really make sense. Having a knob to initiate BMP side refresh would be very nice and hopefully less intrusive. Regardless of the BMP server needing a refresh, a BMP server does not know when someone has requested route-refresh IN at the peer level (maybe it was requested for policy change, …) Instead, the BMP receiver, blindly, receives a boat load of updates with no awareness that it was a new RIB dump or controlled refresh. In this case, it would appear to be churn. IMO, there is value in having a message to signal the receiver that a refresh is coming, followed by an EoR. A PEER_UP could be used for this, but that is intrusive and misuse of PEER_UP. --Tim On 9/22/22, 11:03 AM, "Jeffrey Haas" <[email protected]> wrote: > On Sep 21, 2022, at 7:42 AM, Zhuangshunwan > <[email protected]> wrote: > > Hi Tim and All, > > I think the idea of a "BMP route refresh" would be appreciated, it will > helps keep the information synchronized between the BMP Server and the BMP > Client. Would someone clarify what they mean by a bmp route refresh? The BMP protocol was intentionally designed as write-only. -- Jeff
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
