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

From: IESG Secretary <[email-masked]>
Date: Tue, 14 Feb 2012 14:23:16 -0800 (PST)

A modified charter has been submitted for the Locator/ID Separation 
Protocol (lisp) working group in the Internet Area of the IETF.  The 
IESG has not made any determination as yet.  The modified charter is 
provided below for informational purposes only.  Please send your 
comments to the IESG mailing list ([email-masked]) by Thursday, March 1, 
2011.

Locator/ID Separation Protocol (lisp)
-------------------------------------
Current Status: Active
Last updated: 2012-02-14

 Chairs:
     Joel Halpern <[email-masked]>
     Terry Manderson <[email-masked]>

 Internet Area Directors:
     Ralph Droms <[email-masked]>
     Jari Arkko <[email-masked]>

 Internet Area Advisor:
     Jari Arkko <[email-masked]>

 Secretaries:
     Wassim Haddad <[email-masked]>
     Luigi Iannone <[email-masked]>

 Mailing Lists:
     General Discussion: [email-masked]
     To Subscribe:       https://www.ietf.org/mailman/listinfo/lisp
     Archive:            http://www.ietf.org/mail-archive/web/lisp/current/maillist.html

Description of Working Group:

The IAB's October 2006 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. 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 is 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.

A number of approaches are being looked at in parallel in other
contexts. The IRTF RRG examined several proposals, some of which were
published as IRTF-track Experimental RFCs.

The LISP WG has completed the first set of Experimental RFCs
describing the Locator/ID Separation Protocol. LISP requires no
changes to end-systems or to routers that do not directly participate
in the LISP deployment. LISP aims for an incrementally deployable
protocol.

The LISP WG is chartered to continue work on the LISP base protocol, completing
the ongoing work, and any items which directly impact LISP protocol
structures and which are related to using LISP for improving Internet routing
scalability. Specifically, the group will work on:

- Architecture description: This document will describe the
  architecture of the entire LISP system, making it easier to read the
  rest of the LISP specifications and providing a basis for discussion
  about the details of the LISP protocols.

- Deployment models: This document will describe what kind of
  deployments can be expected for LISP, and give operational advice on
  how they can be set up.

- A description of the impacts of LISP: This document will describe
  the problems that LISP is intended to address and the impacts that
  employing LISP has. While the work on LISP was initiated by Internet
  routing scaling concerns, there has also been an interest on
  improved solutions to a number of different problems, such as
  traffic engineering. This document should describe problem areas
  (such as scaling or traffic engineer) where LISP is expected to have
  a positive effect, as well as any tradeoffs that are caused by
  LISP's design.

- LISP security threats and solutions: This document will describe the
  security analysis of the LISP system, what issues it needs to
  protect against, and a solution that helps defend against those
  issues. The replay attack problem discussed on the mailing list
  should be included in this work.

- Allocation of Endpoint IDentifier (EID) space: This document
  requests address space to be used for the LISP experiment as
  identifier space

- Alternate mapping system designs: Develop alternative mapping
  designs to be tested.

- Data models for management of LISP.

The first three items need to be completed first before other items
can be submitted as RFCs. The three first documents also need to
complement each other, by describing how the architecture supports a
solution for a particular problem area and how the solution can be
deployed to help with that problem.

In addition, if work chartered in some other IETF WG requires changes
in the LISP base protocol or any items which directly impact LISP
protocol structures, then the LISP WG is chartered to work on such
changes.

It is expected that the results of specifying, implementing, and testing
LISP will be fed to the general efforts at the IETF and IRTF to
understand which type of a solution is optimal. The LISP WG is not
chartered to develop a standard solution for solving the routing
scalability problem at this time. The specifications developed by the WG
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.

Goals and Milestones

September 2012: Submit an architecture description to the IESG for
publication as an Experimental RFC

September 2012: Submit a deployment model document to the IESG for
publication as an Experimental RFC

September 2012: Submit a LISP impact discussion document to the IESG
for publication as an Experimental RFC

October 2012: Submit a LISP threats analysis document to the IESG for
publication as an Experimental RFC

October 2012: Submit an EID allocation document to the IESG for
publication as an Experimental RFC

January 2013: Submit an lternate mapping system designs to the IESG
for publication as an Experimental RFC

March 2013: Submit a data model (e.g., a MIB) document to the IESG for
publication as an Experimental RFC

---

From: Thomas Narten <[email-masked]>
Date: Wed, 15 Feb 2012 16:31:11 -0500

A WG Review message for this WG already went out a month ago.

What has changed to necessitate another Last Call?

Could the-powers-that-be please make it easier for those who might
care to understand if there is something here that we should know and
possibly comment about?

