Subject: LISP: update to charter in external review

From: Sam Hartman <[email-masked]>
Date: Sun, 29 Mar 2009 23:29:56 -0400

I'd like to present the following revised charter to the community
(and with Jari's approval) to the IESG for review.  This charter
represents discussion on the LISP list and in the LISP session at IETF
74.

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".

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
be used by de-capsulation devices to 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.

LISP requires no changes to end-systems or to most routers.  LISP aims
for an incrementally deployable protocol.

A number of other approaches 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 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 write
concrete protocol specifications and develop implementations that can be
used to understand the characteristics of these designs. The LISP WG is
chartered to work on the LISP base protocol (draft-farinacci-lisp-12.txt),
the LISP+ALT mapping system (draft-fuller-lisp-alt-05.txt), LISP
Interworking (draft-lewis-lisp-interworking-02.txt), LISP Map Server
(draft-fuller-lisp-ms-00.txt), and LISP multicast
(draft-farinacci-lisp-multicast-01.txt) for these purposes, with the given
drafts as a starting point. 
The working group will encourage and support
interoperable LISP implementations as well as defining requirements for
alternate mapping systems. The Working Group will also develop security
profiles for the ALT and/or other mapping systems.

It is expected that the results of specifying, implementing, and
testing LISP will be fed to the general efforts at the IETF and IRTF
(e.g., the Routing Research Group) that attempts to understand which
type of a solution is optimal. The LISP WG is NOT chartered to develop
the final or standard solution for solving the routing scalability
problem. Its specifications are Experimental and labeled with accurate
disclaimers about their limitations and not fully understood
implications for Internet traffic. In addition, as these issues are
understood, the working group will analyze and document the
implications of LISP on Internet traffic, applications, routers, and
security. This analysis will explain what role LISP can play in
scalable routing. The analysis should also look at scalability and
levels of state required for encapsulation, decapsulation, liveness,
and so on (draft-meyer-loc-id-implications) as well as the
manageability and operability of LISP.

Goals and Milestones:

Mar 2010 Submit base LISP specification to the IESG as Experimental

Mar 2010 Submit base ALT specification to the IESG as Experimental

Mar 2010 Submit the LISP Interworking specification to the IESG as
Experimental

June 2010 Submit the LISP Map Server specification to the IESG as
Experimental

June 2010 Submit Recommendations for Securing the LISP Mapping System to
the IESG as Experimental

Jul 2010 Submit LISP for Multicast Environments to the IESG as
Experimental

Dec 2010 Submit a preliminary analysis as Informational

Dec 2010 Re-charter or close.
_______________________________________________
lisp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lisp

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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 30 Mar 2009 08:42:57 +0200

> represents discussion on the LISP list and in the LISP session at IETF
Sam,

thanks for the update - this is the first I've seen on the IETF list 
about LISP for a while, so I assume that it's appropriate to continue 
discussion there at this time; I'm not a member of the LISP list.

One point of clarification: Is it the intent of the LISP WG that "IP" in 
this proposed charter text should be read as "IPv4 or IPv6"?

My understanding (seen from a VERY long distance) is that the routing 
scaling problems are substantially the same for both dialects of IP, and 
that initial efforts have focused on encapsulating either, with the 
initial experiments using IPv4 as the encapsulating protocol.

Is this understanding correct?

                Harald

IPv6: When four billion is a small number.

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Mon, 30 Mar 2009 09:52:10 -0700

> Sam,
> 
> thanks for the update - this is the first I've seen on the 
> IETF list about LISP for a while, so I assume that it's 
> appropriate to continue discussion there at this time; I'm 
> not a member of the LISP list.

We've had a fairly lively discussion of the charter text on the LISP
mailing list, its been my sense that the community has come to a rough
consensus on what we want the WG to do, but haven't ironed out the best
way to articulate that in the Charter just yet.  Sam has been diligently
grinding through the details of the wording - for which I thank him most
sincerely. :-)

> 
> One point of clarification: Is it the intent of the LISP WG 
> that "IP" in this proposed charter text should be read as 
> "IPv4 or IPv6"?

Yes, perhaps on the first occurrence of such we could add "(IPv4 or
IPv6)"

> 
> My understanding (seen from a VERY long distance) is that the 
> routing scaling problems are substantially the same for both 
> dialects of IP, and that initial efforts have focused on 
> encapsulating either, with the initial experiments using IPv4 
> as the encapsulating protocol.
> 

It is, with the note that the initial implementations are supporting
both IPv4 and IPv6 as the (outer) encapsulating protocol, and the
(inner) encapsulated protocol.

-Darrel

---

From: David Meyer <[email-masked]>
Date: Mon, 30 Mar 2009 09:53:49 -0700

Harald,

> scaling problems are substantially the same for both dialects
> of IP, 

	Correct.

