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,
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
On 16.02.2012 19:00, John Scudder wrote:
Hi Thomas,
On Feb 15, 2012, at 4:31 PM, Thomas Narten wrote:
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.
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf