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. > 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. 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]
