Tony - I am motivated to send an additional response because I believe there are a set of facts on which we should be able to agree - but the words which have thus far been used to characterize behaviors are misleading - in particular your statement that HSNP hash collisions are:
"exactly analogous to the situation with CSNPs". As we have both discussed in this thread, it is possible (though unlikely) that during LSP transmission an LSP is received which matches that in the receiver’s database i.e., same (LSPID, sequence #, checksum) but has different data. This could occur because of corruption during transmission which does not alter (LSPID, sequence #) but (unluckily) leaves the same checksum as still valid for the corrupted data. It might also occur if a node restarts, generates a new version of an LSP which matches that of a stale LSP from its previous incarnation in (LSPID, sequence #, checksum) but differs in some portion of the data. (This latter case is limited to small LSP sequence numbers). But neither of these unlikely events has anything to do with CSNPs (or HSNPs). The collision is a vulnerability in the LSP flooding procedure which cannot be detected or corrected by CSNPs or HSNPs. (NOTE: More on how to close this vulnerability below.) What is introduced by the use of HSNPs is something quite different. A new hash calculation is introduced which summarizes the (LSPID. Sequence #, checksum) tuples for (a portion of) the LSPDB. This introduces the possibility that the hash calculated over a range of LSPs by two neighbors might match even though the state of the LSPDB on the neighbors for that range differs. This (admittedly unlikely) possibility exists with HSNPs - does not exist with CSNPs as they do not such hash calculation. We may have different opinions on the significance of this - but we should be able to agree that this is a new vulnerability introduced by HSNPs. I hope we have agreement on the above. My original post was only meant to express my opinion as regards whether HSNPs are a desirable solution. Given the added vulnerability and the likelihood that at scale the compression benefits of HSNPs will not be realized (see my original post for more details on that) I am not enthused about the HSNP proposal. I understand that you feel differently. Thanx for continuing to listen. Les Additional note: If we wanted to eliminate the LSP flooding vulnerability, we would need to amend the procedures to be followed when receiving an LSP that matches an existing LSP in the receiver’s database (i.e., same (LSPID, sequence #, checksum). ISO 10589 7.3.16.2 would need to be amended to say something like: <snip> If (LSPID, Sequence #, checksum) match the receiver should perform a comparison of the data in the received LSP to that in the matching LSP currently stored in the receiver’s database. If there is any difference the receiver should: o purge the LSP if the originator of the LSP is some other system o increment the sequence # and flood a new version of the LSP if the receiver is the originator of the LSP, <end snip> If you want to further discuss whether such an amendment to the spec is worth doing, please start a separate thread. I am open to the idea of doing so … From: Tony Li <[email protected]> On Behalf Of Tony Li Sent: Monday, October 6, 2025 10:54 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, When an LSP is received, the receiving IS validates the checksum. If the checksum is invalid, the LSP is discarded – which means the transmitter will be forced to retransmit (SRM bit is not cleared). True, but irrelevant. So an LSP with invalid checksum will never be placed in the receiver’s database. ISO 10589 7.3.14.2e. True, but also irrelevant. Which means if a CSNP entry with that invalid checksum is received the receiver will not find a match in its database and will follow ISO 10589 7.3.16.2. We are not discussing CSNPs with invalid checksums. If an LSP is received, checksum is validated, but the data in the LSP is in some way different than what is in the LSP in the transmitters DB, then we still have the actual TLV content which is in some way corrupted. In a robust implementation the corrupt information would be detected and not used. We are not discussing LSP corruption here. Now, you seem to be trying to equate this last case with a hash collision in an HSNP where the range of LSPs covered by an HSNP advertisement incorrectly collides with the hash calculated by the receiver over the same range. But in such a case, we have one or more LSPs which have not been synced between the two systems. Either an LSP doesn’t exist at all in one database or a different version of that LSP exists – and you are trying to say that lack of an entire LSP is equivalent to having the same LSP in both databases when some bits in the data are different. No. That’s not what I’m saying at all. Please reread my mail. The point is simple: CSNP’s are not 100% reliable. There can be checksum collisions. But I am not warming to the idea of introducing new ways to compromise flooding integrity in the name of efficiency. Your opinion is duly noted. We are not compromising flooding integrity at all, but if you will not discuss reality, I cannot help you. Regards, Tony
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
