[rrg] Ivip "rebuttal"

[Robin Whittle <[e-mail]>]

Here is a 499 word "rebuttal" for Ivip.

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

  - Robin




Since the Summary and Critique were written, Ivip's mapping system
has been significantly redesigned: DRTM - Distributed Real Time
Mapping (draft-whittle-ivip-drtm-00).

DRTM makes it easier for ISPs to install their own ITRs.  It also
facilitates MAB (Mapped Address Block) operating companies - which
need not be ISPs - leasing SPI address space to end-user networks
with almost no ISP involvement.  ISPs need not install ITRs or ETRs.
 For an ISP to support its customers using SPI space, they need only
allow the forwarding outgoing packets whose source addresses are from
SPI space.  End-user networks can implement their own ETRs on their
existing PA address(es) - and MAB operating companies make all the
initial investments.

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 and
return in tunnels to ETRs in the 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 "nearby" query servers will
be at DITR (Default ITR in the DFZ) 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.

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.

The critique implies a threshold of adoption is required before
significant routing scaling benefits occur.  This is untrue of any
Core-Edge Separation proposal, including LISP and Ivip.  Both can
achieve scalable routing benefits in direct proportion to their level
of adoption by providing portability, multihoming and inbound TE to
large numbers of end-user networks.

Core-Edge Elimination architectures require all Internet
communications to change to IPv6 with a new Locator/Identifier
Separation naming model.  This would impose burdens of extra
management effort, packets and session establishment delays on all
hosts - which is a particularly unacceptable burden on
battery-operated mobile hosts which rely on wireless links.

Core-Edge Separation architectures retain the current, efficient,
naming model, require no changes to hosts and support both IPv4 and
IPv6.  Ivip is the most promising architecture for future development
because its scalable, distributed, real-time mapping system best
supports TTR Mobility, enables ITRs to be simpler and gives real-time
control of ITR tunneling to the end-user network or to organizations
they appoint to control the mapping of their micronets.