[RRG] IPv4: how bad, when to fix?

[Robin Whittle <rw@firstpr.com.au>]

Can we agree that we need to recommend a fix for the IPv4 routing
scaling problem - and that this is our most urgent priority?  I
propose some text for potential consensus in a separate message
"Take 2: AA, BB, CC".

Here are some arguments about why we need to fix IPv4 first.


In the thread: "Re: [RRG] Long term clean-slate only for the RRG?"
Yakov Rekhter wrote:

> Perhaps we should first agree that there is a need a *short term*
> solution for both IPv4 and IPv6. The following (from Tony's e-mail
> on 5/26/2008) is relevant to the discussion on whether there is
> such a need:
>
>   Well, Ross Callon has been quoted as saying that the Juniper
>   implementation will have no problems up through many millions
>   of routes.
>
>   Now, conceptually, that could happen tomorrow.  However, at the
>   current growth rates, that's likely to be many years.


Previously, in http://psg.com/lists/rrg/2008/msg01612.html, Brian
Carpenter wrote:

> Dino Farinacci wrote:
> ...
>> Could we agree that one map-n-encap solution for both IPv4 and
>> IPv6 be a short-term solution while we work on a long-term
>> solution for IPv6-only?
>
> Clarifying question: do we have to hold our breath while
> waiting for the long term solution?
>
> But seriously - since it doesn't seem that we want to shrug our
> shoulders over IPv4, and I don't see the industry being willing
> to support two solutions, I don't see much choice.

I agree we can't shrug our shoulders and let today's Internet
degenerate, solely on the basis that we are devising another
Internet to which we assume everyone will happily migrate before too
long.

I would much rather develop a long-term solution at a relaxed pace
without expecting the rest of the world to hold its breath and wait
for our great creation to be ready for mass inhabitation.

Some other perspectives which seem to be critical of the view that
router technology will cope acceptably with the IPv4 routing scaling
problem - so we don't need to fix it and should concentrate on an
IPv6 or clean-slate solution:

In a message which was addressed to the list, but has not so far
been propagated, Eliot Lear wrote:

> Yakov,
>
> If IPv6 is any measure it could take 15 years to deploy the next
> thing.  Are you are willing to categorically state that there is
> no problem for that period of time?


Dino wrote:

> The routing table size problem is not the only problem. There are
> many enterprise sites that want to do low-cost multihoming, they
> want to be good citizens to the Internet and don't want to inject
> more specifics, and they want to control their ingress traffic
> flows.


Regarding the quote from Russ Callon: it is no surprise people from
the big router vendors say they can build routers to handle "many
millions of routes".  I am sure they can, for a price.  They would
be averse to stating there was some limit to their technical
capability.  However, Tony Li and maybe others in the RAWS workshop
did point out that relying on Moore's Law to cope with the scaling
problem was unrealistic.

http://www.iab.org/about/workshops/routingandaddressing/Router_Scalability.pdf

One difficulty with throwing silicon at the problem is that at some
point, the job has to be split between multiple CPUs with their own
RAM.  This raises some really nasty problems with costs, software
complexity and the CPU resources devoted to those separate route
processor systems communicating with each other so they behave as
one.  Likewise, fail-over protection becomes trickier still.

There are several other problems with this "millions of routes" idea.

Firstly, there are stability concerns with the BGP system handling
such numbers of advertised prefixes.

Secondly the number of routes a DFZ router can handle depends very
much on its memory and CPU capacity, in terms of how it handles the
number of DFZ routes *multiplied* by the number of interfaces which
 link to other DFZ routers.

In broad principle, the router has to maintain a separate
"conversation" about each route with each DFZ neighbour router - and
so has to engage in communications, store state etc. in proportion
to the total number of such "conversations".

