[RRG] Consensus? Scope of "It" in "Doing It Right"

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

In http://psg.com/lists/rrg/2008/msg01345.html, Tony Li wrote that
there was no catastrophic limit to the growth in the DFZ routing
table.

>> What do the big router implementers on this list think about the
>> question of when we will hit a "catastrophic" scaling limit ?
>
> 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.
>
> If you believe this, then the issue is real and is strategic, not
> tactical. We have the opportunity to Do It Right, and we should.

I agree.

The Internet's routing scaling problem is not like a damsel bound to
the railway tracks with the 6 O'Clock Express bearing down upon her.

The scaling problem results in growing costs and difficulties which
flow to all Internet users as it becomes more and more expensive to
field DFZ routers, and as end-user networks find it harder and
harder to get the portable, multihomable IPv4 address space they need.

Technically, it would be possible to solve the routing scaling
problem (thereby providing portable, multihomable address space for
hundreds of millions of end-user networks) by a major architectural
change which involves a new system of identifiers, and therefore
involves changes to applications and operating systems, as Bill
Herrin wrote:

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

    RW > Can we form rough consensus on this?
    RW >
    RW > Short version:
    RW >
    RW >   End-user networks need their own portable address space.
    >
    > Concur but I want to explicitly state the assumption:
    >
    > [In any complex internet in which the host network address is
    > not strictly ephemeral,] end-user networks need their own
    > portable address space.
    >
    > In theory, we could redesign IP from the ground up so that the
    > hostname was king and the network addresses assigned to a
    > particular machine could change at any time without disrupting
    > communications. In practice, we're not going to and if we were
    > going to it would be far beyond the scope of this working
    > group. This leaves us at your conclusion.

In offlist discussions I also learnt that at least one RRG member is
keen for a solution which would help with intra-network failures, so
a host with two interfaces and so two IP addresses, could keep
working on the one session, even when one interface fails or is
unreachable.  SCTP (and maybe SHIM6 and Six/One?) already does this,
as far as I know.  However I think he envisages an RRG solution
which underlies all existing communications, which would involve
impractical lower levels of stack modifications (maybe global
routing stuff too?) to protect TCP, UDP, ICMP etc. sessions as well
- or perhaps such a solution would also new applications, new OS
functions etc.


The map-encap solutions (and Six/One router too?) are all based on
the assumption that we can't mess with applications or host stacks -
because we need to have a solution implementable at the network level.

A network-level solution is the only way of providing the required
centralised (ie. robust, simple, secure) control over portability,
multihoming and TE and also the only practical way of applying a new
architectural enhancement.  Any proposal which requires changes to
host OSes would be difficult or impossible to implement with the
required 100% success in a sufficiently high proportion o end-user
networks - and application changes are out of the question.

I think the map-encap schemes are also based on the assumption that
the routing scaling problem should be solved purely at an IP address
level - for both IPv4 and IPv6.  These map-encap solutions
(LISP-NERD, LISP-ALT, APT, Ivip and TRRP) are the only potentially
practical complete systems which have been proposed since RAWS.
They are all based on the notion that the solution needs to work
with all existing applications and host stacks.

I think that for the RRG to make any meaningful contribution, we
need to define the scope of Tony's "It" clearly, such as this:

  The RRG's proposed solution to the routing scaling problem
  will work for both IPv4 and IPv6, and be capable of widespread
  adoption based primarily or solely on the immediate benefits
  it provides to end-user networks and ISPs.

  To this end, the solution will not attempt to alter host-level
  Internet protocols in any way, but will operate purely at the
  level of IP addresses, and with mechanisms by which packets
  are transited across the generally unmodified DFZ, from and to
  the new network elements and/or new router functions defined by
  the solution.

  There has long been, and remains, a desirable goal of having
  applications work with end-point identifiers which remain stable
  despite the workings of the routing system - in particular
  regarding outages, network reconfiguration, portability,
  multihoming and traffic engineering.  Any solution to the routing
  scaling problem which relies on such changes is beyond the scope
  of the RRG, because it involves host changes and deployment
  hurdles which cannot be solved within the (five?) years we have to
  tackle the routing scaling problem.  Such approaches would best be
  developed in a separate forum, with a longer time-frame and a much
  more ambitious scope.


  - 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