Tony –
I agree with what you say below, but...
In a perfect (distributed) world all nodes in the network would receive all LSP
updates within a single "SPF interval" and trigger an SPF at the "same time".
But we cannot guarantee that will happen.
OSNC is trying to mitigate the consequences of a distributed network by trying
to guarantee that no node in the network triggers an SPF until it has received
all of the LSPs in a single "batch" as defined by the originator. But you still
can't guarantee that the batch will arrive at every node at the "same time".
And what is the definition of a “batch”. You cannot limit a batch simply to
cases where you move a single TLV. To do so would require you to delay any
other updates until you were “certain” that the TLV move had been processed
network-wide – which you have no way to determine.
Consider Node A which has generated 10 LSPs - and updates two of them (quickly)
in the following order:
A.00-2 includes an update to a prefix admin tag (minimal impact on convergence)
A.00-4 includes a new adjacency (significant impact on convergence)
NOTE: Does not matter whether you treat this as two different batches
(different OSNC in each LSP) or as one batch (same OSNC in both LSPs).
Nodes B and C are multiple hops away from Node A - potentially on different
flooding paths.
We have the following possible combinations:
B supports OSNC - C does not. [B(OSNC) C]
B and C support OSNC [B(OSNC) C(OSNC)]
Neither B nor C supports OSNC [B C] (AKA legacy)
Case 0: A.00-2 and A.00-4 arrive at B and C at the "same time".
All combinations behave the same
Case 1: A.00-4 arrives at B and C at the "same time" but A.00-2 is delayed in
arriving at both nodes.
[B(OSNC) C] Node C Converges faster than Node B
[B(OSNC) C(OSNC)] Both nodes delay convergence
[B C] Both nodes converge quickly
Conclusion: OSNC has not helped. Partial deployment makes things worse
Case 2: A.00-2 arrives at B and C at the "same time" but A.00-4 is delayed in
arriving at node B only.
{B(OSNC) C] Node C Converges faster than Node B
[B(OSNC) C(OSNC)] Both nodes delay convergence
{B C] Both nodes converge quickly
Conclusion: OSNC has not helped. Partial deployment makes things worse
No doubt there are other examples – some of which may be more favorable to OSNC
- but the point here is that there are cases where partial deployment can make
things worse.
Adding complexity and not being able to guarantee improved results is not a
winning combination.
Les
From: Tony Li <[email protected]> On Behalf Of Tony Li
Sent: Tuesday, July 14, 2026 5:02 PM
To: Les Ginsberg (ginsberg) <[email protected]>
Cc: Tony Przygienda <[email protected]>; Hegde, Shraddha
<[email protected]>; [email protected]; [email protected]
Subject: Re: [Lsr] New draft on Originator Sequence Number Checksum
Hi Les,
\Well no. If some nodes in the network do NOT use LSPs they receive for several
seconds while other nodes use them immediately this will certainly negatively
impact convergence. That has been clearly demonstrated in real networks in the
past.
I don’t see how you can safely enable what you propose unless all nodes in the
area support it.
I’m not following this line of reasoning.
Today, thanks to the vagaries of flooding, different segments arrive at
different times. There’s not a lot that the transmitter can do to ensure that
the intermediate nodes do The Right Thing, whatever that may be. Different
implementations will SPF at different times, creating inconsistent results. In
other words, things are not safe today.
The whole point of this exercise is to try to help everyone align on
convergence. What we’d really like is for everything to flood and then somehow
magically everyone SPFs at the exact same time. Unfortunately, this only
happens at Hogwarts.
The proposal on the table is to convey some amount of temporal dependency so
that receivers can make a slightly more intelligent decision about when to SPF.
I’m not seeing how more information makes the situation worse.
Cheers,
Tony
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
