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]> Sent: Monday, July 6, 2026 10:05 PM To: [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/ Shraddha Hegde Distinguished Engineer HPE Networking E: [email protected]<mailto:[email protected]> [cid:[email protected]]
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