> and that initial efforts have focused on encapsulating either,
> with the initial experiments using IPv4 as the encapsulating
> protocol. 
>

	Close. First, no formal experiments have been defined in
	the WG context (to the best of my knowledge).
	
	Next, we have 4-to-4-over-6 (464), 6-to-6-over-4 (646), 
	4-to-4-over-4 (444) and 6-to-6-over-6 spec'ed and running
	in the field, so any combination of those is available for
	experimentation. Of course, any X6X (for X = 4 or 6)
	requires a 6 path between xTRs.

	Dave

---

From: Dow Street <[email-masked]>
Date: Sun, 29 Mar 2009 21:30:54 -0700

On Mar 29, 2009, at 8:29 PM, Sam Hartman wrote:

> space: The IP address.

I don't think the preceding lines form a sentence.  Is there an "is"  
missing?  Alternatively, here is possible substitute:

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 the separation architecture

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Mon, 30 Mar 2009 19:33:24 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Dow Street
> Sent: Monday, March 30, 2009 6:31 AM
> To: Sam Hartman
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [lisp] LISP: update to charter in external review
> 
> 

in order to prevent confusion between a name and an address, it would be
preferable to state:

Locator/Identifier separation approaches are rooted in the premise that
the current Internet architecture designates by a single number space,
i.e., the IP address, two distinctly different roles: Routing Locators
(which describe "where" you are attached to the network) and Identifiers
(which describe "who" you are).

Thanks,
-dimitri.
> > be used by de-capsulation devices to reach the identified 
> interface;  
> > as a consequence a host would
> > All proposals (including LISP) have potentially harmful 
> side-effects  
> > to
> > it is not yet known what kind of design alternative is the 
> best one  
> > among
> > many.
> >
> > used to understand the characteristics of these designs. 
> The LISP WG  
> > is
> > (draft-farinacci-lisp-multicast-01.txt) for these purposes, 
> with the  
> > given
> > interoperable LISP implementations as well as defining 
> requirements  
> > for

---

From: Robin Whittle <[email-masked]>
Date: Tue, 31 Mar 2009 12:21:12 +1100

Short version:    I support Dimitri's suggested changes about the
                  roles of Locators and Identifiers.

                  The current draft still contains an erroneous
                  inference that the one address could be used as
                  both a locator (RLOC) and an identifier (EID).

                  The draft should be improved to better explain
                  the purpose of EID addresses and to show that
                  LISP involves separate roles for EIDs and RLOCs
                  - not separate namespaces, as with HIP.

                  Links to all versions of the draft LISP WG Charter.

Hi Dimitri,

I think your suggested improvement to the draft LISP WG Charter is

> (which describe "who" you are).

I stopped trying to suggest improvements on the LISP list after my
concerted effort last week - 15 messages and a research project
into the meaning of "namespace" - was ignored.  Links to these
messages are here:

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

Sam Hartman suggested there may be multiple meanings of "namespace",
but I could find only one:

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

My efforts included trying to point out that "Typically, the same IP
address will not be used as an identifier and locator in LISP." is
misleading, since it indicates it may be allowable to do something
which is prohibited by all 13 versions of the central LISP I-D:

   http://tools.ietf.org/html/draft-farinacci-lisp-12#page-8

        "EIDs MUST NOT be used as LISP RLOCs."

No-one has shown where using the same IP address as an EID and an
RLOC is allowed for in the LISP I-Ds or how it could work in
practice.  I have argued in detail it cannot work.

My suggested changes are not criticisms of LISP - just an attempt at
making the Charter a more accurate and helpful explanation.

My suggested changes included better general explanation of how LISP
helps with routing scalability and that EID addresses are intended
for end-user networks which need multihoming and/or portability of
their address space.  I suggested including the term "core-edge
separation scheme" as a better overall description for the class of
potentially practical solutions which LISP is one of.  This is the
best term for the most promising class of scalable routing
solutions, following this paper:

   Towards a Future Internet Architecture: Arguments for
   Separating Edges from Transit Core
   Dan Jen, Lixia Zhang, Lan Wang, Beichuan Zhang
   http://conferences.sigcomm.org/hotnets/2008/papers/18.pdf

I also suggested changes which made it clear that (contrary to
repeated statements in presentations, and inferences in I-Ds) LISP
does not involve separate namespaces for EIDs and RLOCs.  HIP does,
and this makes HIP impossible to introduce incrementally and
voluntarily - all participating hosts need new (IPv6) stacks with
HIP extensions and perhaps (I am not sure) HIP-compliant
applications.  A scalable routing solution needs to be voluntarily
adopted by many or most multihoming-needing end-user networks.
This will only occur if the scheme provides immediate benefits,
including handling packets sent from non-upgraded networks, and if
it requires no host changes.

