4.  Internet Vastly Improved Plumbing (Ivip)

4.1.  Summary

4.1.1.  Key Ideas

   Ivip (pronounced eye-vip, est. 2007-06-15) is a Core-Edge Separation
   scheme for IPv4 and IPv6.  It provides multihoming, portability of
   address space, and inbound traffic engineering for end-user networks
   of all sizes and types, including those of corporations, SOHO (Small
   Office, Home Office), and mobile devices.

   Ivip meets all the constraints imposed by the need for widespread
   voluntary adoption [Ivip_Constraints].

   Ivip's global fast-push mapping distribution network is structured
   like a cross-linked multicast tree.  This pushes all mapping changes
   to full-database query servers (QSDs) within ISPs and end-user
   networks that have ITRs.  Each mapping change is sent to all QSDs
   within a few seconds.  (Note: "QSD" is from Query Server with full
   Database.)

   ITRs gain mapping information from these local QSDs within a few tens
   of milliseconds.  QSDs notify ITRs of changed mappings with similarly
   low latency.  ITRs tunnel all traffic packets to the correct ETR
   without significant delay.

   Ivip's mapping consists of a single ETR address for each range of
   mapped address space.  Ivip ITRs do not need to test reachability to
   ETRs because the mapping is changed in real-time to that of the
   desired ETR.

   End-user networks control the mapping, typically by contracting a
   specialized company to monitor the reachability of their ETRs, and
   change the mapping to achieve multihoming and/or traffic engineering
   (TE).  So, the mechanisms that control ITR tunneling are controlled
   by the end-user networks in real-time and are completely separate
   from the Core-Edge Separation scheme itself.

   ITRs can be implemented in dedicated servers or hardware-based
   routers.  The ITR function can also be integrated into sending hosts.
   ETRs are relatively simple and only communicate with ITRs rarely --
   for Path MTU management with longer packets.

   Ivip-mapped ranges of end-user address space need not be subnets.
   They can be of any length, in units of IPv4 addresses or IPv6 /64s.

   Compared to conventional unscalable BGP techniques, and to the use of
   Core-Edge Separation architectures with non-real-time mapping
   systems, end-user networks will be able to achieve more flexible and
   responsive inbound TE.  If inbound traffic is split into several
   streams, each to addresses in different mapped ranges, then real-time
   mapping changes can be used to steer the streams between multiple
   ETRs at multiple ISPs.

   Default ITRs in the DFZ (DITRs; similar to LISP's Proxy Tunnel
   Routers) tunnel packets sent by hosts in networks that lack ITRs.  So
   multihoming, portability, and TE benefits apply to all traffic.

   ITRs request mappings either directly from a local QSD or via one or
   more layers of caching query servers (QSCs), which in turn request it
   from a local QSD.  QSCs are optional but generally desirable since
   they reduce the query load on QSDs.  (Note: "QSC" is from Query
   Server with Cache.)

   ETRs may be in ISP or end-user networks.  IP-in-IP encapsulation is
   used, so there is no UDP or any other header.  PMTUD (Path MTU
   Discovery) management with minimal complexity and overhead will
   handle the problems caused by encapsulation, and adapt smoothly to
   jumbo frame paths becoming available in the DFZ.  The outer header's
   source address is that of the sending host -- this enables existing
   ISP Border Router (BR) filtering of source addresses to be extended
   to encapsulated traffic packets by the simple mechanism of the ETR
   dropping packets whose inner and outer source address do not match.

4.1.2.  Extensions

4.1.2.1.  TTR Mobility

   The Translating Tunnel Router (TTR) approach to mobility
   [Ivip_Mobility] is applicable to all Core-Edge Separation techniques
   and provides scalable IPv4 and IPv6 mobility in which the MN keeps
   its own mapped IP address(es) no matter how or where it is physically
   connected, including behind one or more layers of NAT.

   Path lengths are typically optimal or close to optimal, and the MN
   communicates normally with all other non-mobile hosts (no stack or
   application changes), and of course other MNs.  Mapping changes are
   only needed when the MN uses a new TTR, which would typically occur
   if the MN moved more than 1000 km.  Mapping changes are not required
   when the MN changes its physical address(es).

4.1.2.2.  Modified Header Forwarding

   Separate schemes for IPv4 and IPv6 enable tunneling from ITR to ETR
   without encapsulation.  This will remove the encapsulation overhead
   and PMTUD problems.  Both approaches involve modifying all routers
   between the ITR and ETR to accept a modified form of the IP header.
   These schemes require new FIB/RIB functionality in DFZ and some other
   routers but do not alter the BGP functions of DFZ routers.

