RE: [RRG] Hosts, DFZ, purity & incremental deployment

["Tony Li" <tony.li@tony.li>]

Hi Robin,


| 1 - A solution which requires host changes in both communicating
|     hosts is not incrementally deployable, since benefits only
|     accrue to a tiny proportion of end-users (people who use hosts)
|     due to the fact that initially, very few hosts have the
|     upgrades.


Hmmm... Well, you and I have very different semantics assigned to
"incremental deployability".  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.


| 7 - This leaves the following types of solution:
|
|     e - Upgrade only one host - if benefits accrue to
|         that host when communicating with non-upgraded
|         hosts.
|
|     f - Likewise, upgrade only one network, if benefits
|         accrue to that network and/or its hosts when
|         communicating with non-upgraded hosts in non-upgraded
|         networks.
|
|     g - Likewise, upgrade both hosts and networks to
|         achieve immediate benefits for one or probably
|         both, when communicating with non-upgraded
|         hosts in non-upgraded networks.
|
|     h - Upgrade some routers in the DFZ, which support
|         communications from all non-upgraded networks to
|         all upgraded networks, and then upgrade some
|         networks so that those networks and the hosts in
|         those networks (also the end-user networks which
|         connect to those upgraded networks) experience
|         immediate benefits.
|
|         Ivip, LISP with Proxy Tunnel Routers, APT and
|         (I guess) TRRP fit this description.


So from this perspective, I guess you'd define incremental deployability as
some manner of monotonically increasing benefit function, yes?  

Under your definition (which I don't agree with), your point certainly seems
valid.

However, under the looser definition of a non-decreasing benefit function, I
don't see that it follows.  Any two host can deploy a new namespace and
benefit from it for their private connections.  It's true that a single host
won't benefit, but that's not a corner case that I consider to be essential.

Tony


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