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 :-) Regards, Marc > > Dino > > On Feb 19, 2014, at 11:53 AM, Marc Binderberger <[email protected]> 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 <[email protected]> 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/lisp >>> > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
