Marc, Thanks for the comments. Inline…
On Mar 4, 2014, at 4:01, Marc Binderberger <[email protected]> wrote: > Hello LISP experts, hello Isidoros/Christian/Darrel, > > had a quick look at your draft - and now I have some questions. > > > You make the statement that your proposal avoids the load problem of > periodic registration and processing. But I wonder if you simply move > the problem out of the LISP domain. What do I mean: > > protocols like BGP and LDP use explicit KeepAlive messages on the TCP > session. The rationale is (from the LDP and BGP RFCs): > > LDP uses the regular receipt of LDP PDUs on the session transport > connection to monitor the integrity of the session. > > KEEPALIVE messages may be sent periodically to ensure that the > connection is live. > > Have there been improvements in TCP implementations that make such > checks unnecessary today? > > > My guess is what you can achieve is reducing per-EID refresh/timeout > with a per-session or per-xTR timeout (?). Which is no small > achievement. But your statement goes further - and I don't fully buy > into it :-) We have two different requirements. One is to be able to communicate EID to RLOC registrations the other is to be able to detect session liveness. The periodic UDP registrations cover both as if the MS reloads the next periodic registration will rebuild the MS state. With the reliable transport what we are doing is eliminating the periodic overhead of EID registrations. You are correct that some periodic processing is still necessary for liveness purposes (either at the TCP level or through keep-alives on top of the session). The benefit is that the keep-alive is now independent of the EID prefix scale. > Another statement in your draft says > > The use of the reliable transport > session for EID prefix registration is an alternative and does not > replace the existing UDP based mechanism. > > Okay, you describe the coexistence of periodic and stateful in section > 6.2 but the question I have is: is this wise to mix a soft-state and a > stateful protocol definition? I'm not arguing in favour for one of > them but it seems a duplication of work to implement both. Which again > is fine for some interim period if you plan to morph LISP from soft > state to hard state (?). But that's not what you state. > > So I wonder if splitting this into at least two orthogonal aspects was > considered: (1) replacing the UDP socket with a TCP socket to allow > large updates and get PMTU discovery, retransmit etc. for free, solving > the reliability for large EID updates. And (2) per-xTR keepalive to > address large scale problems on the map server. That is large scale > either in EID prefixes and/or large number of xTRs. > This would keep the soft state at the core but add improvements. > > Again, just wonder if this was discussed and if so what made the > decision to go for an additional hard-state implementation? Maintaining compatibility with existing code and keeping the barrier for new implementations low is significant. There are also several use cases with a small number of EID prefixes per xTR that can still work perfectly well with the existing UDP based registration model. For example mobile node would never have more than a single EID prefix and the changing RLOC would complicate reliable transport session maintenance. thanks Isidor _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