A simple explanation, or a pointer to diffs, etc. would do the job
nicely.

Thomas

---

From: John Scudder <[email-masked]>
Date: Thu, 16 Feb 2012 09:00:19 -0800

Hi Thomas,

> A simple explanation, or a pointer to diffs, etc. would do the job

Good question! I did go back and diff the last couple of versions and though this isn't the exhaustive diff, these are the key changes that caught my eye:

This text was lost from the previous draft charter:

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 as well as the manageability and
operability of LISP. Specifically, the group will work on:

- documenting areas that need experimentation
- summarizing the results of implementation, experiments, and deployment
  experience
- describing the implications of employing LISP
- operational guidance for using LISP

And so were these Goals and Milestones:

Jun 2012    Forward to the IESG an operational document which should
           include cache management and ETR synchronization
           techniques (draft-ietf-lisp-deployment).

Dec 2013    Publish an example cache management specification.

Jun 2014    Summarize results of specifying, implementing, and testing
           LISP and forward to IESG and/or IRTF.

Jun 2014    Analyze and document the implications of LISP deployments in
           Internet topologies and forward to IESG for publication.

I'm not sure why these were removed, and I would like to see them reinstated or at least have a discussion about their removal.

Thanks,

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 16 Feb 2012 12:34:39 -0500

Thanks, Thomas. In case it's not obvious, Jari's message isn't responsive to the points I raised in my own message so I'll look forward to discussing those. 

--John

On Feb 16, 2012, at 12:10 PM, Thomas Narten <[email-masked]> wrote:

> Hi John.
> 
> Turns out Jari sent a message with an overview of the changes. But it
> only went to the lisp mailing list, to which I'm not subscribed. 
> 
> See http://www.ietf.org/mail-archive/web/lisp/current/msg03674.html
> 
> That is the sort of explanation I was looking for.
> 
> But since re-chartering is an IETF-wide discussion, I think it would
> be helpful that these sorts of things get mentioned in the "WG Review"
> messages. That would be helpful to the broader community.
> 
> Thomas
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 16 Feb 2012 21:26:15 -0500

If I may separate issues for a moment,
the absence of milestones is because Terry and I have to come up with a 
proposal for them which matche sthe revised goals.

If you read the rest of the differences, you will see that the general 
question of what LISP is aimed at providing is indeed still there.

