[rrg] RANGER and SEAL critique

[Robin Whittle <[e-mail]>]

A word file of the following text is attached.

This is my attempt to write a critique of RANGER and SEAL for the
RRG Report.  The SEAL critique is at the end.

Since there is a 500 word limit for the RRG report, I suggest
that just the first 7 paragraphs be used.  Trying to discuss
RANGER in any more detail quickly expands to much larger task.

This is not an exhaustive critique.  I have done enough to
satisfy myself that RANGER, as currently specified, should not
be considered as a possible practical solution to the routing
scaling problem.

This is just my writing - it does not reflect RRG consensus and
it has not benefited from any input from Fred or anyone else.
Please watch the RRG list for any clarifications, corrections etc.

Maybe someone else can improve on this critique.

Robin Whittle  2010-01-26



Critique of Fred Templin's RANGER and SEAL

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.

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, how the
mapping lookup system would work on a global scale.

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.

Nor is there any provision for inbound TE or support of mobile
devices which frequently change their point of attachment.

Therefore, it 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.

RANGER uses its own tunneling and PMTUD management protocol:
SEAL.  Adoption of SEAL in its current form would prevent the
proper utilization of jumboframe 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 jumboframe capable.

A fuller version of this critique was posted to the RRG list on
2010-01-26.

<<< - - - - End of <500 word critique - - - - - - - - - - - ->>>

RANGER involves novel and potentially confusing terminology and
is explained in terms of the greatest generality - which makes
it difficult to determine the simplest arrangement necessary for
widespread adoption in order to solve the routing scaling problem.

Encapsulation is used to tunnel packets from an ITR like device,
which may be referred to as an "Ingress Tunnel Endpoint" (ITE)
or "ingress Enterprise Border Router" (iEBR) to an ETR-like
device - an "Egress Tunnel Endpoint" (ETE) or an "egress
Enterprise Border Router" (eEBR).

The term "enterprise" can refer to a network of any size,
including the Internet.  SEAL's extendibility goes beyond this:
"other internets could be manifested as 'parallel universes' and
joined together at still higher levels of recursion".

A further difficulty is that RANGER uses the term "RLOC" with
greater flexibility than any other CES architecture. If the
subset of the global unicast space of the Internet which is not
devoted to EID (scalable end-user network) space is regarded as
"RLOC" commons for the enterprise of the Internet, then within
the RANGER model, any subsidiary enterprise which connects to
this Internet enterprise has its own RLOC commons, which may (or
must?) involve independent re-use of the RLOC space of the
Internet, plus any private address space which this subsidiary
enterprise uses.

It is different to envisage scalable routing with full
interworking to hosts in other networks using "Internet RLOC"
addresses from a subsidiary enterprise network if its own use of
these addresses is wholly, or partially, or at least potentially
"private" to this enterprise and therefore in a separate namespace.

While RANGER is claimed to be suitable for both IPv4 and IPv6,
some of its internal mechanisms depend on IPv6.  So it is
especially difficult to envisage a pure IPv4 implementation of
RANGER to solve the IPv4 scalable routing problem.  The ID tends
to regard IPv4 communications as "legacy".

Although RANGER is claimed to provide mobility, true mobility,
with frequent MN changes of address, is to be provided by HIP or
Mobile IPv6, rather than by RANGER itself.  This precludes the
achievement of mobility for IPv4 hosts.

RANGER uses the SEAL tunneling and Path MTU Discovery
management.  Some limitations of this have been mentioned above
and are discussed in greater detail below.

Wide adoption of RANGER for scalable routing purposes would not
necessarily involve deeply recursive levels of enterprises.  A
single depth of "enterprise" would avoid the need for
concatenated tunnels, with decapsulation and re-encapsulation at
each depth of enterprise traversed.  Since RANGER's mapping
system returns different eEBR addresses depending on which
enterprise the mapping is looked up within, it is difficult to
envisage a simple mapping and tunneling arrangement comparable
to the unified systems used by other CES architectures.

draft-russert-rangers-01 page 15 has an example of how the
mapping systems in different nested enterprises produce
different results for the one EID address.  The packet is
tunneled within one enterprise to a router which decapsulates it
and looks up its the EID address' mapping in the mapping system
of the enclosing enterprise.  This causes the packet to be
tunneled to another router where the same process may occur for
the next level of enclosing enterprise.  Exactly how this would
work for ISP networks and end-user networks in a minimal
scalable routing scenario is difficult to understand.

