+1 for the value in having a message to signal the receiver that a refresh is coming, followed by an EoR. I think Tim's proposal is very useful. Especially in the BMP for BGP-LS address family, the controller builds a real-time topology based on BGP-LS information. Another scenario is where the controller collects BGP routes through BMP and correlates them with traffic information collected by IPFIX to build a traffic matrix.
Thanks, Shunwan From: Tim Evens (tievens) [mailto:[email protected]] Sent: Friday, September 23, 2022 8:03 AM To: Jeffrey Haas <[email protected]>; Zhuangshunwan <[email protected]> Cc: Luuk Hendriks <[email protected]>; Maximilian Wilhelm <[email protected]>; John Scudder <[email protected]>; Paolo Lucente <[email protected]>; [email protected] Subject: Re: [GROW] [Idr] RFC7854: EoR 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] https://www.ietf.org/mailman/listinfo/grow
