Tim,
> On Sep 22, 2022, at 8:02 PM, Tim Evens (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. Thanks. This is now clear. > 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. I think my concerns are in terms of incremental impact on existing BMP receivers. Two thoughts come to mind about encoding: 1. A new BMP message type is used to signal a refresh for the appropriate logical view, and similarly that the end of rib markers that this thread was originally discussing would happen. :-) 2. Deliberate mis-use of peer-up. One option is to add a new informational TLV to cover that this is a refresh. For this point, the question to ask of receivers is what they would do if they received a peer-up when they already had state covering a session that is up. A quick glance (but not thorough audit) of RFC 7854 is that it seems silent on what would happen if you got a redundant peer-up. While I'd be generally inclined for the new message option, I could sort of see cases where existing BMP collectors might be happier using existing peer-up triggers for things. But I could similarly see where some might consider it a flavor of state machine violation and may not be happy with it. -- Jeff
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
