Re: [RRG] Moving forward... IPv4 now, IPv6 less urgent and perhaps more ambitious

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

I am replying to Tony Li and David Conrad - and requesting the views
of the LISP and APT developers on my proposed text:

  http://psg.com/lists/rrg/2008/msg01444.html

Tony wrote:

> |There is currently only one routing scaling problem - in the IPv4
> |Internet.  There's no hurry about solving the IPv6 routing scaling
> |problem because it will only occur if and when IPv6 is widely adopted.
> 
> I have a lot of sympathy for where you're coming from, but I have to
> disagree.  Yes, we have one routing scaling problem, but it's the IP routing
> architecture, and it's common for both v4 and v6 because both use exactly
> the same routing architecture.  

There is a potential routing scaling problem because the IPv4 and
IPv6 routing systems are identical in respect of the limitations
which give rise to the problem.  However the IPv6 system does not
have the physical problem so far because very few people use it.

This is a routing and addressing scaling problem and I think it is
is only solvable by creating some new kind of address space which
provides multihoming etc. in a scalable way.

The fact that IPv4 and IPv6 use exactly the same routing structure
does not mean that the solution needs to be the same, because there
are significant differences in the addressing systems:  IPv6 has 96
more bits and a vast, currently largely uninhabited space.

This enables that compared to an IPv4 solution, an IPv6 solution can
involve different assignment policies and new protocols making more
creative use of address bits.  For instance IPv6's larger address
space makes it practical to have duplicate address ranges going to a
translation router, such as with Six One Router: one from each
upstream ISP, each of the same length as the end-user prefix.  See:
http://psg.com/lists/rrg/2008/msg01314.html


> There's no hurry to fixing it for IPv4
> because frankly, we can scale the hardware to support the usual PI prefix
> sizes (/24 -> 2^24 routes == 16M routes).  Yes, it will cost a bit more, but
> over the long run, that's probably a lot cheaper than upgrading every CPE or
> PE router.

If your view reflects consensus in the RRG, then perhaps we could
form rough consensus on something like this:

  While some architectural enhancements could solve the routing and
  addressing problem by creating a new kind of address space which
  is portable, multihomable etc. without significantly burdening the
  BGP system, we believes that none of them could be practical or
  cost-effective enough to warrant development or deployment for
  IPv4, compared with letting the current system saturate towards
  16M individually routed /24s.

If so - and if I believed this was a viable solution - then I would
mothball Ivip until about 2020.

You are suggesting the current DFZ size of 250k:

  http://bgp.potaroo.net   Ooops make that ~260k . . .

should be allowed to grow a factor of up to 64 without any changes
in the BGP system or any architectural enhancements.

If this could be done, then we could split up the IPv4 space finely
and make pretty good use of it, without any new map-encap scheme
etc.  Quite a large number of end user networks could work fine with
a /24.

However, map-encap would be much better because a much larger number
of end-user networks could scalably have their own portable,
multihomable space, in any address size - 1, 2, 4 etc. through 256
IP addresses and beyond.  The right map-encap system could also
support a new global form of mobility.

I understand that for considerable, but perhaps not unthinkable,
expense the 200k+ (and more in the future) DFZ routers could be
upgraded to have FIBs to handle this.  My first suggestion (early
2007, now abandoned) for the routing scaling problem:

  http://www.firstpr.com.au/ip/sram-ip-forwarding/

was just this, when I thought that the FIB was the problem, not the
RIB and the associated BGP communications.

My understanding of your suggestion is that it is much the same as
my now-abandoned solution: flat routing to /24 with souped up
SRAM-based FIBs and hoping that Moore's Law would affordably provide
the extra CPU and RIB RAM grunt required to handle the up-to 64
times increase in the number of conversations each DFZ router needs
to have with each of its peers.

No-one would have gone to the trouble of developing a map-encap
proposals if we thought that it was acceptable to let the IPv4
system degenerate as you suggest without any new architectural
system for taking the load off the BGP system.

None of the map-encap systems were made with the intention that IPv4
be left to fester in a swamp ten or more times bigger than its
current predicament.  They are all described initially in terms of
fixing IPv4.

Surely enough was agreed at RAWS about problems with BGP stability
and the load on CPUs and RAM to make your suggestion of leaving IPv4
alone a non-starter.


> Where we have major issues is (and, admittedly, if we transition to) v6.
> Since the canonical PI prefix is a /48, we will have a very serious problem
> on our hands.  Now, I'm no lover of v6 and I think my views on it are pretty
> well known.  While you may not take v6 very seriously, there are those that
> do, and frankly it's our joint responsibility to plan for its adoption.  

