[rrg] Vote [1] Ivip, [2] LISP

[Robin Whittle <[e-mail]>]

BTW, I am taking a 5 day break from RRG, scalable routing etc.


Short version:      Why I suggest:

                       Vote [1] Ivip
                            [2] LISP

                    and why I believe no other proposals are
                    currently suitable for IETF development.


By a process of elimination, here is why I think Ivip and LISP are
the only proposals which can be seriously considered for
recommendation to the IETF, and why I believe Ivip is a more promising
architecture than LISP-ALT or any other approach to LISP.

For my understanding of the scalable routing problem and of other
problems we should solve as part of a future architectural
enhancement, please see this messages, and any updates or discussions
which follow:

  Scalable routing problem & architectural enhancements  2010-02-3
  http://www.ietf.org/mail-archive/web/rrg/current/msg06099.html

I believe we need to work on the IPv4 scaling problem first - and
that we have more time before needing to decide how to solve the
future IPv6 scaling problem:

  IPv4 & IPv6 routing scaling problems
  http://www.ietf.org/mail-archive/web/rrg/current/msg05946.html

The Ivip page, with links to other items such as constraints due to
the need for widespread voluntary adoption:

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

The RRG wiki and Report ID:

  http://trac.tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup
  http://tools.ietf.org/html/draft-irtf-rrg-recommendation


Below, EUN means End User Network.

 - Robin




Non-solutions
=============

Several proposals are not complete scalable routing architectures -
they concern just mapping systems:

   2-phased mapping for Internet core/edge split schemes
   Enhanced Efficiency of Mapping Distribution Protocols in Map-and-Encap Schemes
   Layered Mapping System (LMS)
   Mapping system based on Compact Routing



Non CES or CEE solutions which won't work, or won't work well enough
====================================================================

Some proposals do not resemble either Core-Edge Elimination (CEE) or
Core-Edge Separation (CES) architectures.  Here is a brief account of
why I think they are not the basis for a good scalable routing
solution.

   Aggregation with Increasing Scopes: An Evolutionary Path Towards Global Routing
   Scalability  (AIS)

      While the first two steps (FIB Aggregation and Virtual
      Aggregation) may be useful to some networks, these do not
      provide anything like the gains required to solve the routing
      scaling problem.  Nor does AIS help with Mobility.

      I am not convinced that the complex arrangements suggested will
      be practical or worth the trouble, considering in general that
      they make each network harder to configure and debug, more
      dependent on a larger number of routers and probably more prone
      to failure - or at least difficult to fix failures.  Also,
      some of the suggestions such as Virtual Aggregation frequently
      result in longer paths.


  hIPv4 - Hierarchical IPv4

      hIPv4 doesn't tackle any future IPv6 scaling problem.
      Unfortunately its 04 approach involves header options which
      do not appear to be well enough supported by routers to use for
      traffic packets.

      hIPv5 does not seem to have this problem, but the new packet
      format must only be sent to upgraded hosts.

      hIPv5 requires upgraded host stacks and applications, and so
      appears to have impossibly high barriers adoption on a wide
      enough scale to solve the IPv4 routing scaling problem.


  Name Overlay (NOL)

      NOL is a NAT-based approach to scalable routing for both IPv4
      and IPv6.  However, an approach such as this is not suitable
      for IPv4 since a /24 EUN multihomed with two ISPs requires a
      total of three /24s of global unicast space.

      While NOL may in principle work for IPv6, it requires new
      network elements (Name Transfer Relays), changes to DNS and
      upgraded IPv6 applications.

      I can't imagine how this could be superior to, or easier to
      introduce, than a good CES solution.




The Core-Edge Elimination vs. Core-Edge Separation distinction
==============================================================

For the CEE and CES distinction, and why I believe we should not
adopt (as all CEE architectures require) the "Locator / Identifier
Separation" naming model (not to be confused with LISP, which is a
CES architecture), please see:

  CES & CEE are completely different (graphs)
  http://www.ietf.org/mail-archive/web/rrg/current/msg05865.html

  Today's "IP addr. = ID = Loc" naming model should be retained
  http://www.ietf.org/mail-archive/web/rrg/current/msg05864.html

  CES & CEE: GLI-Split; GSE, Six/One Router; 2008 sep./elim. paper (v3)
  http://www.ietf.org/mail-archive/web/rrg/current/msg06110.html

  LEIDs, SPI & ordinary IP addresses as both IDs & Locs
  http://www.ietf.org/mail-archive/web/rrg/current/msg06070.html
  http://www.ietf.org/mail-archive/web/rrg/current/msg06074.html