The big deal about LISP, APT, Ivip, TRRP and Six/One Router is that
these core-edge separation solutions to the routing scaling problem
do not involve separate namespaces - or as you describe it, in
accordance with the draft Charter "number spaces".

As your text makes clear, the nature of the separation is in terms
of "roles".   HIP is arguably the architecture which truly separates
Locators and Identifiers.  I think this is important to state in the
WG Charter, since LISP's name "Locator Identifier Separation
Protocol" seems to imply it is the primary such protocol.

In LISP, a subset (in multiple separate prefixes) of the global
unicast addresses which are reserved for use as EIDs - addresses for
hosts in end-user networks with LISP-mapped prefixes.  The remainder
of the global unicast addresses are can be used as RLOCs: for ITR
and ETR addresses.

   (However, in general LISP usage, the term "RLOC" is used more
    broadly than the above description, which is based on the
    formal definition of terms in draft-farinacci-lisp.  "RLOC"
    is also frequently used to refer to any non-EID address, such
    as those of hosts and routers which are not involved in LISP.)

The different way of interpreting EID addresses affects the behaviour
of ITRs and ETRs.  Hosts and all routers other than ITRs and ETRs have
no knowledge of these differing roles and continue to interpret all
these addresses as they do today - according to how they are
interpreted as part of the global unicast namespace.

My suggested changes were mainly to the first half of paragraph 3 of
the initial version - which has been expanded to paragraphs 3 to 4 in
the latest version.

Your suggested changes are to paragraph 2 and I think they compatible
with what I suggested.

However, here is a tweak of your last two lines, to remove the "you":

    i.e., the IP address, two distinctly different roles: Routing
    Locators (which enable routers to forward a packet to the correct
    destination network) and Identifiers (which uniquely identify a
    stack on an interface on a host in an LISP-enabled end-user
    network).

The brief definitions I gave above strike me as apt for LISP.  More
comprehensive definitions are possible, but there seems to be a
strong aversion to anything which is not terse.

The IRTF Routing Research Group is currently debating the definitions
of "Locator", "Identifier" and "Address".  I think it is pointless
trying to agree on precise definitions for these terms, because in
practice people will use them in different ways depending on the
particular conceptual framework they are using.

Below are links to the various drafts of the Charter and to the more
extensive of the suggested changes.  The version numbers are mine.

  - Robin

  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

  Version 03 presented to the IETF and IESG lists:
    http://www.ietf.org/mail-archive/web/lisp/current/msg00380.html  March 29
    http://www.ietf.org/mail-archive/web/ietf/current/msg56361.html

---

From: Sam Hartman <[email-masked]>
Date: Mon, 30 Mar 2009 22:40:55 -0400

>>>>> "Michael" == Michael Menth <[email-masked]> writes:

    Michael> The sentence "who you are" is rather confusing to me
    Michael> although its intention is certainly to be a simple and
    Michael> catchy explanation. However, "you" - the user (?) is
    Michael> probably not an edge interface designator. "who you are"
    Michael> suggests that the identifier has something to do with the
    Michael> identity of some device or its owner (whoever "you" is)
    Michael> that would stay the same when moving around which is
    Michael> clearly not the case in this context.

    Michael> Wouldn't it be clearer to say: core Routing Locators
    Michael> (which describe "where" an edge network is attached to
    Michael> the Internet core) and edge interface designators (which
    Michael> describe to "which" interface a device is attached within
    Michael> an edge network)? I find this easier to understand and
    Michael> according to my understanding this is 100% in line with
    Michael> the third paragraph of the charter.

the second paragraph is intended to be far more general than LISP and
carefully avoids using any LISP terms.  I think it is accurate,
although the pronoun "you" is unbound.  For LISP, it's an edge network
(in your vocabulary),a site in others' vocabulary, etc.  For HIPP, you
is bound to a something.  Some people would probably say stack,
although that's misleading as HIP explicitly supports stacks with
multiple HITs.  For shim6, you is bound to something close to stack,
although it's a bit more complicated than that.

The second paragraph has not undergone a lot of editing other than to
remove LISP-specific terms from the general description.  However, it
also has not drawn a lot of fire.  If you do try to build consensus
behind a change, I strongly recommend against introducing new terms or
acronym expansions.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 30 Mar 2009 22:52:35 -0400

>>>>> "Robin" == Robin Whittle <[email-masked]> writes:

    Robin> Short version: I support Dimitri's suggested changes about
    Robin> the roles of Locators and Identifiers.

    Robin>                   The current draft still contains an
    Robin> erroneous inference that the one address could be used as
    Robin> both a locator (RLOC) and an identifier (EID).

For the information of the IETF and IESG, I made a consensus call on
the lisp list that there was rough consensus that there will be cases where the same IP stands both as an EID and a
RLOC.