4.1.3.  Gains

   o  Amenable to widespread voluntary adoption due to no need for host
      changes, complete support for packets sent from non-upgraded
      networks and no significant degradation in performance.

   o  Modular separation of the control of ITR tunneling behavior from
      the ITRs and the Core-Edge Separation scheme itself: end-user
      networks control mapping in any way they like, in real-time.

   o  A small fee per mapping change deters frivolous changes and helps
      pay for pushing the mapping data to all QSDs.  End-user networks
      that make frequent mapping changes for inbound TE should find
      these fees attractive considering how it improves their ability to
      utilize the bandwidth of multiple ISP links.

   o  End-user networks will typically pay the cost of Open ITR in the
      DFZ (OITRD) forwarding to their networks.  This provides a
      business model for OITRD deployment and avoids unfair distribution
      of costs.

   o  Existing source address filtering arrangements at BRs of ISPs and
      end-user networks are prohibitively expensive to implement
      directly in ETRs, but with the outer header's source address being
      the same as the sending host's address, Ivip ETRs inexpensively
      enforce BR filtering on decapsulated packets.

4.1.4.  Costs

   QSDs receive all mapping changes and store a complete copy of the
   mapping database.  However, a worst-case scenario is 10 billion IPv6
   mappings, each of 32 bytes, which fits on a consumer hard drive today
   and should fit in server DRAM by the time such adoption is reached.

   The maximum number of non-mobile networks requiring multihoming,
   etc., is likely to be ~10 million, so most of the 10 billion mappings
   would be for mobile devices.  However, TTR mobility does not involve
   frequent mapping changes since most MNs only rarely move more than
   1000 km.

4.1.5.  References

   [Ivip_EAF] [Ivip_PMTUD] [Ivip_PLF] [Ivip_Constraints] [Ivip_Mobility]
   [Ivip_DRTM] [Ivip_Glossary]

4.2.  Critique

   Looked at from the thousand-foot level, Ivip shares the basic design
   approaches with LISP and a number of other map-and-encap designs
   based on the Core-Edge Separation.  However, the details differ
   substantially.  Ivip's design makes a bold assumption that, with
   technology advances, one could afford to maintain a real-time
   distributed global mapping database for all networks and hosts.  Ivip
   proposes that multiple parties collaborate to build a mapping
   distribution system that pushes all mapping information and updates
   to local, full-database query servers located in all ISPs within a
   few seconds.  The system has no single point of failure and uses end-
   to-end authentication.

   A "real time, globally synchronized mapping database" is a critical
   assumption in Ivip.  Using that as a foundation, Ivip design avoids
   several challenging design issues that others have studied
   extensively, that include

   1.  special considerations of mobility support that add additional
       complexity to the overall system;

   2.  prompt detection of ETR failures and notification to all relevant
       ITRs, which turns out to be a rather difficult problem; and

   3.  development of a partial-mapping lookup sub-system.  Ivip assumes
       the existence of local query servers with a full database with
       the latest mapping information changes.

   To be considered as a viable solution to the Internet routing
   scalability problem, Ivip faces two fundamental questions.  First,
   whether a global-scale system can achieve real-time synchronized
   operations as assumed by Ivip is an entirely open question.  Past
   experiences suggest otherwise.

   The second question concerns incremental rollout.  Ivip represents an
   ambitious approach, with real-time mapping and local full-database
   query servers -- which many people regard as impossible.  Developing
   and implementing Ivip may take a fair amount of resources, yet there
   is an open question regarding how to quantify the gains by first
   movers -- both those who will provide the Ivip infrastructure and

   those that will use it.  Significant global routing table reduction
   only happens when a large enough number of parties have adopted Ivip.
   The same question arises for most other proposals as well.

   One belief is that Ivip's more ambitious mapping system makes a good
   design tradeoff for the greater benefits for end-user networks and
   for those that develop the infrastructure.  Another belief is that
   this ambitious design is not viable.

