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

From: Jari Arkko <[email-masked]>
Date: Thu, 08 Mar 2012 19:25:32 +0200

Thanks for your feedback, John. Would a modified charter with these changes work for you:

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 08 Mar 2012 23:13:35 +0200

I hear what you are saying. But I think the opinion in the IESG at least was, however, that those three really are high priority, and that other documents before them are not so useful before they are completed. I guess it is a different perspective, whether you do things top-down or bottom-up. I do agree with both points of view, actually.

Jari

---

From: Barry Leiba <[email-masked]>
Date: Thu, 8 Mar 2012 16:34:30 -0500

>> But it's not clear to me that these (especially architecture and impacts) can
>> be said to have been properly analyzed until some of the lower-priority items
>> (I'm thinking of threats, cache, ETR sync) have been fleshed out.
>
> I hear what you are saying. But I think the opinion in the IESG at least
> was, however, that those three really are high priority, and that other
> documents before them are not so useful before they are completed. I guess
> it is a different perspective, whether you do things top-down or bottom-up.
> I do agree with both points of view, actually.

The dependencies (threats, cache, ETR sync, and whatever else) can
certainly be discussed to the extent needed to lay out the
architecture and other priority documents, with notes taken and saved
for when other documents need to be produced.  That still says that
the working group needs to focus on discussion that leads to the
completion of the three priority documents first, before tackling the
others.  Everyone understands that these priority items can't be
developed in a vacuum; we just don't want things to wander off into
lower-level details such as protocol elements and text that can wait
for the next phase.

Barry

---

From: John Scudder <[email-masked]>
Date: Thu, 8 Mar 2012 12:51:10 -0800

Jari,

This is pretty good, thank you. I have one further comment. You guys have prioritized three of the work items:

"The first three items (architecture, deployment models, impacts) need
to be completed first before other items can be submitted as RFCs."

But it's not clear to me that these (especially architecture and impacts) can be said to have been properly analyzed until some of the lower-priority items (I'm thinking of threats, cache, ETR sync) have been fleshed out. So although I understand your desire to move these three forward I question whether the strong mandate to do them first is a good idea. Possibly continue to state that they're a priority without actually gating other work, so that the WG can make its own decision about working on dependencies as needed?

--John

On Mar 8, 2012, at 12:25 PM, Jari Arkko wrote:

Jari

<charter-as-modified.txt><charter-as-modifi-from-propos.diff.html>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 13 Mar 2012 15:04:36 -0400

Actually John, I would have to disagree with your assertion about what 
it takes to describe the archtiecture.
It may take engineering and evaluating some cache management schemes 
before one can decide whether the archtiecture is a good one.  But that 
is very different from being able to describe the archteicture so that 
one can understand the system level behavior.

Yours,
Joel

