[rrg] Compact Routing - draft critique

[Robin Whittle <[e-mail]>]

No-one has submitted a critique of Hannu Flinck's proposal:

  Compact routing in locator identifier mapping system
  http://tools.ietf.org/html/draft-irtf-rrg-recommendation-04#section-7

The RRG Report ID does not have any references, but the proposal
document itself is an attachment to:

  Mapping system based on compact routing  (2009-12-15)
  http://www.ietf.org/mail-archive/web/rrg/current/msg05519.html

The summary was posted on 2009-12-17:

  http://www.ietf.org/mail-archive/web/rrg/current/msg05531.html

Here is my 1006 word (including quotation footnote) draft critique.
I will revise it, perhaps to less than 500 words, once I get some
feedback from Hannu.


  - Robin




Critique of "Compact routing in locator identifier mapping system"
------------------------------------------------------------------

The "Compact routing in locator identifier mapping system" proposal -
hereafter "CRM" - is most easily understood as an alteration to the
routing structure of the LISP-ALT mapping overlay system.  It is not a
complete proposal, and therefore cannot be considered as a scalable
routing solution suitable for further development.

ALT is a global query server system by which ITRs or Map Resolvers (MRs)
can request mapping for a given "edge" address (EID) address.  The
authoritative query servers are either ETRs or Map Servers (MSs).  The
query traverses the ALT network and is delivered to the MS or ETR -
which sends it reply directly to the MR or ITR via the Internet.
Despite its name, LISP is not a Locator / Identifier Separation
architecture.   LISP is a Core-Edge Separation architecture.  Core-Edge
Elimination architectures such as ILNP and HIP implement the Locator /
Identifier Separation naming model.

The ALT network consists of routers running a BGP system quite separate
from that of the Internet, communicating with each other via tunnels.
ALT can be used to deliver the initial packets an ITR has no mapping
for, to deliver them to the destination network and for them to function
as map requests.  CRM includes this as a specific aim:

  ... particularly when the mapping system is also a message relaying
  service, i.e. the first packet is delivered through the mapping
  system to its destination.

Since fractions of a second to perhaps several seconds may elapse before
the ITR receives the map reply, it is possible that more than one packet
may be sent over the ALT overlay network.  This use of the overlay
network for potentially long and/or numerous traffic packets, rather
than short map requests, significantly increases the load on the data
plane of the overlay network.

CRM is concerned with optimising the path length taken by these "query"
packets (which may be traffic packets) through a significantly modified
version of the ALT network - by altering or adding to the network's BGP
control plane.  Compact Routing principles are discussed in this regard,
with the aim of reducing the control plane load on any one router while
also generally reducing typical or maximum paths taken by the query
packets.

While Compact Routing principles may be able to achieve these goals,
compared to whatever, as-yet unspecified, structure the ALT network
would achieve (to minimise path lengths while remaining robust against
single points of failure) there are two objections to this approach.

Firstly, a CRM-modified ALT structure would still be a global query
server system.  No matter how ALT's path lengths and delays are
optimised, there is a fundamental 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 which are
inherent in such a system constitute a fundamental problem for any CES
or CEE system which relies on it.  The only solution is to employ local
full database query servers, or some other arrangement in which there
are larger numbers of authoritative query servers, with one or more
typically being located quite close (say one or two thousand kilometers)
from any querier.

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.  Therefore, at one point in time, a
physical node may be responsible for aggregating routes to a given set
of authoritative query servers, while at a later time, this role may be
moved to another node.

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-organising
properties of the system [1], there are concerns about how the vital
function of EID registration can be performed securely, when no
particular physical node is responsible for it.

Since individual nodes cost money, and are presumably run by individual
participants in the entire system, it is not clear how those nodes which
have the greatest traffic and the most responsibilities are to have
their running costs paid for by those who benefit from its activities.
Furthermore, those who benefit also rely on this node in terms of
reliability and security - and it does not seem tenable to trust this to
some dynamically chosen node, whose security and reliability cannot be
reliably ascertained.

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.   This 10^6 figure is
mentioned on page 3.  Whether it is a realistic figure is uncertain,
since neither CRM nor ALT have any clear set of design objectives.

Neither ALT nor a CRM-enhanced ALT network can be suitable mapping
solutions for CES or CEE architectures due to their global nature.  The
solution to this problem involve bringing authoritative query servers
closer to the queriers.


[1] "Accepting a map registration from an xTR, the map server also
accepts to take a role to create a cluster of neighborhood, and to act
as a cluster head for these xTRs. To summarize map servers forming the
clusters of compact routing should be selected based on their capability
to aggregate EIDs. This capability can be concluded from BGP
announcements. For boot strapping an initial seed set of EIDs could be
delegated to all or some map servers. However, this set will change as
the registration situation evolves."