4.3.  Rebuttal

   Since the Summary and Critique were written, Ivip's mapping system
   has been significantly redesigned: DRTM - Distributed Real Time
   Mapping [Ivip_DRTM].

   DRTM makes it easier for ISPs to install their own ITRs.  It also
   facilitates Mapped Address Block (MAB) operating companies -- which
   need not be ISPs -- leasing Scalable Provider-Independent (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 of
   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 that are sent from
   customer networks and that 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 that stores the full mapping information for all Mapped
   Address Blocks (MABs).  ISPs that want ITRs will install two or more
   Map Resolver (MR) servers.  These are caching query servers which
   query multiple (typically nearby) query servers that are full-
   database for the subset of MABs they serve.  These "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.

   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 (CEE) 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 that 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.

5.  Hierarchical IPv4 Framework (hIPv4)

5.1.  Summary

5.1.1.  Key Idea

   The Hierarchical IPv4 Framework (hIPv4) adds scalability to the
   routing architecture by introducing additional hierarchy in the IPv4
   address space.  The IPv4 addressing scheme is divided into two parts,
   the Area Locator (ALOC) address space, which is globally unique, and
   the Endpoint Locator (ELOC) address space, which is only regionally
   unique.  The ALOC and ELOC prefixes are added as a shim header
   between the IP header and transport protocol header; the shim header
   is identified with a new protocol number in the IP header.  Instead
   of creating a tunneling (i.e., overlay) solution, a new routing
   element is needed in the service provider's routing domain (called
   ALOC realm) -- a Locator Swap Router.  The current IPv4 forwarding
   plane remains intact, and no new routing protocols, mapping systems,
   or caching solutions are required.  The control plane of the ALOC
   realm routers needs some modification in order for ICMP to be
   compatible with the hIPv4 framework.  When an area (one or several
   autonomous systems (ASes)) of an ISP has transformed into an ALOC
   realm, only ALOC prefixes are exchanged with other ALOC realms.
   Directly attached ELOC prefixes are only inserted to the RIB of the
   local ALOC realm; ELOC prefixes are not distributed to the DFZ.
   Multihoming can be achieved in two ways, either the enterprise

   requests an ALOC prefix from the RIR (this is not recommended) or the
   enterprise receives the ALOC prefixes from their upstream ISPs.  ELOC
   prefixes are PI addresses and remain intact when an upstream ISP is
   changed; only the ALOC prefix is replaced.  When the RIB of the DFZ
   is compressed (containing only ALOC prefixes), ingress routers will
   no longer know the availability of the destination prefix; thus, the
   endpoints must take more responsibility for their sessions.  This can
   be achieved by using multipath enabled transport protocols, such as
   SCTP [RFC4960] and Multipath TCP (MPTCP) [MPTCP_Arch], at the
   endpoints.  The multipath transport protocols also provide a session
   identifier, i.e., verification tag or token; thus, the location and
   identifier split is carried out -- site mobility, endpoint mobility,
   and mobile site mobility are achieved.  DNS needs to be upgraded: in
   order to resolve the location of an endpoint, the endpoint must have
   one ELOC value (current A-record) and at least one ALOC value in DNS
   (in multihoming solutions there will be several ALOC values for an
   endpoint).

5.1.2.  Gains

   1.  Improved routing scalability: Adding additional hierarchy to the
       address space enables more hierarchy in the routing architecture.
       Early adapters of an ALOC realm will no longer carry the current
       RIB of the DFZ -- only ELOC prefixes of their directly attached
       networks and ALOC prefixes from other service providers that have
       migrated are installed in the ALOC realm's RIB.

   2.  Scalable support for traffic engineering: Multipath enabled
       transport protocols are recommended to achieve dynamic load-
       balancing of a session.  Support for Valiant Load-balancing (VLB)
       [Valiant] schemes has been added to the framework; more research
       work is required around VLB switching.

   3.  Scalable support for multihoming: Only attachment points of a
       multihomed site are advertised (using the ALOC prefix) in the
       DFZ.  DNS will inform the requester on how many attachment points
       the destination endpoint has.  It is the initiating endpoint's
       choice/responsibility to choose which attachment point is used
       for the session; endpoints using multipath-enabled transport
       protocols can make use of several attachment points for a
       session.

   4.  Simplified Renumbering: When changing provider, the local ELOC
       prefixes remains intact; only the ALOC prefix is changed at the
       endpoints.  The ALOC prefix is not used for routing or forwarding
       decisions in the local network.

   5.  Decoupling Location and Identifier: The verification tag (SCTP)
       and token (MPTCP) can be considered to have the characteristics
       of a session identifier, and thus a session layer is created
       between the transport and application layers in the TCP/IP model.

   6.  Routing quality: The hIPv4 framework introduces no tunneling or
       caching mechanisms.  Only a swap of the content in the IPv4
       header and locator header at the destination ALOC realm is
       required; thus, current routing and forwarding algorithms are
       preserved as such.  Valiant Load-balancing might be used as a new
       forwarding mechanism.

   7.  Routing Security: Similar as with today's DFZ, except that ELOC
       prefixes cannot be hijacked (by injecting a longest match prefix)
       outside an ALOC realm.

   8.  Deployability: The hIPv4 framework is an evolution of the current
       IPv4 framework and is backwards compatible with the current IPv4
       framework.  Sessions in a local network and inside an ALOC realm
       might in the future still use the current IPv4 framework.

