Hello Florin, > is that all active, egressing flows passing > through the ITR to be reloaded (ITR1 in your example) will cache miss > in the backup ITR.
no, we covered the operational steps to make sure the backup (new-backup, actually active during reload) has learned "everything". But the storm from the reloaded ITR does not go away, I agree. All the procedure fixes is the packet loss. And as I mentioned one could throttle the map requests from the reloading ITR as the delay in resolving EIDs does not hurt, due to the "deflection". Regards, Marc On Thu, 20 Feb 2014 03:13:51 +0100, Florin Coras wrote: > 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 <[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 > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
