Hi Robert, Unfortuantely, there are many LANs still deployed. We cannot deprecate support for them anytime within the foreseeable future.
T > On Oct 8, 2025, at 12:38 PM, Robert Raszuk - robert at raszuk.net > <[email protected]> wrote: > > > > How do you deal with LANs? > > Would we not benefit the protocol if we give up support for LANs in ISIS ? > > Yeh that question is a bit outside of the scope of this thread, but I just > could not resist to send it. For me p2p ISIS is all what it needs, but surely > I am perhaps a bit biased. > > Thx, > R. > > On Wed, Oct 8, 2025 at 9:21 PM Tony Li <[email protected] > <mailto:[email protected]>> wrote: >> >> 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 >>> <http://raszuk.net/> <[email protected] >>> <mailto:[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]