5.1.3.  Costs and Issues

   1.  Upgrade of the stack at an endpoint that is establishing sessions
       outside the local ALOC realm.

   2.  In a multihoming solution, the border routers should be able to
       apply policy-based routing upon the ALOC value in the locator
       header.

   3.  New IP allocation policies must be set by the RIRs.

   4.  There is a short timeframe before the expected depletion of the
       IPv4 address space occurs.

   5.  Will enterprises give up their current globally unique IPv4
       address block allocation they have gained?

   6.  Coordination with MPTCP is highly desirable.

5.1.4.  References

   [hIPv4] [Valiant]

5.2.  Critique

   hIPv4 is an innovative approach to expanding the IPv4 addressing
   system in order to resolve the scalable routing problem.  This
   critique does not attempt a full assessment of hIPv4's architecture
   and mechanisms.  The only question addressed here is whether hIPv4
   should be chosen for IETF development in preference to, or together
   with, the only two proposals which appear to be practical solutions
   for IPv4: Ivip and LISP.

   Ivip and LISP appear to have a major advantage over hIPv4 in terms of
   support for packets sent from non-upgraded hosts/networks.  Ivip's
   DITRs (Default ITRs in the DFZ) and LISP's PTRs (Proxy Tunnel
   Routers) both accept packets sent by any non-upgraded host/network
   and tunnel them to the correct ETR -- thus providing the full
   benefits of portability, multihoming, and inbound TE for these
   packets as well as those sent by hosts in networks with ITRs. hIPv4
   appears to have no such mechanism, so these benefits are only
   available for communications between two upgraded hosts in upgraded
   networks.

   This means that significant benefits for adopters -- the ability to
   rely on the new system to provide the portability, multihoming, and
   inbound TE benefits for all, or almost all, their communications --
   will only arise after all, or almost all, networks upgrade their
   networks, hosts, and addressing arrangements. hIPv4's relationship
   between adoption levels and benefits to any adopter therefore are far
   less favorable to widespread adoption than those of Core-Edge
   Separation (CES) architectures such as Ivip and LISP.

   This results in hIPv4 also being at a disadvantage regarding the
   achievement of significant routing scaling benefits, which likewise
   will only result once adoption is close to ubiquitous.  Ivip and LISP
   can provide routing scaling benefits in direct proportion to their
   level of adoption, since all adopters gain full benefits for all
   their communications, in a highly scalable manner.

   hIPv4 requires stack upgrades, which are not required by any CES
   architecture.  Furthermore, a large number of existing IPv4
   application protocols convey IP addresses between hosts in a manner
   that will not work with hIPv4: "There are several applications that
   are inserting IP address information in the payload of a packet.
   Some applications use the IP address information to create new
   sessions or for identification purposes.  This section is trying to
   list the applications that need to be enhanced; however, this is by
   no means a comprehensive list" [hIPv4].

   If even a few widely used applications would need to be rewritten to
   operate successfully with hIPv4, then this would be such a
   disincentive to adoption to rule out hIPv4 ever being adopted widely
   enough to solve the routing scaling problem, especially since CES
   architectures fully support all existing protocols, without the need
   for altering host stacks.

   It appears that hIPv4 involves major practical difficulties, which
   mean that in its current form it is not suitable for IETF
   development.

5.3.  Rebuttal

   No rebuttal was submitted for this proposal.

6.  Name Overlay (NOL) Service for Scalable Internet Routing

6.1.  Summary

