inline
On Wed, Jul 15, 2026 at 7:39 AM Les Ginsberg (ginsberg) <[email protected]>
wrote:
> 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
>
it really depends what you define as "convergence". if you consider
computation triggered with anything that arrived as convergence generating
any kind of results then it's not "convergence", it's possibly just random
stuff firing on inconsistent view of topology when fragments interdepend,
consider
fragment#1: slides adjacency out
fragment#2: slides same adjacency in
Node A gets 1 but not 2 and computes, link is down
Node B gets 2 but not 1 and computes, same link is visible twice
if that's convergence then it's for OSPF for A a link flap and for node B
seeing actually LSP/TLV it should throw away since it's incorrect encoding
of the adjacency
So, yes, it's really fast but neither good nor cheap since the resulting
effect can lead to multi-seconds (or worse) massive reconvergence of things
that depend on IGP's view of topology. And it does today in our experience.
if you want fast you have it already today, but unless I see a solution
that makes stuff less "fast" but good and cheap by preventing spurious
flaps (and other effects when interdependent fragments don't arrive as a
"batch" or "transaction" as better word) we simply disagree what
"convergence" is and as I said, I don't think we will make any further real
progress in this thread
What you say however is valid in the sense that we have to give thought to
the fact that we do not want change on a single fragment block a previous
change on a fragment if both are not related and never will. I can imagine
multiple ways to achieve that in the encoding but I'm more than happy to
hear ideas from others first. However, the discussion gets tricky quickly
since a change in a single fragment _may_ have implication on change in
single another fragment at a later date, as quick example
fragment #0@1: capability X *not* supported, single fragment changed,
nothing here
fragment #0@2: capability X supported, single fragment changed, nothing
here
fragment #2@1: adding some TLVs that are valid only _if_ capability X is
supported
if fragment#2@1 shows up but #1@2 is not there yet the TLV makes no sense
at best, causes damage at worst. Yes, ultimately e'thing will settle
assuming flooding works fine but in the meantime interesting effects can
arise we have no solution for today
-- tony
>
>
> 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]
