Tony - From: Tony Li <[email protected]> On Behalf Of Tony Li Sent: Monday, October 6, 2025 11:25 AM 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
Hi Les, Please see inline. If you do not reply, then we assume that you have seen the error of your ways and subsequently agree. Silence is assent. [LES:] I think we all have experience on how dangerous an assumption that can be – but I won’t debate… In this case I thought we had both expressed our POV and I didn’t have more to say. If you disagree and do not reply, we have no way of knowing that we do not have consensus. If you choose not to debate, that is your choice, but then to reiterate the exact same points months later is a disservice to the working group. The working group can only make progress when all parties participate and behave professionally. [LES:] Life has taught me that “silence != agreement”. But I note your POV and you now clearly know that I do not agree. 😊 This can happen because the Fletcher checksum, like any hashing function, has hash collisions. They’re rare, but they can happen. This means that the legacy mechanism is NOT 100% reliable, just close to it. I will happily stipulate that it is Super Good Enough. [LES:] So, that was my original understanding – but Tony P’s response (today) made me think perhaps you were talking about the different checksum case. As regards the same checksum case, my point was/is that for standard IS-IS PDUs (SNPs or LSPs) if the data in the PDU differs you still have the actual TLVs themselves. If something has been corrupted that is not detected by the PDU checksum, we still have multiple detection mechanisms as a result of data corruption. For example: * Bad TLV code * Bad TLV length * Bad TLV data You don’t have that with HSNPs. 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. 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. 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. Les We are debating the corner cases of the CSNP and HSNP mechanisms, nothing else. T
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
