Hi, That's orthogonal to using BMP to carry BGP-LS AF.
Anyway RFC7854 section 4.7 does not seem to limit mirroring to only BGP_UPDATE Messages. So all messages can be mirrored to BMP collectors including Type 5. That means that it should be possible today to use route monitoring and mirroring together. And filter route mirroring to type 5 (or other bgp messages) if needed. Not sure if we need a new extension to explicitly carry route refresh as part of route monitoring, but if so it would be fine. Thx, R. On Fri, Sep 23, 2022 at 2:35 PM Zhuangshunwan <[email protected]> wrote: > 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) <tievens= > [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]> wrote: > > > > > > > On Sep 21, 2022, at 7:42 AM, Zhuangshunwan <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
