Tony/Shraddha –
Thanx for the replies.
As I see it, fundamentally you are trying to change the current flooding model
– which is per LSP – to be “per LSP Batch”.
Not sure I want to go down that road…and there are certainly strategies
associated with LSP Generation that can minimize the occurrence of this problem.
I think a better way to start this discussion would be for you folks to go into
more detail on the problematic cases and why they cannot be addressed at the
source.
I would hope/ask that you focus the discussion there to start with – rather
than starting with a solution which even you folks admit needs significantly
more work.
Thanks.
Les
From: Tony Przygienda <[email protected]>
Sent: Monday, July 13, 2026 1:59 AM
To: Hegde, Shraddha <[email protected]>
Cc: Les Ginsberg (ginsberg) <[email protected]>; [email protected]
Subject: Re: [Lsr] Re: New draft on Originator Sequence Number Checksum
for 3. Les, thanks for comments. Despite having implemented (obviously) pretty
much e'thing you mention and even more clever things to deal with the fragment
movement we still encounter the problem in the field and hence propose this
TLV. Some affected operators may chime in. We do not only see link flaps but
other problems manifesting due to fragment shifting BTW.
We have also a proposal dealing perfectly with the transaction order/no delay
necessary etc but it's significantly more complex and we judged that this is
the goldi locks between extreme complexity and something that should improve
the situation noticeably from the current state. From the more complex proposal
I suggested and we are discussing through possibly including the transaction ID
which will solve your example as in
fragment 4 -> transaction ID 1
fragment 6 -> transaction ID 2
so when 6 floods in first and then 4 the node knows that it has still to use
the 6 to validate the checksum and 4 with ID 1 checksum does not matter.
tricky part are of course reboots/attacks and so on and very high frequency
fragments being regenerated for which the timer is the simplified heuristic
since the complete solution is practically speaking much more complex than this
draft
-- tony
On Mon, Jul 13, 2026 at 6:49 AM Hegde, Shraddha
<[email protected]<mailto:[email protected]>>
wrote:
Hi Les,
Thanks for detailed review and valuable comments.
1. This is a valid scenario and as per the current proposal there will be a
delay in computing SPF , eventually the timeout will cause the SPF to be
triggered.
This delay is not desirable and the proposal can be improved to do better in
this case.
My thought is to indicate the fragment movement case in the TLV with a flag and
let receiver apply delay only when needed.
Will update draft once window opens.
1. I agree when there are unrelated changes to multiple LSPs the existing
mechanisms should be good enough
1. I don't agree the current mechanisms are good enough to handle the
fragment movement case. There are a number of new TLVs/sub-TLVs being proposed
in IETF and every time a new feature is to be enabled in the network, operator
has the risk that it might cause fragment movement and cause disruptions in the
network. The sender deterministically knows the fragment movement got triggered
and can do better to let other nodes gracefully handle it.
Rgds
Shraddha
________________________________
From: Les Ginsberg (ginsberg)
<[email protected]<mailto:[email protected]>>
Sent: Wednesday, July 8, 2026 5:33 AM
To: Hegde, Shraddha <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>
Subject: RE: New draft on Originator Sequence Number Checksum
Shraddha –
Some questions/comments regarding this draft.
1)I am struggling to see how what you propose works in the following scenario.
Node A currently has generated/flooded 10 LSPs at Level-1.
At Time T0, it updates LSP A.00-04 , recomputes the OSNC – which is “1234” –
and includes that in the new version of A.00-04 and floods the LSP.
A short time later – say T0 + 20 ms - Node A now updates LSP.00-06 with
information unrelated to the previous change to LSP #4.
It recomputes the OSNC – which is now “5678” – and includes that in the new
version of A.00-06 and floods that LSP.
You cannot control the order in which the LSP updates are received as the LSPs
are propagated through the area.
Some nodes may receive LSPs in the following order:
A.00-04(OSNC 1234)
A.00-06(OSNC 5678)
Nodes which try to validate their database against the received OSNC will
succeed as they process each received LSP.
But some nodes may receive LSPS in the following order:
A.00-06(OSNC 5678)
A.00-04(OSNC 1234)
Nodes which receive the LSPs in this order will fail the OSNC validation.
The problem here is that the receivers do not know the order in which the LSPs
were generated. So any set of LSPs which were not part of an “atomic update” on
the originator will have different OSNC values and receivers don’t know which
one is the latest.
How are you intending to address this problem??
2)The problem you are trying to address (updates to a single object – such as a
neighbor) which impact multiple LSPs is not the only case in which updates to
multiple LSPs may occur.
A node may (for example) add a new neighbor to one LSP and a new prefix to
another LSP. There is far less motivation to treat these as an atomic update –
yet you are imposing requirements on the receiver that these two unrelated
updates cannot be processed by the receiver until/unless both are received.
3)The issue of movement of information about a single object is well known and
was considered even in ISO 10589. Section 7.3.4.4 states:
“Once a particular adjacency has been assigned to a particular LSP Number, it
is desirable that it not be moved to another LSP Number. This is because moving
an adjacency from one LSP to another can cause temporary loss of connectivity
to that system. This can occur if the new version of the LSP which originally
contained information about the adjacency (which now does not contain that
information) is propagated before the new version of the other LSP (which now
contains the information about the adjacency).
…
If it is necessary to move an adjacency from one LSP to another, the SRMflags
(see 7.3.15) for the two new LSPs shall be set as an atomic action.”
In addition, implementations have for many years included the capability to
flood a limited number of LSPs “back-to-back” as a means of insuring that when
other routers in the network trigger the Decision process, they would be more
likely to have all the updated topology information.
Also, implementations provide the ability to delay the start of the Decision
process by a modest amount of time (e.g., 50 milliseconds) to allow time for
multiple LSPs to be received before a new SPT is calculated.
All of this has been demonstrated to reliably improve convergence.
So, while the concern you raise regarding moving an object such as a neighbor
from one LSP to another is legitimate, it has already been considered in
existing implementations.
Given the added complexity the draft’s solution imposes on receivers, the
difficulties in dealing with cases when the order of receipt does not match the
order of generation, and the significant potential for negatively impacting
convergence – it is difficult to be enthused about this proposal.
It seems to me to be an example where “striving for perfection is the enemy of
the good”.
Les
From: Hegde, Shraddha
<[email protected]<mailto:[email protected]>>
Sent: Monday, July 6, 2026 10:05 PM
To: [email protected]<mailto:[email protected]>
Subject: [Lsr] New draft on Originator Sequence Number Checksum
WG,
A new draft is posted on Originator Sequence number
The proposal defines a new TOP level TLV that carries checksum of LSP-ID,
sequence number and size of all the self originated LSPs. This is to be used by
the receiver to get the information about the senders database. Pls review
details from the draft below
https://datatracker.ietf.org/doc/draft-hegde-lsr-isis-osnc/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hegde-lsr-isis-osnc/__;!!NpxR!jKnJ-5wj-zweoNDtMG8kZVwCP1dGlm2X1VJDpQULPfi9AxNixaFa45znEdKVp0w54EJC1KVHFS5y0HgMdufNTKoLohX_v_Vq$>
Shraddha Hegde
Distinguished Engineer
HPE Networking
E: [email protected]<mailto:[email protected]>
[cid:[email protected]]
_______________________________________________
Lsr mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
