Reshad, On Thu, Nov 06, 2025 at 07:47:23PM +0000, Reshad Rahman wrote: > Wrt having an indication that says "this is part of a snapshot", isn't this > covered by the Snapshot Id TLV?
Partially! And I admit to reading too fast and thinking that this was only being added to the peer-up messaging. :-) (Admit it when you're being lazy...) > On Thursday, November 6, 2025 at 01:58:50 PM EST, Jeffrey Haas > <[email protected]> wrote: > > One possible way to address this ambiguity is to include a boolean TLV that > > says "this is a snapshot". By direct analogy, if you were sending a route > > solely because of a "route refresh" type snapshot behavior, this is distinct > > from a topology change. So, I think the distinction I was scanning (poorly) for is the situation where you have the topology change while you're serializing your snapshot. If a route has a change when in the midst of serializing a snapshot, what do you do? Probably not pause all route monitoring until we're done - or at least that's my hope. So, this would mean that we'd drop the new TLV in this case? When this is going into an MRT file in the traditional way for a new dump file, this is less of a problem. The more confusing case is the live monitoring situation. As an example of how this behavior could differ in an implementation, Juniper's implementation of BGP permits routes in the rib-out to be prioritized into a number of user-configured queues. Refreshes may be placed in a different queue than topology changes. This is beneficial to ensure that a refersh doesn't enqueue a large number of prefixes for advertisement and block something important behind the refreshes. -- Jeff _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