CEE - Core-Edge Elimination proposals
=====================================

There are four proposals which I believe are Core-Edge Elimination
(CEE) architectures:

   GLI-Split
   ILNP - Identifier-Locator Network Protocol
   Name-Based Sockets
   RANGI

I have discussed all these, and while there are unresolved questions
about which would work better - and with some requiring application
upgrades and others not, here are the reasons why I believe no CEE
architecture should be contemplated for solving the scalable routing
problem:

  1 - CEE architectures require all hosts to use the "Locator /
      Identifier Separation" naming model, in which there are
      separate layers, separate objects, for Identifying hosts and
      for guiding the packet (Locator) on its trip across the
      routing system.

      The sole advantage of this seems to be achieving scalable
      routing while not making the routing system more complex.
      (Nonetheless some CEE proposals do involve significant
      alterations to some routers.)

      Loc/ID Separation inevitably burdens all hosts with greater
      responsibilities.  This will generally delay the establishment
      of communication sessions and require extra packets for looking
      up the Identifier -> Locator mapping - usually by both hosts.
      Some protocols (e.g. Name Based Sockets) involve extra
      information being included in traffic packets - and sometimes
      extra packets flowing between the communicating hosts.

      This extra burden on all hosts and the general slowing of
      communication establishment must be avoided.  In particular it
      must be avoided due to the future of Internet communications
      involving ubiquitous use of mobile, hand-held, battery-operated
      devices which operate over wireless links which are frequently
      slow, congested and/or less then reliable.

      Even if CEE architectures had no other problems, these concerns
      should rule them out of serious consideration.

  2 - CEE architectures are only practical on IPv6.

  3 - CEE architectures require stack upgrades, and in some cases
      application upgrades - which is the greatest adoption hurdle
      imaginable.

  4 - CEE architectures only provide significant benefits to adopters
      or significant routing scaling benefits after all, or nearly
      all hosts and networks have adopted it.

      By contrast, CES architectures such as LISP and Ivip provide
      immediate full portability, multihoming and inbound TE benefits
      to all adopters.

  5 - Likewise, CEE architectures only provide substantial routing
      scaling benefits when all, or nearly all, hosts and networks
      adopt it.  CES architectures are totally different: routing
      scaling benefits accrue in direct proportion to adoption, and
      only those EUNs which want portability, multihoming and inbound
      TE need to adopt the new kind of scalable "edge" address space.




CES - Core-Edge Separation Proposals
====================================

There are four Core-Edge Separation proposals:

   IRON-RANGER
   Ivip
   LISP
   TIDR

TIDR cannot be considered an effective scalable routing solution
because it uses the BGP control plane to carry its "mapping" - which
is little different from carrying routes for all end-user prefixes,
including those which are using the new scalable "edge" subset of the
global unicast address space.

IRON-RANGER is not yet specified in enough detail (in my view, and I
spent a long time trying to understand it) to enable anyone to
estimate its scaling and security properties - such as how each
prefix of "edge" space is registered, on a repeated, continual, basis
with one or more Virtual Prefix routers, which could be anywhere in
the Net.


TTR Mobility
------------

Any future architectural enhancement for IPv4 or IPv6 should support
mobility - since in the foreseeable future, there are going to be
billions of IP-capable mobile devices, probably 5 to 10 billion of
them.

