Wait, a BMP server is not a BGP peer. It does not replicate a routing table. It is a logger/processor of information. It doesn't "delete" older information, just because some newer information arrived. Its purpose it to tell you what happened at some time in the past, because you are trying to debug a problem or do some capacity planning or whatever. Just because a BGP router changed its BGP-ID does not mean that all the routes it had 2 days ago magically did not happen.
Regards, Jakob. -----Original Message----- From: Paolo Lucente <[email protected]> Sent: Thursday, December 13, 2018 10:58 AM To: Jeffrey Haas <[email protected]>; Jakob Heitz (jheitz) <[email protected]> Cc: [email protected]; [email protected] Subject: Re: [GROW] BMP loc-rib Peer-Type behavior Hi Jakob, Jeff, +1 for the peer down / peer up sequence for the scenario described (and in general for changes to the peer, like peer address?). But not re-sending RMs after the peer up seems very unclean to me. True we can invent an extra mechanism to say hold on your routes, like Jeff says, but i see the extra complexity with that (do we really need it?): it would work if the BMP server is building RIBs out of received RMs but what about more streaming data scenarios? Not to speak that if there was a route flap in BGP, due to the OPEN, you are effectively hiding it. Not BGP Monitoring Protocol anymore. Paolo > On 13 Dec 2018, at 19:49, Jeffrey Haas <[email protected]> wrote: > > Jakob, > > On Thu, Dec 13, 2018 at 06:14:17PM +0000, Jakob Heitz (jheitz) wrote: >> From: Jeffrey Haas <[email protected]> >>> On Thu, Dec 13, 2018 at 02:29:13AM +0000, Jakob Heitz (jheitz) wrote: >>>> Sending a peer-down followed by a peer-up seems reasonable to me. >>>> Changing these requires a new OPEN message to neighbors, so everything >>>> is going to bounce anyway. >>> >>> I think so as well. >>> >>> But what of the route monitoring messages? >> >> I would leave those alone. Sending them again adds no new information. >> The BMP server can switch the ASN and BGP-ID on its own if it wants. > > That's my impression too. However, if the implementation treats the > peer-down as an implicit flush it won't work cleanly. > > This means that something in the header needs to indicate "I'm > updating some state, hold on to your RMs". > > -- 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
