One document matched: draft-irtf-rrg-recommendation-16.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC3007 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3007.xml">
<!ENTITY RFC3552 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC4033 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC4034 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4034.xml">
<!ENTITY RFC4035 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035.xml">
<!ENTITY RFC4423 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4423.xml">
<!ENTITY RFC4861 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY RFC4960 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960.xml">
<!ENTITY RFC5201 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5201.xml">
<!ENTITY RFC5214 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5214.xml">
<!ENTITY RFC5534 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5534.xml">
<!ENTITY RFC5720 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5720.xml">
<!ENTITY RFC5887 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5887.xml">
<!ENTITY RFC5902 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5902.xml">
<!ENTITY I-D.narten-radir-problem-statement SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-radir-problem-statement.xml">
<!ENTITY I-D.irtf-rrg-design-goals SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.irtf-rrg-design-goals.xml">
<!ENTITY I-D.ietf-lisp SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp.xml">
<!ENTITY I-D.ietf-lisp-alt SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-alt.xml">
<!ENTITY I-D.ietf-lisp-ms SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-ms.xml">
<!ENTITY I-D.ietf-lisp-interworking SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-interworking.xml">
<!ENTITY I-D.meyer-lisp-mn SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.meyer-lisp-mn.xml">
<!ENTITY I-D.farinacci-lisp-lig SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.farinacci-lisp-lig.xml">
<!ENTITY I-D.meyer-loc-id-implications SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.meyer-loc-id-implications.xml">
<!ENTITY I-D.xu-rangi SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.xu-rangi.xml">
<!ENTITY I-D.xu-rangi-proxy SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.xu-rangi-proxy.xml">
<!ENTITY I-D.whittle-ivip4-etr-addr-forw SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.whittle-ivip4-etr-addr-forw.xml">
<!ENTITY I-D.frejborg-hipv4 SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.frejborg-hipv4.xml">
<!ENTITY I-D.adan-idr-tidr SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.adan-idr-tidr.xml">
<!ENTITY I-D.zhang-evolution SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.zhang-evolution.xml">
<!ENTITY I-D.templin-iron SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.templin-iron.xml">
<!ENTITY I-D.russert-rangers SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.russert-rangers.xml">
<!ENTITY I-D.templin-intarea-vet SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.templin-intarea-vet.xml">
<!ENTITY I-D.templin-intarea-seal SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.templin-intarea-seal.xml">
<!ENTITY I-D.rja-ilnp-nonce SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.rja-ilnp-nonce.xml">
<!ENTITY I-D.carpenter-behave-referral-object SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.carpenter-behave-referral-object.xml">
<!ENTITY I-D.ford-mptcp-architecture SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ford-mptcp-architecture.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-irtf-rrg-recommendation-16"
ipr="trust200902">
<front>
<title abbrev="RRG Recommendation">Recommendation for a Routing
Architecture</title>
<author fullname="Tony Li" initials="T." role="editor"
surname="Li">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 West Tasman Dr.</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+1 408 853 9317</phone>
<email>tony.li@tony.li</email>
</address>
</author>
<date month='November' day='29' year="2010" />
<area></area>
<workgroup>Internet Research Task Force</workgroup>
<keyword>routing</keyword>
<abstract>
<t>
It is commonly recognized that the Internet routing and addressing
architecture is facing challenges in scalability, multihoming, and
inter-domain traffic engineering. This document presents, as a
recommendation of future directions for the IETF, solutions which
could aid the future scalability of the Internet. To this end, this
document surveys many of the proposals that were brought forward
for discussion in this activity, as well as some of the subsequent
analysis and the architectural recommendation of the chairs. This
document is a product of the Routing Research Group.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
It is commonly recognized that the Internet routing and addressing
architecture is facing challenges in scalability, multihoming, and
inter-domain traffic engineering. The problem being addressed has
been documented in
<xref target='I-D.narten-radir-problem-statement'/>, and the design
goals that we have discussed can be found in
<xref target='I-D.irtf-rrg-design-goals'/>.
</t>
<t>
This document surveys many of the proposals that were brought
forward for discussion in this activity. For some of the
proposals, this document also includes additional analysis showing
some of the concerns with specific proposals, and how some of those
concerns may be addressed. Readers are cautioned not to draw any
conclusions about the degree of interest or endorsement by the
Routing Research Group (RRG) from the presence of any proposals in
this document, or the amount of analysis devoted to specific
proposals.
</t>
<section title="Background to This Document">
<t>
The RRG was chartered to research and recommend a new routing
architecture for the Internet. The goal was to explore many
alternatives and build consensus around a single proposal. The
only constraint on the group's process was that the process be
open and the group set forth with the usual discussion of
proposals and trying to build consensus around them. There were
no explicit contingencies in the group's process for the
eventuality that the group did not reach consensus.
</t>
<t>
The group met at every IETF meeting from March 2007 to March 2010
and discussed many proposals, both in person and via its mailing
list. Unfortunately, the group did not reach consensus. Rather
than lose the contributions and progress that had been made, the
chairs (Lixia Zhang, Tony Li) elected to collect the proposals of
the group and some of the debate concerning the proposals and
make a recommendation from those proposals. Thus, the
recommendation reflects the opinions of the chairs and not
necessarily the consensus of the group.
</t>
<t>
The group was able to reach consensus on a number of items that
are included below. The proposals included here were collected
in an open call amongst the group. Once the proposals were
collected, the group was solicited to submit critiques of each
proposal. The group was asked to self-organize to produce a
single critique for each proposal. In cases where there were
several critiques submitted, the editor selected one. The
proponents of each proposal then were given the opportunity to
write a rebuttal of the critique. Finally, the group again had
the opportunity to write a counterpoint of the rebuttal. No
counterpoints were submitted. For pragmatic reasons, each
submission was severely constrained in length.
</t>
<t>
All of the proposals were given the opportunity to progress their
documents to RFC status, however, not all of them have chosen to
pursue this path. As a result, some of the references in this
document may become inaccessible. This is unfortunately
unavoidable.
</t>
<t>
The group did reach consensus that the overall document should be
published. The document has been reviewed by many of the active
members of the Research Group.
</t>
</section>
<section title="Areas of Group Consensus" anchor='Consensus'>
<t>
The group was also able to reach broad and clear consensus on
some terminology and several important technical points. For the
sake of posterity, these are recorded here:
<list style='numbers'>
<t>
A "node" is either a host or a router.
</t>
<t>
A "router" is any device that forwards packets at the Network
Layer (e.g. IPv4, IPv6) of the Internet Architecture.
</t>
<t>
A "host" is a device that can send/receive packets
to/from the network, but does not forward packets.
</t>
<t>
A "bridge" is a device that forwards packets at the Link
Layer (e.g. Ethernet) of the Internet Architecture. An
Ethernet switch or Ethernet hub are examples of bridges.
</t>
<t>
An "address" is an object that combines aspects of identity
with topological location. IPv4 and IPv6 addresses are
current examples.
</t>
<t>
A "locator" is a structured topology-dependent name that
is not used for node identification, and is not a path.
Two related meanings are current, depending on the class
of things being named:
<list style='numbers'>
<t>
The topology-dependent name of a node's interface.
</t>
<t>
The topology-dependent name of a single subnetwork OR
topology-dependent name of a group of related subnetworks
that share a single aggregate. An IP routing prefix is a
current example of the latter.
</t>
</list>
</t>
<t>
An "identifier" is a topology-independent name for a logical
node. Depending upon instantiation, a "logical node" might be
a single physical device, a cluster of devices acting as a
single node, or a single virtual partition of a single
physical device. An OSI End System Identifier (ESID) is an
example of an identifier. A Fully-Qualified Domain Name that
precisely names one logical node is another example. (Note
well that not all FQDNs meet this definition.)
</t>
<t>
Various other names (i.e. other than addresses, locators, or
identifiers), each of which has the sole purpose of
identifying a component of a logical system or physical
device, might exist at various protocol layers in the
Internet Architecture.
</t>
<t>
The Research Group has rough consensus that separating identity
from location is desirable and technically feasible. However,
the Research Group does NOT have consensus on the best
engineering approach to such an identity/location split.
</t>
<t>
The Research Group has consensus that the Internet needs to
support multihoming in a manner that scales well and does not
have prohibitive costs.
</t>
<t>
Any IETF solution to Internet scaling has to not only support
multihoming, but address the real-world constraints of the
end customers (large and small).
</t>
</list>
</t>
</section>
<section title="Abbreviations">
<t>
This section lists some of the most common abbreviations used in
the remainder of this document.
<list style='hanging'>
<t hangText='DFZ'>
Default-Free Zone
</t>
<t hangText='EID'>
Endpoint IDentifer: The precise definition varies depending
on the proposal.
</t>
<t hangText='ETR'>
Egress Tunnel Router: In a system that tunnels traffic
across the existing infrastructure by encapsulating it, the
device close to the actual ultimate destination that
decapsulates the traffic before forwarding it to the
ultimate destination.
</t>
<t hangText='FIB'>
Forwarding Information Base: The forwarding table, used in
the data plane of routers to select the next hop for each
packet.
</t>
<t hangText='ITR'>
Ingress Tunnel Router: In a system that tunnels traffic
across the existing infrastructure by encapsulating it, the
device close to the actual original source that encapsulates
the traffic before using the tunnel to send it to the
appropriate ETR.
</t>
<t hangText='PA'>
Provider Aggregatable: Address space that can be aggregated
as part of a service provider's routing advertisements.
</t>
<t hangText='PI'>
Provider Independent: Address space assigned by an Internet
registry independent of any service provider.
</t>
<t hangText='PMTUD'>
Path Maximum Transmission Unit Discovery: The process or
mechanism that determines the largest packet that can be sent
between a given source and destination without being either
i) fragmented (IPv4 only), or ii) discarded (if not
fragmentable) because it is too large to be sent down one
link in the path from the source to the destination.
</t>
<t hangText='RIB'>
Routing Information Base. The routing table, used in the
control plane of routers to exchange routing information and
construct the FIB.
</t>
<t hangText='RLOC'>
Routing LOCator: The precise definition varies depending on
the proposal.
</t>
<t hangText='xTR'>
Tunnel Router: In some systems, the term used to describe a
device which can function as both an ITR and an ETR.
</t>
</list>
</t>
</section>
</section>
<section title="Locator Identifier Separation Protocol (LISP)">
<section title='Summary'>
<section title="Key Idea">
<t>
Implements a locator-identifier separation mechanism using
encapsulation between routers at the "edge" of the Internet. Such
a separation allows topological aggregation of the routable
addresses (locators) while providing stable and portable
numbering of end systems (identifiers).
</t>
</section>
<section title="Gains">
<t>
<list style='symbols'>
<t>
topological aggregation of locator space (RLOCs) used for
routing, which greatly reduces both the overall size and the
"churn rate" of the information needed to operate the Internet
global routing system
</t>
<t>
separate identifier space (EIDs) for end-systems, effectively
allowing "PI for all" (no renumbering cost for connectivity
changes) without adding state to the global routing system
</t>
<t>
improved traffic engineering capabilities that explicitly do
not add state to the global routing system and whose deployment
will allow active removal of the more-specific state that
is currently used
</t>
<t>
no changes required to end systems
</t>
<t>
no changes to Internet "core" routers
</t>
<t>
minimal and straightforward changes to "edge" routers
</t>
<t>
day-one advantages for early adopters
</t>
<t>
defined router-to-router protocol
</t>
<t>
defined database mapping system
</t>
<t>
defined deployment plan
</t>
<t>
defined interoperability/interworking mechanisms
</t>
<t>
defined scalable end-host mobility mechanisms
</t>
<t>
prototype implementation already exists and undergoing testing
</t>
<t>
production implementations in progress
</t>
</list>
</t>
</section>
<section title='Costs'>
<t>
<list style='symbols'>
<t>
mapping system infrastructure (map servers, map resolvers,
Alternative Logical Topology (ALT) routers) (new potential
business opportunity)
</t>
<t>
Interworking infrastructure (proxy ITRs) (new potential
business opportunity)
</t>
<t>
overhead for determining/maintaining locator/path liveness
(common issue for all id/loc separation proposals)
</t>
</list>
</t>
</section>
<section title='References'>
<t>
<xref target='I-D.ietf-lisp'/>
<xref target='I-D.ietf-lisp-alt'/>
<xref target='I-D.ietf-lisp-ms'/>
<xref target='I-D.ietf-lisp-interworking'/>
<xref target='I-D.meyer-lisp-mn'/>
<xref target='I-D.farinacci-lisp-lig'/>
<xref target='I-D.meyer-loc-id-implications'/>
</t>
</section>
</section>
<section title='Critique'>
<t>
LISP-ALT distributes mapping information to ITRs via (optional,
local, potentially caching) Map Resolvers and with globally
distributed query servers: ETRs and optional Map Servers (MS).
</t>
<t>
A fundamental problem with any global query server network is
that the frequently long paths and greater risk of packet loss
may cause ITRs to drop or significantly delay the initial packets
of many new sessions. ITRs drop the packet(s) they have no
mapping for. After the mapping arrives, the ITR waits for a
resent packet and will tunnel that packet correctly. These
"initial packet delays" reduce performance and so create a major
barrier to voluntary adoption on wide enough basis to solve the
routing scaling problem.
</t>
<t>
ALT's delays are compounded by its structure being "aggressively
aggregated", without regard to the geographic location of the
routers. Tunnels between ALT routers will often span
intercontinental distances and traverse many Internet routers.
</t>
<t>
The many levels to which a query typically ascends in the ALT
hierarchy before descending towards its destination will often
involve excessively long geographic paths and so worsen initial
packet delays.
</t>
<t>
No solution has been proposed for these problems or for the
contradiction between the need for high aggregation while making
the ALT structure robust against single points of failure.
</t>
<t>
LISP's ITRs multihoming service restoration depends on them
determining reachability of end-user networks via two or more
ETRs. Large numbers of ITRs doing this is inefficient and may
overburden ETRs.
</t>
<t>
Testing reachability of the ETRs is complex and costly - and
insufficient. ITRs cannot test network reachability via each
ETR, since the ITRs have no address of a device in that network.
So ETRs must report network un-reachability to ITRs.
</t>
<t>
LISP involves complex communication between ITRs and ETRs, with
UDP and 64-bit LISP headers in all traffic packets.
</t>
<t>
The advantage of LISP+ALT is that its ability to handle billions
of EIDs is not constrained by the need to transmit or store the
mapping to any one location. Such numbers, beyond a few tens of
millions of EIDs, will only result if the system is used for
Mobility. Yet the concerns just mentioned about ALT's structure
arise from the millions of ETRs which would be needed just for
non-mobile networks.
</t>
<t>
In LISP's mobility approach each Mobile Node (MN) needs an RLOC
address to be its own ETR, meaning the MN cannot be behind
NAT. Mapping changes must be sent instantly to all relevant ITRs
every time the MN gets a new address - which LISP cannot achieve.
</t>
<t>
In order to enforce ISP filtering of incoming packets by source
address, LISP ITRs would have to implement the same filtering on
each decapsulated packet. This may be prohibitively expensive.
</t>
<t>
LISP monolithically integrates multihoming failure detection and
restoration decision-making processes into the Core-Edge
Separation (CES) scheme itself. End-user networks must rely on the
necessarily limited capabilities which are built into every ITR.
</t>
<t>
LISP-ALT may be able to solve the routing scaling problem, but
alternative approaches would be superior because they eliminate
the initial packet delay problem and give end-user networks
real-time control over ITR tunneling.
</t>
</section>
<section title='Rebuttal'>
<t>
Initial-packet loss/delays turn out not to be a deep
issue. Mechanisms for interoperation with the legacy part of the
network are needed in any viably deployable design, and LISP has
such mechanisms. If needed, initial packets can be sent via those
legacy mechanisms until the ITR has a mapping. (Field experience
has shown that the caches on those interoperation devices are
guaranteed to be populated, as 'crackers' doing address-space
sweeps periodically send packets to every available mapping.)
</t>
<t>
On ALT issues, it is not at all mandatory that ALT be the mapping
system used in the long term. LISP has a standardized mapping
system interface, in part to allow reasonably smooth deployment
of whatever new mapping system(s) experience might show are
required. At least one other mapping system (LISP-TREE)
<xref target='LISP-TREE'/>, which avoids ALT's problems (such as
query load concentration at high-level nodes), has already been
laid out and extensively simulated. Exactly what mixture of
mapping system(s) is optimal is not really answerable without
more extensive experience, but LISP is designed to allow
evolutionary changes to other mapping system(s).
</t>
<t>
As far as ETR reachability goes, a potential problem to which
there is a solution which has an adequate level of efficiency,
complexity and robustness is not really a problem. LISP has a
number of overlapping mechanisms which it is believed will
provide adequate reachability detection (along the three axes
above), and in field testing to date, they have behaved as
expected.
</t>
<t>
Operation of LISP devices behind a NAT has already been
demonstrated. A number of mechanisms to update correspondent
nodes when a mapping is updated have been designed (some are
already in use).
</t>
</section>
</section>
<section title="Routing Architecture for the Next Generation Internet
(RANGI)">
<section title='Summary'>
<section title="Key Idea">
<t>
Similar to Host Identity Protocol (HIP)
<xref target='RFC4423'/>, RANGI introduces a host identifier
layer between the network layer and the transport layer, and
the transport-layer associations (i.e., TCP connections) are no
longer bound to IP addresses, but to host identifiers. The
major difference from HIP is that the host identifier in RANGI
is a 128-bit hierarchical and cryptographic identifier which
has organizational structure. As a result, the corresponding
ID->locator mapping system for such identifiers has a
reasonable business model and clear trust boundaries. In
addition, RANGI uses IPv4-embedded IPv6 addresses as
locators. The Locator Domain Identifier (LD ID) (i.e., the
leftmost 96 bits) of this locator is a provider-assigned /96
IPv6 prefix, while the last four octets of this locator is a
local IPv4 address (either public or private). This special
locator could be used to realize 6over4 automatic tunneling
(borrowing ideas from ISATAP <xref target='RFC5214'/>), which
will reduce the deployment cost of this new routing
architecture. Within RANGI, the mappings from FQDN to host
identifiers are stored in the DNS system, while the mappings
from host identifiers to locators are stored in a distributed
id/locator mapping system (e.g., a hierarchical Distributed
Hash Table (DHT) system, or a reverse DNS system).
</t>
</section>
<section title='Gains'>
<t>
RANGI achieves almost all of the goals set forth by RRG as
follows:
<list style='numbers'>
<t>
Routing Scalability: Scalability is achieved by decoupling
identifiers from locators.
</t>
<t>
Traffic Engineering: Hosts located in a multihomed site
can suggest the upstream ISP for outbound and inbound
traffic, while the first-hop Locator Domain Border Router
(LDBR) (i.e., site border router) has the final decision
on the upstream ISP selection.
</t>
<t>
Mobility and Multihoming: Sessions will not be interrupted
due to locator change in cases of mobility or multihoming.
</t>
<t>
Simplified Renumbering: When changing providers, the local
IPv4 addresses of the site do not need to change. Hence the
internal routers within the site don't need renumbering.
</t>
<t>
Decoupling Location and Identifier: Obvious.
</t>
<t>
Routing Stability: Since the locators are topologically
aggregatable and the internal topology within the LD will
not be disclosed outside, routing stability could be
improved greatly.
</t>
<t>
Routing Security: RANGI reuses the current routing system
and does not introduce any new security risks into the
routing system.
</t>
<t>
Incremental Deployability: RANGI allows an easy transition
from IPv4 networks to IPv6 networks. In addition, RANGI
proxy allows RANGI-aware hosts to communicate to legacy
IPv4 or IPv6 hosts, and vice-versa.
</t>
</list>
</t>
</section>
<section title="Costs">
<t>
<list style='numbers'>
<t>
A host change is required.
</t>
<t>
The first-hop LDBR change is required to support
site-controlled traffic-engineering capability.
</t>
<t>
The ID->Locator mapping system is a new infrastructure to be
deployed.
</t>
<t>
RANGI proxy needs to be deployed for communication between
RANGI-aware hosts and legacy hosts.
</t>
</list>
</t>
</section>
<section title='References'>
<t>
<xref target='RFC3007'/>
<xref target='RFC4423'/>
<xref target='I-D.xu-rangi'/>
<xref target='I-D.xu-rangi-proxy'/>
<xref target='RANGI'/>
</t>
</section>
</section>
<section title='Critique'>
<t>
RANGI is an ID/locator split protocol that, like HIP, places a
cryptographically signed ID between the network layer (IPv6) and
transport. Unlike the HIP ID, the RANGI ID has a hierarchical
structure that allows it to support ID->locator lookups. This
hierarchical structure addresses two weaknesses of the flat HIP
ID: the difficulty of doing the ID->locator lookup, and the
administrative scalability of doing firewall filtering on flat
IDs. The usage of this hierarchy is overloaded: it serves to make
the ID unique, to drive the lookup process, and possibly other
things like firewall filtering. More thought is needed as to
what constitutes these levels with respect to these various
roles.
</t>
<t>
The RANGI draft suggests FQDN->ID lookup through DNS, and
separately an ID->locator lookup which may be DNS or may be
something else (a hierarchy of DHTs). It would be more efficient
if the FQDN lookup produces both ID and locators (as does ILNP).
Probably DNS alone is sufficient for the ID->locator lookup since
individual DNS servers can hold very large numbers of mappings.
</t>
<t>
RANGI provides strong sender identification, but at the cost of
computing crypto. Many hosts (public web servers) may prefer to
forgo the crypto at the expense of losing some functionality
(receiver mobility or dynamic multihoming load balancing). While
RANGI doesn't require that the receiver validate the sender, it
may be good to have a mechanism whereby the receiver can signal
to the sender that it is not validating, so that the sender can
avoid locator changes.
</t>
<t>
Architecturally there are many advantages to putting the mapping
function at the end host (versus at the edge). This simplifies
the neighbor aliveness and delayed first packet problems, and
avoids stateful middleboxes. Unfortunately, the early-adopter
incentive for host upgrade may not be adequate (HIP's lack of
uptake being an example).
</t>
<t>
RANGI does not have an explicit solution for the mobility race
condition (there is no mention of a home-agent like device).
However, host-to-host notification combined with fallback on the
ID->locators lookup (assuming adequate dynamic update of the
lookup system) may be good enough for the vast majority of
mobility situations.
</t>
<t>
RANGI uses proxies to deal with both legacy IPv6 and IPv4 sites.
RANGI proxies have no mechanisms to deal with the edge-to-edge
aliveness problem. The edge-to-edge proxy approach dirties-up an
otherwise clean end-to-end model.
</t>
<t>
RANGI exploits existing IPv6 transition technologies (ISATAP and
softwire). These transition technologies are in any event being
pursued outside of RRG and do not need to be specified in RANGI
drafts per se. RANGI only needs to address how it interoperates
with IPv4 and legacy IPv6, which through proxies it appears to do
adequately well.
</t>
</section>
<section title='Rebuttal'>
<t>
The reason why the ID->Locator lookup is separated from the
FQDN->ID lookup is: 1) not all applications are tied to FQDNs,
and 2) it seems unnecessary to require all devices to possess a
FQDN of their own. Basically RANGI uses DNS to realize the
ID->Locator mapping system. If there are too many entries to be
maintained by the authoritative servers of a given Administrative
Domain (AD), Distributed Hash Table (DHT) technology can be used
to make these authoritative servers scale better, e.g., the
mappings maintained by a given AD will be distributed among a
group of authoritative servers in a DHT fashion. As a result, the
robustness feature of DHT is inherited naturally into the
ID->Locator mapping system. Meanwhile, there is no trust issue
since each AD authority runs its own DHT ring which maintains
only the mappings for those identifiers that are administrated by
that AD authority.
</t>
<t>
For host mobility, if communicating entities are RANGI nodes, the
mobile node will notify the correspondent node of its new locator
once its locator changes due to a mobility or re-homing
event. Meanwhile, it should also update its locator information
in the ID->Locator mapping system in a timely fashion by using
the Secure DNS Dynamic Update mechanism defined in
<xref target='RFC3007'/>. In case of simultaneous mobility, at
least one of the nodes has to resort to the ID->Locator mapping
system for resolving the correspondent node's new locator so as
to continue their communication. If the correspondent node is a
legacy host, Transit Proxies, which play a similar function to
the home-agents in Mobile IP, will relay the packets between the
communicating parties.
</t>
<t>
RANGI uses proxies (e.g., Site Proxy and Transit Proxy) to deal
with both legacy IPv6 and IPv4 sites. Since proxies function as
RANGI hosts, they can handle Locator Update Notification messages
sent from remote RANGI hosts (or even from remote RANGI proxies)
correctly. Hence there is no edge-to-edge aliveness
problem. Details will be specified in a later version of
RANGI-PROXY.
</t>
<t>
The intention behind RANGI using IPv4-embedded IPv6 addresses as
locators is to reduce the total deployment cost of this new
Internet architecture and to avoid renumbering the site internal
routers when such a site changes ISPs.
</t>
</section>
</section>
<section title="Internet Vastly Improved Plumbing (Ivip)">
<section title='Summary'>
<section title='Key Ideas'>
<t>
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 and mobile devices.
</t>
<t>
Ivip meets all the constraints imposed by the need for widespread
voluntary adoption <xref target='Ivip Constraints' />.
</t>
<t>
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 which have ITRs. Each mapping
change is sent to all QSDs within a few seconds.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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 which control ITR
tunneling are controlled by the end-user networks in real-time
and are completely separate from the core-edge separation
scheme itself.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
Default ITRs in the DFZ (DITRs, similar to LISP's Proxy Tunnel
Routers) tunnel packets sent by hosts in networks which lack
ITRs. So multihoming, portability and TE benefits apply to all
traffic.
</t>
<t>
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.
</t>
<t>
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 - which 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.
</t>
</section>
<section title='Extensions'>
<section title='TTR Mobility'>
<t>
The Translating Tunnel Router (TTR) approach to mobility
<xref target='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.
</t>
<t>
Path-lengths are typically optimal or close to optimal and
the MN communicates normally with all other non-mobile hosts
(no stack or app changes), and of course other MNs. Mapping
changes are only needed when the MN uses a new TTR, which
would typically be if the MN moved more than 1000km. Mapping
changes are not required when the MN changes its physical
address(es).
</t>
</section>
<section title='Modified Header Forwarding'>
<t>
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.
</t>
</section>
</section>
<section title='Gains'>
<t>
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.
</t>
<t>
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.
</t>
<t>
A small fee per mapping change deters frivolous changes and
helps pay for pushing the mapping data to all QSDs. End-user
networks who 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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title='Costs'>
<t>
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.
</t>
<t>
The maximum number of non-mobile networks requiring multihoming
etc. is likely to be ~10M, so most of the 10B mappings would be
for mobile devices. However, TTR mobility does not involve
frequent mapping changes since most MNs only rarely move more
than 1000km.
</t>
</section>
<section title='References'>
<t>
<xref target='I-D.whittle-ivip4-etr-addr-forw'/>
<xref target='Ivip PMTUD'/>
<xref target='Ivip6'/>
<xref target='Ivip Constraints'/>
<xref target='Ivip Mobility'/>
<xref target='I-D.whittle-ivip-drtm'/>
<xref target='I-D.whittle-ivip-glossary'/>
</t>
</section>
</section>
<section title='Critique'>
<t>
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.
</t>
<t>
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
<list style='numbers'>
<t>
special considerations of mobility support that add
additional complexity to the overall system;
</t>
<t>
prompt detection of ETR failures and notification to all
relevant ITRs, which turns out to be a rather difficult
problem; and
</t>
<t>
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.
</t>
</list>
</t>
<t>
To be considered as a viable solution to 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.
</t>
<t>
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.
</t>
<t>
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 which develop the infrastructure. Another
belief is that this ambitious design is not viable.
</t>
</section>
<section title='Rebuttal'>
<t>
Since the Summary and Critique were written, Ivip's mapping system
has been significantly redesigned: DRTM - Distributed Real Time
Mapping <xref target="I-D.whittle-ivip-drtm"/>.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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 that 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 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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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 which rely on wireless links.
</t>
<t>
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.
</t>
</section>
</section>
<section title="Hierarchical IPv4 Framework (hIPv4)">
<section title='Summary'>
<section title='Key Idea'>
<t>
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 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 a 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 <xref target='RFC4960'/> and
Multipath TCP (MPTCP)
<xref target='I-D.ford-mptcp-architecture'/>, 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).
</t>
</section>
<section title='Gains'>
<t>
<list style='numbers'>
<t>
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.
</t>
<t>
Scalable support for traffic engineering: Multipath enabled
transport protocols are recommended to achieve dynamic
load-balancing of a session. Support for Valiant
Load-balancing <xref target='Valiant'/> schemes has been
added to the framework; more research work is required
around VLB switching.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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
layer in the TCP/IP model.
</t>
<t>
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.
</t>
<t>
Routing Security: Similar as with today's DFZ, except that
ELOC prefixes can not be hijacked (by injecting a
longest match prefix) outside an ALOC realm.
</t>
<t>
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.
</t>
</list>
</t>
</section>
<section title='Costs And Issues'>
<t>
<list style='numbers'>
<t>
Upgrade of the stack at an endpoint that is establishing
sessions outside the local ALOC realm.
</t>
<t>
In a multihoming solution the border routers should be
able to apply policy based routing upon the ALOC value in
the locator header.
</t>
<t>
New IP allocation policies must be set by the RIRs.
</t>
<t>
Short timeframe before the expected depletion of the IPv4
address space occurs.
</t>
<t>
Will enterprises give up their current globally unique IPv4
address block allocation they have gained?
</t>
<t>
Coordination with MPTCP is highly desirable.
</t>
</list>
</t>
</section>
<section title='References'>
<t>
<xref target='I-D.frejborg-hipv4'/>
</t>
</section>
</section>
<section title='Critique'>
<t>
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.
</t>
<t>
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 - so providing 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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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
which will not work with hIPv4: "There are several applications that
are inserting IPv4 address information in the payload of a packet.
Some applications use the IPv4 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." <xref target='I-D.frejborg-hipv4'/>
</t>
<t>
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.
</t>
<t>
It appears that hIPv4 involves major practical difficulties which
mean that in its current form it is not suitable for IETF
development.
</t>
</section>
<section title='Rebuttal'>
<t>
No rebuttal was submitted for this proposal.
</t>
</section>
</section>
<section title='Name overlay (NOL) service for scalable Internet
routing'>
<section title='Summary'>
<section title='Key Idea'>
<t>
The basic idea is to add a name overlay (NOL) onto the existing
TCP/IP stack.
</t>
<t>
Its functions include:
<list style='numbers'>
<t>
Managing host name configuration, registration and
authentication;
</t>
<t>
Initiating and managing transport connection channels (i.e.,
TCP/IP connections) by name;
</t>
<t>
Keeping application data transport continuity for mobility.
</t>
</list>
</t>
<t>
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 performs address
and/or port translation between blocked PI addresses and
globally routable addresses, which seem like today's widely
used NAT/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 traverse the NTR
by name and initiate connections to the hosts behind it.
</t>
<t>
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 and their packet
formats. NOL can co-exist with the legacy infrastructure, and
the core-edge separation solutions (e.g., APT, LISP, Six/one,
Ivip, etc.)
</t>
</section>
<section title='Gains'>
<t>
<list style='numbers'>
<t>
Reduce routing table size: Prevent edge network PI address
from leaking into transit network by deploying gateway NTRs.
</t>
<t>
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.
</t>
<t>
Multihoming: When a PI addressed network connects to the
Internet by multihoming with several providers, it can
deploy NTRs to block the PI addresses from leaking into
provider networks.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
No need to change TCP/IP stack, sockets and DNS system.
</t>
<t>
No need for extra mapping system.
</t>
<t>
NTR can be deployed unilaterally, just like NATs
</t>
<t>
NOL applications can communicate with legacy applications.
</t>
<t>
NOL can be compatible with existing solutions, such as APT,
LISP, Ivip, etc.
</t>
<t>
End user controlled multipath indirect routing based on
distributed NTRs. This will give benefits to the
performance-aware applications, such as, MSN, Video
streaming, etc.
</t>
</list>
</t>
</section>
<section title='Costs'>
<t>
<list style='numbers'>
<t>
Legacy applications have trouble with initiating access to
the servers behind NTR. Such trouble can be resolved by
deploying 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.
</t>
<t>
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@domain.net. The needed DNS entries and
query is just for "domain.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 is
guaranteed by its naming hierarchy and caching mechanisms.
</t>
<t>
Address translating/rewriting costs on NTRs.
</t>
</list>
</t>
</section>
<section title='References'>
<t>
No references were submitted.
</t>
</section>
</section>
<section title='Critique'>
<t>
<list style='numbers'>
<t>
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 or will have difficultly accessing the endpoints
behind a NTR without the help of NOL.
</t>
<t>
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. Edge networks prefer PI address space to PA
address space whether they are IPv4 or IPv6 networks.
</t>
<t>
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 are on a voluntary basis
and have few economic incentives.
</t>
<t>
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.
</t>
<t>
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 of DNS.
</t>
<t>
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.
</t>
</list>
</t>
</section>
<section title='Rebuttal'>
<t>
NOL resembles neither CEE nor CES as a solution. By supporting
application level session 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 ITR/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, in the mean time, doesn't accelerate, or
decrease, the growth of global routing table size.
</t>
<t>
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@domain.net". The
mapping between "domain.net" and IP address of corresponding NTR
will be registered in DNS. The NOL layer will understand the
meaning of the name "des@domain.net" , and it will send a query
to DNS only for "domain.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.
</t>
<t>
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 can not
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 be assigned PA addresses in a NTR-adopting EUN.
</t>
</section>
</section>
<section title='Compact routing in locator identifier mapping system (CRM)'>
<section title='Summary'>
<section title='Key Idea'>
<t>
This proposal 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 <xref target='CRM'/>. Map servers are assigned as
cluster heads or landmarks based on their capability to
aggregate EID announcements.
</t>
</section>
<section title='Gains'>
<t>
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.
</t>
<t>
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.
</t>
<t>
Availability and robustness of the overall routing system
(including xTRs and map servers) is improved because of the
potential to use multiple map servers and direct routes without
the involvement of map servers.
</t>
</section>
<section title='Costs'>
<t>
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 xTRs need to have memory/cache for the mappings
of its cluster.
</t>
</section>
<section title='References'>
<t>
<xref target='CRM'/>
</t>
</section>
</section>
<section title='Critique'>
<t>
The CRM proposal is not a complete proposal, and therefore cannot
be considered for further development by the IETF as a scalable
routing solution.
</t>
<t>
While Compact Routing principles may be able to improve a mapping
overlay structure such as LISP-ALT there are several objections
to this approach.
</t>
<t>
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.
</t>
<t>
Secondly, the alterations contemplated in this proposal involve
the roles of particular nodes in the network being dynamically
assigned as part of its self-organizing nature.
</t>
<t>
The discussion of Clustering in the middle of page 4 also
indicates that particular nodes are responsible for registering
EIDs from typically far-distant ETRs, all of which are handling
closely related EIDs which 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.
</t>
<t>
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 interdomain routing
system, and are a challenge for any scalable routing solution.
</t>
<t>
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.
</t>
<t>
It appears that the inherently greater delays and risks of packet
loss of any global query server system 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.
</t>
</section>
<section title='Rebuttal'>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
</section>
<section title='Layered mapping system (LMS)'>
<section title='Summary'>
<section title='Key Ideas'>
<t>
The layered mapping system proposal builds a hierarchical
mapping system to support scalability, analyzes the design
constraints and presents an explicit system structure; designs
a two-cache mechanism on ingress tunneling router (ITR) to gain
low request delay and facilitates data validation. Tunneling
and mapping are done at the core and no change is needed on
edge networks. The mapping system is run by interest groups
independent of any ISP, which conforms to an economical model
and can be voluntarily adopted by various networks. Mapping
systems can also be constructed stepwise, especially in the
IPv6 scenario.
</t>
</section>
<section title='Gains'>
<t>
<list style='numbers'>
<t>
Scalability
<list style='numbers'>
<t>
Distributed storage of mapping data avoids central
storage of massive amounts of data and restricts updates
within local areas.
</t>
<t>
The cache mechanism in an ITR reduces request loads on
mapping system reasonably.
</t>
</list>
</t>
<t>
Deployability
<list style='numbers'>
<t>
No change on edge systems, only tunneling in core routers,
and new devices in core networks.
</t>
<t>
The mapping system can be constructed stepwise: a
mapping node needn't be constructed if none of its
responsible ELOCs is allocated. This makes sense
especially for IPv6.
</t>
<t>
Conforms to a viable economic model: the mapping system
operators can profit from their services; core routers
and edge networks are willing to join the circle either
to avoid router upgrades or realize traffic
engineering. Benefits from joining are independent of
the scheme's implementation scale.
</t>
</list>
</t>
<t>
Low request delay: The low number of layers in the mapping
structure and the two-stage cache help achieve low request
delay.
</t>
<t>
Data consistency: The two-stage cache enables an ITR to
update data in the map cache conveniently.
</t>
<t>
Traffic engineering support: Edge networks inform the
mapping system of their prioritized mappings with all
upstream routers, thus giving the edge networks control
over their ingress flows.
</t>
</list>
</t>
</section>
<section title='Costs'>
<t>
<list style='numbers'>
<t>
Deployment of LMS needs to be further discussed.
</t>
<t>
The structure of mapping system needs to be refined according
to practical circumstances.
</t>
</list>
</t>
</section>
<section title='References'>
<t>
<xref target='LMS Summary'/>
<xref target='LMS'/>
</t>
</section>
</section>
<section title='Critique'>
<t>
LMS is a mapping mechanism based on core-edge separation. In
fact, any proposal that needs a global mapping system with keys
with similar properties to that of an "edge address" in a
core-edge separation scenario can use such a mechanism. This
means that those keys are globally unique (by authorization or
just statistically), at the disposal of edge users, and may have
several satisfied mappings (with possibly different weights). A
proposal to address routing scalability that needs mapping but
doesn't specify the mapping mechanism can use LMS to strengthen
its infrastructure.
</t>
<t>
The key idea of LMS is similar to that of LISP+ALT: that the
mapping system should be hierarchically organized to gain
scalability for storage and updates, and to achieve quick
indexing for lookups. However, LMS advocates an ISP-independent
mapping system and ETRs are not the authorities of mapping
data. ETRs or edge-sites report their mapping data to related
mapping servers.
</t>
<t>
LMS assumes that mapping servers can be incrementally deployed in
that a server may not be constructed if none of its administered
edge addresses are allocated, and that mapping servers can charge
for their services, which provides the economic incentive for
their existence. How this brand-new system can be constructed is
still not clear. Explicit layering is only an ideal state, and
the proposal analyzes the layering limits and feasibility, rather
than provide a practical way for deployment.
</t>
<t>
The drawbacks of LMS's feasibility analysis also include that it
1) is based on current PC power and may not represent future
circumstances (especially for IPv6), and 2) does not consider the
variability of address utilization. Some IP address spaces may be
effectively allocated and used while some may not, causing some
mapping servers to be overloaded with others poorly
utilized. More thoughts are needed as to the flexibility of the
layer design.
</t>
<t>
LMS doesn't fit well for mobility. It does not solve the problem
when hosts move faster than the mapping updates and propagation
between relative mapping servers. On the other hand, mobile hosts
moving across ASes and changing their attachment points (core
addresses) is less frequent than hosts moving within an AS.
</t>
<t>
Separation needs two planes: core-edge separation, which is to
gain routing table scalability and identity-location separation,
which is to achieve mobility. GLI does a good clarification of
this and in that case, LMS can be used to provide
identity-to-core address mapping. Of course, other schemes may be
competent and LMS can be incorporated with them if the scheme has
global keys and needs to map them to other namespaces.
</t>
</section>
<section title='Rebuttal'>
<t>
No rebuttal was submitted for this proposal.
</t>
</section>
</section>
<section title='2-phased mapping'>
<section title='Summary'>
<section title='Considerations'>
<t>
<list style='numbers'>
<t>
A mapping from prefixes to ETRs is an M:M mapping. Any change
of a (prefix, ETR) pair should be updated in a timely manner
which can be a heavy burden to any mapping system if the
relation changes frequently.
</t>
<t>
A prefix<->ETR mapping system cannot be deployed
efficiently if it is overwhelmed by the worldwide
dynamics. Therefore the mapping itself is not scalable with
this direct mapping scheme.
</t>
</list>
</t>
</section>
<section title='Basics of a 2-phased mapping'>
<t>
<list style='numbers'>
<t>
Introduce an AS number in the middle of the mapping, the
phase I mapping is prefix<->AS#, phase II mapping is
AS#<->ETRs. This creates a M:1:M mapping model.
</t>
<t>
It is fair to assume that all ASes know their local
prefixes (in the IGP) better than others and that it is
most likely that local prefixes can be aggregated when they
can be mapped to the AS number, which will reduce the
number of mapping entries. ASes also know clearly their
ETRs on the border between core and edge. So all mapping
information can be collected locally.
</t>
<t>
A registry system will take care of the phase I mapping
information. Each AS should have a registration agent to
notify the registry of the local range of IP address
space. This system can be organized as a hierarchical
infrastructure like DNS, or alternatively as a centralized
registry like "whois" in each RIR. Phase II mapping
information can be distributed between xTRs as a BGP
extension.
</t>
<t>
The basic forwarding procedure is that the ITR first gets
the destination AS number from the phase I mapper (or from
cache) when the packet is entering the "core". Then it will
extract the closest ETR for the destination AS number.
This is local, since phase II mapping information has been
"pushed" to it through BGP updates. Finally, the ITR
tunnels the packet to the corresponding ETR.
</t>
</list>
</t>
</section>
<section title='Gains'>
<t>
<list style='numbers'>
<t>
Any prefix reconfiguration (aggregation/deaggregation)
within an AS will not be reflected in the mapping system.
</t>
<t>
Local prefixes can be aggregated with a high degree of
efficiency.
</t>
<t>
Both phase I and phase II mappings can be stable.
</t>
<t>
A stable mapping system will reduce the update overhead
introduced by topology changes and/or routing policy dynamics.
</t>
</list>
</t>
</section>
<section title='Summary'>
<t>
<list style='numbers'>
<t>
The 2-phased mapping scheme introduces an AS number between
the mapping prefixes and ETRs.
</t>
<t>
The decoupling of direct mapping makes highly dynamic
updates stable, therefore it can be more scalable than any
direct mapping designs.
</t>
<t>
The 2-phased mapping scheme is adaptable to any core/edge
split based proposals.
</t>
</list>
</t>
</section>
<section title='References'>
<t>
No references were submitted.
</t>
</section>
</section>
<section title='Critique'>
<t>
This is a simple idea on how to scale mapping. However, this
design is too incomplete to be considered a serious input to
RRG. Take the following 2 issues as example:
</t>
<t>
First, in this 2-phase scheme, an AS is essentially the unit of
destinations (i.e. sending ITRs find out destination AS D, then
send data to one of of D's ETR). This does not offer much choice
for traffic engineering.
</t>
<t>
Second, there is no consideration whatsoever on failure detection
and handling.
</t>
</section>
<section title='Rebuttal'>
<t>
No rebuttal was submitted for this proposal.
</t>
</section>
</section>
<section
title='Global Locator, Local Locator, and Identifier Split (GLI-Split)'>
<section title='Summary'>
<section title='Key Idea'>
<t>
GLI-Split implements a separation between global routing (in
the global Internet outside edge networks) and local routing
(inside edge networks) using global and local locators (GLs,
LLs). In addition, a separate static identifier (ID) is used to
identify communication endpoints (e.g. nodes or services)
independently of any routing information. Locators and IDs are
encoded in IPv6 addresses to enable backwards-compatibility
with the IPv6 Internet. The higher order bits store either a GL
or a LL while the lower order bits contain the ID. A local
mapping system maps IDs to LLs and a global mapping system maps
IDs to GLs. The full GLI-mode requires nodes with upgraded
networking stacks and special GLI-gateways. The GLI-gateways
perform stateless locator rewriting in IPv6 addresses with the
help of the local and global mapping system. Non-upgraded IPv6
nodes can also be accommodated in GLI-domains since an enhanced
DHCP service and GLI-gateways compensate their missing
GLI-functionality. This is an important feature for incremental
deployability.
</t>
</section>
<section title='Gains'>
<t>
The benefits of GLI-Split are
<list style='symbols'>
<t>
Hierarchical aggregation of routing information in the global
Internet through separation of edge and core routing
</t>
<t>
Provider changes not visible to nodes inside GLI-domains
(renumbering not needed)
</t>
<t>
Rearrangement of subnetworks within edge networks not visible
to the outside world (better support of large edge networks)
</t>
<t>
Transport connections survive both types of changes
</t>
<t>
Multihoming
</t>
<t>
Improved traffic engineering for incoming and outgoing
traffic
</t>
<t>
Multipath routing and load balancing for hosts
</t>
<t>
Improved resilience
</t>
<t>
Improved mobility support without home agents and triangle
routing
</t>
<t>
Interworking with the classic Internet
<list style='symbols'>
<t>
without triangle routing over proxy routers
</t>
<t>
without stateful NAT
</t>
</list>
</t>
</list>
</t>
<t>
These benefits are available for upgraded GLI-nodes, but
non-upgraded nodes in GLI-domains partially benefit from these
advanced features, too. This offers multiple incentives for early
adopters and they have the option to migrate their nodes gradually
from non-GLI stacks to GLI-stacks.
</t>
</section>
<section title='Costs'>
<t>
<list style='symbols'>
<t>
Local and global mapping system
</t>
<t>
Modified DHCP or similar mechanism
</t>
<t>
GLI-gateways with stateless locator rewriting in IPv6
addresses
</t>
<t>
Upgraded stacks (only for full GLI-mode)
</t>
</list>
</t>
</section>
<section title='References'>
<t>
<xref target='GLI'/>
<xref target='Valiant'/>
</t>
</section>
</section>
<section title='Critique'>
<t>
GLI-Split makes a clear distinction between two separation
planes: the separation between identifier and locator, which is
to meet end-users needs including mobility; and the separation
between local and global locator, to make the global routing
table scalable. The distinction is needed since ISPs and hosts
have different requirements, also make the changes inside and
outside GLI-domains invisible to their opposites.
</t>
<t>
A main drawback of GLI-Split is that it puts a burden on
hosts. Before routing a packet received from upper layers,
network stacks in hosts first need to resolve the DNS name to an
IP address; if the IP address is GLI-formed, it may look up the
map from the identifier extracted from the IP address to the
local locator. If the communication is between different
GLI-domains, hosts may further look up the mapping from the
identifier to the global locator. Having the local mapping system
forward requests to the global mapping system for hosts is just
an option. Though host lookup may ease the burden of intermediate
nodes which would otherwise to perform the mapping lookup, the
three lookups by hosts in the worst case may lead to large delays
unless a very efficient mapping mechanism is devised. The work
may also become impractical for low-powered hosts. On one hand,
GLI-split can provide backward compatibility where classic and
upgraded IPv6 hosts can communicate, which is its big virtue;
while the upgrades may work against hosts' enthusiasm to
change, compared to the benefits they would gain.
</t>
<t>
GLI-split provides additional features to improve TE and to
improve resilience, e.g., exerting multipath routing. However the
cost is that more burdens are placed on hosts, e.g. they may need
more lookup actions and route selections. However, these kinds of
tradeoffs between costs and gains exists in most proposals.
</t>
<t>
One improvement of GLI-Split is its support for mobility by
updating DNS data as GLI-hosts move across GLI-domains. Through
this the GLI-corresponding-node can query DNS to get a valid
global locator of the GLI-mobile-node and need not query the
global mapping system (unless it wants to do multipath routing),
giving more incentives for nodes to become GLI-enabled. The merits
of GLI-Split, simplified-mobility-handover provision, compensate
for the costs of this improvement.
</t>
<t>
GLI-Split claims to use rewriting instead of tunneling for
conversions between local and global locators when packets span
GLI-domains. The major advantage is that this kind of rewriting
needs no extra state, since local and global locators need not
map to each other. Many other rewriting mechanisms instead need
to maintain extra state. It also avoids the MTU problem faced by
the tunneling methods. However, GLI-Split achieves this only by
compressing the namespace size of each attribute (identifier,
local and global locator). GLI-Split encodes two namespaces
(identifier and local/global locator) into an IPv6 address, each
has a size of 2^64 or less, while map-and-encap proposals assume
that identifier and locator each occupy a 128 bit space.
</t>
</section>
<section title='Rebuttal'>
<t>
The arguments in the GLI-Split critique are correct. There are
only two points that should be clarified here. (1) First, it is
not a drawback that hosts perform the mapping lookups. (2)
Second, the critique proposed an improvement to the mobility
mechanism, which is of general nature and not specific to
GLI-Split.
</t>
<t>
<list style='numbers'>
<t>
The additional burden on the hosts is actually a benefit,
compared to having the same burden on the gateways. If the
gateway would perform the lookups and packets addressed to
uncached EIDs arrive, a lookup in the mapping system must be
initiated. Until the mapping reply returns, packets must be
either dropped, cached, or the packets must be sent over the
mapping system to the destination. All these options are not
optimal and have their drawbacks. To avoid these problems in
GLI-Split, the hosts perform the lookup. The short additional
delay is not a big issue in the hosts because it happens
before the first packets are sent. So no packets are lost or
have to be cached. GLI-Split could also easily be adapted to
special GLI-hosts (e.g., low power sensor nodes) that do not
have to do any lookup and simply let the gateway do all the
work. This functionality is included anyway for backward
compatibility with regular IPv6-hosts inside the GLI-domain.
</t>
<t>
The critique proposes a DNS-based mobility mechanism as
an improvement to GLI-Split. However, this improvement is an
alternative mobility approach which can be applied to any
routing architecture including GLI-Split and raises also some
concerns, e.g., the update speed of DNS. Therefore, we prefer
to keep this issue out of the discussion.
</t>
</list>
</t>
</section>
</section>
<section title='Tunneled Inter-domain Routing (TIDR)'>
<section title='Summary'>
<section title='Key Idea'>
<t>
Provides a method for locator-identifier separation using
tunnels between routers on the edge of the Internet transit
infrastructure. It enriches the BGP protocol for distributing
the identifier-to-locator mapping. Using new BGP attributes,
"identifier prefixes" are assigned inter-domain routing
locators so that they will not be installed in the RIB and will
be moved to a new table called Tunnel Information Base
(TIB). Afterwards, when routing a packet to an "identifier
prefix", the TIB will be searched first to perform tunneling,
and secondly the RIB for actual routing. After the edge router
performs tunneling, all routers in the middle will route this
packet until the router at the tail-end of the tunnel.
</t>
</section>
<section title='Gains'>
<t>
<list style='symbols'>
<t>
Smooth deployment
</t>
<t>
Size reduction of the global RIB
</t>
<t>
Deterministic customer traffic engineering for incoming
traffic
</t>
<t>
Numerous forwarding decisions for a particular address prefix
</t>
<t>
Stops AS number space depletion
</t>
<t>
Improved BGP convergence
</t>
<t>
Protection of the inter-domain routing infrastructure
</t>
<t>
Easy separation of control traffic and transit traffic
</t>
<t>
Different layer-2 protocol-IDs for transit and non-transit
traffic
</t>
<t>
Multihoming resilience
</t>
<t>
New address families and tunneling techniques
</t>
<t>
Support for IPv4 or IPv6, and migration to IPv6
</t>
<t>
Scalability, stability and reliability
</t>
<t>
Faster inter-domain routing
</t>
</list>
</t>
</section>
<section title='Costs'>
<t>
<list style='symbols'>
<t>
Routers on the edge of the inter-domain infrastructure will
need to be upgraded to hold the mapping database (i.e. the
TIB)
</t>
<t>
"Mapping updates" will need to be treated differently from
usual BGP "routing updates"
</t>
</list>
</t>
</section>
<section title='References'>
<t>
<xref target='I-D.adan-idr-tidr'/>
<xref target='TIDR identifiers'/>
<xref target='TIDR and LISP'/>
<xref target='TIDR AS forwarding'/>
</t>
</section>
</section>
<section title='Critique'>
<t>
TIDR is a Core-Edge Separation architecture from late 2006 which
distributes its mapping information via BGP messages which are
passed between DFZ routers.
</t>
<t>
This means that TIDR cannot solve the most important goal of
scalable routing - to accommodate much larger numbers of end-user
network prefixes (millions or billions) without each such prefix
directly burdening every DFZ router. Messages advertising routes
for TIDR-managed prefixes may be handled with lower priority, but
this would only marginally reduce the workload for each DFZ
router compared to handling an advertisement of a conventional PI
prefix.
</t>
<t>
Therefore, TIDR cannot be considered for RRG recommendation as a
solution to the routing scaling problem.
</t>
<t>
For a TIDR-using network to receive packets sent from any host,
every BR of all ISPs must be upgraded to have the new ITR-like
functionality. Furthermore, all DFZ routers would need to be
altered so they accepted and correctly propagated the routes for
end-user network address space, with the new LOCATOR attribute
which contains the ETR address and a REMOTE-PREFERENCE value.
Firstly, if they received two such advertisements with different
LOCATORs, they would advertise a single route to this prefix
containing both. Secondly, for end-user address space (for IPv4)
to be more finely divided, the DFZ routers must propagate
LOCATOR-containing advertisements for prefixes longer than /24.
</t>
<t>
TIDR's ITR-like routers store the full mapping database - so
there would be no delay in obtaining mapping, and therefore no
significant delay in tunneling traffic packets.
</t>
<t>
The TIDR ID is written as if traffic packets are classified by
reference to the RIB - but routers use the FIB for this purpose,
and "FIB" does not appear in the ID.
</t>
<t>
TIDR does not specify a tunneling technique, leaving this to be
chosen by the ETR-like function of BRs and specified as part of a
second-kind of new BGP route advertised by that ETR-like BR.
There is no provision for solving the PMTUD problems inherent in
encapsulation-based tunneling.
</t>
<t>
ITR functions must be performed by already busy routers of ISPs,
rather than being distributed to other routers or to sending
hosts. There is no practical support for mobility. The mapping
in each end-user route advertisement includes a REMOTE-PREFERENCE
for each ETR-like BR, but this is used by the ITR-like functions
of BRs to always select the LOCATOR with the highest value. As
currently described, TIDR does not provide inbound load splitting
TE.
</t>
<t>
Multihoming service restoration is achieved initially by the
ETR-like function of BR at the ISP whose link to the end-user
network has just failed, looking up the mapping to find the next
preferred ETR-like BR's address. The first ETR-like router
tunnels the packets to the second ETR-like router in the other
ISP. However, if the failure was caused by the first ISP itself
being unreachable, then connectivity would not be restored until
a revised mapping (with higher REMOTE-PREFERENCE) from the
reachable ETR-like BR of the second ISP propagated across the DFZ
to all ITR-like routers, or the withdrawn advertisement for the
first one reaches the ITR-like router.
</t>
</section>
<section title='Rebuttal'>
<t>
No rebuttal was submitted for this proposal.
</t>
</section>
</section>
<section title='Identifier-Locator Network Protocol (ILNP)'>
<section title='Summary'>
<section title='Key Ideas'>
<t>
<list style='symbols'>
<t>
Provides crisp separation of Identifiers from Locators.
</t>
<t>
Identifiers name nodes, not interfaces.
</t>
<t>
Locators name subnetworks, rather than interfaces, so they
are equivalent to an IP routing prefix.
</t>
<t>
Identifiers are never used for network-layer routing, whilst
Locators are never used for Node Identity.
</t>
<t>
Transport-layer sessions (e.g. TCP session state) use only
Identifiers, never Locators, meaning that changes in location
have no adverse impact on an IP session.
</t>
</list>
</t>
</section>
<section title='Benefits'>
<t>
<list style='symbols'>
<t>
The underlying protocol mechanisms support fully scalable
site multihoming, node multihoming, site mobility,
and node mobility.
</t>
<t>
ILNP enables topological aggregation of location information
while providing stable and topology-independent identities
for nodes.
</t>
<t>
In turn, this topological aggregation reduces both the
routing prefix "churn" rate and the overall size of the
Internet's global routing table, by eliminating the value
and need for more-specific routing state currently carried
throughout the global (default-free) zone of the routing
system.
</t>
<t>
ILNP enables improved Traffic Engineering capabilities without
adding any state to the global routing system. TE capabilities
include both provider-driven TE and also end-site-controlled
TE.
</t>
<t>
ILNP's mobility approach:
<list style='symbols'>
<t>
eliminates the need for special-purpose routers (e.g. Home
Agent and/or Foreign Agent now required by Mobile IP &
NEMO).
</t>
<t>
eliminates "triangle routing" in all cases.
</t>
<t>
supports both "make before break" and "break before make"
layer-3 handoffs.
</t>
</list>
</t>
<t>
ILNP improves resilience and network availability while
reducing the global routing state (as compared with the
currently deployed Internet).
</t>
<t>
ILNP is Incrementally Deployable:
<list style='symbols'>
<t>
No changes are required to existing IPv6 (or IPv4)
routers.
</t>
<t>
Upgraded nodes gain benefits immediately ("day one");
those benefits gain in value as more nodes are upgraded
(this follows Metcalfe's Law).
</t>
<t>
Incremental Deployment approach is documented.
</t>
</list>
</t>
<t>
ILNP is Backwards Compatible:
<list style='symbols'>
<t>
ILNPv6 is fully backwards compatible with IPv6
(ILNPv4 is fully backwards compatible with IPv4).
</t>
<t>
Reuses existing known-to-scale DNS mechanisms to provide
identifier/locator mapping.
</t>
<t>
Existing DNS Security mechanisms are reused without change.
</t>
<t>
Existing IP Security mechanisms are reused with one minor
change (IPsec Security Associations replace the current use
of IP Addresses with the use of Identifier values).
NB: IPsec is also backwards compatible.
</t>
<t>
Backwards Compatibility approach is documented.
</t>
</list>
</t>
<t>
No new or additional overhead is required to determine
or to maintain locator/path liveness.
</t>
<t>
ILNP does not require locator rewriting (NAT);
ILNP permits and tolerates NAT should that be desirable
in some deployment(s).
</t>
<t>
Changes to upstream network providers do not require
node or subnetwork renumbering within end-sites.
</t>
<t>
Compatible with and can facilitate the transition from
current single-path TCP to multipath TCP.
</t>
<t>
ILNP can be implemented such that existing applications
(e.g. applications using the BSD Sockets API) do NOT
need any changes or modifications to use ILNP.
</t>
</list>
</t>
</section>
<section title='Costs'>
<t>
<list style='symbols'>
<t>
End systems need to be enhanced incrementally to support
ILNP in addition to IPv6 (or IPv4 or both).
</t>
<t>
DNS servers supporting upgraded end systems also should be
upgraded to support new DNS resource records for ILNP.
(DNS protocol & DNS security do not need any changes.)
</t>
</list>
</t>
</section>
<section title='References'>
<t>
<xref target='ILNP Site'/>
<xref target='MobiArch1'/>
<xref target='MobiArch2'/>
<xref target='MILCOM1'/>
<xref target='MILCOM2'/>
<xref target='DNSnBIND'/>
<xref target='I-D.carpenter-behave-referral-object'/>
<xref target='I-D.rja-ilnp-nonce'/>
<xref target='RFC4033'/>
<xref target='RFC4034'/>
<xref target='RFC4035'/>
<xref target='RFC5534'/>
<xref target='RFC5902'/>
</t>
</section>
</section>
<section title='Critique'>
<t>
The primary issue for ILNP is how the deployment incentives and
benefits line up with the RRG goal of reducing the rate of growth
of entries and churn in the core routing table. If a site is
currently using PI space, it can only stop advertising that space
when the entire site is ILNP capable. This needs at least clear
elucidation of the incentives for ILNP which are not related to
routing scaling, in order for there to be a path for this to
address the RRG needs. Similarly, the incentives for upgrading
hosts need to align with the value for those hosts.
</t>
<t>
A closely related question is whether this mechanism actually
addresses the sites need for PI addresses. Assuming ILNP is
deployed, the site does achieve flexible, resilient,
communication using all of its Internet connections. While the
proposal addresses the host updates when the host learns of
provider changes, there are other aspects of provider change that
are not addressed. This includes renumbering router, subnets,
and certain servers. (It is presumed that most servers, once the
entire site has moved to ILNP, will not be concerned if their
locator changes. However, some servers must have known locators,
such as the DNS server.) The issues described in
<xref target='RFC5887'/> will be ameliorated, but not resolved.
To be able to adopt this proposal, and have sites use it, we need
to address these issues. When a site changes points of
attachment only a small amount of DNS provisioning should be
required. The LP record is apparently intended to help with
this. It is also likely that the use of dynamic DNS will help
this.
</t>
<t>
The ILNP mechanism is described as being suitable for use in
conjunction with mobility. This raises the question of race
conditions. To the degree that mobility concerns are valid at
this time, it is worth asking how communication can be
established if a node is sufficiently mobile that it is moving
faster than the DNS update and DNS fetch cycle can effectively
propagate changes.
</t>
<t>
This proposal does presume that all communication using this
mechanism is tied to DNS names. While it is true that most
communication does start from a DNS name, it is not the case that
all exchanges have this property. Some communication initiation
and referral can be done with an explicit I/L pair. This does
appear to require some extensions to the existing mechanism (for
both sides to add locators). In general, some additional clarity
on the assumptions regarding DNS, particularly for low end
devices, would seem appropriate.
</t>
<t>
One issue that this proposal shares with many others is the
question of how to determine which locator pairs (local and
remote) are actually functional. This is an issue both for
initial communications establishment, and for robustly
maintaining communication. While it is likely that a combination
of monitoring of traffic (in the host, where this is tractable),
coupled with other active measures, can address this. ICMP is
clearly insufficient.
</t>
</section>
<section title='Rebuttal'>
<t>
ILNP eliminates the perceived need for PI addressing,
and encourages increased DFZ aggregation. Many enterprise users
view DFZ scaling issues as too abstruse. So ILNP creates
more user-visible incentives to upgrade deployed systems.
</t>
<t>
ILNP mobility eliminates Duplicate Address Detection (DAD),
reducing the layer-3 handoff time significantly, compared to IETF
standard Mobile IP. <xref target='MobiArch1'/>
<xref target='MobiArch2'/> ICMP Location updates separately
reduce the layer-3 handoff latency.
</t>
<t>
Also, ILNP enables both host multihoming and site
multihoming. Current BGP approaches cannot support
host multihoming. Host multihoming is valuable in
reducing the site's set of externally visible nodes.
</t>
<t>
Improved mobility support is very important. This is shown
by the research literature and also appears in discussions
with vendors of mobile devices (smartphones, MP3-players).
Several operating system vendors push "updates" with major
networking software changes in maintenance releases today.
Security concerns mean most hosts receive vendor updates
more quickly these days.
</t>
<t>
ILNP enables a site to hide exterior connectivity changes from
interior nodes, using various approaches. One approach deploys
unique local address (ULA) prefixes within the site and has the
site border router(s) rewrite the Locator values. The usual NAT
issues don't arise because the Locator value is not used above
the network-layer. <xref target='MILCOM1'/>
<xref target='MILCOM2'/>
</t>
<t>
<xref target='RFC5902'/> makes clear that many users
desire IPv6 NAT, with site interior obfuscation as a
major driver. This makes global-scope PI addressing much
less desirable for end sites than formerly.
</t>
<t>
ILNP-capable nodes can talk existing IP with legacy
IP-only nodes, with no loss of current IP capability.
So ILNP-capable nodes will never be worse off.
</t>
<t>
Secure Dynamic DNS Update is standard, and widely supported in
deployed hosts and DNS servers. <xref target='DNSnBIND'/> says
many sites have deployed this technology without realizing it
(e.g. by enabling both the DHCP server and Active Directory of
MS-Windows Server).
</t>
<t>
If a node is as mobile as the critique says, then existing
IETF Mobile IP standards also will fail. They also use
location updates (e.g. MN->HA, MN->FA).
</t>
<t>
ILNP also enables new approaches to security that eliminate
dependence upon location-dependent ACLs without packet
authentication. Instead, security appliances track flows using
Identifier values, and validate the I/L relationship
cryptographically <xref target='RFC4033'/>
<xref target='RFC4034'/> <xref target='RFC4035'/> or
non-cryptographically by reading the
<xref target='I-D.rja-ilnp-nonce'/>.
</t>
<t>
The DNS LP record has a more detailed explanation now.
LP records enable a site to change its upstream connectivity
by changing the L records of a single FQDN covering the
whole site, providing scalability.
</t>
<t>
DNS-based server load balancing works well with ILNP by using DNS
SRV records. DNS SRV records are not new, are widely available
in DNS clients & servers, and are widely used today in the
IPv4 Internet for Server Load Balancing.
</t>
<t>
Recent ILNP I-Ds discuss referrals in more detail. A node with a
binary-referral can find the FQDN using DNS PTR records, which
can be authenticated <xref target='RFC4033'/>
<xref target='RFC4034'/> <xref target='RFC4035'/>. Approaches
such as <xref target='I-D.carpenter-behave-referral-object'/>
improve user experience and user capability, so are likely to
self-deploy.
</t>
<t>
Selection from multiple Locators is identical to an
IPv4 system selecting from multiple A records for its
correspondent. Deployed IP nodes can track reachability
via existing host mechanisms, or by using the SHIM6 method.
<xref target='RFC5534'/>
</t>
</section>
</section>
<section title='Enhanced Efficiency of Mapping Distribution Protocols
in Map-and-Encap Schemes (EEMDP)'>
<section title='Summary'>
<section title='Introduction'>
<t>
We present some architectural principles pertaining to the
mapping distribution protocols, especially applicable to
map-and-encap (e.g., LISP) type of protocols. These principles
enhance the efficiency of the map-and-encap protocols in terms
of (1) better utilization of resources (e.g., processing and
memory) at Ingress Tunnel Routers (ITRs) and mapping servers,
and consequently, (2) reduction of response time (e.g., first
packet delay). We consider how Egress Tunnel Routers (ETRs) can
perform aggregation of end-point ID (EID) address space
belonging to their downstream delivery networks, in spite of
migration/re-homing of some subprefixes to other ETRs. This
aggregation may be useful for reducing the processing load and
memory consumption associated with map messages, especially at
some resource-constrained ITRs and subsystems of the mapping
distribution system. We also consider another architectural
concept where the ETRs are organized in a hierarchical manner
for the potential benefit of aggregation of their EID address
spaces. The two key architectural ideas are discussed in some
more detail below. A more complete description can be found in
<xref target='EEMDP Considerations'/> and
<xref target='EEMDP Presentation'/>.
</t>
<t>
It will be helpful to refer to Figures 1, 2, and 3 in the
document noted above for some of the discussions that follow here
below.
</t>
</section>
<section title='Management of Mapping Distribution of Subprefixes
Spread Across Multiple ETRs'>
<t>
To assist in this discussion, we start with the high level
architecture of a map-and-encap approach (it would be helpful to
see Fig. 1 in the document mentioned above). In this architecture
we have the usual ITRs, ETRs, delivery networks, etc. In
addition, we have the ID-Locator Mapping (ILM) servers which are
repositories for complete mapping information, while the
ILM-Regional (ILM-R) servers can contain partial and/or
regionally relevant mapping information.
</t>
<t>
While a large endpoint address space contained in a prefix may be
mostly associated with the delivery networks served by one ETR,
some fragments (subprefixes) of that address space may be located
elsewhere at other ETRs. Let a/20 denote a prefix that is
conceptually viewed as composed of 16 subnets of /24 size that
are denoted as a1/24, a2/24, ..., a16/24. For example, a/20 is
mostly at ETR1, while only two of its subprefixes a8/24 and
a15/24 are elsewhere at ETR3 and ETR2, respectively (see Fig. 2
in the document). From the point of view of efficiency of the
mapping distribution protocol, it may be beneficial for ETR1 to
announce a map for the entire space a/20 (rather than fragment it
into a multitude of more-specific prefixes), and provide the
necessary exceptions in the map information. Thus the map message
could be in the form of Map:(a/20, ETR1; Exceptions: a8/24,
a15/24). In addition, ETR2 and ETR3 announce the maps for a15/24
and a8/24, respectively, and so the ILMs know where the exception
EID addresses are located. Now consider a host associated with
ITR1 initiating a packet destined for an address a7(1), which is
in a7/24 that is not in the exception portion of a/20. Now a
question arises as to which of the following approaches would be
the best choice:
<list style='numbers'>
<t>
ILM-R provides the complete mapping information for a/20 to
ITR1 including all maps for relevant exception subprefixes.
</t>
<t>
ILM-R provides only the directly relevant map to ITR1 which
in this case is (a/20, ETR1).
</t>
</list>
</t>
<t>
In the first approach, the advantage is that ITR1 would have the
complete mapping for a/20 (including exception subnets), and it
would not have to generate queries for subsequent first packets
that are destined to any address in a/20, including a8/24 and
a15/24. However, the disadvantage is that if there is a
significant number of exception subprefixes, then the very first
packet destined for a/20 will experience a long delay, and also
the processors at ITR1 and ILM-R can experience overload. In
addition, the memory usage at ITR1 can be very inefficient as
well. The advantage of the second approach above is that the
ILM-R does not overload resources at ITR1 both in terms of
processing and memory usage but it needs an enhanced map response
in of the form Map:(a/20, ETR1, MS=1), where MS (more specific)
indicator is set to 1 to indicate to ITR1 that not all subnets in
a/20 map to ETR1. The key idea is that aggregation is beneficial
and subnet exceptions must be handled with additional messages or
indicators in the maps.
</t>
</section>
<section title='Management of Mapping Distribution for Scenarios with
Hierarchy of ETRs and Multihoming'>
<t>
Now we highlight another architectural concept related to
mapping management (please refer to Fig. 3 in the
document). Here we consider the possibility that ETRs may be
organized in a hierarchical manner. For instance ETR7 is higher
in hierarchy relative to ETR1, ETR2, and ETR3, and like-wise
ETR8 is higher relative to ETR4, ETR5, and ETR6. For instance,
ETRs 1 through 3 can relegate the locator role to ETR7 for
their EID address space. In essence, they can allow ETR7 to act
as the locator for the delivery networks in their purview. ETR7
keeps a local mapping table for mapping the appropriate EID
address space to specific ETRs that are hierarchically
associated with it in the level below. In this situation, ETR7
can perform EID address space aggregation across ETRs 1 through
3 and can also include its own immediate EID address space for
the purpose of that aggregation. The many details related to
this approach and special circumstances involving multihoming
of subnets are discussed in detail in the detailed document
noted earlier. The hierarchical organization of ETRs and
delivery networks should help in the future growth and
scalability of ETRs and mapping distribution networks. This is
essentially recursive map-and-encap, and some of the mapping
distribution and management functionality will remain local to
topologically neighboring delivery networks which are
hierarchically underneath ETRs.
</t>
</section>
<section title='References'>
<t>
<xref target='EEMDP Considerations'/>
<xref target='EEMDP Presentation'/>
<xref target='FIBAggregatability'/>
</t>
</section>
</section>
<section title='Critique'>
<t>
This scheme <xref target='EEMDP Considerations'/> represents one
approach to mapping overhead reduction, and it is a general idea
that is applicable to any proposal that includes prefix or EID
aggregation. A somewhat similar idea is also used in Level-3
aggregation in the FIB aggregation proposal.
<xref target='FIBAggregatability'/> There can be cases where
deaggregation of EID prefixes occur in such a way that bulk of an
EID prefix P would be attached to one locator (say, ETR1) while a
few subprefixes under P would be attached to other locators
elsewhere (say, ETR2, ETR3, etc.). Ideally such cases should not
happen, however in reality it can happen as RIR's address
allocations are imperfect. In addition, as new IP address
allocations become harder to get, an IPv4 prefix owner might
split previously unused subprefixes of that prefix and allocate
them to remote sites (homed to other ETRs). Assuming these
situations could arise in practice, the nature of the solution
would be that the response from the mapping server for the
coarser site would include information about the more
specifics. The solution as presented seems correct.
</t>
<t>
The proposal mentions that in Approach 1, the ID-Locator Mapping
(ILM) system provides the complete mapping information for an
aggregate EID prefix to a querying ITR including all the maps for
the relevant exception subprefixes. The sheer number of such
more-specifics can be worrisome, for example, in LISP. What if a
company's mobile-node EIDs came out of their corporate
EID-prefix? Approach 2 is far better but still there may be too
many entries for a regional ILM to store. In Approach 2, the ILM
communicates that there are more specifics but does not
communicate their mask-length. A suggested improvement would be
that rather than saying that there are more specifics, indicate
what their mask-lengths are. There can be multiple mask
lengths. This number should be pretty small for IPv4 but can
be large for IPv6.
</t>
<t>
Later in the proposal, a different problem is addressed
involving a hierarchy of ETRs and how aggregation of EID
prefixes from lower level ETRs can be performed at a higher
level ETR. The various scenarios here are well illustrated and
described. This seems like a good idea, and a solution like
LISP can support this as specified. As any optimization scheme
would inevitably add some complexity; the proposed scheme for
enhancing mapping efficiency comes with some of its own
overhead. The gain depends on the details of specific EID
blocks, i.e., how frequently the situations arise such as an
ETR having a bigger EID block with a few holes.
</t>
</section>
<section title='Rebuttal'>
<t>
There are two main points in the critique that would be addressed
here: (1) The gain depends on the details of specific EID blocks,
i.e., how frequently the situations arise such as an ETR having a
bigger EID block with a few holes, and (2) Approach 2 is lacking
an added feature of conveying just the mask-length of the more
specifics that exist as part of current map-response.
</t>
<t>
Regarding comment (1) above, there are multiple possibilities
regarding how situations can arise resulting in allocations
having holes in them. An example of one of these possibilities
is as follows. Org-A has historically received multiple /20s,
/22s, /24s over the course of time which are adjacent to each
other. At the present time, these prefixes would all aggregate to
a /16 but for the fact that just a few of the underlying /24s
have been allocated elsewhere historically to other organizations
by an RIR or ISPs. An example of a second possibility is that
Org-A has an allocation of a /16. It has suballocated a /22 to
one of its subsidiaries, and subsequently sold the subsidiary to
another Org-B. For ease of keeping the /22 subnet up and running
without service disruption, the /22 subprefix is allowed to be
transferred in the acquisition process. Now the /22 subprefix
originates from a different AS and is serviced by a different ETR
(as compared to the parent \16 prefix). We are in the process of
performing an analysis of RIR allocation data and are aware of
other studies (notably at UCLA) which are also performing similar
analysis to quantify the frequency of occurrence of the holes. We
feel that the problem that has been addressed is a realistic one,
and the proposed scheme would help reduce the overheads
associated with the mapping distribution system.
</t>
<t>
Regarding comment (2) above, the suggested modification to
Approach 2 would be definitely beneficial. In fact, we feel that
it would be fairly straight forward to dynamically use Approach 1
or Approach 2 (with the suggested modification), depending on
whether there are only a few (e.g., <=5) or many (e.g., >5)
more specifics, respectively. The suggested modification of
notifying the mask-length of the more specifics in map-response
is indeed very helpful because then the ITR would not have to
resend a map-query for EID addresses that match the EID address
in the previous query up to at least mask-length bit
positions. There can be a two-bit field in map-response that
would indicate: (a) With value 00 for notifying that there are no
more-specifics; (b) With value 01 for notifying that there are
more-specifics and their exact information follows in additional
map-responses, and (c) With value 10 for notifying that there are
more-specifics and the mask-length of the next more-specific is
indicated in the current map-response. An additional field will
be included which will be used to specify the mask-length of the
next more-specific in the case of the "10" indication (case (c)
above).
</t>
</section>
</section>
<section title='Evolution'>
<section title='Summary'>
<t>
As the Internet continues its rapid growth, router memory size and
CPU cycle requirements are outpacing feasible hardware upgrade
schedules. We propose to solve this problem by applying aggregation
with increasing scopes to gradually evolve the routing system
towards a scalable structure. At each evolutionary step, our
solution is able to interoperate with the existing system and
provide immediate benefits to adopters to enable deployment. This
document summarizes the need for an evolutionary design, the
relationship between our proposal and other revolutionary proposals
and the steps of aggregation with increasing scopes. Our detailed
proposal can be found in <xref target='I-D.zhang-evolution' />.
</t>
<section title='Need for Evolution'>
<t>
Multiple different views exist regarding the routing scalability
problem. Networks differ vastly in goals, behavior, and
resources, giving each a different view of the severity and
imminence of the scalability problem. Therefore we believe that,
for any solution to be adopted, it will start with one or a few
early adopters, and may not ever reach the entire Internet. The
evolutionary approach recognizes that changes to the Internet can
only be a gradual process with multiple stages. At each stage,
adopters are driven by and rewarded with solving an immediate
problem. Each solution must be deployable by individual networks
who deem it necessary at a time they deem it necessary, without
requiring coordination from other networks, and the solution has
to bring immediate relief to a single first-mover.
</t>
</section>
<section title='Relation to Other RRG Proposals'>
<t>
Most proposals take a revolutionary approach that expects the
entire Internet to eventually move to some new design whose
main benefits would not materialize until the vast majority of
the system has been upgraded; their incremental deployment plan
simply ensures interoperation between upgraded and legacy parts
of the system. In contrast, the evolutionary approach depicts a
picture where changes may happen here and there as needed, but
there is no dependency on the system as a whole making a
change. Whoever takes a step forward gains the benefit by
solving his own problem, without depending on others to take
actions. Thus, deployability includes not only
interoperability, but also the alignment of costs and gains.
</t>
<t>
The main differences between our approach and more revolutionary
map-and-encap proposals are: (a) we do not start with a pre-defined
boundary between edge and core; and (b) each step brings
immediate benefits to individual first-movers. Note that our
proposal neither interferes nor prevents any revolutionary
host-based solutions such as ILNP from being rolled out. However,
host-based solutions do not bring useful impact until a large
portion of hosts have been upgraded. Thus even if a host-based
solution is rolled out in the long run, an evolutionary solution
is still needed for the near term.
</t>
</section>
<section title='Aggregation with Increasing Scopes'>
<t>
Aggregating many routing entries to a fewer number is a basic
approach to improving routing scalability. Aggregation can take
different forms and be done within different scopes. In our
design, the aggregation scope starts from a single router, then
expands to a single network, and neighbor networks. The order
of the following steps is not fixed but is merely a suggestion;
it is under each individual network's discretion which steps
they choose to take based on their evaluation of the severity
of the problems and the affordability of the solutions.
<list style='numbers'>
<t>
FIB Aggregation (FA) in a single router. A router
algorithmically aggregates its FIB entries without changing
its RIB or its routing announcements. No coordination among
routers is needed, nor any change to existing protocols. This
brings scalability relief to individual routers with only a
software upgrade.
</t>
<t>
Enabling 'best external' on PEs, ASBRs, and RRs, and turning
on next-hop-self on RRs. For hierarchical networks, the RRs
in each PoP can serve as a default gateway for nodes in the
PoP, thus allowing the non-RR nodes in each PoP to maintain
smaller routing tables that only include paths that egress
out of that PoP. This is known as 'topology-based mode'
Virtual Aggregation, and can be done with existing hardware
and configuration changes only. Please see
<xref target='Evolution Grow Presentation'/> for details.
</t>
<t>
Virtual Aggregation (VA) in a single network. Within an AS,
some fraction of existing routers are designated as
Aggregation Point Routers (APRs). These routers are either
individually or collectively maintain the full FIB
table. Other routers may suppress entries from their FIBs,
instead forwarding packets to APRs, which will then tunnel
the packets to the correct egress routers. VA can be viewed
as an intra-domain map-and-encap system to provide the
operators with a control mechanism for the FIB size in their
routers.
</t>
<t>
VA across neighbor networks. When adjacent networks have VA
deployed, they can go one step further by piggybacking egress
router information on existing BGP announcements, so that
packets can be tunneled directly to a neighbor network's
egress router. This improves packet delivery performance by
performing the encapsulation/decapsulation only once across
these neighbor networks, as well as reducing the stretch of
the path.
</t>
<t>
Reducing RIB Size by separating the control plane from the
data plane. Although a router's FIB can be reduced by FA or
VA, it usually still needs to maintain the full RIB to
produce complete routing announcements to its neighbors. To
reduce the RIB size, a network can set up special boxes,
which we call controllers, to take over the eBGP sessions
from border routers. The controllers receive eBGP
announcements, make routing decisions, and then inform
other routers in the same network of how to forward
packets, while the regular routers just focus on the job of
forwarding packets. The controllers, not being part of the
data path, can be scaled using commodity hardware.
</t>
<t>
Insulating forwarding routers from routing churn. For
routers with a smaller RIB, the rate of routing churn is
naturally reduced. Further reduction can be achieved by not
announcing failures of customer prefixes into the core, but
handling these failures in a data-driven fashion, e.g., a
link failure to an edge network is not reported unless and
until there are data packets that are heading towards the
failed link.
</t>
</list>
</t>
</section>
<section title='References'>
<t>
<xref target='I-D.zhang-evolution'/>
<xref target='Evolution Grow Presentation'/>
</t>
</section>
</section>
<section title='Critique'>
<t>
All of the RRG proposals that scale the routing architecture
share one fundamental approach, route aggregation, in different
forms, e.g., LISP removes "edge prefixes" using encapsulation at
ITRs, and ILNP achieves the goal by locator rewrite. In this
evolutionary path proposal, each stage of the evolution applies
aggregation with increasing scopes to solve a specific
scalability problem, and eventually the path leads towards global
routing scalability. For example, it uses FIB aggregation at the
single router level, virtual aggregation at the network level,
and then between neighboring networks at the inter-domain level.
</t>
<t>
Compared to other proposals, this proposal has the lowest hurdle
to deployment, because it does not require that all networks move
to use a global mapping system or upgrade all hosts, and it is
designed for each individual network to get immediate benefits
after its own deployment.
</t>
<t>
Criticisms of this proposal fall into two types. The first type
concerns several potential issues in the technical design as
listed below:
<list style='numbers'>
<t>
FIB aggregation, at level-3 and level-4, may introduce extra
routable space. Concerns have been raised about the
potential routing loops resulting from forwarding otherwise
non-routable packets, and the potential impact on RPF
checking. These concerns can be addressed by choosing a
lower level of aggregation and by adding null routes to
minimize the extra space, at the cost of reduced aggregation
gain.
</t>
<t>
Virtual Aggregation changes the traffic paths in an ISP
network, thereby introducing stretch. Changing the traffic
path may also impact the reverse path checking practice used
to filter out packets from spoofed sources. More analysis is
need to identify the potential side-effects of VA and to
address these issues.
</t>
<t>
The current Virtual Aggregation description is difficult to
understand, due to its multiple options for encapsulation and
popular prefix configurations, which makes the mechanism look
overly complicated. More thought is needed to simplify the
design and description.
</t>
<t>
FIB Aggregation and Virtual Aggregation may require
additional operational cost. There may be new design
trade-offs that the operators need to understand in order to
select the best option for their networks. More analysis is
needed to identify and quantify all potential operational
costs.
</t>
<t>
In contrast to a number of other proposals, this solution
does not provide mobility support. It remains an open
question as to whether the routing system should handle
mobility.
</t>
</list>
</t>
<t>
The second criticism is whether deploying quick fixes like FIB
aggregation would alleviate scalability problems in the short
term and reduce the incentives for deploying a new architecture;
and whether an evolutionary approach would end up with adding
more and more patches to the old architecture, and not lead to a
fundamentally new architecture as the proposal had expected.
Though this solution may get rolled out more easily and quickly,
a new architecture, if/once deployed, could solve more problems
with cleaner solutions.
</t>
</section>
<section title='Rebuttal'>
<t>
No rebuttal was submitted for this proposal.
</t>
</section>
</section>
<section title='Name-Based Sockets'>
<section title='Summary'>
<t>
Name-based sockets are an evolution of the existing address-based
sockets, enabling applications to initiate and receive
communication sessions based on the use of domain names in lieu
of IP addresses. Name-based sockets move the existing
indirection from domain names to IP addresses from its current
position in applications down to the IP layer. As a result,
applications communicate exclusively based on domain names, while
the discovery, selection, and potentially in-session re-selection
of IP addresses is centrally performed by the IP stack itself.
</t>
<t>
Name-based sockets help mitigate the Internet routing scalability
problem by separating naming and addressing more consistently
than what is possible with the existing address-based sockets.
This supports IP address aggregation because it simplifies the
use of IP addresses with high topological significance, as well
as the dynamic replacement of IP addresses during
network-topological and host-attachment changes.
</t>
<t>
A particularly positive effect of name-based sockets on Internet
routing scalability is the new incentives for edge network
operators to use provider-assigned IP addresses, which are more
aggregatable than the typically preferred provider-independent IP
addresses. Even though provider-independent IP addresses are
harder to get and more expensive than provider-assigned IP
addresses, many operators desire provider-independent addresses
due to the high indirect cost of provider-assigned IP addresses.
This indirect cost is comprised of both difficulties in
multihoming, and tedious and largely manual renumbering upon
provider changes.
</t>
<t>
Name-based sockets reduce the indirect cost of provider-assigned
IP addresses in three ways, and hence make the use of
provider-assigned IP addresses more acceptable: (1) They enable
fine-grained and responsive multihoming. (2) They simplify
renumbering by offering an easy means to replace IP addresses in
referrals with domain names. This helps avoiding updates to
application and operating system configurations, scripts, and
databases during renumbering. (3) They facilitate low-cost
solutions that eliminate renumbering altogether. One such
low-cost solution is IP address translation, which in combination
with name-based sockets loses its adverse impact on applications.
</t>
<t>
The prerequisite for a positive effect of name-based sockets on
Internet routing scalability is their adoption in operating
systems and applications. Operating systems should be augmented
to offer name-based sockets as a new alternative to the existing
address-based sockets, and applications should use name-based
sockets for their communications. Neither an instantaneous, nor
an eventually complete transition to name-based sockets is
required, yet the positive effect on Internet routing scalability
will grow with the extent of this transition.
</t>
<t>
Name-based sockets were hence designed with a focus on deployment
incentives, comprising both immediate deployment benefits as well
as low deployment costs. Name-based sockets provide a benefit to
application developers because the alleviation of applications
from IP address management responsibilities simplifies and
expedites application development. This benefit is immediate
owing to the backwards compatibility of name-based sockets with
legacy applications and legacy peers. The appeal to application
developers, in turn, is an immediate benefit for operating system
vendors who adopt name-based sockets.
</t>
<t>
Name-based sockets furthermore minimize deployment costs:
Alternative techniques to separate naming and addressing provide
applications with "surrogate IP addresses" that dynamically map
onto regular IP addresses. A surrogate IP address is
indistinguishable from a regular IP address for applications, but
does not have the topological significance of a regular IP
address. Mobile IP and the Host Identity Protocol are examples
of such separation techniques. Mobile IP uses "home IP
addresses" as surrogate IP addresses with reduced topological
significance. The Host Identity Protocol uses "host identifiers"
as surrogate IP addresses without topological significance. A
disadvantage of surrogate IP addresses is their incurred cost in
terms of extra administrative overhead and, for some techniques,
extra infrastructure. Since surrogate IP addresses must be
resolvable to the corresponding regular IP addresses, they must
be provisioned in the DNS or similar infrastructure. Mobile IP
uses a new infrastructure of home agents for this purpose, while
the Host Identity Protocol populates DNS servers with host
identities. Name-based sockets avoid this cost because they
function without surrogate IP addresses, and hence without the
provisioning and infrastructure requirements that accompany
surrogate addresses.
</t>
<t>
Certainly, some edge networks will continue to use
provider-independent addresses despite name-based sockets,
perhaps simply due to inertia. But name-based sockets will help
reduce the number of those networks, and thus have a positive
impact on Internet routing scalability.
</t>
<t>
A more comprehensive description of name-based sockets can be found
in <xref target='Name Based Sockets'/>.
</t>
<section title='References'>
<t>
<xref target='Name Based Sockets'/>
</t>
</section>
</section>
<section title='Critique'>
<t>
Name-based sockets contribution to the routing scalability
problem is to decrease the reliance on PI addresses, allowing a
greater use of PA addresses, and thus a less fragmented routing
table. It provides end hosts with an API which makes the
applications address-agnostic. The name abstraction allows the
hosts to use any type of locator, independent of format or
provider. This increases the motivation and usability of PA
addresses. Some applications, in particular bootstrapping
applications, may still require hard coded IP addresses, and as
such will still motivate the use of PI addresses.
</t>
<section title='Deployment'>
<t>
The main incentives and drivers are geared towards the
transition of applications to the name-based sockets. Adoption
by applications will be driven by benefits in terms of reduced
application development cost. Legacy applications are expected
to migrate to the new API at a slower pace, as the name-based
sockets are backwards compatible, this can happen in a per-host
fashion. Also, not all applications can be ported to a FQDN
dependent infrastructure, e.g. DNS functions. This hurdle is
manageable, and may not be a definite obstacle for the
transition of a whole domain, but it needs to be taken into
account when striving for mobility/multihoming of an entire
site. The transition of functions on individual hosts may be
trivial, either through upgrades/changes to the OS or as linked
libraries. This can still happen incrementally and
independently, as compatibility is not affected by the use of
name-based sockets.
</t>
</section>
<section title='Edge-networks'>
<t>
Name-based sockets rely on the transition of individual
applications and are backwards compatible, so they do not
require bilateral upgrades. This allows each host to migrate
its applications independently. Name-based sockets may make an
individual client agnostic to the networking medium, be it
PA/PI IP-addresses or in a the future an entirely different
networking medium. However, an entire edge-network, with
internal and external services will not be able to make a
complete transition in the near future. Hence, even if a
substantial fraction of the hosts in an edge-network use
name-based sockets, PI addresses may still be required by the
edge-network. In short, new services may be implemented using
name-based sockets, old services may be ported. Name-based
sockets provide an increased motivation to move to PA-addresses
as actual provider independence relies less and less on
PI-addressing.
</t>
</section>
</section>
<section title='Rebuttal'>
<t>
No rebuttal was submitted for this proposal.
</t>
</section>
</section>
<section title='Routing and Addressing in Networks with Global
Enterprise Recursion (IRON-RANGER)'>
<section title='Summary'>
<t>
RANGER is a locator-identifier separation approach that uses
IP-in-IP encapsulation to connect edge networks across transit
networks such as the global Internet. End systems use endpoint
interface identifier (EID) addresses that may be routable within
edge networks but do not appear in transit network routing
tables. EID to Routing Locator (RLOC) address bindings are
instead maintained in mapping tables and also cached in default
router FIBs (i.e., very much the same as for the global DNS and
its associated caching resolvers). RANGER enterprise networks are
organized in a recursive hierarchy with default mappers
connecting lower layers to the next higher layer in the
hierarchy. Default mappers forward initial packets and push
mapping information to lower-tier routers and end systems through
secure redirection.
</t>
<t>
RANGER is an architectural framework derived from the Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP).
</t>
<section title='Gains'>
<t>
<list style='symbols'>
<t>
provides a scalable routing system alternative in instances
where dynamic routing protocols are impractical
</t>
<t>
naturally supports a recursively-nested
"network-of-networks" (or, "enterprise-within-enterprise")
hierarchy
</t>
<t>
uses asymmetric security mechanisms (i.e., secure neighbor
discovery) to secure router discovery and the redirection
mechanism
</t>
<t>
can quickly detect path failures and pick alternate routes
</t>
<t>
naturally supports provider-independent addressing
</t>
<t>
support for site multihoming and traffic engineering
</t>
<t>
ingress filtering for multihomed sites
</t>
<t>
mobility-agile through explicit cache invalidation (much more
reactive than DynDns)
</t>
<t>
supports neighbor discovery and neighbor unreachability
detection over tunnels
</t>
<t>
no changes to end systems
</t>
<t>
no changes to most routers
</t>
<t>
supports IPv6 transition
</t>
<t>
compatible with true identity/locator split mechanisms such
as HIP (i.e., packets contain a HIP Host Identity Tag (HIT)
as an end system identifier, IPv6 address as endpoint
Interface iDentifier (EID) in the inner IP header and IPv4
address as Routing LOCator (RLOC) in the outer IP header)
</t>
<t>
prototype code available
</t>
</list>
</t>
</section>
<section title='Costs'>
<t>
<list style='symbols'>
<t>
new code needed in enterprise border routers
</t>
<t>
locator/path liveness detection using RFC 4861 neighbor
unreachability detection (i.e., extra control messages,
but data-driven) <xref target='RFC4861'/>
</t>
</list>
</t>
</section>
<section title='References'>
<t>
<xref target='I-D.templin-iron'/>
<xref target='I-D.russert-rangers'/>
<xref target='I-D.templin-intarea-vet'/>
<xref target='I-D.templin-intarea-seal'/>
<xref target='RFC5201'/>
<xref target='RFC5214'/>
<xref target='RFC5720'/>
</t>
</section>
</section>
<section title='Critique'>
<t>
The RANGER architectural framework is intended to be applicable
for a Core-Edge Separation (CES) architecture for scalable
routing, using either IPv4 or IPv6 - or using both in an
integrated system which may carry one protocol over the other.
</t>
<t>
However, despite the ID being readied for publication as an
experimental RFC, the framework falls well short of the level of
detail required to envisage how it could be used to implement a
practical scalable routing solution. For instance, the ID
contains no specification for a mapping protocol, or how the
mapping lookup system would work on a global scale.
</t>
<t>
There is no provision for RANGER's ITR-like routers being able
to probe the reachability of end-user networks via multiple
ETR-like routers - nor for any other approach to multihoming
service restoration.
</t>
<t>
Nor is there any provision for inbound TE or support of mobile
devices which frequently change their point of attachment.
</t>
<t>
Therefore, in its current form, RANGER cannot be contemplated as
a superior scalable routing solution to some other proposals
which are specified in sufficient detail and which appear to be
feasible.
</t>
<t>
RANGER uses its own tunneling and PMTUD management protocol:
SEAL. Adoption of SEAL in its current form would prevent the
proper utilization of jumbo frame paths in the DFZ, which will
become the norm in the future. SEAL uses RFC 1191 PTB messages
to the sending host only to fix a preset maximum packet length.
To avoid the need for the SEAL layer to fragment packets of this
length, this MTU value (for the input of the tunnel) needs to be
set significantly below 1500 bytes, assuming the typically ~1500
byte MTU values for paths across the DFZ today. In order to
avoid this excessive fragmentation, this value could only be
raised to a ~9k byte value at some time in the future where
essentially all paths between ITRs and ETRs were jumbo frame
capable.
</t>
</section>
<section title='Rebuttal'>
<t>
The Internet Routing Overlay Network (IRON)
<xref target='I-D.templin-iron'/> is a scalable Internet routing
architecture that builds on the RANGER recursive enterprise
network hierarchy <xref target='RFC5720'/>. IRON bonds together
participating RANGER networks using VET
<xref target='I-D.templin-intarea-vet'/> and SEAL
<xref target='I-D.templin-intarea-seal'/> to enable secure and
scalable routing through automatic tunneling within the Internet
core. The IRON-RANGER automatic tunneling abstraction views the
entire global Internet DFZ as a virtual NBMA link similar to
ISATAP <xref target='RFC5214'/>.
</t>
<t>
IRON-RANGER is an example of a Core-Edge Separation (CES)
system. Instead of a classical mapping database, however,
IRON-RANGER uses a hybrid combination of a proactive dynamic
routing protocol for distributing highly aggregated Virtual
Prefixes (VPs) and an on-demand data driven protocol for
distributing more-specific Provider Independent (PI) prefixes
derived from the VPs.
</t>
<t>
The IRON-RANGER hierarchy consists of recursively-nested
RANGER enterprise networks joined together by IRON routers
that participate in a global BGP instance. The IRON BGP
instance is maintained separately from the current Internet
BGP Routing LOCator (RLOC) address space (i.e., the set of
all public IPv4 prefixes in the Internet). Instead, the IRON
BGP instance maintains VPs taken from Endpoint Interface
iDentifier (EID) address space, e.g., the IPv6 global unicast
address space. To accommodate scaling, only O(10k) - O(100k)
VPs are allocated e.g., using /20 or shorter IPv6 prefixes.
</t>
<t>
IRON routers lease portions of their VPs as Provider
Independent (PI) prefixes for customer equipment (CEs),
thereby creating a sustainable business model. CEs that lease
PI prefixes propagate address mapping(s) throughout their
attached RANGER networks and up to VP-owning IRON router(s)
through periodic transmission of "bubbles" with authentication
and PI prefix information. Routers in RANGER networks and IRON
routers that receive and forward the bubbles securely install
PI prefixes in their FIBs, but do not inject them into the RIB.
IRON routers therefore keep track of only their customer base
via the FIB entries and keep track of only the Internet-wide
VP database in the RIB.
</t>
<t>
IRON routers propagate more-specific prefixes using secure
redirection to update router FIBs. Prefix redirection is
driven by the data plane and does not affect the control
plane. Redirected prefixes are not injected into the RIB,
but rather are maintained as FIB soft state that is purged
after expiration or route failure. Neighbor unreachability
detection is used to detect failure.
</t>
<t>
Secure prefix registrations and redirections are accommodated
through the mechanisms of SEAL. Tunnel endpoints using SEAL
synchronize sequence numbers, and can therefore discard any
packets they receive that are outside of the current sequence
number window. Hence, off-path attacks are defeated. These
synchronized tunnel endpoints can therefore exchange prefixes
with signed certificates that prove prefix ownership in such
a way that DoS vectors that attack crypto calculation overhead
are eliminated due to the prevention of off-path attacks.
</t>
<t>
CEs can move from old RANGER networks and re-inject their PI
prefixes into new RANGER networks. This would be accommodated by
IRON-RANGER as a site multihoming event while host mobility and
true locator-ID separation is accommodated via HIP
<xref target='RFC5201'/>.
</t>
</section>
</section>
<section title="Recommendation">
<t>
As can be seen from the extensive list of proposals above, the
group explored a number of possible solutions. Unfortunately, the
group did not reach rough consensus on a single best approach.
Accordingly, the recommendation has been left to the co-chairs.
The remainder of this section describes the rationale and decision
of the co-chairs.
</t>
<t>
As a reminder, the goal of the research group was to develop a
recommendation for an approach to a routing and addressing
architecture for the Internet. The primary goal of the
architecture is to provide improved scalability for the routing
subsystem. Specifically, this implies that we should be able to
continue to grow the routing subsystem to meet the needs of the
Internet without requiring drastic and continuous increases in the
amount of state or processing requirements for routers.
</t>
<section title='Motivation'>
<t>
There is a general concern that the cost and structure of the
routing and addressing architecture as we know it today may
become prohibitively expensive with continued growth, with
repercussions to the health of the Internet. As such, there is an
urgent need to examine and evaluate potential scalability
enhancements.
</t>
<t>
For the long term future of the Internet, it has become apparent
that IPv6 is going to play a significant role. It has taken more
than a decade, but IPv6 is starting to see some non-trivial
amount of deployment. This is in part due to the depletion of
IPv4 addresses. It therefore seems apparent that the new
architecture must be applicable to IPv6. It may or may not be
applicable to IPv4, but not addressing the IPv6 portion of the
network would simply lead to recreating the routing scalability
problem in the IPv6 domain, because the two share a common
routing architecture.
</t>
<t>
Whatever change we make, we should expect that this is a very
long-lived change. The routing architecture of the entire
Internet is a loosely coordinated, complex, expensive subsystem,
and permanent, pervasive changes to it will require difficult
choices during deployment and integration. These cannot be
undertaken lightly.
</t>
<t>
By extension, if we are going to the trouble, pain, and expense
of making major architectural changes, it follows that we want to
make the best changes possible. We should regard any such
changes as permanent and we should therefore aim for long term
solutions that place the network in the best possible position
for ongoing growth. These changes should be cleanly integrated,
first-class citizens within the architecture. That is to say
that any new elements that are integrated into the architecture
should be fundamental primitives, on par with the other existing
legacy primitives in the architecture, that interact naturally
and logically when in combination with other elements of the
architecture.
</t>
<t>
Over the history of the Internet, we have been very good about
creating temporary, ad-hoc changes, both to the routing
architecture and other aspects of the network layer. However,
many of these band-aid solutions have come with a significant
overhead in terms of long-term maintenance and architectural
complexity. This is to be avoided and short-term improvements
should eventually be replaced by long-term, permanent solutions.
</t>
<t>
In the particular instance of the routing and addressing
architecture today, we feel that the situation requires that we
pursue both short-term improvements and long-term solutions.
These are not incompatible because we truly intend for the
short-term improvements to be completely localized and temporary.
The short-term improvements are necessary to give us the time
necessary to develop, test, and deploy the long-term solution.
As the long-term solution is rolled out and gains traction, the
short-term improvements should be of less benefit and can
subsequently be withdrawn.
</t>
</section>
<section anchor='recommendation' title='Recommendation to the IETF'>
<t>
The group explored a number of proposed solutions but did not reach
consensus on a single best approach. Therefore, in fulfillment
of the routing research group's charter, the co-chairs recommend
that the IETF pursue work in the following areas:
<list>
<t>
Evolution
<xref target='I-D.zhang-evolution'/>
</t>
<t>
Identifier/Locator Network Protocol (ILNP)
<xref target='ILNP Site'/>
</t>
<t>
Renumbering <xref target='RFC5887'/>
</t>
</list>
</t>
</section>
<section title='Rationale'>
<t>
We selected Evolution because it is a short-term improvement. It
can be applied on a per-domain basis, under local administration
and has immediate effect. While there is some complexity
involved, we feel that this option is constructive for service
providers who find the additional complexity to be less painful
than upgrading hardware. This improvement can be deployed by
domains that feel it necessary, for as long as they feel it is
necessary. If this deployment lasts longer than expected, then
the implications of that decision are wholly local to the domain.
</t>
<t>
We recommended ILNP because we find it to be a clean solution for
the architecture. It separates location from identity in a
clear, straightforward way that is consistent with the remainder
of the Internet architecture and makes both first-class
citizens. Unlike the many map-and-encap proposals, there are no
complications due to tunneling, indirection, or semantics that
shift over the lifetime of a packet's delivery.
</t>
<t>
We recommend further work on automating renumbering because even
with ILNP, the ability of a domain to change its locators at
minimal cost is fundamentally necessary. No routing architecture
will be able to scale without some form of abstraction, and
domains that change their point of attachment must fundamentally
be prepared to change their locators in line with this
abstraction. We recognize that
<xref target='RFC5887'/> is not a solution
so much as a problem statement, and we are simply recommending
that the IETF create effective and convenient mechanisms for site
renumbering.
</t>
</section>
</section>
<section title="Acknowledgments">
<t>
This document presents a small portion of the overall work
product of the Routing Research Group, who have developed all of
these architectural approaches and many specific proposals within
this solution space.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no requests to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
Space precludes a full treatment of security
considerations for all proposals summarized herein.
<xref target='RFC3552'/> However, it
was a requirement of the research group to provide security that is
at least as strong as the existing Internet routing and addressing
architecture. Each technical proposal has slightly different
security considerations, the details of which are in many of the
references cited.
</t>
</section>
</middle>
<back>
<references title="Informative References">
&I-D.narten-radir-problem-statement;
&I-D.irtf-rrg-design-goals;
<!-- Informative references -->
&RFC5887;
&RFC3552;
<!-- LISP References -->
&I-D.ietf-lisp;
&I-D.ietf-lisp-alt;
&I-D.ietf-lisp-ms;
&I-D.ietf-lisp-interworking;
&I-D.meyer-lisp-mn;
&I-D.farinacci-lisp-lig;
&I-D.meyer-loc-id-implications;
<reference anchor='LISP-TREE'
target='http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5586446'>
<front>
<title>LISP-TREE: A DNS Hierarchy to Support the LISP Mapping
System</title>
<author initials='L.' surname='Jakab' fullname='Lorànd Jakab'>
<organization>
Department of Computer Architecture, Universitat Politècnica
de Catalunya, Barcelona, Spain
</organization>
<address>
<email>ljakab@ac.upc.edu</email>
</address>
</author>
<author initials='A.' surname='Cabellos-Aparicio'
fullname='Albert Cabellos-Aparicio'>
<organization>
Department of Computer Architecture, Universitat Politècnica
de Catalunya, Barcelona, Spain
</organization>
<address>
<email>acabello@ac.upc.edu</email>
</address>
</author>
<author initials='F.' surname='Coras'
fullname='Florin Coras'>
<organization>
Department of Computer Architecture, Universitat Politècnica
de Catalunya, Barcelona, Spain
</organization>
<address>
<email>fcoras@ac.upc.edu</email>
</address>
</author>
<author initials='D.' surname='Saucez'
fullname='Damien Saucez'>
<organization>
Department of Computer Science and Engineering, Universitè
Catholique de Louvain, Louvain-la-Neuve, Belgium
</organization>
<address>
<email>damien.saucez@uclouvain.be</email>
</address>
</author>
<author initials='O.' surname='Bonaventure'
fullname='Olivier Bonaventure'>
<organization>
Department of Computer Science and Engineering, Universitè
Catholique de Louvain, Louvain-la-Neuve, Belgium
</organization>
<address>
<email>olivier.bonaventure@uclouvain.be</email>
</address>
</author>
</front>
</reference>
<!-- "RANGI References" -->
&RFC3007;
&RFC4423;
&I-D.xu-rangi;
&I-D.xu-rangi-proxy;
<reference anchor='RANGI'
target='http://www.ietf.org/proceedings/09nov/slides/RRG-1.ppt'>
<front>
<title>Routing Architecture for the Next-Generation Internet
(RANGI)</title>
<author initials="X." surname='Xu' fullname='Xiaohu Xu'>
<organization>
Huawei
</organization>
</author>
</front>
<format type='PPT'
target='http://www.ietf.org/proceedings/09nov/slides/RRG-1.ppt' />
</reference>
<!-- 'Ivip References' -->
&I-D.whittle-ivip4-etr-addr-forw;
<reference anchor='Ivip PMTUD'
target='http://www.firstpr.com.au/ip/ivip/pmtud-frag/'>
<front>
<title>IPTM - Ivip's approach to solving the problems with
encapsulation overhead, MTU, fragmentation and Path MTU
Discovery</title>
<author initials='R.' surname='Whittle' fullname='Robin Whittle'>
<organization>
</organization>
</author>
</front>
<format type='HTML'
target='http://www.firstpr.com.au/ip/ivip/pmtud-frag/' />
</reference>
<reference anchor='Ivip6'
target='http://www.firstpr.com.au/ip/ivip/ivip6/'>
<front>
<title>Ivip6 - instead of map-and-encap, use the 20 bit Flow
Label as a Forwarding Label</title>
<author initials='R.' surname='Whittle' fullname='Robin Whittle'>
<organization>
</organization>
</author>
</front>
<format type='HTML' target='http://www.firstpr.com.au/ip/ivip/ivip6/' />
</reference>
<reference anchor='Ivip Constraints'
target='http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/'>
<front>
<title>List of constraints on a successful scalable routing
solution which result from the need for widespread voluntary
adoption</title>
<author initials='R.' surname='Whittle' fullname='Robin Whittle'>
<organization>
</organization>
</author>
</front>
<format type='HTML'
target='http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/' />
</reference>
<reference anchor='Ivip Mobility'
target='http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf'>
<front>
<title>TTR Mobility Extensions for Core-Edge Separation
Solutions to the Internet's Routing Scaling Problem</title>
<author initials='R.' surname='Whittle' fullname='Robin Whittle'>
<organization>
</organization>
</author>
</front>
<format type='PDF'
target='http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf' />
</reference>
<reference anchor='I-D.whittle-ivip-drtm'>
<front>
<title>DRTM - Distributed Real Time Mapping for Ivip and
LISP</title>
<author initials='R' surname='Whittle' fullname='Robin Whittle'>
<organization />
</author>
<date year='2010' month='March' day='06' />
</front>
<seriesInfo name='Internet-Draft'
value='draft-whittle-ivip-drtm-01' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-whittle-ivip-drtm-01.txt'
/>
</reference>
<reference anchor='I-D.whittle-ivip-glossary'>
<front>
<title>Glossary of some Ivip and scalable routing terms</title>
<author initials='R' surname='Whittle' fullname='Robin Whittle'>
<organization />
</author>
<date year='2010' month='March' day='06' />
</front>
<seriesInfo name='Internet-Draft'
value='draft-whittle-ivip-glossary-01' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-whittle-ivip-glossary-01.txt'
/>
</reference>
<!-- 'hIPv4 References' -->
&I-D.frejborg-hipv4;
&I-D.ford-mptcp-architecture;
&RFC4960;
<!-- 'CRM References' -->
<reference anchor='CRM'
target='http://www.tschofenig.priv.at/rrg/CR_mapping_system_0.1.pdf'>
<front>
<title>Compact routing in locator identifier mapping system</title>
<author initials='H' surname='Flinck' fullname='Hannu Flinck'>
<organization>
Nokia Siemens Networks
</organization>
</author>
</front>
</reference>
<!-- 'Layered Mapping System References' -->
<reference anchor='LMS Summary'
target='http://docs.google.com/Doc?docid=0AQsJc7A4NTgeZGM3Y3o1NzVfNmd3eGRzNGhi&hl=en'>
<front>
<title>A Layered Mapping System (Summary)</title>
<author initials='C.' surname='Sun' fullname='Charrie Sun'>
<organization>
</organization>
</author>
</front>
</reference>
<reference anchor='LMS'
target='http://docs.google.com/fileview?id=0BwsJc7A4NTgeOTYzMjFlOGEtYzA4OC00NTM0LTg5ZjktNmFkYzBhNWJhMWEy&hl=en'>
<front>
<title>A Layered Mapping System For Scalable Routing</title>
<author initials='S.' surname='Letong' fullname='Sun Letong'>
<organization>
</organization>
</author>
<author initials='Y.' surname='Xia' fullname='Yin Xia'>
<organization>
</organization>
</author>
<author initials='W.' surname='ZhiLiang' fullname='Wang
ZhiLiang'>
<organization>
</organization>
</author>
<author initials='W.' surname='Jianping' fullname='Wu Jianping'>
<organization>
</organization>
</author>
</front>
</reference>
<!-- 'GLI References' -->
<reference anchor='GLI'
target='http://www3.informatik.uni-wuerzburg.de/TR/tr470.pdf'>
<front>
<title>Global Locator, Local Locator, and Identifier Split
(GLI-Split)</title>
<author initials='M.' surname='Menth' fullname='Michael Menth'>
<organization>
University of Wurzburg, Institute of Computer Science, Germany
</organization>
</author>
<author initials='M.' surname='Hartmann' fullname='Matthias Hartmann'>
<organization>
University of Wurzburg, Institute of Computer Science, Germany
</organization>
</author>
<author initials='D.' surname='Klein' fullname='Dominik Klein'>
<organization>
University of Wurzburg, Institute of Computer Science, Germany
</organization>
</author>
</front>
</reference>
<reference anchor='Valiant'
target='http://tiny-tera.stanford.edu/~nickm/papers/HotNetsIII.pdf'>
<front>
<title>Designing a Predictable Internet Backbone Network</title>
<author initials='R.' surname='Zhang-Shen'
fullname='Rui Zhang-Shen'>
<organization>
Computer Systems Laboratory, Stanford University
</organization>
</author>
<author initials='N.' surname='McKeown' fullname='Nick McKeown'>
<organization>
Computer Systems Laboratory, Stanford University
</organization>
</author>
</front>
</reference>
<!-- 'TIDR References' -->
&I-D.adan-idr-tidr;
<reference anchor='TIDR identifiers'
target='http://www.ietf.org/mail-archive/web/ram/current/msg01308.html'>
<front>
<title>TIDR using the IDENTIFIERS attribute</title>
<author initials='J.J.' surname='Adan' fullname='Juan-Jose Adan'>
<organization>
Gerencia de Informatica de la Seguridad Social (GISS)
</organization>
</author>
</front>
</reference>
<reference anchor='TIDR and LISP'
target='http://www.ops.ietf.org/lists/rrg/2007/msg00902.html'>
<front>
<title>LISP etc architecture</title>
<author initials='J.J.' surname='Adan' fullname='Juan-Jose Adan'>
<organization>
Gerencia de Informatica de la Seguridad Social (GISS)
</organization>
</author>
</front>
</reference>
<reference anchor='TIDR AS forwarding'
target='http://www.ops.ietf.org/lists/rrg/2008/msg00716.html'>
<front>
<title>yetAnotherProposal: AS-number forwarding</title>
<author initials='J.J.' surname='Adan' fullname='Juan-Jose Adan'>
<organization>
Gerencia de Informatica de la Seguridad Social (GISS)
</organization>
</author>
</front>
</reference>
<!-- 'ILNP References' -->
<reference anchor='ILNP Site'
target='http://ilnp.cs.st-andrews.ac.uk'>
<front>
<title>ILNP - Identifier/Locator Network Protocol</title>
<author initials='R.' surname='Atkinson' fullname='Randall Atkinson'>
<organization>
Extreme Networks
</organization>
</author>
<author initials='S.' surname='Bhatti' fullname='Saleem Bhatti'>
<organization>
University of St. Andrews
</organization>
</author>
<author initials='S.' surname='Hailes' fullname='Stephen Hailes'>
<organization>
University College London
</organization>
</author>
<author initials='D.' surname='Rehunathan'
fullname='Devan Rehunathan'>
<organization>
University of St. Andrews
</organization>
</author>
<author initials='M.' surname='Lad' fullname='Manish Lad'>
<organization>
University College London
</organization>
</author>
</front>
</reference>
<reference anchor='MobiArch2'>
<front>
<title>Mobility Through Naming: Impact on DNS</title>
<author initials='R.' surname='Atkinson' fullname='Randall Atkinson'>
<organization>
Extreme Networks
</organization>
</author>
<author initials='S.' surname='Bhatti' fullname='Saleem Bhatti'>
<organization>
University of St. Andrews
</organization>
</author>
<author initials='S.' surname='Hailes' fullname='Stephen Hailes'>
<organization>
University College London
</organization>
</author>
<date month="August" year='2008'/>
</front>
<seriesInfo name="ACM International Workshop on Mobility in the
Evolving Internet (MobiArch)" value="3, Seattle,
USA"/>
</reference>
<reference anchor='MobiArch1'>
<front>
<title>Mobility as an Integrated Service through the Use of
Naming</title>
<author initials='R.' surname='Atkinson' fullname='Randall Atkinson'>
<organization>
Extreme Networks
</organization>
</author>
<author initials='S.' surname='Bhatti' fullname='Saleem Bhatti'>
<organization>
University of St. Andrews
</organization>
</author>
<author initials='S.' surname='Hailes' fullname='Stephen Hailes'>
<organization>
University College London
</organization>
</author>
<date month='August' year='2007'/>
</front>
<seriesInfo name="ACM International Workshop on Mobility in the
Evolving Internet (MobiArch)" value="2, Kyoto,
Japan"/>
</reference>
<reference anchor='MILCOM1'>
<front>
<title>Site-Controlled Secure Multi-homing and Traffic
Engineering for IP</title>
<author initials='R.' surname='Atkinson' fullname='Randall Atkinson'>
<organization>
Extreme Networks
</organization>
</author>
<author initials='S.' surname='Bhatti' fullname='Saleem Bhatti'>
<organization>
University of St. Andrews
</organization>
</author>
<date month='October' year='2009'/>
</front>
<seriesInfo name='IEEE Military Communications Conference (MILCOM)'
value='28, Boston, MA, USA'/>
</reference>
<reference anchor='MILCOM2'>
<front>
<title>Harmonised Resilience, Multi-homing and Mobility
Capability for IP</title>
<author initials='R.' surname='Atkinson' fullname='Randall Atkinson'>
<organization>
Extreme Networks
</organization>
</author>
<author initials='S.' surname='Bhatti' fullname='Saleem Bhatti'>
<organization>
University of St. Andrews
</organization>
</author>
<author initials='S.' surname='Hailes' fullname='Stephen Hailes'>
<organization>
University College London
</organization>
</author>
<date month='November' year='2008'/>
</front>
<seriesInfo name='IEEE Military Communications Conference (MILCOM)'
value='27, San Diego, CA, USA'/>
</reference>
<reference anchor='DNSnBIND'>
<front>
<title>DNS & BIND</title>
<author initials='C.' surname='Liu'>
<organization>
</organization>
</author>
<author initials='P.' surname='Albitz'>
<organization>
</organization>
</author>
<date year='2006'/>
</front>
<annotation>
5th Edition, O'Reilly & Associates, Sebastopol, CA, USA.
ISBN 0-596-10057-4
</annotation>
</reference>
&I-D.carpenter-behave-referral-object;
&I-D.rja-ilnp-nonce;
&RFC4033;
&RFC4034;
&RFC4035;
&RFC5534;
&RFC5902;
<!-- 'EEMDP References' -->
<reference anchor='EEMDP Considerations'
target='http://www.antd.nist.gov/~ksriram/EEMDP_ICCCN2010.pdf'>
<front>
<title>Enhanced Efficiency of Mapping Distribution Protocols in
Scalable Routing and Addressing Architectures</title>
<author initials='K.' surname='Sriram'
fullname='Kotikalapudi Sriram'>
<organization>
National Institute of Standards and Technology
</organization>
<address>
<email>pgleichm@nist.gov</email>
</address>
</author>
<author initials='Y.' surname='Kim' fullname='Young-Tak Kim'>
<organization>
Yeungnam University
</organization>
<address>
<email>ytkim@yu.ac.kr</email>
</address>
</author>
<author initials='D' surname='Montgomery' fullname='Doug Montgomery'>
<organization>
National Institute of Standards and Technology
</organization>
<address>
<email>dougm@nist.gov</email>
</address>
</author>
</front>
<seriesInfo name='Proceedings of the ICCCN, August' value='2010'/>
<annotation>
Zurich, Switzerland
</annotation>
</reference>
<reference anchor='EEMDP Presentation'
target='http://www.ietf.org/proceedings/78/slides/lisp-6.pdf'>
<front>
<title>Enhanced Efficiency of Mapping Distribution Protocols in
Scalable Routing and Addressing Architectures</title>
<author initials='K.' surname='Sriram'
fullname='Kotikalapudi Sriram'>
<organization>
National Institute of Standards and Technology
</organization>
<address>
<email>ksriram@nist.gov</email>
</address>
</author>
<author initials='P.' surname='Gleichmann'
fullname='Patrick Gleichmann'>
<organization>
National Institute of Standards and Technology
</organization>
<address>
<email>pgleichm@nist.gov</email>
</address>
</author>
<author initials='Y.' surname='Kim' fullname='Young-Tak Kim'>
<organization>
Yeungnam University
</organization>
<address>
<email>ytkim@yu.ac.kr</email>
</address>
</author>
<author initials='D' surname='Montgomery' fullname='Doug Montgomery'>
<organization>
National Institute of Standards and Technology
</organization>
<address>
<email>dougm@nist.gov</email>
</address>
</author>
</front>
<annotation>
Presented at the LISP WG meeting, IETF-78, July 2010.
Originally presented at the RRG meeting at IETF-72.
</annotation>
</reference>
<reference anchor="FIBAggregatability"
target='http://www.ietf.org/proceedings/76/slides/grow-2.pdf'>
<front>
<title>An Evaluation Study of Router FIB Aggregatability</title>
<author initials='B.' surname='Zhang' fullname='Beichuan Zhang'>
<organization>
Univ. of Arizona
</organization>
</author>
<author initials='L.' surname='Wang' fullname='Lan Wang'>
<organization>
Univ. of Memphis
</organization>
</author>
<author initials='X.' surname='Zhao' fullname='Xin Zhao'>
<organization>
Univ. of Arizona
</organization>
</author>
<author initials='Y.' surname='Liu' fullname='Yaoqing Liu'>
<organization>
Univ. of Memphis
</organization>
</author>
<author initials='L.' surname='Zhang' fullname='Lixia Zhang'>
<organization>
UCLA
</organization>
</author>
</front>
</reference>
<!-- 'Evolution References' -->
&I-D.zhang-evolution;
<reference anchor='Evolution Grow Presentation'
target='http://tools.ietf.org/agenda/76/slides/grow-5.pdf'>
<front>
<title>Virtual Aggregation (VA)</title>
<author initials='P.' surname='Francis' fullname='Paul Francis'>
<organization>
MPI-SWS
</organization>
</author>
<author initials='X.' surname='Xu' fullname='Xiaohu Xu'>
<organization>
Huawei
</organization>
</author>
<author initials='H.' surname='Ballani' fullname='Hitesh Ballani'>
<organization>
Cornell
</organization>
</author>
<author initials='D.' surname='Jen' fullname='Dan Jen'>
<organization>
UCLA
</organization>
</author>
<author initials='R.' surname='Raszuk' fullname='Robert Raszuk'>
<organization>
Cisco
</organization>
</author>
<author initials='L.' surname='Zhang' fullname='Lixia Zhang'>
<organization>
UCLA
</organization>
</author>
</front>
</reference>
<!-- 'Name Based Sockets References' -->
<reference anchor='Name Based Sockets'
target='http://christianvogt.mailup.net/pub/vogt-2009-name-based-sockets.pdf'>
<front>
<title>Simplifying Internet Applications Development With A
Name-Based Sockets Interface</title>
<author initials='C.' surname='Vogt' fullname='Christian Vogt'>
<organization>
Ericsson
</organization>
</author>
</front>
</reference>
<!-- 'RANGER References' -->
&I-D.templin-iron;
&I-D.russert-rangers;
&I-D.templin-intarea-vet;
&I-D.templin-intarea-seal;
&RFC5201;
&RFC5214;
&RFC5720;
&RFC4861;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:57:47 |