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?
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.
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).
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.
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.
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.
Les
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
