NOTE: Sorry for the delay... end of year commitments are pressing... Addressing these comments in descending order.
See inline marked [tievens] On 12/13/18, 10:58 AM, "Paolo Lucente" <[email protected]> wrote: 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. [tievens] This is classic state exchange and the reason why a RIB dump is needed upon PEER UP. It is simple to exchange the current state. IMO, it will be more complex to implement a reconciling method to sync the BMP server (receiver) based on delta changes from time T1 to Tn. A reconciling method will require the router to track where the BMP server is in terms of the RIB state and to exchange updates relative to new connect time. BGP doesn't even attempt to do this, for good reason! I believe the confusion with Jakob's response is that he is thinking we (the receivers) are log endpoints, which is totally not true. Logging BGP changes are only part of the monitoring. We fully expect to use BMP to monitor the RIB states, just like we have been doing with MRT(TABLE_DUMP/BGP4MP_MESSAGE) and PCAP for the past several years. 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
