Hi Robert, According to my knowledge, the current BMP protocol is completely unaware of the existence of the BGP Route Refresh message. This is why the proposal of the BMP client sends an refresh signal to the BMP server arise.
Thanks, Shunwan From: Robert Raszuk [mailto:[email protected]] Sent: Friday, September 23, 2022 3:54 PM To: Tim Evens (tievens) <[email protected]> Cc: Jeffrey Haas <[email protected]>; Zhuangshunwan <[email protected]>; [email protected]; Maximilian Wilhelm <[email protected]> Subject: Re: [GROW] [Idr] RFC7854: EoR Tim, Why not just send BGP Message Type 5 verbatim ? Are you saying that BMP is not sending this message to BMP receivers when arriving from BGP peers of the router ? If so why ? Thx, R. On Fri, Sep 23, 2022 at 2:03 AM Tim Evens (tievens) <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[email protected]>> wrote: > On Sep 21, 2022, at 7:42 AM, Zhuangshunwan > <[email protected]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/grow
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
