Re: [rrg] A Revised critique for LISP

Eliot Lear <lear@cisco.com> Sat, 13 February 2010 23:07 UTC

Return-Path: <lear@cisco.com>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 832D93A783C for <rrg@core3.amsl.com>; Sat, 13 Feb 2010 15:07:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level:
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAHXdM8E4f6v for <rrg@core3.amsl.com>; Sat, 13 Feb 2010 15:07:01 -0800 (PST)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 2E31E28C0E1 for <rrg@irtf.org>; Sat, 13 Feb 2010 15:07:01 -0800 (PST)
Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArgAAFPAdkuQ/uCWe2dsb2JhbACDBZgbFQEBFiQGHaNDiBCPE4QAWwSOJw
X-IronPort-AV: E=Sophos;i="4.49,469,1262563200"; d="scan'208,217";a="3428136"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 13 Feb 2010 22:36:52 +0000
Received: from dhcp-10-55-83-150.cisco.com (dhcp-10-55-83-150.cisco.com [10.55.83.150]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1DN8B0h007887; Sat, 13 Feb 2010 23:08:11 GMT
Message-ID: <4B7730DB.4070106@cisco.com>
Date: Sun, 14 Feb 2010 00:08:11 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: Lixia Zhang <lixia@cs.ucla.edu>
References: <20E2830D-6BB4-4D0A-A788-4B3DE274CE5E@cs.ucla.edu>
In-Reply-To: <20E2830D-6BB4-4D0A-A788-4B3DE274CE5E@cs.ucla.edu>
X-Enigmail-Version: 1.0
Content-Type: multipart/alternative; boundary="------------070904030900060605050500"
Cc: rrg@irtf.org
Subject: Re: [rrg] A Revised critique for LISP
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Feb 2010 23:07:02 -0000

Lixia,

I have a problem with the below text:

On 2/13/10 11:39 PM, Lixia Zhang wrote:
> Because of this caching effect, and the fact that the ETR to a
> multihomed destination site is chosen at ITR, LISP design also faces
> challenges of response to component failures. LISP cannot easily test
> reachability of ultimate destinations (e.g. behind an ETR).

As a critique it suffers from lack of specificity.  To say that LISP (or
any of the other proposals, for that matter) "cannot easily" do
something, absent in this case an explanation of what the 'caching
effect' is, for lack of better words, pot shots.  What is one supposed
to do with this "information"?  No citations, no nothing.  I do not mean
to defend LISP here, but simply point out that I remain deeply concerned
about the format and content of this report.  Maybe I haven't been
paying attention for a while, but weren't reachability bits supposed to
handle a significant number of these cases?

> Another class of issues relates to network management and operations.
> - Although LISP does provide significant tools for multi-homing,
>   load-sharing, optimal-entry-selection, etc, these currently depend
> on correct
>   configuration; response to component failures is also limited.

Two problems with the above statement.  The term "limited" suffers the
exact same problem as my previous complaint.  Second, network management
always lags underlying functionality.  Unless you are saying that there
is some fundamental problem that *prevents* network management, this
would seem to be an unfair criticism.

> - LISP is currently working through NAT boxes, but only in limited
>   configurations. In particular, due to the use of fixed UDP ports, it
> is not
>   currently possible to support more than one ETR behind a NAT box.

I've not been following LISP-NAT well enough to know if the above
statement holds true, but I will say that this is the sort of specific
statement that can at least be tested, challenged, agreed to, etc.

Eliot