Re: [lisp] Questions about draft-saucez-lisp-itr-graceful-03

[Damien Saucez <[e-mail]>]

> On 19 Feb 2014, at 20:17, Marc Binderberger <[e-mail]> wrote:
> 
> Hello Damien,
> 
> thanks for the reply!
> 
>> If you have a solution to continuously synchronise ITRs caches, we
>> would be very happy to look at them and integrate them in the proposed
>> solution.
> 
> And I was curious to see a light-weight protocol extension from you :-)
> Seriously, was wondering if you see an elegant, light way to implement 
> this in the LISP protocol (?). 

Well directly using LISP maybe we could imagine something with map-notify and multicast to keep caches synchronized but I have to think more about that.

Damien Saucez
> 
>> the purpose of the document is to deal with planned restart of routers
>> meaning that we know exactly when the routeur will get down then up
>> (it is controlled by the operator).
> 
> but then the "Traffic deflection to other ITRs (or a PxTR)" could be 
> used to fill the cache of the 2nd ITR (the one that is not reloaded). 
> You turn it on on ITR2 (off on ITR1), change your IGP to send all LISP 
> data to remote sites to ITR2, "wait a bit", then ITR2 should be ready, 
> you turn off deflection on ITR2 and reload ITR1. Then turning on 
> deflection on ITR1 and bring the IGP routing back to active-active (or 
> whatever the setup was before).
> 
> 
> Regards, Marc
> 
> 
> 
> 
> 
> 
>> On Wed, 19 Feb 2014 09:38:54 +0100, Damien Saucez wrote:
>> Hello Marc,
>> 
>>> On 18 Feb 2014, at 23:48, Marc Binderberger <[e-mail]> wrote:
>>> 
>>> Hello Damien/Olivier/Luigi/Clarence & LISP experts,
>>> 
>>> had a look at draft-saucez-lisp-itr-graceful-03. And wonder if there is 
>>> more to come?
>> 
>> Thank you for the interest.  We are indeed thinking on ways to extend
>> the document and provide more details on the ways the solutions could
>> be implemented.
>> 
>> 
>>> Somehow section 4 feels a bit "short".
>>> 
>>> What I mean: if you try to solve the problem of the _two_ cache-miss 
>>> storms - first on the 2nd ITR (ITR2) when your restarting ITR (ITR1) 
>>> goes down, then on the restarting ITR1 when it picks up traffic again - 
>>> then section 4 would probably need to talk about a permanent cache 
>>> synchronization (?). Unless you want to solve a planned restart only. 
>>> But for a failure of the ITR1 I don't see how the solution you describe 
>>> would work
>>> 
>>>  o  ITR cache synchronization: upon startup, the ITR synchronizes its
>>>     cache with the other ITRs in its synchronization set.  The ITR is
>>>     marked as available only after the cache is synchronized.
>>> 
>>> as ITR2 would trigger the cache-miss storm for the traffic after ITR1 
>>> failure.
>>> 
>>> Or if you want to solve only the cache-miss storm when ITR1 comes back 
>>> into the traffic stream then the ITR deflection has the advantage to 
>>> not require any cache-synchronization protocol, IMHO. The rate of 
>>> Map-Requests could be throttled to turn the storm into a breeze. The 
>>> method how to transport traffic to ITR2 could be one of many - a direct 
>>> LAN, GRE, Lisp.
>>> 
>>> 
>>> So my question in short: are you planning to add some words about a 
>>> permanent cache synchronization?
>> 
>> For now we don't have acceptable techniques to keep caches
>> synchronised in a permanent way but I don't think it is a big issue as
>> the purpose of the document is to deal with planned restart of routers
>> meaning that we know exactly when the routeur will get down then up
>> (it is controlled by the operator).
>> 
>> If you have a solution to continuously synchronise ITRs caches, we
>> would be very happy to look at them and integrate them in the proposed
>> solution.
>> 
>> Thank you,
>> 
>> Damien Saucez
>> 
>>> 
>>> Thanks & Regards,
>>> Marc
>>