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.