The largest single difference is the addition of the architecture draft, 
which the IESG considers a gating item for any of the longer term work 
(such as the security solutions or the additional mapping system.

Some of the apparent removal is because, as Jari stated, the IESG has 
requested that the working group focus on fewer deliverables.

Yours,
Joel

---

From: Jari Arkko <[email-masked]>
Date: Fri, 17 Feb 2012 14:46:05 +0200

> A simple explanation, or a pointer to diffs, etc. would do the job

I should have sent the e-mail to the [email-masked] list as well.

Looks like you found the e-mail from the WG mailing list later in the thread, so I am not repeating it here any more. Long story short, the IESG members had plenty of opinions about what the working group should be doing, given the recent experience of processing many documents from the working group.

I do agree that it would be useful to post the same message to other places where the review went. Sorry, I missed it in this case (or, to be precise, I was too busy to craft a second message focused on the recharter part only before you took notice...)

Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 17 Feb 2012 14:58:03 +0200

John,

The IESG had no specific objection to these parts, but we made the charter in general shorter and reformulated some of the results. In particular, the idea was to put much of the material that you pointed to into the "LISP impacts" document. In general, the IESG felt that we had to go back a bit, and describe more of the big picture - the architecture, what problem we are addressing, what the results and downsides are - than the technical details. But it was not intended that topics like scalability and amount of state could be left out.

I do agree that the description of the impacts document is short at the moment, is there something that you'd like to lift to put in the new charter?

Jari

---

From: Thomas Narten <[email-masked]>
Date: Thu, 16 Feb 2012 12:10:24 -0500

Hi John.

Thomas

---

From: John Scudder <[email-masked]>
Date: Mon, 20 Feb 2012 12:06:58 -0800

Jari,

I appreciate that brevity is desirable. I think in this case, the compression process may have been unintentionally lossy. Let me say what in my view was lost:

1. In discussions within the LISP WG it's frequently stated that experimentation will resolve some disputed question. Given this WG reliance on experimentation to resolve architectural issues, it seems desirable that such experimentation be recognized as a first-class output of the group, on a par with the architecture itself (something you have identified as a high priority). As with any experiment, it's important to document the experiments that were performed, and their outcomes.
  I do see that this is captured at a high level here: "It is expected that the results of specifying, implementing, and testing LISP will be fed to the general efforts at the IETF and IRTF to understand which type of a solution is optimal." However, there are no milestones to correspond with this expectation. It generally seems sensible to have a milestone for each expectation. Below I propose adding one.

2. LISP relies on caching, but it has been difficult to carry on architectural discussion and analysis of LISP because cache management is unspecified. In such WG discussions, it's common for it to be asserted that the problem is solvable, but the solution is left 'as an exercise for the reader' or similar. To enable this impasse to be resolved, it was agreed that an example cache management specification would be produced. This would enable discussion about something concrete without resorting to argument by emphatic assertion.

3. ETR synchronization is an important component for correct functioning of the overall LISP system but similar to caching, it has been difficult to have a concrete discussion about it. Similar to the above, this is why the previous version of the charter had an milestone for documenting it.

Broadly, these points have in common that they remind us that the LISP WG has a stated bias for working towards the concrete and the quantifiable. I think that is the high-order bit of what has been lost.

You ask for something to lift to put in the new charter. Here are some suggested edits:

Add:

DATE TBD: Publish an example cache management specification.

DATE TBD: Publish an example ETR synchronization specification.

Since you mention prioritizing the architecture document, one other alternative would be to explicitly call out the above two items as needing to be addressed in that document. This might make sense insofar as these are both needs that arose in the process of trying to work through the LISP architecture (i.e. they identify incompletely documented or worked-out areas of the architecture).

DATE TBD: Summarize results of specifying, implementing, and testing
LISP and forward to IESG and/or IRTF.

(The 'summarize' item does not seem to be what you're envisioning for the 'impact' work item, but if that's incorrect I would be OK with making that work item more explicit by adding the above text or similar.)

Thanks,

--John

On Feb 17, 2012, at 7:58 AM, Jari Arkko wrote:

John,

Jari

Thanks,

--John

---

From: Eliot Lear <[email-masked]>
Date: Thu, 23 Feb 2012 07:38:44 +0100

On 2/20/12 9:06 PM, John Scudder wrote:
> Jari,
>
>
> 2. LISP relies on caching,

LISP-ALT relies on caching.

Eliot

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 23 Feb 2012 12:01:28 +0200

Just for the sake of clarity both Lisp and lisp-alt relies on caching.

In Lisp there is EID-to-RLOC Cache in an ITR and ETR MAY create a cache
entry that maps the source EID.

- Hannu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Eliot Lear
Sent: Thursday, February 23, 2012 8:39 AM
To: John Scudder
Cc: [email-masked] IESG; [email-masked] list; [email-masked]
Subject: Re: [lisp] WG Review: Recharter of Locator/ID Separation
Protocol (lisp)

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

---

From: Damien Saucez <[email-masked]>
Date: Thu, 23 Feb 2012 11:15:07 +0100

Hello Eliot,

May I ask you why you say that LISP+ALT relies on caching?

LISP+ALT is just a BGP based overlay, where is the caching
there (is the BGP RIB that you consider as a cache?).

Cheers,

Damien Saucez

---

From: Eliot Lear <[email-masked]>
Date: Thu, 23 Feb 2012 13:47:57 +0100

Damian, others,

> there (is the BGP RIB that you consider as a cache?).

An investigation I ran looked at the possibility of doing a "push"
versus "pull" of the mappings.  It's not where the main LISP group went,
but it is possible.  To be fair there is still caching of state, but the
performance profile.  See draft-lear-lisp-nerd.

    Eliot

---

From: Damien Saucez <[email-masked]>
Date: Thu, 23 Feb 2012 13:57:39 +0100

Eliot,

On 23 Feb 2012, at 13:47, Eliot Lear wrote:

> An investigation I ran looked at the possibility of doing a "push" versus "pull" of the mappings.  It's not where the main LISP group went, but it is possible.  To be fair there is still caching of state, but the performance profile.  See draft-lear-lisp-nerd.

I remember NERD very well and I think that NERD could be useful in
some local environments. However, in the global Internet, NERD implies
that every ITR has all the mappings and their associated churn which
might impact the scalability.

All that is nice but it does not answer my question, why do you say that ALT relies on
caching? And what do you mean by "to be fair there is still caching of state"?

Thank you,
Damien Saucez

---

From: Eliot Lear <[email-masked]>
Date: Thu, 23 Feb 2012 14:37:17 +0100

Damian,

> might impact the scalability.

That's right.  It might.

> caching?

Pull implies caching.  That is- you pull the routes you need.  The BGP
provides the overlay to find the right ETR to transmit the cache
information to the ITR.

>  And what do you mean by "to be fair there is still caching of state"?

Because NERD assumes presence and use of reachibility bits.  That
information would be cached.

Eliot