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

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: Thomas Narten <[email-masked]>
Date: Thu, 16 Feb 2012 12:10:24 -0500

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: 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

---

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: 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: Eliot Lear <[email-masked]>
Date: Thu, 23 Feb 2012 13:47:57 +0100

Damian, others,

On 2/23/12 11:15 AM, Damien Saucez wrote:
> 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?).

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 11:15:07 +0100

Hello Eliot,

Cheers,

Damien Saucez

On 23 Feb 2012, at 07:38, Eliot Lear wrote:

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