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? 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?
Thanks & Regards,
Marc
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp