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.
