[rrg] Scalable routing problem & architectural enhancements

Robin Whittle <rw@firstpr.com.au> Tue, 23 February 2010 06:11 UTC

Return-Path: <rw@firstpr.com.au>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 1DDBA28C209 for <rrg@core3.amsl.com>; Mon, 22 Feb 2010 22:11:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.578
X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id W2fMB1s5lVvK for <rrg@core3.amsl.com>; Mon, 22 Feb 2010 22:11:20 -0800 (PST)
Received: from gair.firstpr.com.au (gair.firstpr.com.au []) by core3.amsl.com (Postfix) with ESMTP id 88E353A8411 for <rrg@irtf.org>; Mon, 22 Feb 2010 22:11:18 -0800 (PST)
Received: from [] (wira.firstpr.com.au []) by gair.firstpr.com.au (Postfix) with ESMTP id B4D0C175A38; Tue, 23 Feb 2010 17:13:18 +1100 (EST)
Message-ID: <4B8371FF.60609@firstpr.com.au>
Date: Tue, 23 Feb 2010 17:13:19 +1100
From: Robin Whittle <rw@firstpr.com.au>
Organization: First Principles
User-Agent: Thunderbird (Windows/20090812)
MIME-Version: 1.0
To: RRG <rrg@irtf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [rrg] Scalable routing problem & architectural enhancements
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Feb 2010 06:11:24 -0000

Here is my understanding of the scalable routing problem, and how
this is part of the broader question of how to devise a "once in
several decades" architectural enhancement for the IPv4 and IPv6

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

The scalable routing problem

For brevity:

   EUN =   End User Network.

   PMHTE = Portability, Multihoming and/or Inbound Traffic
           Engineering.  These the the benefits many EUNs seek and
           which they can currently only gain by advertising PI
           prefixes in the DFZ - which is the cause of the
           scaling problems.  See definitions in point 4 below.

   CES =   Core-Edge (address) Separation architecture - such as
           LISP, APT, Ivip, TRRP, TIDR or IRON-RANGER.  See
           (msg05865).  CES architectures require no host changes
           and maintain the current two-level IPv4/v6 naming
           model.  (msg05864)

   CEE =   Core-Edge (address) Elimination architecture, such as
           GSE, ILNP, GLI-Split and Name-Based Sockets.  These
           only work for IPv6 and require host changes - with
           rewritten applications for ILNP and Name-Based Sockets.
           All CEE architectures alter the naming model to one
           of "Locator/Identifier Separation" (LISP does not do
           this - it is a CES architecture).

IPv4 scaling problem and solution constraints

There are several broad aspects to the IPv4 routing scaling problem.
 No-one appears to know for sure how many DFZ routers there are, but
all Internet users pay for them indirectly, since all substantial
ISPs have DFZ routers - and any smaller ISP without DFZ routers is
relying on an upstream larger ISP which does.

Also, larger EUNs have DFZ routers, and Internet users in general pay
for the operating costs of many of these larger EUNs.  Furthermore
the reliability of Internet communications depends on the DFZ routers
quickly adjusting themselves ("converge") to be able to deliver
packets by suitably short paths, with as little packet loss as
possible due to congestion or paths leading to black holes.

