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

Marc Binderberger <marc@sniff.de> Tue, 04 March 2014 02:01 UTC

Return-Path: <marc@sniff.de>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62E11A012F for <lisp@ietfa.amsl.com>; Mon, 3 Mar 2014 18:01:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2G7_sHgrijPf for <lisp@ietfa.amsl.com>; Mon, 3 Mar 2014 18:01:11 -0800 (PST)
Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B01761A0123 for <lisp@ietf.org>; Mon, 3 Mar 2014 18:01:11 -0800 (PST)
Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id E61382AA0F; Tue, 4 Mar 2014 02:01:04 +0000 (GMT)
Date: Mon, 3 Mar 2014 18:01:04 -0800
From: Marc Binderberger <marc@sniff.de>
To: Isidoros Kouvelas (kouvelas) <kouvelas@cisco.com>, ccassar@cisco.com, Darrel Lewis (darlewis) <darlewis@cisco.com>, LISP mailing list list <lisp@ietf.org>
Message-ID: <20140303180104006703.80a87a81@sniff.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: GyazMail version 1.5.15
Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/fvFxB_yewdAB40IhKCVWrT2ntyM
Subject: [lisp] Some questions about draft-kouvelas-lisp-reliable-transport-00
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Mar 2014 02:01:14 -0000

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