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