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]