6.1.1.  Key Idea

   The basic idea is to add a name overlay (NOL) onto the existing
   TCP/IP stack.

   Its functions include:

   1.  Managing host name configuration, registration, and
       authentication;

   2.  Initiating and managing transport connection channels (i.e.,
       TCP/IP connections) by name;

   3.  Keeping application data transport continuity for mobility.

   At the edge network, we introduce a new type of gateway, a Name
   Transfer Relay (NTR), which blocks the PI addresses of edge networks
   into upstream transit networks.  NTRs perform address and/or port
   translation between blocked PI addresses and globally routable
   addresses, which seem like today's widely used NAT / Network Address
   Port Translation (NAPT) devices.  Both legacy and NOL applications
   behind a NTR can access the outside as usual.  To access the hosts
   behind a NTR from outside, we need to use NOL to traverse the NTR by
   name and initiate connections to the hosts behind it.

   Different from proposed host-based ID/locator split solutions, such
   as HIP, Shim6, and name-oriented stack, NOL doesn't need to change
   the existing TCP/IP stack, sockets, or their packet formats.  NOL can
   coexist with the legacy infrastructure, and the Core-Edge Separation
   solutions (e.g., APT, LISP, Six/One, Ivip, etc.).

6.1.2.  Gains

   1.   Reduce routing table size: Prevent edge network PI address from
        leaking into the transit network by deploying gateway NTRs.

   2.   Traffic Engineering: For legacy and NOL application sessions,
        the incoming traffic can be directed to a specific NTR by DNS.
        In addition, for NOL applications, initial sessions can be
        redirected from one NTR to other appropriate NTRs.  These
        mechanisms provide some support for traffic engineering.

   3.   Multihoming: When a PI addressed network connects to the
        Internet by multihoming with several providers, it can deploy
        NTRs to prevent the PI addresses from leaking into provider
        networks.

   4.   Transparency: NTRs can be allocated PA addresses from the
        upstream providers and store them in NTRs' address pool.  By DNS
        query or NOL session, any session that wants to access the hosts
        behind the NTR can be delegated to a specific PA address in the
        NTR address pool.

   5.   Mobility: The NOL layer manages the traditional TCP/IP transport
        connections, and provides application data transport continuity
        by checkpointing the transport connection at sequence number
        boundaries.

   6.   No need to change TCP/IP stack, sockets, or DNS system.

   7.   No need for extra mapping system.

   8.   NTR can be deployed unilaterally, just like NATs.

   9.   NOL applications can communicate with legacy applications.

   10.  NOL can be compatible with existing solutions, such as APT,
        LISP, Ivip, etc.

   11.  End-user-controlled multipath indirect routing based on
        distributed NTRs.  This will give benefits to the performance-
        aware applications, such as video streaming, applications on
        MSN.com, etc.

6.1.3.  Costs

   1.  Legacy applications have trouble with initiating access to the
       servers behind NTR.  Such trouble can be resolved by deploying
       the NOL proxy for legacy hosts, or delegating globally routable
       PA addresses in the NTR address pool for these servers, or
       deploying a proxy server outside the NTR.

   2.  NOL may increase the number of entries in DNS, but it is not
       drastic because it only increases the number of DNS records at
       domain granularity not the number of hosts.  The name used in
       NOL, for example, is similar to an email address
       hostname@example.net.  The needed DNS entries and query are just
       for "example.net", and the NTR knows the "hostnames".  Not only
       will the number of DNS records be increased, but the dynamics of
       DNS might be agitated as well.  However, the scalability and
       performance of DNS are guaranteed by its naming hierarchy and
       caching mechanisms.

   3.  Address translating/rewriting costs on NTRs.

6.1.4.  References

   No references were submitted.

