Re: [rrg] RANGER and SEAL critique

["Templin, Fred L" <[e-mail]>]

Robin,

I will respond to the RANGER portion of the critique later,
but in terms of the SEAL portion please be sure you are
evaluating the correct version. The latest SEAL spec is
found here:

  http://tools.ietf.org/html/draft-templin-intarea-seal

and fully supports jumbograms.

Thanks - Fred
[e-mail]

> -----Original Message-----
> From: Robin Whittle [mailto:[e-mail]]
> Sent: Tuesday, January 26, 2010 3:48 AM
> To: RRG
> Cc: Templin, Fred L
> Subject: RANGER and SEAL critique
>
> 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.
>