And why not simply use the same hash function just increase its size, say to 256 bits ?
Isn't it true that the probability of collision significantly (or even exponentially) decreases when hash size grows ? 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.* Thx, Robert On Wed, Oct 8, 2025 at 4:02 PM <[email protected]> wrote: > Hi all, > > [Thinking out loud, so I'm pretty sure I'll regret sending this email ...] > > With regards to hash collision, I'm wondering whether we could benefit > from using a different hash (method/function) per neighbor, and/or over > time. (As a priori it's enough for me to detect my LSDB inconsistency with > a single neighbor) > This requires more computation but assuming that a significant > contribution to collision is the final step (from 64 bits to 32 bits), > rotating a number of bits in one 32-bit int on a per neighbor basis seems > relatively low cost. > > Regards, > --Bruno > > ____________________________________________________________________________________________________________ > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
