<div dir="auto">I sort of remember that when we were building ChronoChat on top of ChronoSync we always append random strings to the user names to avoid confusing the sync layer. This could also be applied to NLSR.<div dir="auto"><br></div><div dir="auto">Essentially we need something to differentiate the old router instance from the new. Under NDN design principle the "thing" that differentiates them must be reflected in the name. It could be either random number or a timestamp (assuming you can recover old timestamp when you reinstall the router instance).</div><div dir="auto"><br></div><div dir="auto">Wentao</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 22, 2019, 8:44 AM Ashlesh Gawande (agawande) <<a href="mailto:agawande@memphis.edu">agawande@memphis.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Just one sequencing file is used to store three separate numbers now (including 0.5.0 release that is under test here).</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
This is a known design issue from "<a href="https://named-data.net/wp-content/uploads/2018/05/secure_link_state_routing_protocol_ndn.pdf" title="https://named-data.net/wp-content/uploads/2018/05/secure_link_state_routing_protocol_ndn.pdf" id="m_-2358685907573908175LPlnk343367" target="_blank" rel="noreferrer">A
 Secure Link State Routing Protocol for NDN</a>" paper:</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
"Another problem is that the sequence number file where NLSR records its LSA version numbers can become corrupted during operation or during reboot, which can cause a router to inject LSAs with older version numbers than the ones already distributed. In this
 case, the new LSAs will be discarded by other routers, so this router cannot become part of the topology. It is our ongoing work to address this problem."</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
ChronoSync/PSync (NLSR can switch b/w either as of 0.5.0) does not remove old data from sync but that is a separate problem (some discussion here about adding timestamp to LSAs:
<a href="https://redmine.named-data.net/issues/3593" id="m_-2358685907573908175LPNoLP997518" target="_blank" rel="noreferrer">https://redmine.named-data.net/issues/3593</a>). Because even if sync did remove obsolete data by some mechanism, NLSR still holds onto the sequence number information (but maybe then NLSR
 could also let go of old data after notification of removal from sync).<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Ashlesh<br>
</div>
<div id="m_-2358685907573908175appendonsend"></div>
<hr style="display:inline-block;width:98%">
<div id="m_-2358685907573908175divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Ndn-interest <<a href="mailto:ndn-interest-bounces@lists.cs.ucla.edu" target="_blank" rel="noreferrer">ndn-interest-bounces@lists.cs.ucla.edu</a>> on behalf of David R. Oran <<a href="mailto:daveoran@orandom.net" target="_blank" rel="noreferrer">daveoran@orandom.net</a>><br>
<b>Sent:</b> Thursday, August 22, 2019 10:18 AM<br>
<b>To:</b> Viktor S. Wold Eide <<a href="mailto:viktor.s.wold.eide@gmail.com" target="_blank" rel="noreferrer">viktor.s.wold.eide@gmail.com</a>><br>
<b>Cc:</b> ndn-interest <<a href="mailto:ndn-interest@lists.cs.ucla.edu" target="_blank" rel="noreferrer">ndn-interest@lists.cs.ucla.edu</a>><br>
<b>Subject:</b> Re: [Ndn-interest] Network inconsistency and NLSR sequence numbers</font>
<div> </div>
</div>
<div class="m_-2358685907573908175BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="m_-2358685907573908175PlainText">This sounds like a CLASSIC link state algorithm design bug. I’m
<br>
frankly pretty surprised the NLSR team didn’t learn from correct link <br>
state protocols like ISIS.<br>
<br>
Maybe it’s because of inappropriate reliance on Chronosync rather than <br>
doing a bespoke flooding protocol?<br>
<br>
In addition to sequence numbers, you need an AGE field to time out old <br>
LSPs and something like CSNPs to recover state faster than the age <br>
timeout.<br>
<br>
I’d be interested in whether this is just some code bug and things are <br>
actually properly designed.<br>
<br>
(BTW: modulo sequence spaces are neither necessary nor desirable for <br>
link stat protocols - again look at ISIS which uses a simple linear <br>
space, avoiding classic bugs like the old Arpanet “Christmas” <br>
problem.)<br>
<br>
On 22 Aug 2019, at 7:24, Viktor S. Wold Eide via Ndn-interest wrote:<br>
<br>
> Hi Junxiao,<br>
><br>
> Thanks a lot for the quick reply.<br>
><br>
> Having to backup sequence numbers sounds like a flaw in the protocol<br>
> design, but I guess there are some reasons for the choices?<br>
><br>
> Regarding your suggestion using a random UUID, let's hope some of the<br>
> NLSR developers can share their viewpoint?<br>
><br>
> Regarding your suggestion that a node might query the network / other<br>
> nodes about it's own sequence number. I understand that it might fix<br>
> the problem for some cases, but I expect that this will lead to other<br>
> and more severe problems and errors. What if other nodes do not agree<br>
> and answer with different numbers? It seems the problem quickly gets<br>
> worse.<br>
><br>
> Could this be fixed using a sliding window approach for sequence<br>
> numbers? That is, if and when a node experiences segment numbers<br>
> outside some valid window (to far behind or to far ahead for node X)<br>
> this is interpreted as a need to re-synchronize / accept a new<br>
> sequence number window for node X? Or will this approach not work? If<br>
> not, what are the issues?<br>
><br>
>> From looking very quickly at the nlsr source code, it appears that<br>
> sequence numbers are uint32_t, at least in some places (lsa.hpp),<br>
> while uint64_t in other places (lsdb.cpp). If 32-bit, or if starting<br>
> at a random number, some wrap-around handling appears necessary<br>
> anyway?<br>
><br>
> As written initially, I would expect that nodes must forget / delete /<br>
> reset knowledge of other nodes in some cases, and at least after some<br>
> time. Is this the case, or will a node be remembered forever,<br>
> potentially?<br>
><br>
> Best regards<br>
> Viktor S. Wold Eide<br>
> _______________________________________________<br>
> Ndn-interest mailing list<br>
> <a href="mailto:Ndn-interest@lists.cs.ucla.edu" target="_blank" rel="noreferrer">Ndn-interest@lists.cs.ucla.edu</a><br>
> <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" target="_blank" rel="noreferrer">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br>
<br>
DaveO<br>
_______________________________________________<br>
Ndn-interest mailing list<br>
<a href="mailto:Ndn-interest@lists.cs.ucla.edu" target="_blank" rel="noreferrer">Ndn-interest@lists.cs.ucla.edu</a><br>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" target="_blank" rel="noreferrer">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br>
</div>
</span></font></div>
</div>

_______________________________________________<br>
Ndn-interest mailing list<br>
<a href="mailto:Ndn-interest@lists.cs.ucla.edu" target="_blank" rel="noreferrer">Ndn-interest@lists.cs.ucla.edu</a><br>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" rel="noreferrer noreferrer" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br>
</blockquote></div>