Subject: Re: [lisp] Charter for discussion at today's meeting

From: Dow Street <[email-masked]>
Date: Wed, 25 Mar 2009 11:06:08 -0700

Some possible re-wording for the charter text:

<previous>
The basic idea behind the separation that the Internet architecture  
combines two functions, Routing Locators, (where you are attached to  
the network) and Identifiers (who you are) in one number space: The IP  
address. Proponents of the separation architecture postulate that  
splitting these functions apart will yield several advantages,  
including improved scalability for the routing system. The separation  
aims to decouple locators and identifiers, thus allowing for efficient  
aggregation of the routing locator space and providing persistent  
identifiers in the identifier space.
LISP supports the separation of the Internet address space following a  
network-based map-and-encapsulate scheme (RFC 1955). In LISP, both  
identifiers and locators are IP addresses. In LISP, identifiers are  
composed of two parts: a "global" portion that uniquely identifies a  
particular site and a "local" portion that identifies an interface  
within a site. The "local" portion may be subdivided to identify a  
particular network within the site. For a given identifier, LISP maps  
the "global" portion of the identifier into a set of locators that can  
reach the identified interface; as a consequence a host would  
typically change identifiers when it moves from one site to another or  
whenever it moves from one subnet to another within an site.  
Typically, the same IP address will not be used as an identifier and  
locator in LISP.

<revised>
Locator/Identifier separation approaches are rooted in the premise  
that the current Internet architecture often uses a single IP address  
(i.e. name) for two distinctly different roles: Routing Locators  
(which describe "where" you are attached to the network) and  
Identifiers (which describe "who" you are). Proponents of separation  
approaches postulate that acknowledging these two distinct functions,  
and using different names when referencing them, can yield several  
advantages. LISP attempts to leverage such a split to improve  
scalability of the routing system.
A Locator/Identifier split can be applied at different points in the  
architecture, and when applied, establishes two namespaces of  
different scopes where there was previously a single namespace. The  
two new namespaces may be similar to, or differ from, both the  
previous single namespace and each other. For example, the Host  
Identity Protocol (HIP) applies a split within the host, where the HIP  
"Locator" namespace retains the structure and location semantics of an  
IP address, but the "Identifier" namespace has notably different  
properties. In contrast, LISP applies a Locator/Identifier split  
within the network topology, following a network-based map-and- 
encapsulation scheme (RFC 1955). In LISP, both locators and  
identifiers are structurally equivalent to IP addresses. A primary  
function of LISP is to establish these two namespaces and to provide a  
function for mapping an identifier into a set of locators that can  
reach the identified interface. A LISP identifier itself is  
semantically defined to be composed of two parts: a "global" portion  
that uniquely identifies a particular site (i.e. sub-graph of the  
network topology) and a "local" portion that identifies an interface  
within a site. Only the "global" portion of the identifier is relevant  
when conducting this mapping function. In LISP, when a host moves from  
one site to another, or moves between subnets within a site, a new  
locator-to-identifier mapping would generally be triggered.  This  
layer of indirection allows the routing locator space to retain an  
aggregatable structure, without requiring changes to identifiers,  
across several types of topology change events. Although LISP uses an  
IP address for both the "Locator" and "Identifier" name, in general  
these namespaces are discrete.

---

From: Dow Street <[email-masked]>
Date: Wed, 25 Mar 2009 11:08:50 -0700

Lost some line breaks in there somehow...

R,
Dow

On Mar 25, 2009, at 11:06 AM, Dow Street wrote:

<previous>

<revised>

_______________________________________________
lisp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lisp

---

From: Sam Hartman <[email-masked]>
Date: Wed, 25 Mar 2009 19:27:08 -0400

Hi.  based on your wording, I'm interpreting your proposal as a set of
wording suggestions that you think may improve the charter, but not an
objection to the current text.

I'd appreciate comments on your rewording.  However I'll note that you
are rewording a fairly long-standing part of the charter and bringing
up a bunch of words and issues that have falied to gain consensus in
previous discussions.  So, my guess is that we will not get consensus
behind this.

---

From: Robin Whittle <[email-masked]>
Date: Thu, 26 Mar 2009 14:13:47 +1100

Short version:    I think there are some good aspects to Dow's new
                  text for para 3, but I still prefer my suggested
                  text, which is shorter.

Links:

  Draft 00 (my numbering scheme) from Jari:
    http://www.ietf.org/mail-archive/web/lisp/current/msg00262.html  March 13

  My suggested changes to 00:
    http://www.ietf.org/mail-archive/web/lisp/current/msg00286.html  March 19

  Sam's versions 01 and 02:
    http://www.ietf.org/mail-archive/web/lisp/current/msg00314.html  March 23
    http://www.ietf.org/mail-archive/web/lisp/current/msg00342.html  March 25

  Dow's suggested changes to 02:
    http://www.ietf.org/mail-archive/web/lisp/current/msg00355.html  March 25