I totally agree we should plan for widespread IPv6 adoption.  My
text reflects the facts that the IPv6 solution is not so urgently
required and that an IPv6 solution could take advantage of a number
of IPv6-specific conditions which unfortunately don't apply to IPv4.

> We have had one 'success disaster' with v4 and we need to prevent the same
> thing from happening to our grandchildren.  I'll happily stipulate that we
> don't know when a solution will be necessary.  

OK - we don't yet know when an IPv6 solution will be necessary.

> V6 deployment has been about
> 15 years running so far and shows no signs of reaching critical mass anytime
> soon.  However, this is also partly why this is considered a _research_
> topic, not an engineering one.  

As I suggested, I think we would be doing our job well if we
suggested several promising approaches to IPv6, since there is no
urgency about deciding on which should be developed and deployed.  I
think the situation with IPv4 is urgent enough that we should find
the most promising solution, or class of solutions, and recommend
that for immediate development.  Perhaps we won't reach consensus on
one, but there may be considerable support for two solutions.  If
so, that is the best we can recommend.  If we can't reach much
consensus on anything, then I think our report should reflect that.


> |However, I can't rule out that there may be some fancier, better and
> |more ambitious approaches to solving the IPv6 routing scaling
> |problem.  This includes fundamentally different approaches,
> |especially if we contemplate changing the IPv6 protocols.
> 
> ... And that's exactly what we are chartered to explore.

Yes, but I would be surprised if there is consensus that the IPv4
routing and addressing problem is so inconsequential that we don't
need to recommend a more specific and better researched solution for
IPv4 than we do for IPv6.


David Conrad wrote:

> Um. 433 words instead of 28?  In order to reach rough consensus on
> the direction the group is taking?  Do you, perhaps, get paid by
> word?  :-)

I wish.

> More seriously, while I understand some of your concerns (and
> disagree with others), I think we need to plant a stake in the
> ground to demonstrate at least some progress has been made.

Yes, but not if the statement involves shortcuts that fence us off
from the optimal combination of recommendations.  Nor if the
statement is insufficiently meaningful to constitute progress, for
instance by not eliminating any significant part of the solution space.

Despite its length, I think my text has a good signal-to-noise ratio
because it:

  Usefully fences off certain parts of the solution space for IPv4
  (host changes, except perhaps for minor performance enhancements).

  Emphasises that the IPv4 solution needs to involve immediate and
  lasting benefits over costs for ISPs and end-user networks.
  (Implicitly, this is because without coercive powers, the only
  way the IETF can ensure sufficiently widespread adoption to
  substantially solve the problem is by making the solution directly
  attractive according to costs and needs of a large majority of
  potential adopters.  Almost no-one will adopt it simply because it
  is a solution to the scaling problem if it involves any costs or
  disruption, which it certainly will.)

  Commits us to devising an IPv4 solution for immediate development
  and for deployment in what I think is the earliest practical
  time frame.

  Gives us more flexibility in the IPv6 solution space, because it
  is a broader space and because there is no urgency.


> The statement Tony provided is pretty watered down with respect to
> saying much of anything, but it at least points to a
> prioritization and one that I'm comfortable with.  As such, I'm OK
> with the wording as is (although I might prefer "Our
> recommendation must be ..." since it "must" appears in the second
> sentence).

OK.  Based on recent messages of support for Tony's text, I am
surprised by how many people seem to think we don't need to solve
the IPv4 problem.

Where are the LISP and APT developers on this question?  (Bill
Herrin supports my text.)  I think we all went to a lot of trouble
to develop our solutions because we believe something really is
needed ASAP for IPv4.  That was the impetus behind the RAWS workshop
20 months ago.

In my view, there are no other potentially practical solutions for
IPv4 than the map-encap systems.

If the map-encap developers are outvoted in some sense by other folk
who believe there isn't a need to solve the IPv4 routing scaling
problem, then I think that the consensus view would have resulted
from the views of people who haven't yet devised an IPv4 solution
prevailing over those of people who think they have.

If so, folks outside the RRG - who are seriously concerned about the
IPv4 problem in terms of costs and stability now and in the years to
come - will regard the IPv6-centric work of the RRG as irrelevant.
If this eventuates, then the RAM list and later the RRG list will
have been productive in terms of supporting the development of a
bunch of map-encap solutions for IPv4 which the RRG chose not to
recommend.

 - 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