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
