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
