[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.)
- 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