Subject: [lisp] The other question

From: [email-masked] (Noel Chiappa)
Date: Wed, 23 Sep 2009 16:20:37 -0400 (EDT)

In the process of doing somthing else, I ran across a point that I thought
would probably be useful to point out to the WG as a whole.

My perception is that the WG is not as good as it could be at paying
attention to the question of _when_ to make changes; it seems to prefer
mostly to focus on _if_ it should make a change. I think that's a big
problem, since playing with that 'when' variable can make a big difference
in the total costs and benefits of the change.

The thing is that this WG is in a rather unusual postion, as IETF WG's go
these days, in that it's not the usual 'design before implement' environment.

There is a sizeable test-bed running this stuff, and we're learning all
sorts of valuable lessons from it, including finding obscure bugs in the
protocol, its interaction with existing infrastructure, etc. LISP will be
running in a complex environment (lots of deployed data-handling
infrastructure, running tunnels, other kinds of boxes, yadda-yadda), and
there's just no substitute for the actual experience the testbed is giving
(and has given us; it's been around for years).

For a simple protocol, in a simple environment, you might be able to do a
pretty good job with a sheet of paper. In this complex, existing,
environment, experience is critical.

The downside of a testbed (TANSTAAFL) is that making changes has costs
beyond a new rev of the document. An incompatible change means a flag day
(or days) for the testbed; a large change means that not only do we lose
the test-bed for a while, but also developer attention has to go to doing
the change.

So changes have costs. But changing the 'when' can significantly impact those
costs, and so change the cost/benefit ratio of the change. So let's not just
talk about 'if' when it comes to changes, but let's give 'when' prominent
consideration too.

	Noel

---

From: John Zwiebel <[email-masked]>
Date: Wed, 23 Sep 2009 10:27:20 -1000

On Sep 23, 2009, at 10:20 AM, Noel Chiappa wrote:

> So let's not just

+1

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 23 Sep 2009 17:47:49 -0400

Conceptually, I agree.
However, there are complications.
In general, the longer we put off making a change, the harder it will be 
for the folks who have to implement it.
Bundling several changes together makes very good sense.

But, if there is something architectural in the design which will affect 
future flexibility, then (assuming the WG agrees with that description 
rather than it just being my delusion about some corner case) it would 
seem to be necessary to put that sort of change in before RFC publication.
The recent discussion of the architectural role of MS/MR devices is one 
where I do think we need to resolve it before RFC.  Testing in the short 
term probably won't tell us anything, because the issues are all about 
long term direction and architecture.
(To be clear, the resolution may well be that the current approach is 
right.  But I don't think that can be based on "primarily because it is 
what we already implemented.")

At the same time, since it is a long term issue, I have no problem with 
having an extended discussion over several months, and putting 
refinements into the same portion of the document (such as Vince's 
change) so that the interim stuff works better.

Yours,
Joel

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