Tony – 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). So an LSP with invalid checksum will never be placed in the receiver’s database. ISO 10589 7.3.14.2e. 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.
If the received checksum in the LSP is valid then the LSP will be put in the receiver’s LSPDB. If an LSP entry is subsequently received with mismatched checksum, then ISO 10589 7.3.16.2 applies. 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. 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. I have a hard time treating those two conditions as “equivalent”. As far as “If there is a mismatch, that is a clear indication that there is an underlying mismatch in the LSDB and we walk down the hiearchy recursively to determine the specific disconnect and then correct it.” remember that we are discussing the “hash collision” case – which means we don’t know there is a mismatch so nothing will trigger the remedial steps you describe. I suspect we still do not agree. But I am not warming to the idea of introducing new ways to compromise flooding integrity in the name of efficiency. Les From: Tony Li <[email protected]> On Behalf Of Tony Li Sent: Monday, October 6, 2025 7:48 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, We have some disconnect. Indeed we do. 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. Almost true. The receiving node MUST verify the checksum. I agree with never altered. This, however, is wholly irrelevant to the subject at hand. 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. Correct. Also irrelevant. The key point is that the checksum MAY match even tho the contents of the LSP are different. Thus, a CSNP is not 100% reliable, as you claimed. 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. Having individual LSPs in an HSNP would cause it to not scale, which would wholly violate the purpose of the design. If there is a mismatch, that is a clear indication that there is an underlying mismatch in the LSDB and we walk down the hiearchy recursively to determine the specific disconnect and then correct it. At the lowest level, we are back to sending CSNPs for specific ranges of LSPs. So CSNP and HSNP functionality are not comparable in this regard. They are not meant to be ‘comparable’. The point of the HSNP is to be more efficient by summarizing more of the LSDB in fewer bits on the wire. Replicating CSNP functionality would be silly. Regards, T
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
