Subject: [lisp] Architectural concerns about the nature of LISP identifiers

From: Sam Hartman <[email-masked]>
Date: Fri, 13 Mar 2009 11:16:35 -0400

The chairs have recieved comments from Margaret Wasserman and from at
least one IAB member regarding a lack of clarity about the
architecture of LISP in the charter.  Margaret's posting is held in
moderation; I don't yet have access to approve it so I'm forwarding.

Subject: Fwd: [ipdir] LISP WG
From: Margaret Wasserman <[email-masked]>
To: Sam Hartman <[email-masked]>
Date: Thu, 12 Mar 2009 20:07:42 -0400

Well, I tried to send it to LISP, but it is being held for moderator  
approval.  I guess I'm not subscribed.

Margaret

Begin forwarded message:

> From: Margaret Wasserman <[email-masked]>
> Date: March 12, 2009 8:01:46 PM EDT
> To: Jari Arkko <[email-masked]>
> Cc: IESG IESG <[email-masked]>, [email-masked], [email-masked]
> Subject: Re: [ipdir] LISP WG
>
>
> 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