<div dir="ltr">On Mon, Jun 12, 2017 at 11:11 AM, Albert López <span dir="ltr"><<a href="mailto:alopez@ac.upc.edu" target="_blank">alopez@ac.upc.edu</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div class="m_-7264753817308079217moz-cite-prefix">Dear all, <br>
<br>
<font face="monospace">From my point of view I think that it
doesn't matter if we start the refresh of the mapping just when
the timer expires. It will make the code quite more easy.<br>
What I would do is:<br>
<br>
We call the function "mc_entry_expiration_timer_cb" when the
entry is going to be expired. This function should check when
was the last time we had a packet for that map cache entry. If
the time is more than X, we remove the entry otherwise we call a
new function that will do somthing similar to this:<br>
<br>
   timer_arg = timer_map_req_arg_new_init(<wbr>mce,src_eid);<br>
   timer =
oor_timer_with_nonce_new(MAP_<wbr>REQUEST_RETRY_TIMER,xtr,send_<wbr>map_request_retry_cb,<br>
          Â
timer_arg,(oor_timer_del_cb_<wbr>arg_fn)timer_map_req_arg_free)<wbr>;<br>
<br>
What we does this code is to create a new timer that will send a
new map request for the map cache entry. If we don't receive a
map reply after y retries, it will remove the map cache entry,
otherwise it will update the map cache entry with the
information of the map reply. <br>
<br>
The part to obtain when was the last time we had a packet for
that map cache entry is something that should be implemented in
the data plane module. The problem here is that it has been some
changes from the master branch to the new version we are working
with. I think that in that point you should add a new function
in the data_plane_struct to obtain this information but the
implementation of this function will be different for the
current master branch code and the new release code.</font><font face="monospace"> </font></div></div></blockquote><div><br></div><div><br></div><div>Sounds good. It is propably best then for Jose to wait for the new data plane code to become available.</div><div><br></div><div>Best regards,</div><div>-Lori</div><div>Â </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div class="m_-7264753817308079217moz-cite-prefix"><br>
<br>
Best regards<br>
<br>
Albert<br>
<br>
<br>
<br>
El 10/06/17 a les 08:51, Lori Jakab ha escrit:<br>
</div><div><div class="h5">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Fri, Jun 9, 2017 at 11:26 PM, José
Miguel Guzmán <span dir="ltr"><<a href="mailto:jmguzman@whitestack.com" target="_blank">jmguzman@whitestack.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hi Lori, I agree with you.
<div>IMHO, 1) is not so bad, It would help to reduce
delay for the first packet to a forgotten prefix
that reactivates. I am assuming most deployments will
have a few EIDs (<10 in our case)</div>
<div>For 2), I found the function that handles the timer
expiration <font face="monospace">mc_entry_expiration<wbr>_timer_cb</font>.
I will need to review the code to see if it is safe to
call <font face="monospace">handle_map_cache_miss(xtr<wbr>,
dst_eid, src_eid)</font> here. I am confused with
this</div>
<div>
<div><font face="monospace">/* If the EID is not from
a iid net, try to fordward to the PeTR */</font></div>
<div><font face="monospace">if
(lisp_addr_is_iid(dst_eid) == FALSE){</font></div>
</div>
<div><br>
</div>
<div>I am wondering if instead of removing the entry,
and then installing a temporary NOT_ACTIVE entry, is
it not better to keep the same entry in NOT_ACTIVE
status, and use it as it were active (as the last
known mapping).</div>
</div>
</blockquote>
<div><br>
</div>
<div>Well, if a site operator set a certain TTL, that's for
a reason, and we need to respect that, so I think we
should remove or overwrite an expired entry. I would
suggest to do the proactive refresh BEFORE the entry
expires. Say we have a TTL of 1000 seconds, we initiate
the refresh after 990 seconds elapsed, so that the entry
is refreshed already when it would have to be removed.</div>
<div><br>
</div>
<div>-Lori</div>
<div>Â </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><span class="m_-7264753817308079217HOEnZb"><font color="#888888">
<div><br>
</div>
<div>JM</div>
</font></span>
<div>
<div class="m_-7264753817308079217h5">
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
<br>
<div class="gmail_quote">
<div dir="ltr">El vie., 9 jun. 2017 a las 4:00,
Lori Jakab (<<a href="mailto:lorand.jakab@gmail.com" target="_blank">lorand.jakab@gmail.com</a>>)
escribió:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Jose,
<div><br>
</div>
<div>Regardless of the TTL value, one
optimization in the code that could be
made would be to be proactive in
refreshing mappings in the map-cache, so
that active flows don't get packet drops
when the TTL expires. This would need two
things to be implemented:</div>
<div>
<ol>
<li>Keeping a "last hit" timestamp for
each map-cache entry, to be able to
determine which entries have active
flows. For each packet that is cache
hit, we would update the timer.</li>
<li>When a cache entry's TTL expires, if
it is still active (for that we need
to define what active means, which can
be a configurable threshold) we send
out a Map-Request without removing it,
wait for a reply, and install that
into the map-cache.</li>
</ol>
<div>In theory we could just do 2) without
1) but we don't want to keep unused
entries around in the map-cache.</div>
<div><br>
</div>
<div>I'm pretty sure the OOR team is very
busy with other high priority items, but
I'm also pretty sure they would be happy
to take patches implementing the above.</div>
</div>
<div><br>
</div>
<div>Regards,</div>
<div>-Lori</div>
</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">
<div class="gmail_quote">On Fri, Jun 9, 2017
at 10:34 AM, Albert López <span dir="ltr"><<a href="mailto:alopez@ac.upc.edu" target="_blank">alopez@ac.upc.edu</a>></span>
wrote:<br>
</div>
</div>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div class="m_-7264753817308079217m_1430977790609434764m_-2318041939853115081m_-6660769542085780350moz-cite-prefix">Dear
José,<br>
<br>
The expiration time is defined by
TTL. This is a hard coded parameter
that is defined by
DEFAULT_DATA_CACHE_TTL (defs.h) and
is used in
mapping_record_init_hdr(lisp_m<wbr>essage_fields.c)
. We usually set this value to 10
(10 minutes). I don't know why you
have 1, may be I sent to you a
testing version. In a future we
would like to add this parameter in
the configuration file but we don't
have it yet.<br>
<br>
Best regards<br>
<br>
Albert<br>
<br>
<br>
El 09/06/17 a les 00:08, José Miguel
Guzmán ha escrit:<br>
</div>
<div>
<div class="m_-7264753817308079217m_1430977790609434764m_-2318041939853115081h5">
<blockquote type="cite">
<div dir="ltr">Hi All
<div><br>
</div>
<div>We realized that every
minute, we are dropping
traffic packets due to
expiration of the
destination prefix, and time
required to update the entry
form server (couple of
seconds)</div>
<div><br>
</div>
<div>
<div><font face="monospace"><b>[2017/6/8
18:53:48] DEBUG: Got
expiration for EID <a href="http://192.168.102.0/24" target="_blank">192.168.102.0/24</a></b></font></div>
<div><b><span style="font-family:monospace">[2017/6/8
18:53:49] DEBUG: No
map cache for EID
192.168.102.168.
Sending Map-Request!</span><br>
</b></div>
<div><font face="monospace">[2017/6/8
18:53:49] DEBUG-2:
lisp_addr_get_ip_pref_addr:
Not applicable to ip
addressess</font></div>
<div><font face="monospace">[2017/6/8
18:53:49] DEBUG:
Balancing locator vector
for <a href="http://192.168.102.168/32" target="_blank">192.168.102.168/32</a>:</font></div>
<div><font face="monospace">[2017/6/8
18:53:49] DEBUG: Â IPv4
locators vector (0
locators):</font></div>
<div><font face="monospace">[2017/6/8
18:53:49] DEBUG: Â IPv6
locators vector (0
locators):</font></div>
<div><font face="monospace">[2017/6/8
18:53:49] DEBUG: Â IPv4
& IPv6 locators
vector (0 locators):</font></div>
<div><font face="monospace">[2017/6/8
18:53:49] DEBUG:
locators for req:
172.16.60.8</font></div>
<div><font face="monospace">[2017/6/8
18:53:49] DEBUG:
Map-Request->
flags:a=0,m=0,p=0,s=0,P=0,S=0,
irc: 0 (+1),
record-count: 1, nonce:
78627d755,
itr-rlocs:172.16.60.8,
src-eid: 192.168.101.1,
req-eid: <a href="http://192.168.102.168/32" target="_blank">192.168.102.168/32</a></font></div>
<div><font face="monospace">[2017/6/8
18:53:49] DEBUG-2:
lisp_addr_get_ip_addr:
Not applicable to
prefixes</font></div>
<div><font face="monospace">[2017/6/8
18:53:49] DEBUG: ECM
-> flags:s, inner IP:
192.168.101.1 -> <a href="http://192.168.102.168/32" target="_blank">192.168.102.168/32</a>,
inner UDP: 4342 ->
4342</font></div>
<div><font face="monospace">[2017/6/8
18:53:49] DEBUG: Sent
control message IP:
172.16.60.8 ->
172.16.60.194 UDP: 4342
-> 4342</font></div>
<div><font face="monospace"><b>[2017/6/8
18:53:49] DEBUG:
Received
Map-Reply->
flags:P=0,E=0,S=0,
record-count: 1,
nonce:
78627d75597fe77d, IP:
192.168.123.75 ->
172.16.60.8, UDP: 4342
-> 4342</b></font></div>
<div><font face="monospace">[2017/6/8
18:53:49] DEBUG: Â
Mapping-record ->
ttl: 1 loc-count: 1
action: no-action auth:
0 map-version: 0 eid: <a href="http://192.168.102.0/24" target="_blank">192.168.102.0/24</a></font></div>
<div><font face="monospace">[2017/6/8
18:53:49] DEBUG: Â Â
Locator-record ->
flags: L=1,p=0,R=1, p/w:
1/100 255/0, addr:
172.16.60.9</font></div>
<div><font face="monospace">[2017/6/8
18:53:49] DEBUG-2:
mapping_get_locators_with_afi:
List for OOR AFI 1 and
afi 2 not yet created</font></div>
<div><font face="monospace">[2017/6/8
18:53:49] DEBUG-2:
mapping_add_locator:
Added locator
172.16.60.9 to the
mapping with EID <a href="http://192.168.102.0/24" target="_blank">192.168.102.0/24</a>.</font></div>
<div><font face="monospace">[2017/6/8
18:53:49] DEBUG-2:
mapping_get_locators_with_afi:
List for OOR AFI 3 and
afi 10 not yet created</font></div>
<div><font face="monospace">[2017/6/8
18:53:49] DEBUG:
Balancing locator vector
for <a href="http://192.168.102.0/24" target="_blank">192.168.102.0/24</a>:</font></div>
<div><font face="monospace">[2017/6/8
18:53:49] DEBUG: Â IPv4
locators vector (1
locators): Â 172.16.60.9</font></div>
<div><font face="monospace">[2017/6/8
18:53:49] DEBUG: Â IPv6
locators vector (0
locators):</font></div>
<div><font face="monospace">[2017/6/8
18:53:49] DEBUG: Â IPv4
& IPv6 locators
vector (0 locators):</font></div>
<div><font face="monospace"><b>[2017/6/8
18:53:49] DEBUG: The
map cache entry of EID
<a href="http://192.168.102.0/24" target="_blank">192.168.102.0/24</a>
will expire in 1
minutes.</b></font></div>
<div><font face="monospace">[2017/6/8
18:53:49] DEBUG-2:
Programming probing of
EID's <a href="http://192.168.102.0/24" target="_blank">192.168.102.0/24</a>
locator 172.16.60.9 (30
seconds)</font></div>
</div>
<div><br>
</div>
<div>I am not sure if I am
doing something
wrong.. (probably :)) </div>
<div><br>
</div>
<div>Is there any way to
handle this transparently?
For instance, have xTR
refreshing prefixes 5secs
before expiration, so,
traffic is not interrupted?<br>
</div>
<div>Are these
expiration timers,
configurable? I only see
that rloc-probing timers are
tunable.</div>
<div><br>
</div>
<div>Thanks!</div>
<div>JM</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div dir="ltr">-- <br>
</div>
<div data-smartmail="gmail_signature">
<div dir="ltr">
<table cellspacing="0" cellpadding="0">
<tbody>
<tr>
<td colspan="3"><img src="http://www.whitestack.com/static/whitestack_signature.png"></td>
</tr>
<tr>
<td width="31px"><br>
</td>
<td colspan="3"><b>José
Miguel Guzmán<br>
</b>Senior Network
Consultant<br>
Latin America &
Caribbean<br>
</td>
</tr>
<tr>
<td><br>
</td>
<td class="m_-7264753817308079217m_1430977790609434764m_-2318041939853115081m_-6660769542085780350inbox-inbox-icon" valign="top"><img src="http://www.whitestack.com/static/phone-icon.png"></td>
<td class="m_-7264753817308079217m_1430977790609434764m_-2318041939853115081m_-6660769542085780350inbox-inbox-info" valign="top">Â Â <a href="tel:+16502482490" target="_blank">+1
(650) 248-2490</a><br>
  <a href="tel:+56990642780" target="_blank">+56
