Subject: [lisp] WG Review: Locator/ID Separation Protocol (lisp)

From: IESG Secretary <[email-masked]>
Date: Tue, 17 Mar 2009 17:30:00 -0700 (PDT)

A new IETF working group has been proposed in the Routing Area.  The IESG
has not made any determination as yet.  The following draft charter was
submitted, and is provided for informational purposes only.  Please send
your comments to the IESG mailing list ([email-masked]) by Tuesday, March
24, 2009.

Locator/ID Separation Protocol (lisp)
--------------------------------------------------
Last Modified: 2009-03-12

Current status: Proposed Working Group

Chair(s):
TBD

Internet Area Director(s):
TBD

Routing Area Advisor:
TBD

Mailing Lists:
General Discussion: https://www.ietf.org/mailman/listinfo/lisp

Description of Working Group:

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, or RLOCs (where you are attached
to the network) and Endpoint Identifiers, or EIDs (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 location and identity, thus allowing for
efficient aggregation of the RLOC space and providing persistent identity
in the EID space.

LISP supports the separation of the Internet address space into Endpoint
Identifiers and Routing Locators following a network-based map-and-encap
scheme (RFC 1955). It employs EIDs that represent a mixture of locators
and identifiers; it could also be classified as a multi-level locator
scheme.  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).

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.

---

From: Lars Eggert <[email-masked]>
Date: Tue, 17 Mar 2009 21:30:43 -0700

On 2009-3-17, at 19:04, Brian E Carpenter wrote:
> Probably for the last time, I want to object to LISP's basic
> terminology. The entity that LISP calls an EID is in fact a
> locator; it's simply a locator of limited routeability.
>
> I believe it should be called a LLOC (local locator), with
> consequent changes to the charter text. I realise that this
> would spoil a neat acronym, but the risk in the current
> terminology is that people will be confused for ever.

Let's call it an "iddress" :-)

Lars

---

From: Robin Whittle <[email-masked]>
Date: Thu, 19 Mar 2009 11:12:06 +1100

I propose changed and additional text for the LISP WG charter in
response to two types of concern:

  1 - LISP's name and claim to implementing true Loc/Id separation
      is problematic, in that other systems such as HIP implement
      truly separate Locator and Identifier addressing systems (AKA
      namespaces) while LISP does not.  [1] [2]

  2 - That the charter should be unambiguous for readers who know
      nothing about the RRG, LISP etc. and should provide greater
      clarity about the nature of LISP's "separation".  This is
      especially important considering the false claims made in some
      LISP I-Ds, presentations and mailing list messages [3] that
      LISP involves separate namespaces for Locators and Identifiers.

   - Robin

Replace the first 2 sentences of paragraph 3 with the following text
(perhaps as one or two paragraphs, rather than the three below) and
leave the remaining sentences as a separate paragraph.  This new text
also explicitly states that EID space is for end-user networks and
lists the benefits it provides in a scalable manner.

   LISP supports the separation of the Internet address space (IPv4 or IPv6)
   into multiple regions, each of which contains only EIDs or RLOCs. EID
   addresses are intended to be attractive for end-user networks and to
   enable the provision of multihoming, portability of the EID addresses
   between ISPs and inbound traffic engineering to large numbers of these
   networks in a scalable manner.

   LISP Ingress Tunnel Routers (ITRs) handle packets addressed to EID regions
   of the address space via global "map-and-encap" system (RFC 1955) in which
   a mapping system is used to determine the RLOC address of an Egress Tunnel
   Router (ETR) to which the packet will be tunneled. The ETR decapsulates the
   packet and forwards it to the destination network.

   Hosts and conventional routers make no distinction between addresses in the
   EID or RLOC regions of the address space.  No separate namespaces are
   created.  While it may be possible to use an IPv4 RLOC to tunnel a packet
   addressed to an IPv6 EID address or vice-versa, IPv4(6) RLOCs and EIDs share
   the same IPv4(6) namespace.

Optionally, at this point, add a mention of HIP as involving separate
namespaces for Locator and Identifier.

I also propose modifying the last sentence of para 1 to include
mention of the proper term which covers LISP, APT, Ivip, TRRP and
Six/One Router: "core-edge separation schemes" [4]:

  In general, these proposals are core-edge separation schemes and were
  initially known by the term "Locator/Identifier separation".

[1] Margaret Wasserman  2009-03-12
    http://www.ietf.org/mail-archive/web/lisp/current/msg00265.html

[2] Fred Templin  2009-03-13
    http://www.ietf.org/mail-archive/web/lisp/current/msg00266.html

[3] Robin Whittle  2009-03-18
    http://www.ietf.org/mail-archive/web/lisp/current/msg00273.html

[4] 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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 19 Mar 2009 09:11:46 -0400

Thanks for taking a stab at improved charter text!

As I discussed in my other message, it does not seem like an absolute
requirement that the same address can never be used both as an EID and
RLOC.  Any chance you could work on clarifications to your text that
do not strictly forbid this?

Also, could I get feedback from the rest of the list on the text?  Do
we want to adopt it?
If not, what do we want to fix about it?

---

From: Scott Brim <[email-masked]>
Date: Thu, 19 Mar 2009 09:34:19 -0400

Excerpts from Sam Hartman on Thu, Mar 19, 2009 09:11:46AM -0400:
> RLOC.  

A field itself cannot be purely for routing/forwarding or for
identifying -- you cannot control what functions will use to do their
jobs, and they will take anything they can get.  You can assert that a
field "is" a locator or an identifier, but you should understand that
someone will always do something to break your theoretical purity.

> Also, could I get feedback from the rest of the list on the text?
> Do we want to adopt it?  If not, what do we want to fix about it?

I say we all know what we're talking about, so go with what we have,
do the work, and conduct the terminology war in our spare time.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 19 Mar 2009 09:56:57 -0400

>>>>> "Scott" == Scott Brim <[email-masked]> writes:

    Scott> I say we all know what we're talking about, so go with what
    Scott> we have, do the work, and conduct the terminology war in
    Scott> our spare time.

So, the discussion so far is fairly strongly supporting the claim that
the clarity problem needs to be fixed in the charter.  I was more
trying to gather comments on whether Robin's solution was a step
forward than on whether the problem needs to be solved.

I want to stress that I think the discussionsupports improving the
clarity of the charter; that is not the same as changing the
terminology we use.  At least as I read Robin's message, while there
was a lot of complaint about terminology in the justification, the
actual charter text changes did not seem to change terminology.  I
think it did remove some terms of art.