Re: [RRG] What does incremental deployment mean??

[Robin Whittle <rw@firstpr.com.au>]

Hi Ran,

In "Re: [RRG] What does incremental deployment mean - 2 questions"
you wrote:

> As near as I can tell, everyone else already converged on a
> working definition for "incrementally deployable" -- and that
> definition is not consistent with your personal definition.
> Further, I haven't seen any recent support for your broader
> definition from others, though perhaps I've misplaced a note
> someplace.

My definition has more words but is much narrower than the criteria
Tony and Joel mentioned.  Do you have a definition you could post to
the list, perhaps with some examples of schemes which would pass,
fail or be borderline?

> I will also note that conversations in the hallway in
> Philadelphia lead me to believe that many (possibly most) RG
> members do believe that several proposals on the table (including
> LISP, but not limited to LISP) are incrementally deployable.

Sure - I think LISP, APT, Ivip and probably TRRP are all
"incrementally deployable" according to Tony's original definition
below.


I am not trying to change anyone's mind about what "incrementally
deployable" should mean.

However, I don't have a clear idea what people understand by the
term, and since the term is one of the requirements of the Design
Goals, I am seeking clarification of what most people think it
means.  Furthermore, if it means something like what Tony and Joel
wrote, then I think we need something more stringent instead.

I would appreciate you and other folks commenting on my argument:

  http://psg.com/lists/rrg/2008/msg00957.html

that something like (10) in that message would be a much better
criteria to evaluate map-encap proposals by, than whatever it is
most people understand by "incrementally deployable".

We can't cajole or force anyone to adopt the new address space, but
we are wasting our time unless most end-users adopt it.  That means
they need to adopt it willingly, for the immediate benefits they
receive.  That means the earliest adoptors need to experience
substantial and pretty much immediate benefits.  This in turn means
that the benefits to any one adoptor must still be high even when
few, or no, other end-users have adopted it.

I demonstrate how pre-PTR LISP fails the (10) test while Ivip or
LISP with PTRs passes it.

What do you think of my suggestion that your "Economic Incentive
Criteria" is interesting, but of no practical use to the RRG, since
we can't foresee the future commercial and regulatory environment?

Below my signature is an investigation into what various people seem
to think is meant by "incrementally deployable".  In the absence of
further messages from other people, this is the best I can do in
terms of guessing how other people understand a crucial part of the
Design Goals.

   - Robin


Various views on the meaning of "incrementally deployable":


Tony Li 2008-03-17

  http://psg.com/lists/rrg/2008/msg00816.html

>    I would consider anything that could be rolled out one host at
>    a time without breaking anything as being the maximal amount
>    of incremental deployability.

This is a simple criteria which proposals could be tested against,
but it doesn't exactly work with map-encap, which is per network not
per host.  Still, if applied to networks, it is very broad and I
think we need a much fussier criteria.


Joel Halpern 2008-03-17

  http://psg.com/lists/rrg/2008/msg00833.html

> One small aspect that I think I am seeing here is the same words
> ("incrementally deployable") being used to describe two different
> concepts. I may be confused, but it looks to me like:
>
> (1) Deployable incrementally without disruption:
>
>      This means that a portion of the net (host, site ISP,
>      whatever) can deploy the system without losing capability
>      or connectivity. A flag day is not necessary in order to
>      get the system operational.
>
> (2) Deployment incremental incentives:
>
>      This sounds like what Robin is asking for, and is related
>      to a bunch of work I have seen from folks like Dr. Odlyzko
>      on the economic incentives that are needed to drive
>      deployment.  It includes analysis of issues like when do
>      folks need positive return on new technologies to cause
>      them to deploy.
>
> They are both valid concerns. But I think they are two different
> dimensions.

This is two criteria in one - but the second one is not really clear
to me.

If this what most people understand by the words "incrementally
deployable", I don't see how we can use it as a test of an
architecture's fitness to be adopted by the RRG.


Tony Li 2008-03-20

   http://psg.com/lists/rrg/2008/msg00934.html

>   I liked Joel Halpern's characterization.  I thought he said it
>   all.

Yes, but how do we use (2) to evaluate a proposal, and combine the
result of that test with the result of (1), to get a yes/no answer?



--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg