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
- [rrg] A Revised critique for LISP Lixia Zhang
- Re: [rrg] A Revised critique for LISP Eliot Lear
- Re: [rrg] A Revised critique for LISP Dino Farinacci
- Re: [rrg] A Revised critique for LISP Dino Farinacci
- Re: [rrg] A Revised critique for LISP - 745 words Robin Whittle
- Re: [rrg] A Revised critique for LISP Noel Chiappa
- Re: [rrg] A Revised critique for LISP Templin, Fred L
- Re: [rrg] A Revised critique for LISP Noel Chiappa
- Re: [rrg] A Revised critique for LISP Robin Whittle