TTR Mobility is described at:

  http://www.firstpr.com.au/ip/ivip/#mobile

     Works for both IPv4 and IPv6.

     The MN (Mobile Node) gets its own globally portable SPI
     (Scalable PI space, in Ivip, EID in LISP) space.

     The MN uses any access network, including behind one or more
     layers of NAT, using traditional MIP protocols or on SPI/EID
     space itself.

     Paths are generally optimal or close to optimal.

     All protocols are supported and correspondent hosts need no
     upgrades.

     MNs need only special tunneling software to the (typically)
     nearby Translating Tunnel Routers.  The rest of the MN's stack
     and all its applications are unchanged.

     Mapping changes are not required when the MN gets a new
     access network or address in a current access network.  Mapping
     changes are only desirable if the MN moves more than 1000km or
     so from its current TTR, and so would get shorter paths if it
     tunneled to a new, closer, TTR.

     Mapping changes do not disrupt sessions, since the MN has
     tunnels to the old and new TTR.

     Mapping is controlled by the TTR company's management system,
     not the MN.  This is more robust and further saves the MN from
     being involved in routing and addressing management.

LISP and Ivip (but not TIDR or IRON-RANGER) support TTR Mobility.
TTR Mobility does not place any extra architectural demands on CES
architectures such as LISP or Ivip.


LISP vs. Ivip
-------------

Of all the proposals, only LISP and Ivip:

  1 - Are potentially practical solutions to the IPv4 and IPv6
      routing scaling problems, without requiring any changes to host
      stacks or applications.  (All CES architectures maintain the
      current, efficient, 2-level naming model of IPv4 and IPv6 -
      without the need to adopt the "Locator / Identifier Separation"
      naming model.)

  2 - Support TTR Mobility, though Ivip would support it marginally
      better than LISP-ALT.

  3 - Provide immediate substantial benefits to all adopting networks
      - since Ivip's DITRs and LISP's PTRs handle all packets sent
      from networks without ITRs.

  4 - Provide immediate routing scaling benefits since adoptors get
      portability, multihoming and inbound TE for all their
      communications, without using PI space.



Vote [1] Ivip
-------------

Please note that until yesterday, Ivip was described with a single
inverted-tree-like "Replicator" system for fanning out mapping
changes to full-database, real-time-updated query servers in ISPs.

With the new DRTM arrangements, there is no such single, coordinated
global "Replicator" system, and no need for "Replicators" or any
query server having the full mapping database.  This should overcome
some concerns with previous arrangements.

  DRTM - Distributed Real Time Mapping for Ivip & LISP
  http://www.ietf.org/mail-archive/web/rrg/current/msg06128.html
  Later, see: draft-whittle-ivip-drtm

The DRTM material also explains how:

   SPI space for non-mobile networks can be deployed by companies
   which need not be ISPs, with the only required ISP support being
   accepting packets with SPI source address for forwarding.

   TTR Mobility being provided by companies which need not be ISPs -
   with there being no need for ISPs to change anything about their
   networks to allow MNs in their access networks to use TTR Mobility.

   DRTM will scale to billions of micronets, tens of thousands of
   MABs and potentially hundreds of MAB operating companies, without
   single points of failure or central coordination.

These arrangements should counter frequently expressed concerns about
Ivip, LISP, APT and in principle other CES architectures facing
adoption barriers due to ISPs not being motivated to adopt the new
system.

Ivip is unique in having a real-time mapping system so end-user
networks - or some other organisation they appoint to control the
mapping of their micronets (separately mapped contiguous sets of
IPv4 addresses or IPv6 /64s) - directly control the tunneling of all
ITRs in the world which are handling packets addressed to their
network.

This externalises the functions of:

   Detecting reachability of the network through various ETRs.
   Multi-homing restoration decision-making etc.
   Inbound TE control.
   Mapping changes to select a new TTR for TTR Mobility.

from the CES architecture itself.  LISP and all other CES
architectures except Ivip monolithically integrate the control of
mapping, and the related functions of reachability testing and
multihoming service restoration decision-making, into the CES
architecture.  In the case of LISP, this leads to some unsolved
problems with reachability testing, and to ITRs and ETRs being more
complex.

Ivip has a simple method of ETRs supporting any source address
filtering which is performed by ISP BRs on packets arriving from the
DFZ - by extending this automatically, in a very simple algorithm, to
the inner packet.

The ITR tunnels the packet with the outer header's source address
being that of the sending host, not itself.  When the packet arrives
at the ETR, if the inner header's source address differs from the
outer header's source address, the ETR drops the packet.  This works
fine with there being ITRs inside the ISP's network.  If LISP ETRs
were to re-implement ISP BR source address filtering on the
decapsulated packets for more than a handful of protected prefixes
they would need to use expensive - perhaps prohibitively expensive -
techniques, such as TCAM memory.

