Re: [lisp] [ipdir] LISP WG

Margaret Wasserman <mrw@lilacglade.org> Fri, 13 March 2009 00:01 UTC

Return-Path: <mrw@lilacglade.org>
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0A813A6BD8 for <lisp@core3.amsl.com>; Thu, 12 Mar 2009 17:01:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level:
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599]
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 cPHikZ8cQ+9Y for <lisp@core3.amsl.com>; Thu, 12 Mar 2009 17:01:12 -0700 (PDT)
Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id 817973A6B2F for <lisp@ietf.org>; Thu, 12 Mar 2009 17:01:12 -0700 (PDT)
Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id SHgb1b00617UAYkA2Q1r3E; Fri, 13 Mar 2009 00:01:51 +0000
Received: from [10.36.0.45] ([76.119.58.152]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id SQ1n1b00c3H3vh08ZQ1pf1; Fri, 13 Mar 2009 00:01:50 +0000
Message-Id: <1368441D-65C6-40E6-82FA-964E193C826B@lilacglade.org>
From: Margaret Wasserman <mrw@lilacglade.org>
To: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <49AFF574.6090805@piuha.net>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Thu, 12 Mar 2009 20:01:46 -0400
References: <49AFF574.6090805@piuha.net>
X-Mailer: Apple Mail (2.930.3)
X-Mailman-Approved-At: Fri, 13 Mar 2009 09:01:13 -0700
Cc: ipdir@ietf.org, IESG IESG <iesg@ietf.org>, lisp@ietf.org
Subject: Re: [lisp] [ipdir] LISP WG
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 13 Mar 2009 00:01:13 -0000

Hi Jari,

I have some significant concerns about some of the wording in the LISP  
charter (and in the LISP drafts), which I will try to explain here...

Please note that I am not arguing against creation of this WG or  
against publication of the mechanisms described in the LISP drafts.    
Specifically, I am concerned about the accuracy of calling this  
mechanism an ID/Locator split mechanism and/or conflating the concept  
of IDs (in the ID/Loc sense) with the LISP concept of an EID, as EIDs  
serve as both a topological locator and an identifier.

This input is meant to be constructive and not simply pedantic/ 
argumentative.  I am concerned that our lack of accuracy in the  
terminology we are using to discuss this mechanism may reflect a lack  
of clairy in how we are thinking about this technology, and a lack of  
understanding of what benefits it could provide.   In particular, we  
may be attributing architectural merit, or even operational benefits,  
to this technology that it doesn't actually provide, because it does  
not actually separate IDs and Locators within the edge network.   As  
just one small example, if we had a true ID/Loc split mechanism, a  
host could maintain a constant ID as it moved throughout the network,  
somehow updating the ID/locator mapping as it moved.  However, that is  
not a property of LISP EIDs.

On Mar 5, 2009, at 10:53 AM, Jari Arkko wrote:
> LISP (Locator/ID Separation Protocol)

I think that the name of the group is somewhat inaccurate, because the  
LISP specification (as currently written) does not describe a complete  
ID/Locator split mechanism.
>
> The IAB's October 2006 workshop on Routing and Addressing Workshop
> (RFC 4984) rekindled interest in scalable routing and addressing
> architectures for the Internet. Among the many issues driving this
> renewed interest are concerns about the scalability of the routing
> system and the impending exhaustion of the IPv4 address space. Since
> the IAB workshop, several proposals have emerged which attempt to
> address the concerns expressed there and elsewhere. In general, these
> proposals are based on the "Locator/Identifier separation" (frequently
> referred to as Loc/ID split).

I would not personally put this historical information in the charter  
unless there are specific documents from the IAB workshop that you  
want WG members to read.  Citing this meeting without giving a pointer  
to any minutes, notes or output is just an appeal to authority.
>
> The basic idea behind the Loc/ID split that the Internet architecture
> combines two functions, Routing Locators, or RLOCs (where you are
> attached to the network) and Endpoint Identifiers, or EIDs (who you
> are) in one number space: The IP address.

This part of the second paragraph conflates the ideal concept behind  
ID/Locator split with the LISP terminology (RLOC and EID) in a way  
that isn't quite accurate.  While the classic "Locator" is analogous  
to a LISP RLOC, a LISP EID is not a pure identifier, as it is also  
used as a topological locator within the edge network.

It is also stylistically awkward that the introduction of the RLOC and  
EID terms comes before LISP has been introduced.

> Proponents of the Loc/ID
> split postulate that splitting these functions apart with yield
> several advantages, including improved scalability for the routing
> system.

Proponents ... postulate?  I'd remove this sentence unless you can  
cite a reference or something.

> The Loc/ID split aims to decouple location and identity, thus
> allowing for efficient aggregation of the RLOC space and providing
> persistent identity in the EID space.

Again, the charter is conflating the ID/Loc separation concept with  
EIDs and RLOCs.
>
>
> The LISP protocol is an instantiation of the separation of Internet
> address space into Endpoint Identifiers and Routing Locators designed
> by means of a network-based map-and-encap scheme.

While it is clear that LISP separates the Internet address space into  
RLOCs and EIDs, I think this sentence is trying to say that LISP is  
performing an ID/Locator split, which it isn't completely.  LISP is  
really a tiered-routing mechanism that uses pure locators at the  
center (RLOCs) that are de-aggregated/transposed at a defined  
threshold into ID/Locators for use in the edge network (EIDs).

I don't think that "map-and-encaps" is a universally well-understood  
term.  It should be defined here, or a reference should be cited.

> A number of other
> instantiations of the same general concept are being looked at in
> parallel in the IRTF and IETF.  At this time, these proposals are at
> an early stage.  All proposals (including LISP) have potentially
> harmful side-effects to Internet traffic carried by the involved
> routers, have parts where deployment incentives may be lacking, and
> are generally NOT RECOMMENDED for deployment beyond experimental
> situations at this stage. Many of the proposals have components (such
> as the EID-to-RLOC mapping system) where it is not yet known what kind
> of design alternative is the best one among many.
>
> However, despite these issues it would be valuable to be able to
> develop concrete protocol specifications and build equipment that can
> be used to understand the characteristics of these designs. The LISP
> WG is chartered to work on the design on the LISP base protocol [1],

Typo:  s/design on/design of

The rest of the charter from this point forward looks fine to me.

Margaret