Hi Robin,

FWIW I like what's here. However, if we subsequently find ourselves in  
a world where IPv6 remains undeployed, and (possession of) IPv4  
continues to represent a critical bottleneck to nontrivial  
participation in the routing system, then most/all of the maxims below  
would seem to be largely or exclusively relevant to "incumbent" IPv4  
holders. If I'm not off-base in this observation, it would have two  
troubling implications. First, it suggests that this particular vision  
of incremental deployability foregoes, if not excludes, one of the key  
drivers of technology change in other sectors -- i.e., the possibility  
of early adoption led by aspiring new entrants, in this case aspiring  
routing services providers. Second, while the recommendations should,  
if followed, increase the odds of the associated technology being  
widely deployed, it would still leave the fate of the technology in  
question to be determined absolutely by "incumbent" routing system  
participants. In this specific sense, a future technology that  
satisfies all of the requirements for "incremental deployability"  
might still end up getting effectively "vetoed," in the way that (some  
say) IPv6 has been vetoed.

Before I even attempt to suggest what kind of extensions or  
modifications might serve to remedy this perceived "incumbent bias"  
I'd be very interested in hearing reactions from others...

Thanks,

Tom Vest


On Apr 15, 2009, at 10:40 PM, Robin Whittle wrote:

> Short version:  I hope many people will agree with something like:
>
>
>                A successful solution to the routing and addressing
>                scaling problem is tightly constrained by the need
>                for it to be voluntarily adopted by the great
>                majority of end-user networks of all sizes who want
>                or need multihoming, inbound traffic engineering
>                and/or portability of their address space between
>                ISPs.
>
>                Broadly speaking, this means that at the time of
>                introduction:
>
>                 1 - The solution must provide immediate and
>                     compelling benefits to the end-user networks
>                     who adopt it, irrespective of how many other
>                     networks have so far adopted it.
>
>                 2 - Therefore, it must provide multihoming, TE and
>                     portability for the adopting networks in a
>                     manner which fully supports communications with
>                     all hosts - including all hosts in non-upgraded
>                     networks.
>
>                 3 - Therefore, the solution must be compatible with
>                     all hosts (stacks and applications) and routers
>                     in non-upgraded networks.
>
>                 4 - The solution must be compatible with all
>                     existing applications in the adopting networks.
>
>                 5 - Although in principle, some or many host stacks
>                     could be upgraded in the adopting networks, the
>                     difficulties this presents means that a scalable
>                     routing solution will only be widely enough
>                     adopted on a voluntary basis if no such upgrades
>                     are required in order for the new system to
>                     provide compelling benefits.
>
>                     Firstly, there are difficulties in motivating
>                     operating system / stack programmers to add and
>                     test new facilities.  Secondly there may be
>                     costs and disruption for the adopting network in
>                     upgrading the stacks.  Thirdly, in many or most
>                     end-user networks, some or many hosts will not
>                     be amenable to stack upgrades due to them using
>                     operating systems which are no longer being
>                     maintained or developed.  This is especially
>                     the case for devices such as printers, routers
>                     etc. which do not use one of the major operating
>                     systems.
>
>                 6 - The solution must be compatible with all
>                     existing DFZ routers.  (Unless it can be shown
>                     that all DFZ routers can be upgraded - such as
>                     via a software update - by the time of
>                     introduction.)  [See note at end of message.]
>
>                 7 - The solution must be attractive for the large
>                     number of smaller networks who currently cannot
>                     get PI space to do multihoming etc.  Our goal is
>                     not just to reduce the number of DFZ routes but
>                     to enable a much larger number of end-user
>                     networks to gain multihoming, TE and portability
>                     than is currently possible.
>
>                 8 - Ideally the solution will also be attractive for
>                     most or all end-user networks who currently have
>                     their own PI prefixes.  This is firstly to
>                     improve scaling by attracting those larger
>                     end-user networks away from their current
>                     conventional PI address space usage and secondly
>                     to ensure that smaller networks which aspire to
>                     be bigger in the future will perceive the new
>                     kind of scalable end-user network address space
>                     as suitable for their long-term needs.
>
>                 9 - Ideally the new system should not compromise
>                     security or performance compared to that of
>                     current PI or PA techniques.  Any degradation
>                     in security, packet path lengths, end-to-end
>                     packet transit times, packet loss rates and
>                     general robustness etc. needs to be more than
>                     compensated for by reduced costs and/or benefits
>                     such as a more flexible and responsive
>                     multihoming restoration capability than is
>                     possible with current BGP techniques.
>
>                10 - The solution will not be widely enough adopted
>                     if it requires upgrades to the internal routers
>                     of adopting networks - except perhaps in very
>                     small networks such as SOHO where one or a few
>                     routers need upgrading anyway to perform ITR and
>                     ETR etc. functions.
>
>                In the longer term - in the years and decades to
>                come - upgrades to DFZ routers, to ISP and end-user
>                network internal routers and to host stacks can be
>                made without significant cost or inconvenience and
>                may allow enhanced performance for the new system.
>
>
> I counted 4 people, including myself, supporting my statement about
> the scalable routing problem in the "Re: Point of order" thread:
>
>  http://www.ietf.org/mail-archive/web/rrg/current/msg04786.html
>
>    It is a problem whose solutions are tightly bound by the need for
>    compatibility with all existing hosts and most existing routers -
>    and by the need to ensure immediate benefits for early adopters,
>    since the solution will only work if it is voluntarily adopted by
>    most end-user networks which want multihoming, portability etc.
>
> Xiaoliang Zhao (4789), Dino Farinacci (4794) and John Zwiebel (4801).
>
> Joel, you are the only one so far to disagree:
>
>  http://www.ietf.org/mail-archive/web/rrg/current/msg04797.html
>
>> If "it" is a solution to the problems of routing scalability,
>> reliability, robustness, etc that the rrg was chartered to work on,
>> then I do not believe we ever agreed that compatibility with all
>> existing hosts was a requirement.
>
> I wasn't suggesting we had all agreed to this, or that "rough
> consensus" on this had been achieved.
>
> The sentence I wrote was a terse version of what I believe to be
> true.  I believe it would be a good idea to reach rough consensus on
> something like this, such as the new text above.
>
>
>> Deployability in such a way that existing hosts and existing
>> routers can interwork with any solution, deployability such that
>> there is value in incremental deployment, and migratability so that
>> incremental deployment is possible are all things I would buy into.
>
> I agree with this, according to my understanding of "incremental
> deployment" - but after much debate from 2007-11-07 to 2008-04-10 I
> discovered that my understanding of this term could not be defined in
> a few words, and was considerably more complex than the meaning
> several other people ascribed to this term.
>
> You contributed to the debate on 2008-03-18:
>
>  http://www.ietf.org/mail-archive/web/rrg/current/msg01775.html
>
>> 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 agree entirely.  I realised that my use of the term "incrementally
> deployable" involved all the conditions for people being motivated
> to adopt it - in particular by the scalable routing solution
> providing real benefits for the adopters even when very few other
> networks have so far adopted it.  I think this means the system must
> provide multihoming, TE and portability of address space in a way
> which works with all incoming packets, including those from
> non-upgraded networks.
>
> Brian Dickson responded to your message:
>
>  http://www.ietf.org/mail-archive/web/rrg/current/msg01881.html
>
> raising 15 separate points in 4 categories, including:
>
>    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.
>
> which I entirely support.
>
> You also wrote (2008-03-20):
>
>  http://www.ietf.org/mail-archive/web/rrg/current/msg01848.html
>
>> I realize that there has to be a limit how far down the economic /
>> business analysis we go. Among other things, we need to start by
>> coming up with ideas, without regard to such limits. But when it
>> comes to deployment analysis, ignoring the question of who pays,
>> and why, is just not going to work. We don't need (don't want, and
>> can't) to mandate a business model. I would hope that a sensible
>> recommendation allows for multiple business models. But if we can
>> not even imagine one that works, then it fails.
>
> which I also entirely support.
>
> On 2008-04-02 I came up with a detailed description of the deployment
> requirements of a successful scalable routing solution:
>
>  http://www.ietf.org/mail-archive/web/rrg/current/msg02030.html
>
> ======
>
>     "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.
>
> ======
>
> That's a bit of a mouthful, but it is quite a task to fully describe
> the constraints of upgrading the routing and addressing system of the
> Internet when we are relying on purely voluntary adoption by end-user
> networks and their ISPs.
>
>
> The text at the start of this message is an attempt to rewrite the
> sentence Xiaoliang Zhao, Dino Farinacci and John Zwiebel supported,
> in the hope that you and many others will support it too.
>
> You wrote:
>
>> And I do not agree that getting clear terminology is irrelevant to
>> getting to such a goal.  I have frequently found it very confusing,
>> and a hinderance to progress, to realize that the person I was
>> talking with meant something different by the terms he was using
>> than I meant by them.  Yes, it happens.  But that does not make it
>> helpful.  Getting a set of terms we can agree upon, and using them,
>> can be very helpful.
>
> Yes, but I do not want to try to define exact semantics for
> "incrementally deployable".  I am wary of using the term at all,
> without explicit definition, because it apparently means different
> things to different folks, as indicated by the debate over a year ago:
>
> http://www.google.com/search?q=RRG+"incrementally+deployable"+site 
> %3Awww.ietf.org+-"rrg+Discussion+Archive"
>
>  - Robin
>
>
> Note regarding upgrading DFZ routers:
>
>   If all DFZ routers (or every DFZ router between any ITR and
>   any ETR) can be replaced or upgraded with a firmware update
>   before the solution is deployed, then we could gain
>   considerable benefits.
>
>   There may be other benefits of this, but I am thinking of
>   Modified Header Forwarding as an alternative to encapsulation
>   - which would eliminate encapsulation overheads and greatly
>   reduce ITR and ETR complexity, due to avoiding the Path MTU
>   Discovery problems which are inherent in encapsulation:
>
>     http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw
>     http://www.firstpr.com.au/ip/ivip/ivip6/
>
>   How soon must a solution be deployed?
>
>   The IPv4 DFZ routing table http://bgp.potaroo.net currently has a
>   doubling time of about 5.3 years.  I think it will be 5 years or
>   more before we really try to deploy a scalable routing system for
>   IPv4.
>
>   IPv6 DFZ prefixes (click number for IPv6 prefix count at
>   http://bgp.potaroo.net/v6/v6rpt.html) currently number about
>   855 which is 1/256 of the 219,603 for IPv4.  The doubling
>   time is between 2.7 and 4 years.  Even with a doubling time of
>   2 years, it would take 16 years to reach the current IPv4
>   numbers.
>
>   So I think it will be perfectly feasible to have IPv6 DFZ
>   routers upgraded for Modified Header Forwarding in time
>   for a scalable routing solution.
>
>
> _______________________________________________
> rrg mailing list
> rrg@irtf.org
> http://www.irtf.org/mailman/listinfo/rrg