Tony – We have some disconnect. The checksum contained in the header of an LSP is computed by the node which generates the LSP and never altered/recomputed by receiving nodes. It is simply stored on receipt. See ISO 10589 Section 7.3.11.
So, if the checksum reported in an LSP entry in a CSNP does not match the checksum associated with that same LSP (i.e., same source ID. Sequence #) for that LSP in the receiver’s database, this will absolutely be detected by the receiver of a CSNP. The procedures defined in ISO 10589 Section 7.3.16.2 then apply. This cannot be done when receiving an HSNP because you don’t have the checksum associated with an individual LSP – you only have the hash associated with a range of LSPs – which has to be compared against a hash computed by the receiver for whatever range of LSPs are indicated in the HSNP. So CSNP and HSNP functionality are not comparable in this regard. Les From: Tony Li <[email protected]> On Behalf Of Tony Li Sent: Monday, October 6, 2025 12:22 PM To: Les Ginsberg (ginsberg) <[email protected]> Cc: Tony Przygienda <[email protected]>; [email protected]; lsr <[email protected]> Subject: Re: [Lsr] Further Comments on draft-prz-lsr-hierarchical-snps Les, The TLVs of the LSP are not contained in CSNPs. I do not understand your point at all. CSNPs only contain the LSP lifetime, ID, Sequence number, and checksum. Please see ISO 10589, section 9.10 and 9.11. [LES:] Correct. And you have that info for each LSP in the sender’s database. The PDU checksum is only used to verify that data has not been corrupted during transmission/reception. It is not compared against a checksum on the receiver. This is incorrect. When a CSNP is received, the ID, sequence number and checksum are compared against the receiver’s database. If there is a mismatch, then there is a presumption that something is incorrect and an LSP transmission is requested. A PDU checksum collision would imply that some data in the LSP entry TLVs was corrupted – which would mean that some LSP entry data (LSPID, seq #, checksum, lifetime) was altered in a way that was not detected by the PDU checksum – but you would still have a modified LSP entry which would not match what the receiver has in its database. That’s one case. It’s also possible to have a checksum collision between two correctly formatted PDUs. Worse yet, this can happen if the sequence number is the same. Yes, the odds are extremely low, but there is no mechanism that will preclude this. One scenario that might generate this is a node that reboots (perhaps during a software upgrade) and generates a new version of its LSP with a PDU with the matching sequence number and checksum but slightly different contents. Again, odds are extremely low that there is a checksum collision, but they are not zero. CSNPs will not detect or correct this. With HSNP you do not have per LSP information – so if a hash collision occurs you cannot tell that there is a difference in the LSPDB even when there is. That is correct. This is exactly analogous to the situation with CSNPs: if there is a hash collision, you’re going to have a bad day. What we can do is to make the odds of that hash collision acceptably small. Thus, the real debate is what is an acceptable rate of hash collisions and what is an appropriate hashing function to achieve that goal? I will happily stipulate that the rate of hash collisions for HSNP should be lower than for CSNPs, as the blast radius is larger. T
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
