Subject: [lisp] Some questions about draft-kouvelas-lisp-reliable-transport-00

From: Marc Binderberger <[email-masked]>
Date: Mon, 3 Mar 2014 18:01:04 -0800

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 :-)

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?

Best regards,  
Marc

---

From: Isidoros Kouvelas <[email-masked]>
Date: Tue, 4 Mar 2014 18:41:35 +0200

Marc,

Thanks for the comments. Inline…

> achievement. But your statement goes further - and I don't fully buy 

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.

> 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