So the adequacy of a "millions of routes" router in a particular
location depends just as critically on how many DFZ neighbours it
has as on how many routes there are in the DFZ.

   (It has been hard to determine how many DFZ routers there are,
    but a figure of 210k is regarded as a minimum.  Also, there is
    limited information about the distribution of the numbers of
    neighbours.  See the "Routers in DFZ - reliable figures from
    iPlane" thread:

       http://psg.com/lists/rrg/2007/msg00253.html
       http://psg.com/lists/rrg/2007/msg00255.html
       http://psg.com/lists/rrg/2007/msg00257.html
       http://psg.com/lists/rrg/2007/msg00262.html )


Thirdly, these mega routers are going to cost significantly more
than routers with CPU and RAM resources suitable for current (~260k)
numbers of DFZ routes.

Depending on the number of DFZ neighbours for any given router, and
the growth in the number of DFZ routes in the years to come, all DFZ
routers may need to be replaced with these expensive things.  To the
extent that these more expensive replacements occur partially or
solely due to the growth in the number of DFZ routes, then this is a
direct cost burden on ISPs and transit providers which could be
avoided by a solution for IPv4.  These costs are ultimately paid by
all Internet users.  (The trick is to devise a scalability solution
where the costs of adoption are less than the immediate benefits, so
it will be widely adopted.)

Since such costs of mega routers depend in part on the number of DFZ
routes, unconstrained growth in this number will cause increasingly
strong pressure against the further splitting up of the IPv4 address
space via the current BGP-only address management system.  This
further increases the costs and difficulties faced by the growing
number of end-user networks which need, but can't get, portable,
multihomable space.

The above seems to be restating the themes of RAWS 1.66 years ago:

  http://tools.ietf.org/html/rfc4984
  http://www.iab.org/about/workshops/routingandaddressing/

which itself largely involved restating concerns which have been
known for 16 or so years earlier.

All along this process, as far as I can see, some folks have been
focusing on fixing the IPv4 routing scaling problem first, while
others have been thinking it would be OK not to worry about it, and
to get IPv6 ship-shape in time for the mass adoption which has
always been expected "in the next few years".

Now, some people foresee IPv4 becoming rapidly more unworkable due
to the address depletion problem, which buoys their hopes for the
long-awaited mass-migration to IPv6.  I have argued there is a lot
of scope, especially with map-encap, for extending the productive
life of IPv4:

  Many more end-user networks could get their own portable,
  multihomable prefixes via map-encap, with little burden on the
  number of DFZ prefixes.  This is true as long as the DFZ prefixes
  which are the "Mapped Address Blocks" (Ivip terminology) the
  map-encap system splits into micronets (Ivip) or EID prefixes
  (LISP) are generally big blocks split which are split into many
  smaller blocks for large numbers end-user networks.

Opinions vary widely on how realistic this scenario is.  It depends
a lot on our visions of end-user networks, how small a patch of
portable, multihomable, public space they would be happy with, how
we think IPv4 space could be managed with map-encap, how address
space would in fact be managed as the address crunch develops etc.
Most people don't foresee much scope for improving IPv4 utilization,
but I think there will be enormous pressure to do this, and various
methods, including map-encap, will be devised to achieve it.


We have 0.75 years before the RRG's deadline.

We are supposedly going to produce a "single recommendation", but I
don't see how this is realistic.

It would take years to decide reliably on a long-term solution -
probably involving a radically new architecture, protocols and
therefore stack and applications.

I think we may be able to devise an optimal solution for IPv4.

Maybe we could do the same for IPv6 too.  However, that is not so
urgent.  Yet we want to have some idea about potential IPv6 or clean
slate solutions to help us make the IPv4 solution as compatible as
possible with the long-term solution.


I think there is something more important than theoretical
discussions on commonalities between architectures, such as Lixia's
focus: http://psg.com/lists/rrg/2008/msg01599.html

   >> The most substantial solutions to the routing scaling problem
   >> proposed so far are:
   >>
   >>    LISP-NERD
   >>    LISP-ALT
   >>    APT
   >>    Ivip
   >>    TRRP
   >>    Six/One Router
   >
   > From architectural view, I'd identify the commonality of
   > all the above as stopping topology-aggregatable prefixes at
   > the boundary of edge sites, not which version of IP they
   > may/not work with.

While this is true, Six/One Router can't solve the IPv4 scaling problem.

Since I think we need to work fast on IPv4 and can take more time
with IPv6 and clean-slate solutions, the question of whether an
architectural enhancement can support IPv4 is of primary importance
in our most urgent work.  In other words, we can't afford to ignore
important "details" such as the differences between IPv4 and IPv6,
and which potential solutions are applicable to them.

IPv4 is the only current problem.  Unless we are very relaxed about
continuing shortage of multihomable space for end-user networks, the
pressure this puts on the scaling problem when using BGP-managed PI
space for this purpose, the costs this places on ISPs, and the
difficulties faced by the end-user networks who can't get the space
they need, then this is a problem which needs to be fixed in the
next 5 to 8 years.

We can't reliably expect to have an alternative, scalable, Internet
widely adopted anywhere near soon enough to bring the IPv4 problem
to a halt in an acceptably short time.

Supporters of the contrary line - that we don't need to fix IPv4, or
that we can maybe fix it after we have figured out an IPv6 or
clean-slate solution - need to argue convincingly about development
and deployment times for their non-IPv4 solutions.  Then they need
to argue convincingly why most end-users would adopt new
applications, new IPv6 (or whatever) Internet services, and
reconfigure their entire networks and IT systems (to dual stack
initially), in a sufficient short time that the IPv4 scaling problem
would be acceptably limited.

  - Robin


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