Ivip's encapsulation overhead is less than LISP's.

Ivip's approach to handling the Path MTU Discovery problems inherent
in encapsulation-based tunnels is better developed than LISP's.

In the long-term future Ivip will use Modified Header Forwarding -
separate techniques for IPv4 and IPv6 - to tunnel packets across the
DFZ without encapsulation overhead or the PMTUD problems which this
entails.

Ivip enables the ITR function to be performed in sending hosts,
including sending hosts on SPI addresses.  (Currently not on sending
hosts behind NAT, but this would be possible with a different
ITR -> caching query server protocol.)

Once SPI adoption becomes widespread, ISPs will be motivated to
install their own ITRs to locally tunnel packets sent from customer
networks which must be tunneled to SPI-using customers of the same
ISP - rather than letting these packets exit the ISP's network, be
tunneled by a DITR (Default ITR in the DFZ)and then return as a
tunneled packet to ETRs in the ISP's network.

There is no need for full-database query servers in ISPs or for any
device which stores the full mapping information for all Mapped
Address Blocks (MABs).  ISPs which want ITRs will install two or
more Map Resolver (MR) servers.  These are caching query servers
which query multiple typically nearby query servers which are full-
database for the subset of MABs they serve.

These (typically) "nearby" query servers will be at DITR sites, which
will be run by, or for, MAB operating companies who lease MAB space
to large numbers of end-user networks.  These DITR-site servers will
usually be close enough to the MRs to generate replies with
sufficiently low delay and risk of packet loss for ITRs to buffer
initial packets for a few tens of milliseconds while the mapping
arrives.

To read more about Ivip's goals and non-goals, its mechanisms, and
its benefits, please read the latest:

  http://tools.ietf.org/html/draft-whittle-ivip-arch

ivip-arch-03 is prior to DRTM.  If 03 is the latest version, please
also refer to the DTRM material:

  http://www.ietf.org/mail-archive/web/rrg/current/msg06128.html
  http://tools.ietf.org/html/draft-whittle-ivip-drtm



Vote [2] LISP
-------------

LISP may be able to solve the routing scaling problem for both IPv4
and IPv6.

For critiques of LISP, please see:

   LISP critique V2 (2010-01-21 499 words)
   http://www.ietf.org/mail-archive/web/rrg/current/msg05728.html

   747 word version:
   http://www.ietf.org/mail-archive/web/rrg/current/msg05722.html

   More critiques of LISP:
   http://www.firstpr.com.au/ip/ivip/lisp-links/#critiques

   Alternative LISP critique - Noel Chiappa  (2010-01-21)
   http://www.ietf.org/mail-archive/web/rrg/current/msg05747.html


In brief:

    LISP-NERD does not scale well and all other approaches to LISP
    involve global query server systems which cause initial packets
    in a new communication session to be frequently (or at least,
    unacceptably often) dropped or delayed.

    LISP ITRs need to be complex in order to determine reachability
    of ETRs and to make decisions about which ETR to tunnel to.  Yet
    there are still unresolved questions about the ability of an ITR
    to reliably and scalably determine reachability of the
    destination network through each ETR.

    LISP's encapsulation overhead is greater than Ivip's.

    LISP ETRs have no efficient method of enforcing ISP BR source
    address filtering on the traffic packets the decapsulate and
    forward.

    LISP-ALT has serious scaling problems, involving potentially
    very long paths and consequent delay in ITRs forwarding packets.
    ALT, at present, involves ITRs dropping packets they have no
    mapping for.  Only when mapping arrives and the sending host
    generates another packet to the same EID address will the ITR
    actually tunnel a packet to the correct ETR.

    LISP builds into its own architecture all direct control of ITR
    tunneling.  EUNs can only control ITRs in non-real-time - by
    specifying multiple ETRs and giving priorities and load-sharing
    instructions.

I believe LISP would be greatly improved by adopting Ivip's DRTM
mapping system.  But Ivip already has this, and other benefits
besides, so please Vote [1] Ivip!