(9) 9064-2780</a></td>
</tr>
<tr>
<td><br>
</td>
<td class="m_-7264753817308079217m_1430977790609434764m_-2318041939853115081m_-6660769542085780350inbox-inbox-icon" valign="top"><img src="http://www.whitestack.com/static/email-icon.png"></td>
<td class="m_-7264753817308079217m_1430977790609434764m_-2318041939853115081m_-6660769542085780350inbox-inbox-info" valign="top">Â Â <a href="mailto:jmguzman@whitestack.com" target="_blank">jmguzman@whitestack.com</a></td>
</tr>
<tr>
<td><br>
</td>
<td class="m_-7264753817308079217m_1430977790609434764m_-2318041939853115081m_-6660769542085780350inbox-inbox-icon" valign="top"><img src="http://www.whitestack.com/static/skype-icon.png"></td>
<td class="m_-7264753817308079217m_1430977790609434764m_-2318041939853115081m_-6660769542085780350inbox-inbox-info" valign="top">Â Â <a>jmguzmanc</a></td>
</tr>
</tbody>
</table>
</div>
</div>
</blockquote>
<br>
</div>
</div>
</div>
<br>
</blockquote>
</div>
</div>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">______________________________<wbr>_________________<br>
Users mailing list<br>
<a href="mailto:Users@openoverlayrouter.org" target="_blank">Users@openoverlayrouter.org</a><br>
<a href="http://mail.openoverlayrouter.org/cgi-bin/mailman/listinfo/users" rel="noreferrer" target="_blank">http://mail.openoverlayrouter.<wbr>org/cgi-bin/mailman/listinfo/u<wbr>sers</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
<div class="m_-7264753817308079217HOEnZb">
<div class="m_-7264753817308079217h5">
<div dir="ltr">-- <br>
</div>
<div data-smartmail="gmail_signature">
<div dir="ltr">
<table cellspacing="0" cellpadding="0">
<tbody>
<tr>
<td colspan="3"><img src="http://www.whitestack.com/static/whitestack_signature.png"></td>
</tr>
<tr>
<td width="31px"><br>
</td>
<td colspan="3"><b>José Miguel Guzmán<br>
</b>Senior Network Consultant<br>
Latin America & Caribbean<br>
</td>
</tr>
<tr>
<td><br>
</td>
<td class="m_-7264753817308079217m_1430977790609434764inbox-inbox-icon" valign="top"><img src="http://www.whitestack.com/static/phone-icon.png"></td>
<td class="m_-7264753817308079217m_1430977790609434764inbox-inbox-info" valign="top">Â Â <a href="tel:+16502482490" target="_blank">+1
(650) 248-2490</a><br>
  <a href="tel:+56990642780" target="_blank">+56
(9) 9064-2780</a></td>
</tr>
<tr>
<td><br>
</td>
<td class="m_-7264753817308079217m_1430977790609434764inbox-inbox-icon" valign="top"><img src="http://www.whitestack.com/static/email-icon.png"></td>
<td class="m_-7264753817308079217m_1430977790609434764inbox-inbox-info" valign="top">Â Â <a href="mailto:jmguzman@whitestack.com" target="_blank">jmguzman@whitestack.com</a></td>
</tr>
<tr>
<td><br>
</td>
<td class="m_-7264753817308079217m_1430977790609434764inbox-inbox-icon" valign="top"><img src="http://www.whitestack.com/static/skype-icon.png"></td>
<td class="m_-7264753817308079217m_1430977790609434764inbox-inbox-info" valign="top">Â Â <a>jmguzmanc</a></td>
</tr>
</tbody>
</table>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div></div>