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

[Dino Farinacci <[e-mail]>]

Yes, what you describe can work. But once you deflect, the other ITR still needs to send Map-Requests for all the new EIDs that are not cached in the map-cache.

Dino

On Feb 19, 2014, at 11:53 AM, Marc Binderberger <[e-mail]> wrote:

> Hello Dino et al.,
> 
>>> 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). 
>> 
>> Then you get sub-optimal routing.
>> 
>>> 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, 
>> 
>> This is easier said then done. That means you have to inject *all 
>> remote EID-prefixes* into your IGP. That is a non-starter.
> 
> maybe I think too simple. Assuming you have two xTRs to connect your 
> site to the LISP cloud. They both originate a default route into your 
> site IGP. You then e.g. increase the metric of ITR1's default route or 
> remove the default originated into the site IGP. Routing out of the 
> site (to another EID) then moves to ITR2.
> 
> Ingress is a different story, probably you need to reduce TTL for 
> registrations sent from ITR1, so you end up traffic ingress will use 
> ITR2 only (?).
> 
> Then you are ready to reload ITR1.
> 
> 
> Long story short: using the "Traffic deflection to other ITRs" plus the 
> right operational procedure may solve the problem?
> 
> 
> Regards, Marc
> 
> 
> 
> On Wed, 19 Feb 2014 11:41:19 -0800, Dino Farinacci 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 (?). 
>> 
>> Light-weight reads as non-robust and scalable. If you want those 
>> things, you have to do it right. And you then implemented BGP. 
>> 
>> One reason people like LISP is because it is reasonably easy to 
>> understand and employs *less protocol machinery* rather than more.
>> 
>>> 
>>>> 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). 
>> 
>> Then you get sub-optimal routing.
>> 
>>> 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, 
>> 
>> This is easier said then done. That means you have to inject *all 
>> remote EID-prefixes* into your IGP. That is a non-starter.
>> 
>>> 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).
>> 
>> Dino
>> 
>>> 
>>> 
>>> 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
>>>> 
>>> 
>>> _______________________________________________
>>> lisp mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/lisp
>>