Here are the aspects I perceive to the IPv4 routing scaling problem -
most of which also apply to IPv6.

  1 - The growth in the number of prefixes advertised in the DFZ:


      Currently about 300k with a doubling time of about 5 years.
      This figure drives several problems:

      a - Increasing expense for each DFZ router due to the
          correspondingly high number of prefixes in the FIBs.

      b - Potentially greater difficulties updating the FIB, such
          as computational cost and/or time the FIB can't be used
          for classifying packets while updates are applied.

      c - extra load on the RIBs due to the number of prefixes - with
          DFZ routers with more neighbours being more heavily
          affected in terms of the CPU and RAM requirements for
          maintaining a two-way conversation with each neighbour
          about each prefix.

      d - Exacerbating problems with overall stability of the DFZ
          control plane.  For instance, a single outage will affect
          more prefixes, causing more BGP processing, RIB and FIB
          updating, more BGP changed announcements etc.  Since
          routers take time to do this, and due to other problems
          with the BGP control plane (such as unwanted updates
          occurring due to combinations of topology and MRAI timer
          settings) the ability of the entire system to adapt to
          changes and "converge" is lessened.  "Converge" means
          firstly all routers finding best paths which acceptably
          forward traffic packets and secondly finding best paths
          which are stable without requiring any further changes.

  2 - Growth in rate of updates to how these prefixes are announced.
      The number of prefixes represents one dimension of the load on
      the BGP control plane.  Each change adds further load, so the
      number of changes in general adds to the routing scaling
      problem.  Some changes only require adjustments to best paths
      of a few DFZ routers.  Other changes could, in principle,
      require changes to best path, or at least changes to the
      AS details each DFZ router announces for the best path (even
      if the best path remains the same) affecting many, most or
      all DFZ routers.

  3 - It is widely agreed that the DFZ can and must scale to handle
      the prefixes advertised by ISPs - and that the scalability
      problem is due to unsustainable growth in the number of EUNs
      which advertise their own prefixes - and in the rates of
      change in the way these prefixes are added.  These prefixes
      are "PI" prefixes.  (I use this term to include an alternative
      arrangement with the same impact - an EUN with a PA prefix from
      one ISP causing it to be advertising in the DFZ by another

  4 - Consequently, there are high barriers to EUNs obtaining PI
      space and advertising it in the DFZ.  These are not high
      enough to acceptably constrain the growth in the number of
      advertised PI prefixes, but they are already unacceptably
      high compared to the need for millions (up to 10 million)
      EUNs to gain benefits which are currently only available via
      advertising PI space.

      Advertising PI space in the DFZ is the only current method by
      which an EUN can currently obtain the PMHTE benefits:

          Portability - keeping its space when choosing another ISP.

          Multihoming - two or more ISPs with session survivability
                        when switching between them to cope with
                        ISP or link failure.

          Inbound TE -  When two or more ISPs are used, the ability
                        to steer incoming traffic - potentially of
                        different sorts - between these ISP links for
                        the  purposes of load balancing, optimising
                        costs, latency reliability or other

      These high barriers reduce the number of EUNs which can gain
      these PMHTE benefits.  These barriers also increase the costs
      of those which are able to use PI space.

  5 - This leads to a more difficult to measure aspect of the
      problem: a large number of EUNs which want or need PMHTE
      benefits and are currently unable to obtain it, due to the cost
      and administrative barriers to obtaining and advertising PI

  6 - A further aspect of point 5 is that due to the convention of
      not propagating prefixes longer then /24 in the IPv4 DFZ -
      an EUN needs at least a /24 prefix before it can obtain PMHTE
      benefits.  EUNs probably need multiple /24s to be able to do
      inbound TE.

      While the total amount of space used in advertised /24s is
      only a fraction of a percent of advertised space, if it were
      somehow possible for millions of EUNs to have their own PI
      prefixes, the /24 limit would cause many of them to use more
      space than they actually need.  The much higher numbers of
      the smallest prefix - /24s - than any other length indicates
      that the majority of EUNs need 256 IPv4 addresses or less.

There appears to be broad agreement that the solution to these
problems cannot involve any of:

  1 - Souping up all DFZ routers with faster route processors,
      bigger FIB capacity etc.  (This will continue, but the
      current rates of growth in the DFZ and the growing number
      of EUNs which can't get PMHTE benefits, together with the
      increased costs for all DFZ router operators of paying for
      these more capable routers constitutes the ongoing nature
      of the routing scaling problem.)

  2 - Replacing the DFZ with anything fundamentally different.
      Firstly, it is not clear what would work better than BGP.
      Secondly, if something different would work better - there
      seem to be insurmountable barriers to adopting it.

  3 - Erecting financial or administrative barriers to EUNs obtaining
      PI space and advertising it in the DFZ.  This would be
      administratively difficult, would introduce competition
      policy problems and would merely contain one aspect of the
      scaling problem (the growth in the number of DFZ prefixes)
      by worsening the other aspects: the number of EUNs which can't
      get PMHTE benefits and the higher costs incurred by those who
      are able to advertise PI space.

  4 - Solutions to the "portability" problem along the lines of
      EUNs not having truly portable space (or in a CEE architecture,
      not having portable host identifiers) and having some
      supposedly "acceptable" means of automatically renumbering
      the hosts and routers in their networks, when changing ISPs.
      For many networks, no such mechanism can come close to the
      benefits of true portability, because the IP addresses of their
      network and hosts may be stored in many other places beyond
      their control, such as ACLs.

      For example, a university may subscribe to many journals and
      the journal sites give free access to hosts in the university's
      address prefix - using a simple router-based ACL.  Changing
      the address range of the entire university network, to use a
      new ISP, would involve complex, expensive and error prone
      administrative costs for the universities and all the journals
      it subscribes to.

Therefore, a solution to the IPv4 routing scaling problem would
involve, some combination of the following:

  1 - Large numbers of EUNs being able to gain PMHTE - Portability,
      Multi-Homing and inbound TE - for their networks in a manner
      which placed little extra burden on the DFZ control plane
      in general, and on the RIBs and FIBs of DFZ routers.

      There is no consensus on numbers of such EUNs with fixed
      networks which will want or need PMHTE benefits - but Brian
      Carpenter and I have independently suggested 10 million as a
      long-term upper bound.  (BC msg05801).  The RADIR Problem
      Statement refers to "millions": "there are millions of
      potential end sites which would benefit from being able to

  2 - Current EUNs with PI space being able to adopt - and actually
      adopting - some scalable alternative to their current PI
      arrangements.  Likewise, EUNs which in the future would
      in the absence of a solution, would advertise PI space in
      the DFZ.

However, the solution must not involve any of:

  1 - Less efficient use of IPv4 address space.  (This rules
      out CEE, since a CEE-using EUN with N hosts requires at
      least N addresses from each ISP.)

  2 - Changes to host stacks or applications - since this would
      rule out the possibility of the changes being widely enough
      adopted to solve the scaling problem.  See:

      List of constraints on a successful scalable routing solution
      which result from the need for widespread voluntary adoption

  3 - Assuming that IPv4 usage will decline (as most end-users
      migrate to IPv6 and no longer need IPv4 space) fast enough
      to make the IPv4 scaling problem not worth solving.

Future trends for the IPv4 routing scaling problem are the subject of
debate.  Some argue that since IPv4 space is running out rapidly that
migration to IPv6 must begin soon and that therefore the routing
scaling problem in IPv4 will become either less significant and/or
will not grow as fast as in the past.

I believe the growth will accelerate as there is more slicing and
dicing of the available space to use it with more total hosts -
driving up the number of prefixes in the DFZ, of both EUNs and ISPs.
 See the (msg05946) thread mentioned below for more on this.

In several recent RRG messages (sorry, I don't have their numbers
handy) people have expressed the view that IPv4 will be important for
a very long time, or indefinitely.

I believe that attempting to solve the IPv4 routing scaling problem
by solving the IPv6 routing scaling problem and moving the great
majority of end-users to IPv6 would be analogous to solving the
Earth's global warming problem by solving any such problems on Mars -
and assuming that most of humanity will move to Mars since Earth is
so obviously over-crowded.

Since we can only develop and suggest the adoption of technologies to
solve the routing scaling problem, and since it seems we need wide
adoption (such as 90% percent or more) to substantially solve the
problem - considering the two or more orders of magnitude difference
between the current 300k prefixes and a likely 10 million figure - we
face some "constraints due to the need for widespread voluntary
adoption".  Please see my page where I attempt to describe these -
which has been improved after some RRG discussions:


IPv6 scaling problem and solution constraints

The IPv6 Internet currently has no scaling problem.  For a fuller
discussion, please see the thread:

   IPv4 & IPv6 routing scaling problems

     The IPv6 Internet has no scaling problem:


     These indicate about 2.6k prefixes with a doubling time
     of about 20 months.  At these rates it would take 11.4
     years (2021) for this measure of the IPv6 scaling problem
     to reach the level of today's IPv4 scaling problem.  By
     then, at the current growth rates, the IPv4 figure would
     be about 1.46 million.

The IPv6 scalable routing problem - if and when it arises - is in
principle the same as IPv4's.  However, there are some differing
constraints on the IPv6 solution - and potentially some different
techniques which are applicable to IPv6 which won't work on IPv6.

The constraints on IPv4 solutions due to shortage of global unicast
address space don't apply to IPv6.  So CEE architectures could solve
the IPv6 problem.  CEE architectures are wasteful of global unicast
address space, since each multihomed EUN with a /X prefix of IP
address space for the Locators of its hosts needs to obtain a /X PA
prefix from each of its upstream ISPs.  Also, some CEE architectures
implement Locator / Identifier Separation by encoding both the host's
Identifier and its Locator into the one IPv6 address.

The Modified Header Forwarding techniques of Ivip - alternatives to
encapsulation for tunneling packets from ITRs to ETRs - are different
for IPv4 and IPv6:


Also, with IPv6's much lower base of hosts and routers - and with the
lesser urgency of widely deploying a solution - there is probably a
lot more scope than in IPv4 for upgrading routers (including DFZ
routers), host stacks and perhaps applications.  Still, I believe
that requiring applications to be altered in any way presents the
greatest of all barriers to adoption.  This is particularly the case
for the updates which would be required for an IPv4 or IPv6
application to use the CEE naming model - Locator / Identity
Separation.  This may be easy for some applications, but would
require fundamental changes to protocols for others.

It is not absolutely necessary that the IPv4 and IPv6 routing scaling
problems be solved in the same way.  However, the task of making
applications run on these systems at the same time - or at least that
the one code-base and set of basic application protocols could work
on all these systems:

   IPv4 with scalability solution

   IPv6 with scalability solution

is a further argument against CEE.  Only CES architectures require no
changes to applications or stacks.  It would be wildly unrealistic to
expect all IPv4 applications to be altered in any way - for any
reason at all, including scalable routing.  Of the CEE RRG proposals,
only GLI-Split requires no changes to IPv6 applications - but I am
not yet convinced it will work.  (I am yet to get a response from
Michael Menth and colleagues to my msg06056.)

Other problems and goals

I think it would be irresponsible and impractical to develop and
attempt to deploy architectural enhancements - each a once in several
decades opportunity for improving the IPv4 and IPv6 Internets - for
the purpose of solving only a subset of these problems:

   IPv4:   Routing scalability
           Address exhaustion

   IPv6:   Routing scalability

IPv4 address exhaustion and Mobility are discussed in sections below.

The forthcoming enhancements must be an effective solution for all
three IPv4 problems and both IPv6 problems.

First I want to mention some other potential problems which an
architectural enhancement might allow (or be constrained by), since
the IPv4 and IPv6 Internets face pressing problems beyond those
listed above.

Computer Security

There are general problems of computer security, the ability of
attackers to directly gain control of hosts, or trick their users
into giving them control - but these do not seem to be amenable to
solution in the network itself.

DoS and other attacks

There is a general, very serious, problem with the ability of
attackers to mount DoS and other attacks which disrupt Internet

This is largely a function of the ability of attackers to assemble
(or hire the services of) immense botnets of hundreds or thousands or
millions of compromised hosts, each capable of firing out packets to
the target.  This is largely a function of the number of
Net-connected computers, the insecurity of their operating systems
and applications, and the lack or care and expertise of their owners.
 The widespread adoption of faster DSL services - and especially
fibre services with much faster upstream links than are possible with
DSL, HFC cable or wireless links - will make this problem even worse.

If it looks like there might be some method of reducing this problem
as part of an architectural enhancement, I think this should be
explored.  The ability of a CES architecture such as Ivip or LISP to
in some way help with this problem has not really been explored as
far as I know.  I am not sure there is a way of doing so - but it
should be investigated as CES architectures are further developed.

Path MTU Discovery and packet length limits

This is a whole can of worms for IPv4 and IPv6.  Please refer to the

  Fred's IPv4 PMTUD research: RFC1191 support frequently broken

for more information.

PMTUD problem apparently cause minor data loss today on IPv4.  The
problems generally involves some tunnels and networks either not
producing PTBs (Packet To Big messages) or dropping them with
filters.  There may also be a problem with some hosts (stacks and/or
applications?) not responding properly to PTBs.

These problems lead to workarounds in which packet lengths are
artificially limited - which means that it will be impossible to use
~9k byte jumboframe paths across the DFZ as these become available.
In short, the current situation seems to indefinitely lock us into
slightly sub-1500 byte packets.

There are several worrying things about this.  Firstly, the problems
result usually as a combination of circumstances - and can be
difficult to recognise, debug and isolate to the level of identifying
which ISP or other network did the wrong thing with their tunnel
arrangements and/or over-zealous ICMP filtering.

Secondly, each person who encounters these problems tends to adopt
quick-fixes which mask the fundamental problems - thereby enabling
the problems to continue and proliferate, while locking us more and
more into sub-1500 byte packet lengths indefinitely.

Thirdly, neither CES nor CEE routing scaling problems offer any
solution to these problems.

Finally, and most troubling, CES architectures need to use
encapsulation between ITRs and ETRs - unless one of Ivip's Modified
Header Forwarding techniques can be deployed, by upgrading all DFZ
routers, before the Ivip CES architecture itself is deployed.  (In
the long-term Ivip should be able to transition from encapsulation to
MHF.)  So PMTUD problems may make it significantly more difficult to
introduce a CES architecture.

I am unsure how serious these problems will be - but ITRs will need
to be able to send PTBs to sending hosts and have the sending hosts
respond with suitably shortened packets.  If the ITR is outside some
network where the sending host doesn't get these PTBs due to
over-zealous filtering of incoming ICMPs by that network, then this
will cause real difficulties with the CES architecture.  The CES
tunneling will frequently reduce packet sizes below what most
networks are used to getting at present.

There is only one proper answer to this situation - removing the
overzealous filtering.  Placing the ITR in the network would fix this
problem - but make it harder (not impossible, at least with Ivip's
IPTM arrangement) to do PMTUD for the tunnel to the ETR, because then
the overzealous filtering would drop PTBs coming from routers in any
part of the ITR to ETR tunnel.

Tunnels in the DFZ or other networks which are part of the ITR-->ETR
tunnel and which either don't produce valid PTBs, or only produce
them on the second or subsequent occasion they drop a packet, make it
more difficult for ITRs to successfully judge the Path MTU to the
ETR.  This is not insurmountable - but it delays the ability of the
ITR to correctly inform the sending host of the MTU it must use.

My view is that these PMTUD problems arise from people doing things
which are at odds with the Internet standards, and for which there is
no reasonable means of coping defensively.  So I believe it would be
easier and better to identify these bad practices and have these
problems fixed, rather than crafting new protocols, such as RFC 4821,
to "route around" the problems.   Fred Templin has a different view.

I think the PMTUD difficulties are probably worthy of a concerted
research response along the lines of the current phase of scalable
routing research, which was kicked off by the 2006 RAWS conference in

IPv4 address exhaustion and efficient utilization

This is a far more pressing and well accepted problem than scalable
routing.  It is pretty much common knowledge amongst all IT people,
while scalable routing is not so widely known.  Also, I think, even
some within the field regard it as a non-problem - well within the
capability of normal (Moore's law etc.) router technological

I believe that a successful IPv4 scalable routing solution will, to
the maximum extent possible, "solve" the address exhaustion problem
by allowing very high rates of utilization - the percentage of
actively used IPv4 addresses out of each advertised prefix.  Each
IPv4 address may be used for a single host, a NAT box at the end of
DSL, fibre, HFC or wireless service, or a single mobile host.

I believe the only class of solutions which can work for IPv4 are CES
solutions and of the CES RRG proposals, only Ivip or LISP could be
successful.  (APT could also work, I think, but it is no longer being

Both Ivip and LISP enable the slicing of "edge" space (SPI for Ivip,
EID for LISP) down to separately mapped chunks as small as a single
IPv4 address ("/32").  Ivip's micronets can be any integer number of
IPv4 addresses, while LISP only works in power-of-two prefixes.  But
both could, in principle and in practice, scalably allow "edge" space
to be used very flexibly and with a close to 100% utilization level.

This won't forever solve the IPv4 address shortage problem.  But
considering the improvements which can be made to utilization in this
manner, and the fact that only about 2.2 billion IPv4 addresses are
so far advertised, out of a total advertisable global unicast range
of 3.7 billion:

  "Advertised Address Space" in:

I think the successful adoption of a CES architecture such as Ivip or
LISP will give us another 10 or more years of IPv4 usage without
really "running out" of addresses *except* for the desire to give 5
billion or more mobile devices their own global unicast scalable (SPI
or EID) "edge" address.  Most of those billions of mobile IP devices
are going to have to work either behind NAT for IPv4 and/or on IPv6.

Since I believe only Ivip or LISP or the like could solve the IPv4
routing scaling problem, and since I believe each would offer the
best possible means of maximising IPv4 address utilization, I don't
think anything further needs to be done regarding this problem.

Indeed, I think that the IPv4 address shortage will probably drive
the adoption of Ivip or LISP for non-mobile networks wanting PMHTE
benefits who don't need large amounts of space and/or which don't
want to get PI space, advertise it in the DFZ etc.


While no-one has data about the future, I consider these trends:

   Ubiquitous adoption of digital mobile telephony in developed
   and developing nations.

   Miniaturization of computers into hand-held devices for many
   purposes, including playing sound and video, for telephony,
   instant messaging (SMS texts and Internet IM protocols),
   web-browsing and other Internet applications, micro-payment
   systems, GPS capabilities, Bluetooth connections to other
   devices etc. etc.

   Ubiquitous adoption of Internet communications in developed
   and developing nations.

to be analogous to several freight trains approaching the one
junction at full-throttle.

One doesn't need a crystal ball ("data about the future") to be sure
that billions of end-users will soon want Internet access on their
hand-held devices (phones, pads, netbooks, laptops or whatever) AND
that they will want the effective identity of their computer, and its
ongoing communication sessions, to persist despite the device
automatically and frequently connecting to the Internet by a wide
variety of physical link technologies and through various access
networks.  Many of these connections will be completely ad-hoc - such
as a 3G network via roaming arrangements in a foreign country, or
using a WiFi service automatically, or with very little user
interaction, simply by being in range of a free service in a public

I consider the upper limit for the number of these devices to be
approximately 10 billion - one or (sometimes two or more) for pretty
much every person on Earth, plus devices for selected pets, cars,
point of sale terminals, vending machines, trucks in vehicle tracking
systems etc.

Many of these devices will connect to IPv4 behind NAT, which
precludes the use of conventional mobile IP techniques.  NAT will
hopefully not be used for IPv6.

LISP proposes a form of mobility by which the MN (Mobile Node) acts
as its own ETR.  But there are many problems with this, not least its
inability to work behind NAT and the need for each MN to have an IPv4
address of EID space and its own IPv4 address of RLOC space.  See the
end of:


As far as I know, the only way of adequately solving the Mobility
problem - at least as I understand it, for IPv4 and IPv6, with hosts
accessing many networks on an ad-hoc basis, including behind one or
more layers of NAT - is the TTR Mobility architecture:


This is an extension to Ivip or perhaps to LISP.  Mapping changes are
not required for each new host address.  Mapping changes would be
infrequent for most MNs, since they are only needed (and even then,
not absolutely required) when the MN moves more than 1000km or so.

TTR Mobility doesn't require any new elaboration of the basic Ivip
architecture - though it would require many more micronets - up to 10
billion or so, rather than the 10 million or so required without

Because of this, I don't see Mobility as being an extra burden on the
enhancement - as long as the enhancement is a CES architecture such
as Ivip or perhaps LISP.

CEE architectures theoretically support mobility, but not for IPv4,
not with the MN behind NAT - and at the cost of the MN having to do
much more routing and addressing work than the relatively simple
extra responsibilities it has in the TTR Mobility architecture.


I plan to write a separate message about this, but the short version is:

  Many RRG "proposals" are not complete proposals for scalable
  routing and can ignored.

  Three proposals are are potential solutions, and are not CEE or CES
  architectures: "Aggregation with Increasing Scopes" (AIS -
  Evolution), hIPv4 and Name Overlay (NOL).  I believe these are not
  practical solutions.

  There are four CEE proposals:

    Name-Based Sockets

  These are only applicable to IPv6, and they all require host stack
  changes.  All but GLI-Split require upgraded applications.  All of
  them only provide substantial benefits to adoptors and substantial
  routing scaling benefits after essentially all hosts (and therefore
  all applications) adopt the new system.  These are extraordinarily
  high adoption barriers which preclude them from being seriously
  considered, since there are CES architectures which could solve
  the scaling problems and provide mobility.  Even if there were no
  such barriers, I would oppose them because I believe their
  Locator / Identifier Separation naming model would decrease the
  speed of session establishment and unreasonably burden all hosts
  with extra traffic and responsibilities.  That said, I am not
  yet convinced any of these proposals would work as well as their
  proponents intend.  See (msg05865).

  This leaves four CES architectures:

    LISP (currently LISP-ALT, but perhaps in the future
          with another mapping system)

    Ivip (I will soon describe a Distributed Real Time Mapping
          System which will be suitable for Ivip and LISP.)



  TIDR doesn't solve the scaling problem, because the traffic
  handling and mapping distribution is done by DFZ routers.

  I think IRON-RANGER needs a lot of work before the scaling
  and security problems inherent in its continual process of
  EID prefix registration with VP routers can be understood
  and shown to be resolved.  I think it also lacks technical
  and business arrangements for supporting packets sent from
  non-upgraded networks.

  That leaves LISP and Ivip.  For reasons I won't repeat here,
  I believe Ivip would be a good solution to the problems
  discussed here and that LISP in anything like its current form
  would be a poor solution.  FWIW, if APT were still under
  development, I would consider it better than LISP, since
  like Ivip, it uses local full-database query servers to
  avoid delaying or dropping initial packets.

Other work

Please see the RADIR Problem Statement:


and my comments on it, which I will post after this message.  This
message also contains pointers to the RRG Goals ID.