Hi Jeff,
Maybe this shows the importance to merge draft-younsi-grow-bmp-snts into
draft-ietf-grow-bmp-tlv so to get avail of sequence numbers. In the case
you depict - an update is coming while a snapshot is ongoing -
sequencing can help giving the proper ordering. The whole snapshot
having one single sequence number and any, potentially interleaved,
update getting the sequence number incremented.
Some kind of buffering & re-ordering should take place at some point; it
will be nice as part of draft-lucente-grow-bmp-offline and
draft-petrie-grow-mrt-bmp to determine where / when this effort should
come in place: while receiving data at the collector, before the
collector serializes into MRT or leave it as an exercise for a MRT
library that people can use to consume a MRT stream.
Paolo
On 6/11/25 21:02, Jeffrey Haas 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]