Robin challenged this consensus call but has not found support on the
list for his challenge.

So, I believe the community disagrees with Robin's claim that the
discussion of LISP identifiers and locators is erroneous.

That said, I don't see that Dimitri's rewording of the second
paragraph actually touches on how LISP identifiers and locators relate
to each other.  As such, I don't think there has been community
discussion prior to his proposal that would either support or oppose
his proposal.

There is a desire to be done with the charter sooner rather than
later.

---

From: Robin Whittle <[email-masked]>
Date: Tue, 31 Mar 2009 16:03:07 +1100

Short version:   Sam's statement

                 > There is a desire to be done with the charter
                 > sooner rather than later.

                 seems to be true.  The process of revising the
                 draft LISP WG Charter seems to be so hurried
                 that no-one has had time to explain why the
                 LISP list displays 100% consensus that an EID
                 could be used as an RLOC when this has been
                 prohibited by draft-farinacci-lisp since its
                 inception.

Sam wrote:

> For the information of the IETF and IESG, I made a consensus
> call on the lisp list that there was rough consensus that
> there will be cases where the same IP stands both as an EID
> and a RLOC.

This is true.  Sam's 24 March message was:

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

     I think there has been enough discussion on-list and other
     private comments that the rough consensus of the
     participants so far is that there will be cases where the
     same IP stands both as an EID and a RLOC.

     My claim that this typically does not happen may even be
     too strong:-)

     I acknowledge that you disagree and that so far our sample
     size is small.

Before this message, I only know of one from Noel Chiappa (4
hours before Sam's) asserting that an EID could be used as an
RLOC:

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

Noel asserted that it would be technically possible.  He did not
state where in the LISP I-Ds or in any other LISP material this
was allowed or required.

Nor did he provide any critique of my argument that it would be
impossible, since an ITR emitting an encapsulated packet with a
destination address XX (in its RLOC role) would probably accept
the just-emitted packet as an EID-addressed traffic packet to
be encapsulated and tunneled to some RLOC address.  If the
emitted packet (tunnelled to XX which is also an EID) was not
immediately devoured by the ITR as a traffic packet, then it
would be forwarded to some other ITR, including perhaps one of
the Proxy Tunnel Routers in the DFZ, which would do the same
thing.

I was surprised that this establishment of rough consensus on
the basis AFAIK of one message to the list - and surprised at
the mention of "private comments", apparently as one of the
reasons for this decision.

> Robin challenged this consensus call but has not found support
> on the list for his challenge.

This is also true.

> So, I believe the community disagrees with Robin's claim that
> the discussion of LISP identifiers and locators is erroneous.

Judging by the lack of anyone but me disagreeing with Noel's
and Sam's statement this is absolutely true - I agree entirely
with Sam: there has been absolute consensus in agreement with a
statement which I believe violates a central part of the LISP
definition of terms:

If anyone can explain this, please do.

> There is a desire to be done with the charter sooner rather
> than later.

Indeed.  There was such urgency on the LISP list that no-one has
yet explained how consensus occurred on something which is
apparently so at odds with LISP I-Ds and all the prior
discussion of LISP I know of.

While the draft Charter is being presented for review on the
IETF list, my experience on the LISP list and my perception of
the rejection of other people's suggestions indicates that there
is an extreme reluctance both towards altering the text and
towards detailed discussion of well-meant suggestions for
improving it.

What's the rush?

  - Robin

---

From: Michael Menth <[email-masked]>
Date: Tue, 31 Mar 2009 00:24:23 +0200

Hi Sam,

> the network) and Identifiers (who you are) in one number
The sentence "who you are" is rather confusing to me although its 
intention is certainly to be a simple and catchy explanation. However, 
"you" - the user (?) is probably not an edge interface designator. "who 
you are" suggests that the identifier has something to do with the 
identity of some device or its owner (whoever "you" is) that would stay 
the same when moving around which is clearly not the case in this context.

Wouldn't it be clearer to say: core Routing Locators (which describe 
"where"  an edge network is attached to the Internet core) and edge 
interface designators (which describe to "which" interface a device is 
attached within an edge network)? I find this easier to understand and 
according to my understanding this is 100% in line with the third 
paragraph of the charter.

What's LISP's intended functionality beyond a protocol to separate core 
routing locators (RLocs) and edge interface designators (EIDs)? At 
least, this way all acronyms can be saved without keeping the ambiguous 
and misleading word identifier. Or is that too narrow minded and am I 
missing potential future extensions of LISP that are not documented in 
the charter?

Well, it's probably too late for changes anyway.

Just my 2 cents,

    Michael

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: Sam Hartman <[email-masked]>
Date: Tue, 31 Mar 2009 19:16:18 -0400

Sorry, I didn't notice the upper case terms in the second paragraph.
I definitely agree they should be removed.