Hello Jeff, Reshad,
I think you responded the question already. Remember the workflow for a new consumer is: if it doesn’t have the current snapshot, it needs to wait or get the latest one from the history and then catch up with the live data. If the snapshots and the live data are in the same topic, there is little we can do, and consumers would have to “wait”. If we run the snapshots and the live feed in different topics, then, as Jeff tell, it is less risky.. having a single topic makes everything a bit simpler sometimes, so we’ll explore this scenario later in the process of the draft. Camilo From: Reshad Rahman <[email protected]> Reply to: Reshad Rahman <[email protected]> Date: Thursday, 6 November 2025 at 16:09 To: Jeffrey Haas <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [GROW] Re: Snapshots and mixed use case implications Resent from: <[email protected]> Resent to: <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]> Resent date: Thu, 6 Nov 2025 13:09:55 -0800 (PST) Hi Jeff, > 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. I would hope so too. Ideally the snapshot can be paused, i.e. route-monitoring should take priority over snapshot. But I do realize this might be "difficult" for some implementations/designs. Regards, Reshad. On Thursday, November 6, 2025 at 03:13:50 PM EST, Jeffrey Haas <[email protected]> wrote: 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]
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
