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

[Dino Farinacci <[e-mail]>]

Hello Dino et al.,
> 
>> 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.
> 
> True. Two options I see
> 
> (a) rate-limit the map-requests from the just-reloaded ITR. All this 
> does is some EIDs are a bit longer deflected

Already speced.

> 
> (b) as Darrel explained it to me: if the MR/MS/mapping system cannot 
> handle this from a single site then it's probably too weak and not fit 
> for the job :-)
> 
> 
> Regards, Marc

Already speced.

Dino

> 
> 
> 
>> 
>> 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
>>>> 
>>