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

Reply via email to