> Especially in the BMP for BGP-LS address family What ? Are you serious ??? BMP for BGP-LS ... It must be a joke !
Best, R. On Fri, Sep 23, 2022 at 2:21 PM Zhuangshunwan <zhuangshunwan= [email protected]> wrote: > +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]> 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 >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
