Subject: [RRG] Characterizing incremental deployments

From: Brian Dickson <[email-masked]>
Date: Fri, 21 Mar 2008 01:45:28 -0400

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 [email-masked] 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