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]