Assuming an IPv4-only or IPv6-only implementation, for
simplicity, the global unicast address space would be the
commons of the Internet and a subset of this would be reserved
for the globally unique EID addresses.  The global unicast
addresses which are not included in any EID prefixes are then
known as Internet RLOC addresses.  If we assume that no network
re-uses any of this space, then "RLOC" denotes conventional
global unicast addresses which are unique within the whole
Internet and which are not subject to special attention by the
ITR-like ibex when found in the destination field of a packet.
However, private address space within each enterprise is widely
used, and is known as "RLOC" within RANGER, although it is in an
entirely separate namespace from global unicast address space.

An iEBR in any network needs to be able to look up mapping for
the EID prefix matching a destination address of a packet it
receives.  Assuming all iEBRs are preconfigured with information
about which prefixes constitute the EID subset of the global
unicast address space (which the IDs do not mention, but which
would be necessary), it is not clear how an iEBR proceeds to
find the mapping.

No specific mapping protocols are required by RANGER, so the IDs
are incomplete in this respect at least in terms of providing a
practical scalable routing architecture.  This is compounded by
the options of either requesting mapping or forwarding the
packet to an upstream "default mapper".

These mapping lookups appear to be distinct from the use of
redirects (which have no caching time) as a data-driven method
by which a router can discover the next-hop router for packets
matching a given prefix, because this approach only applies to
whatever is regarded as "RLOC" within the enterprise.

Section 3.1 provides the best guidance on mapping systems:

   The mapping system is typically maintained as a per-enterprise
   distributed database that is synchronized among a limited set of
   mapping agents.  Distributed database management alternatives include
   a routing protocol instance maintained by Enterprise Border Gateways
   (EBGs), a DNS reverse zone distributed among a restricted set of
   caching servers, etc.  Mapping entries are inserted into the mapping
   system through administrative configuration, automated prefix
   registrations, etc.

   RANGER allows for an ITE to either consult the mapping system itself
   (while delaying or dropping initial IP packets) or forward initial
   packets to an EBG acting as a "default mapper".  In either case, the
   ITE receives a mapping reply that it can use to populate its
   Forwarding Information Base (FIB).  The choice of mapping approaches
   must be considered with respect to the individual enterprise network
   scenario, e.g., forwarding to an EBG may be more appropriate in some
   scenarios while ITE self-discovery may be more appropriate in others.
   Use of other mapping mechanisms is also possible according to the
   specific enterprise scenario.

Also, section 3.7:

   Selection of mapping alternatives may have significant implications
   for applications, server selection, route determination, security,
   etc.  In particular, applications that expect all packets (including
   initial ones) to experience similar delays may be adversely affected
   by a scheme that imposes non-negligible delays when initial packets
   are queued while a look-aside mapping table is consulted.  Still
   other applications may experience significant startup delays when its
   initial packets are dropped during a mapping lookup event.  These
   factors would seem to favor a scheme that is able to forward initial
   packets along a path with sub-optimal delay while a mapping lookup is
   performed in parallel, e.g., such as when a "default mapper" is used.

   Generally speaking, proactive mapping-maintenance mechanisms may have
   scaling issues with the amount of updates they generate, while
   reactive mechanisms may involve effects to the delay of initial
   packets before the cached state is updated.  Also to be considered
   are attacks against the mapping mechanism, which may result in denial
   of service of the mapping cache.


The first RANGER ID is from October 2008 and the current version
is experimental RFC-5720-to-be.   Yet there is no defined
mapping system.  The choice of mapping system is widely regarded
as the biggest single difficulty in any CES architecture.

Nor is their any specification for, or guidance about:

  * Caching by iEBRs.

  * The technical and administratively authoritative sources of
    mapping.

  * How each enterprise's mapping system interworks with that of
    other enterprises.

  * Administrative arrangements for who controls which parts of
    the global unicast address space are used as EIDs.

  * Format of mapping requests.

  * Format of mapping replies and or how they can be secured when
    they result from either a mapping request or by the forwarding
    of an unencapsulated traffic packet to an upstream router which
    functions both as a default mapper and as an iEBR.

Although the system is supposed to support multihoming, there is
no mention of how an iEBR can learn of multiple eEBR addresses
to use, and how it could decide which of them to used based on
somehow discovering whether each one is currently able to
forward packets to the destination network.

Likewise, there is no discussion of mapping or iEBR mechanisms
for load-sharing or any other approach to inbound TE from the
point of view of the destination network.

There is no plan for gradual deployment, with full benefits to
early adopters, no matter how few have so far adopted RANGER in
their networks.  For instance, there is no apparent equivalent
of Ivip's DITRs or LISP's PTRs, both of which are essential to
correctly tunneling packets sent from networks which have not
yet been upgraded.