6.2.  Critique

   1.  Applications on hosts need to be rebuilt based on a name overlay
       library to be NOL-enabled.  The legacy software that is not
       maintained will not be able to benefit from NOL in the Core-Edge
       Elimination situation.  In the Core-Edge Separation scheme, a new
       gateway NTR is deployed to prevent edge-specific PI prefixes from
       leaking into the transit core.  NOL doesn't impede the legacy
       endpoints behind the NTR from accessing the outside Internet, but
       the legacy endpoints cannot access or will have difficultly
       accessing the endpoints behind a NTR without the help of NOL.

   2.  In the case of Core-Edge Elimination, the end site will be
       assigned multiple PA address spaces, which leads to renumbering
       troubles when switching to other upstream providers.  Upgrading
       endpoints to support NOL doesn't give any benefits to edge
       networks.  Endpoints have little incentive to use NOL in a Core-
       Edge Elimination scenario, and the same is true with other host-
       based ID/locator split proposals.  Whether they are IPv4 or IPv6
       networks, edge networks prefer PI address space to PA address
       space.

   3.  In the Core-Edge Separation scenario, the additional gateway NTR
       is to prevent the specific prefixes from the edge networks, just
       like a NAT or the ITR/ETR of LISP.  A NTR gateway can be seen as
       an extension of NAT (Network Address Translation).  Although NATs
       are deployed widely, upgrading them to support NOL extension or
       deploying additional new gateway NTRs at the edge networks is on
       a voluntary basis and has few economic incentives.

   4.  The stateful or stateless translation for each packet traversing
       a NTR will require the cost of the CPU and memory of NTRs, and
       increase forwarding delay.  Thus, it is not appropriate to deploy
       NTRs at the high-level transit networks where aggregated traffic
       may cause congestion at the NTRs.

   5.  In the Core-Edge Separation scenario, the requirement for
       multihoming and inter-domain traffic engineering will make end
       sites accessible via multiple different NTRs.  For reliability,
       all of the associations between multiple NTRs and the end site
       name will be kept in DNS, which may increase the load on DNS.

   6.  To support mobility, it is necessary for DNS to update the
       corresponding name-NTR mapping records when an end system moves
       from behind one NTR to another NTR.  The NOL-enabled end relies
       on the NOL layer to preserve the continuity of the transport
       layer, since the underlying TCP/UDP transport session would be
       broken when the IP address changed.

6.3.  Rebuttal

   NOL resembles neither CEE nor CES as a solution.  By supporting
   application-level sessions through the name overlay layer, NOL can
   support some solutions in the CEE style.  However, NOL is in general
   closer to CES solutions, i.e., preventing PI prefixes of edge
   networks from entering into the upstream transit networks.  This is
   done by the NTR, like the ITRs/ETRs in CES solutions, but NOL has no
   need to define the clear boundary between core and edge networks.
   NOL is designed to try to provide end users or networks a service
   that facilitates the adoption of multihoming, multipath routing, and
   traffic engineering by the indirect routing through NTRs, and that,
   in the mean time, doesn't accelerate or decelerate the growth of
   global routing table size.

   Some problems are described in the NOL critique.  In the original NOL
   proposal document, the DNS query for a host that is behind a NTR will
   induce the return of the actual IP addresses of the host and the
   address of the NTR.  This arrangement might cause some difficulties
   for legacy applications due to the non-standard response from DNS.
   To resolve this problem, we instead have the NOL service use a new

   namespace, and have DNS not return NTR IP addresses for the legacy
   hosts.  The names used for NOL are formatted like email addresses,
   such as "des@example.net".  The mapping between "example.net" and the
   IP address of the corresponding NTR will be registered in DNS.  The
   NOL layer will understand the meaning of the name "des@example.net" ,
   and it will send a query to DNS only for "example.net".  DNS will
   then return IP addresses of the corresponding NTRs.  Legacy
   applications will still use the traditional FQDN name, and DNS will
   return the actual IP address of the host.  However, if the host is
   behind a NTR, the legacy applications may be unable to access the
   host.

   The stateless address translation or stateful address and port
   translation may cause a scaling problem with the number of table
   entries NTR must maintain, and legacy applications cannot initiate
   sessions with hosts inside the NOL-adopting End User Network (EUN).
   However, these problems may not be a big barrier for the deployment
   of NOL or other similar approaches.  Many NAT-like boxes, proxy, and
   firewall devices are widely used at the ingress/egress points of
   enterprise networks, campus networks, or other stub EUNs.  The hosts
   running as servers can be deployed outside NTRs or can be assigned PA
   addresses in an NTR-adopting EUN.

7.  Compact Routing in a Locator Identifier Mapping System (CRM)

7.1.  Summary

7.1.1.  Key Idea

   This proposal (referred to here as "CRM") is to build a highly
   scalable locator identity mapping system using compact routing
   principles.  This provides the means for dynamic topology adaption to
   facilitate efficient aggregation [CRM].  Map servers are assigned as
   cluster heads or landmarks based on their capability to aggregate EID
   announcements.