On 3/13/2012 2:37 PM, John Scudder wrote:
> Barry and all,
>
> On Mar 8, 2012, at 4:34 PM, Barry Leiba wrote:
> ...
> You don't want to boil the ocean; that's fine. My point is that without covering (at least) cache management and ETR synchronization, the architecture will not be done. Think about the old joke about the mathematical proof that includes "... then a miracle occurs" as one of its steps (http://star.psy.ohio-state.edu/coglab/Miracle.html). Similarly, threats and the impacts document.
>
> One way to handle this (other than what I've already suggested) might be to explicitly note that the respective documents should cover these topics. For example (edits set off by [[ ]]):
>
> - 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. [[The document will
>    cover relevant issues including though not limited to cache
>    management and ETR synchronization.]]
>
> and
>
> - 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. [[The document will discuss potential security-
>    related impacts, whether positive or negative.]]
>
> Regards,
>
> --John
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 13 Mar 2012 20:43:49 +0100

John,

On 3/13/12 8:23 PM, John Scudder wrote:
> Re cache management schemes, I think that depends on whether you mean "system level behavior" of a small-scale system, or one operating at large scale or under some kind of stress. The earlier discussion notwithstanding, for practical purposes caching is central to LISP; as such, it's a little weird to say it's architecturally unimportant.

I don't think Joel is saying that it is architecturally unimportant, but
rather that within the architecture it various caching schemes may work
better than others, and that experience may dictate the answer to this. 
What are system effects, by the way, is its own interesting question.

Eliot

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 14 Mar 2012 10:46:37 -0400

Relevant?  Yes.
Gating?  No.

In fact, I would put it the other way around.
The architecture documentis very useful, almost necessary, for deciding 
whether the solution is a good one.
The cache management evaluations are another component of such an 
evaluation.
Even understanding the cache management quesiton is made significantly 
easier by having a clean architecture description.

Yours,
Joel

On 3/14/2012 10:40 AM, John Scudder wrote:
> One further remark:
>
> On Mar 13, 2012, at 3:04 PM, Joel M. Halpern wrote:
> ...
>> before one can decide whether the archtiecture is a good one.
> ...
>
> Agreed.
>
> Isn't it relevant to the architecture document, that it be possible for a reader to judge whether the architecture is a good one or not?
>
> --John

---

From: Barry Leiba <[email-masked]>
Date: Wed, 14 Mar 2012 11:02:56 -0400

> Even understanding the cache management question is made significantly

Indeed.

At the risk of straining things with an analogy, I'll liken this to
architecture of a building.  At the architecture level, we do have to
consider, say, bathrooms, and it's reasonable at that level to talk
about having bathrooms on each floor, and perhaps the extent to which
accessible bathrooms are needed.  Deciding whether to have two pairs
or three per floor is something that can be left to the detailed
post-architecture specifications, and things like what sorts of
fixtures to put in them *absolutely* come later.

No one is saying that some discussion of caching issues (etc) won't be
needed in defining and specifying the architecture.  We're just saying
that it's not necessary to do the caching document before, as long as
the related discussion that happens at the architecture stage is
preserved for when it's time to work on the caching doc.

Barry

---

From: John Scudder <[email-masked]>
Date: Tue, 13 Mar 2012 11:37:05 -0700

Barry and all,

and

Regards,

--John

---

From: John Scudder <[email-masked]>
Date: Tue, 13 Mar 2012 12:23:20 -0700

Joel,

Re ETR sync, I think not even that much wiggle room exists.

--John

Yours,
Joel

and

Regards,

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

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 13 Mar 2012 21:07:00 -0700

> Re ETR sync, I think not even that much wiggle room exists.

I beg to differ. What happens if an iBGP mesh is not configured properly? Does that mean the BGP architecture is broken? 

We have said in the past, several times, that if the ETRs are out of sync, then the ITR that gets a Map-Reply from one of them, then the ITR uses the locators configured from that ETR. The system works, if it is misconfigured, it works less well.

So I believe the issue could be closed IMO.

Dino

---

From: John Scudder <[email-masked]>
Date: Wed, 14 Mar 2012 07:40:36 -0700

One further remark:

...

Agreed.

--John

---

From: Barry Leiba <[email-masked]>
Date: Wed, 14 Mar 2012 11:30:01 -0400

> I don't think the proper analogy
> is a bathroom. Everyone knows you can build bathrooms that work, having
> seen successful examples in the past. You might instead think of a building
> which includes a perpetual motion machine [*] as a key element.

Fair enough, and now I understand where you fall on the issue.

I agree that my analogy wasn't fully to the point.  But here's the question:
Do you really think the entire discussion has to finish in order to do
a meaningful architecture?  Is it not possible for the architecture
document to have a section about <strike>perpetual-motion
machines</strike> caching that talks about the needs, the benefits,
the drawbacks, and the tradeoffs, and leaves the final design and
decisions for later?  Such a section might well explain why the
required caching is difficult, bordering on impossible to get right,
or whatever.

At this level, do we need to *resolve* the questions and all the
design points?  Or is it possible to have a useful document that helps
everyone understand the issues, while leaving many of those issues
unresolved until later?

Barry

---

From: John Scudder <[email-masked]>
Date: Wed, 14 Mar 2012 08:20:26 -0700

Barry,

On Mar 14, 2012, at 11:02 AM, Barry Leiba wrote:

Relevant?  Yes.
Gating?  No.

Indeed.

Analogies are always risky, but I'll continue. I don't think the proper analogy is a bathroom. Everyone knows you can build bathrooms that work, having seen successful examples in the past. You might instead think of a building which includes a perpetual motion machine [*] as a key element.

--John

[*] Forgive me, press of time prevents me from finding an example which is both less inflammatory, and still has the property "something whose practicability is debatable." Feel free to fill in your favorite.