Robert, Yes, we can introduce any hashing function that we would like. However, implementation complexity and standardization strongly suggest that we pick one. My personal preference is to use the same Fletcher checksum that IS-IS already uses, as that’s the least amount of new code, but I don’t know if that would match everyone’s reliability criteria.
Using multiple algorithms on the fly would be expensive to implement and darn tricky to debug. How do you deal with LANs? However, maybe the same effect could be achieved by varying a seed for the hash function on a per-link basis. T > On Oct 8, 2025, at 11:20 AM, Robert Raszuk - robert at raszuk.net > <[email protected]> wrote: > > Hi Tony, > > I was under the assumption that we are free to introduce a new hashing > function if really needed (as fallback for subset of mismatched LSPs would > still be there so not sure if this is needed). > > Maybe this fallback needs to be said in bold in the document ... > > Thx, > R. > > On Wed, Oct 8, 2025 at 6:47 PM Tony Li <[email protected] > <mailto:[email protected]>> wrote: >> >> Hi Robert, >> >> Discussions about hashing functions are certainly welcome. >> >> >>> And why not simply use the same hash function just increase its size, say >>> to 256 bits ? >> >> >> You can’t always do that. For example CRC-16 is defined to produce a 16 bit >> result. You can’t just cause it to produce 32 bits. You can shift to >> CRC-32, but that’s a different hashing function. >> >> >>> Isn't it true that the probability of collision significantly (or even >>> exponentially) decreases when hash size grows ? >> >> >> That’s true, assuming good hashing functions. Not true for bad functions. >> >> >>> Besides as draft says there is still fallback to scoped lower level check >>> hence I am not sure if there is any issue with the proposal. >>> >>> And ideally, a hash mismatch should produce not more than a single packet >>> or two with lower level checksums or CSNPs to optimize re-convergence >>> while minimizing amount of packets exchanged. >> >> >> Thanks, >> T >>
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