7.1.2.  Gains

   o  Minimizes the routing table sizes at the system level (i.e., map
      servers).  Provides clear upper bounds for routing stretch that
      define the packet delivery delay of the map request / first
      packet.

   o  Organizes the mapping system based on the EID numbering space,
      minimizes the administrative overhead of managing the EID space.
      No need for administratively planned hierarchical address
      allocation as the system will find convergence into a set of EID
      allocations.

   o  Availability and robustness of the overall routing system
      (including xTRs and map servers) are improved because of the
      potential to use multiple map servers and direct routes without
      the involvement of map servers.

7.1.3.  Costs

   The scalability gains will materialize only in large deployments.  If
   the stretch is bounded to those of compact routing (worst-case
   stretch less or equal to 3, on average, 1+epsilon), then each xTR
   needs to have memory/cache for the mappings of its cluster.

7.1.4.  References

   [CRM]

7.2.  Critique

   The CRM proposal is not a complete proposal and therefore cannot be
   considered for further development by the IETF as a scalable routing
   solution.

   While Compact Routing principles may be able to improve a mapping
   overlay structure such as LISP+ALT, there are several objections to
   this approach.

   Firstly, a CRM-modified ALT structure would still be a global query
   server system.  No matter how ALT's path lengths and delays are
   optimized, there is a problem with a querier -- which could be
   anywhere in the world -- relying on mapping information from one or
   ideally two or more authoritative query servers, which could also be
   anywhere in the world.  The delays and risks of packet loss that are
   inherent in such a system constitute a fundamental problem.  This is
   especially true when multiple, potentially long, traffic streams are
   received by ITRs and forwarded over the CRM networks for delivery to
   the destination network.  ITRs must use the CRM infrastructure while
   they are awaiting a map reply.  The traffic forwarded on the CRM
   infrastructure functions as map requests and can present a
   scalability and performance issue to the infrastructure.

   Secondly, the alterations contemplated in this proposal involve the
   roles of particular nodes in the network being dynamically assigned
   as part of the network's self-organizing nature.

   The discussion of clustering in the middle of page 4 of [CRM] also
   indicates that particular nodes are responsible for registering EIDs
   from typically far-distant ETRs, all of which are handling closely
   related EIDs that this node can aggregate.  Since MSes are apparently

   nodes within the compact routing system, and the process of an MS
   deciding whether to accept EID registrations is determined as part of
   the self-organizing properties of the system, there are concerns
   about how EID registration can be performed securely, when no
   particular physical node is responsible for it.

   Thirdly, there are concerns about individually owned nodes performing
   work for other organizations.  Such problems of trust and of
   responsibilities and costs being placed on those who do not directly
   benefit already exist in the inter-domain routing system and are a
   challenge for any scalable routing solution.

   There are simpler solutions to the mapping problem than having an
   elaborate network of routers.  If a global-scale query system is
   still preferred, then it would be better to have ITRs use local MRs,
   each of which is dynamically configured to know the IP address of the
   million or so authoritative Map Server (MS) query servers -- or two
   million or so assuming they exist in pairs for redundancy.

   It appears that the inherently greater delays and risks of packet
   loss of global query server systems make them unsuitable mapping
   solutions for Core-Edge Elimination or Core-Edge Separation
   architectures.  The solution to these problems appears to involve a
   greater number of widely distributed authoritative query servers, one
   or more of which will therefore be close enough to each querier that
   delays and risk of packet loss are reduced to acceptable levels.
   Such a structure would be suitable for map requests, but perhaps not
   for handling traffic packets to be delivered to the destination
   networks.

7.3.  Rebuttal

   CRM is most easily understood as an alteration to the routing
   structure of the LISP+ALT mapping overlay system, by altering or
   adding to the network's BGP control plane.

   CRM's aims include the delivery of initial traffic packets to their
   destination networks where they also function as map requests.  These
   packet streams may be long and numerous in the fractions of a second
   to perhaps several seconds that may elapse before the ITR receives
   the map reply.

   Compact Routing principles are used to optimize the path length taken
   by these query or traffic packets through a significantly modified
   version of the ALT (or similar) network, while also generally
   reducing typical or maximum paths taken by the query packets.

   An overlay network is a diversion from the shortest path.  However,
   CMR limits this diversion and provides an upper bound.  Landmark
   routers/servers could deliver more than just the first traffic
   packet, subject to their CPU capabilities and their network
   connectivity bandwidths.

   The trust between the landmarks (mapping servers) can be built based
   on the current BGP relationships.  Registration to the landmark nodes
   needs to be authenticated mutually between the MS and the system that
   is registering.  This part is not documented in the proposal text.