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

[Florin Coras <[e-mail]>]

On 02/20/2014 01:40 AM, Marc Binderberger wrote:
> 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
>
> (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 :-)

What Dino meant, I think, is that all active, egressing flows passing 
through the ITR to be reloaded (ITR1 in your example) will cache miss in 
the backup ITR. I don't know if the problem you try to solve is is 
theoretical or practical, but in the latter case, maybe it would be 
easier just to provision a local caching Map-Resolver, close to the two 
ITRs.

Florin
>
> Regards, Marc
>
>
>
>> 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
> _______________________________________________
> lisp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp