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, 11:27 AM, "Jeffrey Haas" <[email protected]> wrote: Jakob, On Thu, Dec 13, 2018 at 07:12:08PM +0000, Jakob Heitz (jheitz) wrote: > 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. RFC 7854: : A Peer Down message implicitly withdraws all routes that were : associated with the peer in question. A BMP implementation MAY omit : sending explicit withdraws for such routes. -- Jeff [tievens] This is the expected behavior... we mark all RIB entries as withdrawn/stale upon peer DOWN/UP. Note, there is no guarantee that we will receive a peer down (e.g. router term or connection failure), so upon PEER up we mark previous entries as withdrawn. We expect that a PEER up will be followed by a RIB DUMP with the current state of the RIB. We expect updates following the RIB DUMP that will reconcile and maintain the state. RFC7854 doesn't address the transient changes happening during the RIB dump. For example, it takes 1 minute to complete the RIB dump but about the changes during that dump? IMO, they should be buffered and replayed. This is a topic that is not specific to this draft but does need to be addressed. _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
