Re: [RAM] First cut at routing & addressing problem statement

Hi Thomas,

I think the Problem Statement is well written.  The only typo I
found is that the final sentence in the definition of RIB should
be deleted.

I suggest this be added to Section 6:

  6. Ensures continued reachability from hosts in non-upgraded
     networks to those hosts which directly use the new
     architecture - such as by having an addresses which uses a
     tunnel-based mapping system to enable portability,
     multihoming and traffic engineering without further burdening
    the BGP routing system.

I have one big suggestion and a few smaller ones.

The Statement mentions the looming shortage of IPv4 address
space, but doesn't consider it to be part of the Problem to be
solved.  I think this is the biggest technical problem facing the
Net itself - not counting regulatory problems, botnets, spam and
general security problems with the computers and how they are used.

The Statement recognises that a future solution to the Problem
as currently defined could have great benefits for Mobile IP.

I think it would be good to also recognise that a future solution
to the Problem as currently defined (Section 6) might be able to
help with the IPv4 address shortage, by enabling a much finer
allocation system to end-users, giving them as few addresses as
they actually need, rather than with the current minimum
assignment size of 256 IPv4 addresses.

Another approach would be to define the IPv4 address shortage as
part of the current Problem.  I think this is the best idea, for
two reasons:

1 - The reason for the shortage is the poor utilisation
    of IPv4 address space - which is a direct result of the
    limitations of the BGP system in not being able to
    globally route millions or hundreds of millions of
    prefixes.  Currently, it can only handle a limited number
    of divisions, each of 256 IPv4 addresses or more - and
    ideally these chunks should be advertised in a manner
    which aids route aggregation.

2 - I think the "IP-level" solutions - LISP, eFIT-APT and Ivip -
    to the other parts of the routing and addressing Problem as
    currently defined will also enable a substantial solution of
    the IPv4 address shortage by enabling space to be more finely
    divided between many more end-users.

We are running out of space with 3.7 billion addresses available,
but less than 10% of those addresses are used, as far as I can
tell.  (I could only find just over 100 million with ping, which I
know has its limits.)

The Statement's current wording could be interpreted as indicating
that IPv4 address space is being efficiently used:

  In IPv4 there has been a heavy emphasis on conserving
  address space and obtaining efficient utilization.

but this is just relative to IPv6, not to the ideal of approaching
100% utilisation.

Even allowing for a wide margin of underestimating actual
utilisation with ping, my survey:

  http://www.firstpr.com.au/ip/host-density-per-prefix/

shows that some prefixes have quite high rates of utilisation,
such as more than 30% while most have much lower levels.

30% is pretty low, I think - but if this could be achieved in
general for the whole 3.7 billion IPv4 addresses, this would
provide for probably 4 to 10 times the number of active IP
addresses than there are today.  This doesn't mean IPv4 can go
forever, but it would be a great improvement on continuing to use
the clunky tool of BGP to distributed finite address space to a
growing number of end-users.

There are two broad areas of solution to the Problem as currently
defined, not counting general improvements in routers themselves.

The first area is improvements to the BGP routing system, in terms
of the details of the protocol, how BGP is implemented in routers,
how the routers are configured and run etc.

The second area is an IP-address based system which has nothing
directly to do with BGP, other than either not advertising
prefixes which otherwise would be advertised.

In this second area, four current proposals exist which aim to
work with both IPv4 and IPv6 by altering the behavior of routers -
and so which not require any changes to hosts, host operating
systems or applications.  (However, they all involve tunneling, so
I think there is going to have to be some effect on hosts,
hopefully won't require user configuration changes, in the form of
a marginally reduced MTU.)

  LISP-NERD
  LISP-CONS
  eFIT-APT
  Ivip      (my proposal)

I think the proponents of the first three proposals have the
primary goal of providing multihoming, portability and TE for
end-user networks.

In addition to these goals, my understanding of these proposals
has always been that they can lead to much better utilisation of
IPv4 address space than is possible with the current BGP
arrangements.  The fact that the proponents don't state this and
may not even support or believe this doesn't alter my view that
this increase in utilisation efficiency may be the most important
and immediate benefit these proposals can offer - perhaps more
important than saving existing DFZ routers from early obsolescence
in the rising tide of the global routing table.

BGP slices and dices IPv4 space with 256 address granularity, with
clunky temporal resolution (minutes?) and with unacceptably high
cost burdens on all BPG users, for every new advertised prefix and
every change to how and where the prefix is advertised or not.
The main problem is that the cost of each extra slice falls on
every DFZ router, and that beyond a few hundred thousand slices,
the system becomes expensive and has stability problems and slower
convergence times.

All these new proposals enable the division of IPv4 address space
into prefixes of any length, including to /32 single IP addresses.
 (Ivip is more flexible, because it isn't stuck on prefix
boundaries - it can group one or any number of contiguous IP
addresses together in terms of them all being mapped to the one
ETR address.)

The temporal resolution of these systems varies widely, but even
if they were all really slow, the fact that any of these systems
can be used to make single IP addresses, or 2 or 4 or 8 ... 64
addresses etc. be portable to any ISP in the world which has an
ETR, and to be used for multihoming, is a tremendous step forward
compared to BGP.

I think that any of these schemes, once successfully introduced,
would enable end users - including some who would otherwise get an
ASN and PI space and many who wouldn't - to run their networks
with just as many IP addresses as they need.  I think that in many
cases, end-users would be happy with significantly less than 256
addresses.

So with any of these proposed systems, many more end-users would
be able to have their own portable, multihomable networks in a
given range of IPv4 address than would be possible with BPG now.

Exactly which space gets sliced up finely like this is an
important administrative and business question, which I think will
find natural and generally agreeable solutions when one of these
proposed systems is widely implemented.

I suggest something like this be added to Section 6:

  7. Provide for more efficient utilisation of IPv4 address space,
     such as by enabling end-users to connect their networks with
     portability, multihoming and traffic engineering capabilities
     without burdening the BGP system and in a way which uses only
     the number of IP addresses each network actually needs.

Regarding Mobile IP, I think it is good that the Statement
recognises that the solution for the main routing and addressing
problem could provide tremendous benefits for Mobile IP.

I understand that current Mobile IP systems are not a burden on
the BGP routing system or on the addressing system.  However, I
think that the potential benefits of Mobile IP, including for IPv4
(which as far as I know is not really attempted much at present)
are so important that the mobility support of potential solutions
should be an important factor if is necessary to decide between
two otherwise roughly equivalent proposals.

Ivip is intended to go a step further than the others by providing
very fine temporally resolution to mapping - a few seconds,
ideally - with the user setting up their own systems to control
mapping to achieve multihoming service restoration, mobility etc.
without these being built into Ivip itself.

I think it would be good to state some approximate, but reasonably
concrete figures for BGP router numbers in the Statement.

Is it possible to get reliable figures for the number of BGP
routers, and how many of them are multihomed border routers or
transit routers?  I asked about this on the RAM list a few months
ago, and got no solid figures.

Recently I found this:

  http://iplane.cs.washington.edu/data.html
  Lists of alias clusters:

     Each line in this file contains a space-separated list of
     interfaces that correspond to a single router.

     58,834 lines  (62,699 on 2007-07-12 for reasons unknown.)

Can anyone confirm that this is a good estimate of the number of
BGP routers?  Perhaps there is a way of analysing this data,
probably with other data from the iPlane site, to determine which
are single-homed and which are in the DFZ.

 - Robin                http://www.firstpr.com.au/ip/ivip/

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram