RE: [RRG] What does incremental deployment mean

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

Robin,

>-----Original Message-----
>From: Robin Whittle [mailto:rw@firstpr.com.au] 
>Sent: Tuesday, April 01, 2008 11:22 AM
>To: rrg@psg.com
>Cc: Templin, Fred L; Xu Xiaohu; Dino Farinacci; Noel Chiappa
>Subject: Re: [RRG] What does incremental deployment mean
>
>Hi Fred,
>
>You wrote:
>
>>> From: Xu Xiaohu [mailto:xuxh@huawei.com] 
>>> Hi Noel and Dino,
>>>
>>>>> You can drop the "Without that commitment". It's very simple:
>>>>>
>>>>>  Any solution that *requires* host changes is infeasible.
>>>
>>> According to this criteria, many proposals, including v6 EID over v4
>>> RLOC of LISP have been sentenced to death.
>> 
>> I don't think this is true at all; at least it better not
>> be. AFAICT, IPv6 as EID and IPv4 as RLOC is our best path
>> toward an IPv6 Internet.
>
>I think it is true, since v6 EIDs mean that all participating hosts
>must be using IPv6 addresses for all their applications.
>
>This can't happen for a large number of hosts, or a nearly complete
>coverage of hosts, without major host changes to their OS and/or
>their applications.
>
>Also, these hosts would need IPv6 connectivity in some way, at least
>to and from the ITRs and ETRs they rely upon - so that would involve
>router changes, more ISP management work etc.  If the IPv6
>connectivity only went as far as the nearest ETRs and ITRs, how
>would hosts send and receive packets to and from IPv6 hosts which
>were not part of the map-encap scheme?
>
>From what I understand from your description of ISATAP:
>
>  http://psg.com/lists/rrg/2008/msg01086.html
>  http://www.ietf.org/rfc/rfc5214.txt
>
>all participating hosts must be using IPv6 for all their applications.
>
>That means ISATAP would not come close to meeting the criteria of
>deployability I described in (10) here:
>
>  Re: [RRG] What does incremental deployment mean - 2 questions
>  2008-03-22 http://psg.com/lists/rrg/2008/msg00957.html
>
>This criteria has no short name, but here are two shortish
>descriptions, followed by a fuller definition:
>
>     "No significant barriers to widespread deployment due to
>      initially low uptake rate, or disruption of existing
>      practices"
>
>or:  "The zero (or relatively low) critical mass criteria for
>      ubiquitous deployment on an incremental basis without
>      outside inducements"
>
>
>  (10) The technology must be able to be introduced without
>       disrupting existing practices.  After some low
>       specified level of initial deployment, ideally zero,
>       everyone (or at least most people) who deploys the
>       technology receives benefits (maybe net benefits in
>       some short enough time-frame after accounting for
>       one-off purchase and installation costs) which are
>       not only positive, but substantial and likely to
>       attract many other end-users to the technology.
>       For this to be true, the benefits received must not
>       depend much or at all on what proportion of other
>       users have adopted the technology.  Therefore, if the
>       technology would be fundamentally attractive to many,
>       most or all end-users once deployed by most or all
>       end-users, it would also be attractive enough to the
>       very first (or after some low, specified, level of
>       adoption) to actually become widely deployed via a purely
>       incremental means, without inducements or a major up-front
>       deployment before any end-users gain significant benefits.
>
>I think any map-encap scheme needs to meet the above criteria before
>we could consider developing and deploying it.  (The above is what I
>always thought was meant by "incrementally deployable", but I now
>recognise this is much more stringent than what some or many people
>meant by this term.)

ISATAP allows dual-stack nodes to discover routers that
can reach destinations on the global IPv6 Internet.

ISATAP is already widely implemented and deployed; in
many deployments it is even turned on by default.

Thanks - Fred
fred.l.templin@boeing.com  

>
>  - Robin
>

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