[RRG] Characterizing incremental deployments

[Brian Dickson <briand@ca.afilias.info>]

Joel M. Halpern wrote:
> 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:
>
> 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.
>
> 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.
I think there are other aspects/dimensions to both the incentives to 
deployment (of any new/additional technology), and to non-disruptive 
deployment, that we should not ignore.

They can be characterized further, for example:

   * chicken/egg deployment issues:
         o The upgrades can be deployed to enable a new "thing" without
           disruption, however...
         o Multiple parties need to "jump" to the technology for it to
           be useful
         o Sites need to trade off backwards-compatibility with new
           benefits
         o Example: non-routeable addressing (EIDs) within an IP
           version (IPv4 or IPv6)
   * sunrise/sunset issues:
         o Early adopters need to deploy without any benefit at all, so
           that others can deploy for some benefit
         o Parallel technologies with parallel operational cost,
           running much like "ships in the night" on the same hardware
         o Operational scalability and cost-effectiveness presumes
           eventually completely displacing one of the other parallel
           technologies
         o If none of the other technologies sees sufficient decrease
           in use, this means running N+1 technologies for a long time,
           perhaps forever
         o E.g. any particular RRG-like proposal (map/encap, such as
           any of the LISP variants) in addition to vanilla IPv6 and
           vanilla IPv4
   * eyeballs/content dichotomies - "the pit and the pendulum"
         o These two large collective groups, which need each other,
           have different needs and different economic models/ecosystems
         o If cost parity between those parties (and their respective
           providers) is not maintained, on the evolutionary deployment
           of new technology, strong resistance from one group (the
           losing group) is likely to be seen
         o Successful deployment requires adoption by both groups
   * status quo momentum
         o In addition to the other issues concerning getting any
           *particular* solution deployed (e.g. once we narrow things
           down to a recommendation), there could be parties who don't
           want *any* change
         o Those parties may not play nice, and may address this at
           layers 8, 9, and 10 (including legal and political)
         o We should be sure the benefits are truly compelling, ideally
           universally so, and the costs so marginal as to be nearly
           negligible, before settling on a recommendation. That may
           mean more work for us, but it is a small price to pay.

These observations are not necessarily pointing to solutions, I realize.

But, the "right" answer depends on asking all the right questions. I'm 
suggesting that these are additional questions and issues that we need 
to consider.

Brian Dickson

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