draft-russert-rangers-01 gives an example (Figure 12) of global
mobility with a passenger aircraft.  In this example, "the
worldwide Internet sees no change".  This is because all ground
stations are part of a single "Aero Enterprise" network with a
single point of connection to the Internet.  Consequently,
excessively long paths will frequently be encountered.  If the
network linked to the Internet in Paris and the aircraft was
using a ground station near Dunedin in the South Island of New
Zealand, then any packets sent by hosts in the aircraft to the
University of Otago there would need to travel from the ground
station, to Paris and then back, via the Internet, to Dunedin.
Likewise in the return path the path would be excessively long.

Please see:

  http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf

by Steve Russert (who co-wrote the ID in question) and myself
for an example of using the TTR Mobility architecture to avoid
such excessively long paths.

The RANGER IDs make several references to "Carrier Grade NAT".
Only one reference links to another document:

  An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition
  http://tools.ietf.org/html/draft-jiang-incremental-cgn-00

This is somewhat different than "dual-stack-lite", but still has
the problems inherent in trying to server multiple customers,
such as home or SOHO networks, from a single IPv4 address.
These problems involve scaling difficulties in the CGN box and
the impossibility of more than one of the customers using port
forwarding for the same port.  This is needed for some p2p and
other applications.  The site

   http://www.portforward.com/cports.htm

lists 2221 applications which use port forwarding, most of them
apparently games, but also including various widely used
Instant Messenger applications.

RANGER aims to provide a general, powerful, recursive framework
for networking, based on the Catenet work of Louis Pouzin in 1974:

   By restoring the original CATENET vision to the Internet, the next
   generation Internet can be arbitrarily scalable while simultaneously
   supporting provider independence, mobility, multihoming and security.

However, as currently specified it is unsuitable for adoption as
a scalable routing architecture.



SEAL

An earlier comparison of SEAL and Ivip's IPTM protocol from
April 2008 is:

  SEAL & IPTM: differing goals
  http://www.ietf.org/mail-archive/web/rrg/current/msg02149.html

IPTM is described at:

  http://www.firstpr.com.au/ip/ivip/pmtud-frag/

Re-reading the latest version RFC-5320-to-be on 2010-01-26 I
concluded the following.  I am using "ITR" to denote RANGER's
encapsulating tunnel function (ETE or eEBR):

(4.2.1) SEAL does not attempt to deal with packets longer than
~1500 bytes.  A major goal of IPTM is to enable the ITRs to take
advantage of ~9k byte MTU paths to the ETRs.  These jumboframe
paths will, presumably, become common and later ubiquitous in
the DFZ, as well as within most ISP and end-user networks.
Therefore, adoption of seal would mean these jumboframe paths
would not be properly utilized.

This section, on page 11, states that the ITR could set the MTU
of the tunnel input to 1500 bytes - or somewhat more if it was
desired to cope with ~1500 bytes original packets which had
extra encapsulation by the time they reached the ITR.  The ITU
could also set the MTU as low as 1280 bytes for IPv6, and 576
bytes for IPv4, though it is not explained why such low values
might be considered.

With IPv4 DF=0 packets longer than this chosen MTU, the ITR
fragments them at that point before submitting the resulting
pair (or more than two?) of packets for SEAL processing.

With IPv6 packets and IPv4 DF=1 packets which exceed the chosen
MTU value, the ITR sends a PTB to the SH so future packet
lengths will not exceed the chosen MTU value.

Other than this, SEAL does not attempt to send RFC 1191 PTB
messages to the sending host.  Consequently, for maximal length
packets the same length as the chosen MTU, if this length plus
the SEAL and other encapsulation headers exceeds the actual PMTU
to the ETR, then the ITR and ETR will work together to adapt the
ITRs SEAL fragmentation of the resulting packet.

This means that if the chosen MTU, plus SEAL and other
encapsulation headers results in a figure above ~1500, then in
today's DFZ (which I understand typically has ~1500 byte PMTUs)
each maximal length packet the SH generates will result in the
ITR emitting two separate packets.

To avoid this unsustainable performance and reliability
degradation, SEAL would need to be operated with a low-enough
chosen MTU to ensure the SH's packets are never long enough to
exceed DFZ PMTUs once the SEAL and other encapsulation headers
have been added.   This would be an MTU value substantially
below 1500 bytes, and would be marginally shorter for IPv6
because of its longer IP header.

In summary:

SEAL would prevent the use of jumboframes in the DFZ for all
tunneled packets.  (Until perhaps some time in the future where
all ITRs could reach all ETRs across the DFZ, and via all other
routers, with jumboframe PMTUs - then all SEAL tunnel input MTUs
could be set to some value a little below ~9kbytes.)

Even if a greater than 1500 byte PMTU was available between the
ITR and the ETR, SEAL would not allow it to be used fully, since
the MTU of the tunnel input would (in order to avoid
fragmentation of all maximum length packets) be set to a value
substantially below 1500 bytes.

SEAL has quite a complex protocol for detecting PMTU to the ETR
compared to IPTM.