Here is a rewrite of the Problem Statement, focusing on
"end-users" rather than "sites" and extending the goals in a
number of ways which I think are achievable and highly desirable.

I think the current version of the Statement is compatible with
these two statements being true - but I think they are not true:

1 - That a new architecture could make renumbering robust
    and sufficiently painless and free of costs and risks
    that all end-users would, or should, be happy to get
    new addresses whenever they choose a new provider.

2 - That a new architecture cannot, or should not, enable
    a much finer method of allocating IPv4 address space, to
    accommodate more end-users with multihoming, portability
    etc. - and that this cannot or should not be used to
    enable a much greater number of end-users of all types,
    (including those who don't need portability/MH/TE) to
    use IPv4.

I am also keen to see the new architecture either directly support
Mobile IP, or at least be compatible with future extensions which
do so.  I mean an expansive view of Mobile IPv4 and IPv6, with
correspondent hosts not requiring new software, and with close to
optimal path lengths.

For instance, the new architecture's ITR system could be used to
create generally optimal paths to ETRs which are close to the
mobile node.  This would enable correspondent hosts without any
special mobile IP software to communicate efficiently with mobile
nodes, including small devices (cell-phones and laptops) as well
as nodes which connect mobile networks - for instance in passenger
jets and trains.


I think the term "site" tends to imply a physical installation,
largish network, etc.  These are the only types of end-users who
have the resources to gain ASNs, PI space etc. today.  However I
think the new approach to routing and addressing can and should
provide multihoming, portability and TE (for those with multihomed
links) for a much larger number of end-users, including those who
lack the resources to get an ASN, PI space etc.  In principle, I
think the goals should be extended to apply to single hosts which
are physically mobile, such as cell-phones, laptops etc.  I think
the term "site" does not adequately capture that sort of end-user
or the device, node, network etc. whose address space must support
multihoming, portability and ideally mobility.


I am wary of the current state of point 4:

   4.  Allows end sites to switch providers while minimizing
       configuration changes to internal end site devices.

End-users today need "portable" address space, because there is
currently no mechanism for reliably and painlessly renumbering
every aspect of their network.

The current wording of point 4 only makes sense if a new routing
and addressing architecture might be able to automate address
settings so that end-users with all sizes of networks - including
really large ones - could reliably, quickly and with little cost
adopt a new address range when they change to another provider.

I think this is an unrealistic hope and will remain so within the
foreseeable future - most likely forever.

IPv6 has been designed to support painless renumbering, including
smoothly switching over from one address range to another without
loss of connectivity.  I am not sure how well this is regarded by
the operators of big networks - and I imagine it has rarely, if
ever, been put to the test in a real, busy, substantial commercial
end-user network.

These IPv6 provisions can't cope automatically and reliably with
every little detail programmed into routers, switches, etc. such
as ACLs, VPN configuration, source address spoofing filters etc.
Nor can these IPv6 provisions work fast enough and without human
intervention to support multihoming - because existing
communications sessions do not persist into the new addresses,
unless perhaps both ends of the session are using SHIM6.

It is completely impossible for any new routing and addressing
architecture to enable reliable, cost-free renumbering of IPv4
networks.

So to respect the genuine needs of end-users, I think this should
be rewritten simply to provide "portability" of their address
space between providers.


I am a little wary that the current version of the Problem
Statement's goals could be used to justify a new architecture
which pressures end-users to adopt IPv6, and/or to make any other
such major change their host operating system and application
software.

I think some people see IPv4 as a dead-end and so can only foresee
long-term solutions which involve everyone moving to IPv6.

While I recognise there are fundamental problems with IPv4 (NAT
and limited address space are the most obvious) I think it would
be dangerous in the five to ten year timeframe in which this
Problem Statement is relevant to think that the way forward may be
to discourage people from using IPv4.  I think that any such
attempt by the IETF etc. is bound to fail.

I think people should move to IPv6 (or maybe some new and better
system in the long term future) if and when the benefits they
receive exceed their costs.  At the same time, we should be doing
our best to preserve and improve the usability of IPv4.


I think there is a danger of seeing the Problem being just the
biggest obvious problem: the RIB-BGP load caused by an increasing
number of multihoming end-users who are big enough to get an ASN
and PI space today.

We certainly need to solve this problem in a way which doesn't add
to the number of BGP advertised prefixes.  However, I think it is
important to frame the goals for a new architecture in a way which
encompasses the longer-term challenges posed by ubiquitous
Internet adoption, with millions - or hundreds of millions - of
end-users wanting and needing portability (or at least painless
choice of providers), multihoming, and TE for incoming traffic
over multihomed links.

It seems that these things can all be achieved with an ITR - ETR
scheme as proposed in LISP, eFIT-APT and Ivip.

Furthermore, if the ITR tunneling (EID-RLOC mapping) can be
controlled by the end-user fast enough  (not just codified in the
form of instructions to ITRs regarding multihoming service
restoration), then the new system will support Mobility too.

Although lack of Mobility is not regarded as a crucial problem,
this is a little like thinking lack of cell-phones wasn't a
problem in 1977.  The value of genuine mobility, with sessions
continuing as the mobile node switches between separate provider
networks, will be immense.  This is probably the biggest single
thing which could be done to boost the usefulness of Internet
communications - even more than significant increases in speed or
decreases in cost.

I think this real-time control of mapping - such as with 2 to 4
seconds latency globally - can be achieved, but the proponents of
LISP and eFIT-APT do not base their systems on any such high-speed
mapping information distribution system.

There are two goals not mentioned in the current Problem Statement
which I think are achievable and essential for coping with
long-term growth and ubiquitous adoption:  More efficient
utilization of IPv4 space and Mobility, including Mobile IPv4.

The currently low percentage of advertised IPv4 addresses which
are actually used is a result primarily of the address management
policies of assigning large chunks of space to all applicants.
This long-standing practice is based on the intention that
end-user won't need to ask for more space for a few years.

Another, more crucial, intention of the current address management
system is driven by the desire for route aggregation.  The idea is
that by giving providers and end-users largish slabs of space,
each provider or end-user will be able to satisfy their needs for
a long time with this space, which will either be a single BGP
advertisement or at least be advertised in a few smaller pieces in
roughly the same geographic and topological area.

This goal of route-aggregation would not be so well served in the
current BGP-dependent architecture if the providers and end-users
were only given small pieces of space, on a more frequent basis,
with those smaller pieces making up non-contiguous blocks of
addresses, each requiring a separate advertisement in BGP.

BGP imposes some clunky restrictions on the use of address space.
 The granularity (in IPv4) is 256 addresses at a time, and all
users are urged to minimise the number of prefixes they advertise.

The likely new architectural approaches all enable the address
space to be used much more flexibly.  The granularity of control
can be prefixes of any length, including single IP addresses.  The
number of separately mapped prefixes in the new system places no
burden on BGP, and only burdens the new system - which will be
designed to scale to millions or perhaps a billion such separately
mapped prefixes.

So to the extent that address space is split between end-users
with the new architecture, that new address space can be assigned
in much finer and more flexible ways than has been possible with
BGP.  This is exactly what is needed for the space to be highly
utilised so that more users and or more nodes can be accommodated.
 This is not just for end-users - providers can use space which is
sliced and diced in this way as well, though not for running ITRs
or ETRs.

Ivip is the only proposal which has as one of its explicit goals a
great improvement in how many IPv4 addresses can actually be used.

However, I believe that LISP-NERD, LISP-CONS and probably eFIT-APT
will be just as suitable as Ivip for this fine-grained address
assignment.


Ivip is currently the only proposal which aims for mapping changes
to be transmitted rapidly (a few seconds ideally) to all ITRs.

While I haven't devised precisely how to do this, no-one can say
yet that it can't be done.  We can get packets across the world in
a fraction of second - so maybe all we need is a multicast system
to distribute mapping changes, with some authentication
arrangements and provision for coping gracefully with lost packets.

I hope there will be other people working on Ivip or on their own
proposals with similar high-speed mapping distribution.

Even if the best efforts to devise a system such as this fail in
the next year or two, it cannot be assumed that such a system will
not be practical and attractive in the future.  So while Ivip is a
lone, young, proposal at present, I think that the Problem
Statement should not be limited by the assumption that high-speed,
essentially real-time, user control of ITRs (or however the new
architecture works) will never be feasible.


Here is a chart of the current proposals which are intended to
provide benefits directly to both IPv4 and IPv6, without requiring
changes to hosts.  (So this leaves out SHIM6, Six/One and IPvLX.)

"BGP improvements" encompasses the proposals which are intended to
make the BGP routing system work better, such as being able to
handle more prefixes, increase stability, reduce unnecessary
control plane traffic, lower costs, ease router management
difficulties, improve security etc.  I assume that these
improvements will not drastically increase the BGP system's
ability to handle more prefixes or to propagate advertisement
changes more rapidly.


             Proposal >>  BGP impro-  LISP    eFIT-APT  Ivip
                          vements
New goal:

Better utilization of     NA          Yes*    Yes*      Yes
IPv4 space, via finer
allocations to more
end-users who have
portability, MH and TE
without burdening BGP.

Support major improve-    NA          No      No        Yes
ments to Mobile IPv4
and IPv6 - with optimal
or usually close to
optimal path lengths
and reachability from
non-upgraded hosts and
networks.

  NA   Not applicable - meaning the proposal does not prevent
       this goal, but does not directly support it either.

  No   The proposal does not allow this goal to be achieved.

  Yes  The proposal allows this goal to be achieved.

  Yes* I think the proposal allows the goal to be achieved, but
       this is not necessarily the view or the intention of
       the proponents of this proposal.


This rewrite also attempts to consider other problems the routing
system faces apart from the number of advertised prefixes and
their rate of change - including the cost and processing
difficulties of the FIB.

Having to process 48 bits of IPv6 address for the new PI end-user
assignments of ARIN and AfriNIC seems really inefficient.

Consider the vast number of streams of little VoIP packets - such
as 30 to 50 packets a second with 20 to 30 bytes of voice data,
plus RTP header (12 bytes) and UDP header (8 bytes).  This is 40
to 50 bytes.  Users want this to be a low-cost service, and they
will expect it to be pretty much for free.

Yet with IPv6, the small amount of data per packet gets a
lumbering 40 byte IPv6 header in front of it, and every multihomed
and transit router the packet traverses has to labour its way
through 48 bits of destination address just to figure out which
interface to forward it to.

I think it would be highly desirable to have some policy which
limits the IPv6 classification tasks of DFZ routers to something
like /32 or /35 at the most.  Then, the routers can be optimised
for handling the bulk of their traffic within these limits (which
are still really demanding).  This is not a goal below, but maybe
the new architecture needs to include administrative and other
arrangements which put reasonable limits on the FIB functionality
of routers, since they are so costly, use so much power, and are
going to be handling so many VoIP packets.


Here is a rewrite:

   There is a need for a new architecture for routing and
   addressing that:

   1.  Reduces the growth rate of the DFZ routing load, where the
       routing load is dependent on:

       A.  The number of individual prefixes in the DFZ.

       B.  The update rate associated with those prefixes.

       C.  The length of those prefixes.

       D.  The complexity and size of the RIB and the
           complexity and volume of inter-router communications.

       E.  The complexity, cost and power consumption of the FIB
           functions which handle ordinary routing tasks and any
           requirements of a new architecture, such as
           encapsulation, decapsulation, authentication and
           support for Path MTU Discovery when packets are
           tunneled.

              (Actually, I think the new architecture needs a
               whole new system by which hosts can do a much
               better job of PMTUD than is currently possible.
               The new tunneling architectures will make PMTUD
               much harder, while the problems with MTU and
               fragmentation are going to be made worse.  So there
               is a lot more which probably should be added to the
               goals about this.)

       F.  The costs and difficulties of administering routers
           and the routing system as a whole so routers operate
           efficiently and do not place unreasonable burdens on
           other routers.


   2.  Allows the following benefits for end-users, with the
       needs of larger organisational end-users being most
       important, but in principle extending to individual
       end-users's networks and single devices.  These benefits
       should support communications initiated by hosts in
       networks which have not adopted the new architecture -
       perhaps not with the same efficiency as to non-upgraded
       networks, or with as high an efficiency as between two
       hosts in upgraded networks.  Hosts in non-upgraded
       networks should suffer no loss of reliability in their
       communications with hosts in networks using the new
       architecture.

       A.  Portability of the address space when choosing
           another provider.

       B.  Multihoming with two or more providers, with
           robust session continuity.

       C.  Incoming Traffic Engineering where there are two
           or more links to providers.   This TE should be
           technically capable of being controlled by the
           end-user and/or the provider.


   4.  Provides meaningful benefits to the parties who bear the
       costs of deploying and maintaining the existing and new
       elements of the routing system.


   5.  Requires no change to host operating systems or application
       software.  Configuration changes to hosts in upgraded or
       non-upgraded networks should be minimised and would only be
       required to improve, or perhaps maintain current levels of
       efficiency.  No changes to any hosts will be required to
       maintain current levels of reachability and reliability of
       communications.

          (I am thinking of MTU settings, tunneling and
           fragmentation.  Hosts in both upgraded and non-upgraded
           networks might have less efficient communications with
           hosts in upgraded networks, due to fragmentation, but
           they shouldn't suffer significantly less reliable
           communications.  This may not quite be possible with
           packet loss rates having more impact with
           fragmentation.)


   6.  Requires no changes to networks which do not adopt the
       new architecture in order to maintain current levels of
       reachability and reliability of communications.  Any
       changes of configuration, such as to routers, will be
       necessary only to improve efficiency.

          (It may be best for all networks, upgraded or not, to
           have their DHCP servers send out lower MTU settings,
           to avoid packets being fragmented due to the
           tunneling overhead.)


   7.  Ensures sites which adopt the new approach remain fully
       reachable from sites which do not.

          (May be redundant since point 2 may make this clear.)


   8.  Supports the greater utilization of IPv4 address space
       by enabling greater flexibility in address assignment
       than is currently possible - which will enable a
       greater number of end-users to be assigned address space
       in smaller increments which more closely match their
       immediate needs.


   9.  Supports administrative and commercial frameworks which
       are intended to improve flexibility, choice and
       competition - including the ability of large numbers
       of smaller sites and individual end-users to gain
       address space, with or without the benefits of
       portability, multihoming and TE.

  10.  Either directly supports or at least does not preclude
       the use of the new architecture to be used for supporting
       Mobile IP in terms of greater flexibility, more optimal
       path lengths and communications with non-upgraded
       correspondent hosts.


I also wrote about the RRG Design Goals at:

 http://psg.com/lists/rrg/2007/msg00199.html

but that doesn't include all the stuff I am proposing now.


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





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