[Ndn-interest] Network inconsistency and NLSR sequence numbers

[David R. Oran]

This sounds like a CLASSIC link state algorithm design bug. I’m 
frankly pretty surprised the NLSR team didn’t learn from correct link 
state protocols like ISIS.

Maybe it’s because of inappropriate reliance on Chronosync rather than 
doing a bespoke flooding protocol?

In addition to sequence numbers, you need an AGE field to time out old 
LSPs and something like CSNPs to recover state faster than the age 
timeout.

I’d be interested in whether this is just some code bug and things are 
actually properly designed.

(BTW: modulo sequence spaces are neither necessary nor desirable for 
link stat protocols - again look at ISIS which uses a simple linear 
space, avoiding classic bugs like the old Arpanet “Christmas” 
problem.)

On 22 Aug 2019, at 7:24, Viktor S. Wold Eide via Ndn-interest wrote:

> 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
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

DaveO