Hi Dow,

I think your new suggested text for the Charter is an attempt to
mention in detail LISP's future potential for having separate
namespaces for EIDs and RLOCs.

As I have argued several times, most recently in a reply I just wrote
to Dino (msg00369), according to my understanding of the accepted
meaning of "namespace"

   http://www.firstpr.com.au/ip/ivip/namespace/#best

as long as LISP is to be a practical method of solving the routing
scaling problem, then both the EIDs and RLOC addresses for IPv4(6)
need to be part of the global unicast address space of IPv4(6) and
therefore must be separate subsets of this space.  EIDs and RLOCs
cannot have separate namespaces, since that would mean that a single
numeric address could have two separate meanings depending on which
namespace was applied when interpreting it.  There is no way of doing
this without upgrading either all the hosts and/or all the DFZ and
other routers - which cannot be part of any practical solution to the
routing scaling problem.

I think your text is good in that it mentions that HIP always involves
separate namespaces.  However, I think your text is insufficiently
clear about the restrictions that LISP must works under when it is
deployed as a potentially practical solution to the routing scaling
problem.

The Charter is for a brief period of development on the path towards
developing a fully fledged solution to the routing scaling problem.

While I guess this period would not preclude LISP developing in a way
which could, in the future, use separate namespaces, I don't think
this needs to be mentioned at length in the Charter.

I think some changes along the lines I proposed would be more concise,
more helpful to the reader and more focused on the phase of LISP
development which the Charter will apply to:

  http://www.ietf.org/mail-archive/web/lisp/current/msg00286.html

Discussion:

  http://www.ietf.org/mail-archive/web/lisp/current/msg00298.html
  http://www.ietf.org/mail-archive/web/lisp/current/msg00309.html
  http://www.ietf.org/mail-archive/web/lisp/current/msg00335.html

My rewrite of para 3 has 174 words and yours has 269.

   - Robin

---

From: Dow Street <[email-masked]>
Date: Wed, 25 Mar 2009 22:53:35 -0700

> previous discussions.  So, my guess is that we will not get consensus

Fair enough.  My goal was simply to clarify the description and put  
this work in context, not necessarily change the scope or focus.   
However, if my proposed text raises terms/ideas for which there is not  
consensus, maybe that means we're still not entirely clear on the work  
about to be chartered.  (I'm not sure if this is a problem or not with  
respect to moving ahead with a WG).

If there are notable objections to my suggested revision, either due  
to content or process reasons (e.g., too big a change), I can suggest  
some smaller changes instead.  I'm not even convinced (myself) that a  
charter should have as much "background" information as was in the  
text I drafted.  I am just trying to get to a common understanding.

My comment during the meeting about the identifier definition was  
basically coming from the following perspective:

- there are lots of places in the architecture where you can introduce  
a point of indirection.
- if we call such a point a "locator-identifier" split, that implies  
(to me) that the latter of the namespaces has properties well suited,  
or perhaps "tuned", for the identification role.  In this regard, I  
think you could almost call the primary point of indirection in LISP  
more of a locator-locator split, or a global name - local name split.   
When viewed from the vantage point of the core, the second name in  
this pair does look a lot like a (site) identifier - it just doesn't  
look like an identifier from the edge site's perspective.  Of course,  
if I understand things correctly, from the edge site's perspective the  
identifier name itself is something like a two-part name (locator 
+identifier), right?

In any case, I took from the meeting comments (and some email  
comments) that the terminology ship has sailed on this.  Maybe I'll  
just refer to it as the Locator Indirection for Scalability Protocol  
when I am talking to myself.

R,
Dow

---

From: Dow Street <[email-masked]>
Date: Wed, 25 Mar 2009 23:12:51 -0700

Thanks for the comments, Robin.  To be honest, I have been out of the  
gritty details of this for a while and am just now catching up.   
Please see my response to Sam's message regarding suggestions to the  
charter text.  I was partly using a charter re-write as a (debatably  
poor) method for finding consensus on key points - and agree that in a  
real, final charter conciseness is a virtue.

R,
Dow

On Mar 25, 2009, at 8:13 PM, Robin Whittle wrote:

> March 19

---

From: Sam Hartman <[email-masked]>
Date: Thu, 26 Mar 2009 12:24:23 -0400

I do think your understanding is basically correct.  And I think the
current text is compatible with that understanding.  And I think there
is reasonably broad understanding among the core people who have
worked on LISP about the points that are important to you.