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

[Marc Binderberger <[e-mail]>]

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
>