[Ndn-interest] Network inconsistency and NLSR sequence numbers

[Viktor S. Wold Eide]

Hi Junxiao,

Thanks a lot for the quick reply.

Having to backup sequence numbers sounds like a flaw in the protocol
design, but I guess there are some reasons for the choices?

Regarding your suggestion using a random UUID, let's hope some of the
NLSR developers can share their viewpoint?

Regarding your suggestion that a node might query the network / other
nodes about it's own sequence number. I understand that it might fix
the problem for some cases, but I expect that this will lead to other
and more severe problems and errors. What if other nodes do not agree
and answer with different numbers? It seems the problem quickly gets
worse.

Could this be fixed using a sliding window approach for sequence
numbers? That is, if and when a node experiences segment numbers
outside some valid window (to far behind or to far ahead for node X)
this is interpreted as a need to re-synchronize / accept a new
sequence number window for node X? Or will this approach not work? If
not, what are the issues?

>From looking very quickly at the nlsr source code, it appears that
sequence numbers are uint32_t, at least in some places (lsa.hpp),
while uint64_t in other places (lsdb.cpp). If 32-bit, or if starting
at a random number, some wrap-around handling appears necessary
anyway?

As written initially, I would expect that nodes must forget / delete /
reset knowledge of other nodes in some cases, and at least after some
time. Is this the case, or will a node be remembered forever,
potentially?

Best regards
Viktor S. Wold Eide