Tony – Thanx for the prompt response. Some things are addressed by my reply to Tony Li. Please see inline.
From: Tony Przygienda <[email protected]> Sent: Friday, July 18, 2025 12:54 AM To: Les Ginsberg (ginsberg) <[email protected]> Cc: [email protected]; lsr <[email protected]> Subject: Re: [Lsr] Review comments for draft-prz-lsr-hierarchical-snps-00: High Level Concerns Hey Les, good you read it ;-) [LES:] Of course! 😊 I would have read it sooner if you had announced to the list that you published it. I did not realize it existed until I saw it on the agenda. On 17 Jul 2025, at 23:10, Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>> wrote: Thanx for taking on this topic. This is an area in which we agree that the protocol can be improved - so it is good that you have "started the ball rolling". Here are some High Level Concerns with what is proposed: 1)The uniqueness of the calculated hash is an essential component for this to work. Given that you are using a simple XOR on a 64 bit number - and then "compressing" it to 32 bits for advertisement - uniqueness is NOT guaranteed. The danger of false positives (i.e., hashes that match when they should not) would compromise the solution. Can you provide more detail on the efficacy of the hash? First, no hash will guarantee uniqueness. Hashes are not bijective but surjective, that’s their nature XOR was chosen as one of only two known self-inverse hashes which will allow for “adjusting” if an LSP range is off and updating caches on e.g. while node in internal LSDB in extremely fast manner. We could go the way of saying e.g. , every 5th time send CSNPs and not compressed. Yeah, we are tap dancing around CAP paradigm, the higher availablity and partitioning the harder is to guarantee real time consistency 2)Do we need a more sophisticated hash calculation in order to guarantee uniqueness? If the argument is the update process is already reliable even without CSNPs/HSNPs - that HSNPs are simply an optimization and don't have to be 100% reliable, then I think this implies that periodic CSNPs are not needed at all. And if the hash has a significant possibility of being non-unique, relying on HSNPs during adjacency bringup might actually be a hindrance, not a help. Hashes are always surjective and any _clever_ hash function will cause lots of computation on LSDB updates We could say e.g. during adjacency bringup the first go is full CSNP exchange. Valid argument [LES:] That’s not what I am advocating. I am actually advocating for the opposite – that the more important problem to solve is scalability on adjacency bringup – we don’t really need periodic SNPs. 3)I would like to raise the question as to whether we should prioritize a solution that aids initial LSPDB sync on adjacency bringup over a solution which works well after LSPDB synchronization (periodic CSNPs). I surely do NOT want to end up in OSPF IDBX corner ;-) which has proven pretty fragile and hard to implement IME [LES:] OSPF IDBX is solving a different problem – and IS-IS has a solution for that (SA bit as defined in RFC 8706). But here we are trying to address simply the CSNP scale issue – not how we avoid blackholes associated with restart. The need for periodic CSNPs arose from early attempts at flooding optimizations (mesh groups) where an error in the manual configuration could jeopardize the reliability of the Update Process. In deployments where standards based flooding optimizations are used, the need for periodic CSNPs is lessened as the standards based solution should be well tested. Periodic CSNPs becomes the "suspenders" in a "belt" based deployment (or if you prefer the "belt" in a "suspenders" based deployment). I am wondering if we should deemphasize the use of periodic CSNPs? In any case, the size of a full CSNP set is a practical issue in scale deployments - especially where a node has a large number of neighbors. Sending the full CSNP set on adjacency UP is a necessary step and therefore I would like to see this use case get greater attention over the optional periodic CSNP case. 4)You choose to define new PDUs - which is certainly a viable option. But I am wondering if you considered simply defining a new TLV to be included in existing xSNPs. I can imagine cases - especially in PSNP usage - where a mixture of existing LSP entries and new Merkle Hash entries could usefully be sent in a PSNP to request/ack LSPs as we do today. The use of the hash TLV in PSNPs could add some efficiency to LSP acknowledgments. Ugh, keep things orthogonal rather than making a PSNP some hybrid thing based on this or another especially if old nodes don’t parse it. We have enough codepoints [LES:] See my response to Tony LI. 5)The choice of ranges for the new TLVs depends upon the current state of the LSPDB on the sending node. The definitions you have seem targeted at "periodic CSNPs" where it is reasonable to expect that both neighbors have (nearly) the same LSPDB contents. However, in the case of adjacency bringup, it is likely that there are significant differences in the current content of the LSPDBs on the neighbor - which will make it far more likely that the ranges of nodes chosen in each hash entry will differ between the neighbors - making the strategy less useful for this case. Yeah, so as I write we could say “first shot don’t use HSNP, full CSNP on bringup” [LES:] I think the more significant issue is CSNP scale at adjacency bringup. Les 6)You do not discuss the use of HSNPs on LANs. It would seem intuitive that HSNPs could only be used when all neighbors on the LAN support it. But some discussion of LANs would be desirable. I left it open since broadcast is not much used IME these days and yeah, to be done after we agree on rough scheme Les _______________________________________________ Lsr mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
