[rrg] IRON-RANGER Critique V2

[Robin Whittle <[e-mail]>]

Here is a critique for the RRG Report for Fred Templin's RANGER proposal.

Please see these messages for the longer description and discussion.

  IRON(RANGER): description and draft critique
  http://www.ietf.org/mail-archive/web/rrg/current/msg05983.html RW
  http://www.ietf.org/mail-archive/web/rrg/current/msg05992.html   FT
  http://www.ietf.org/mail-archive/web/rrg/current/msg05996.html RW

The first of these links to the reference documents.

Below is a longer version of my V2 critique, and a shorter 500 word
version for inclusion in the RRG Report.  Ideally other people would
contribute their own critiques of IRON-RANGER.  The shorter version
is just the longer one minus paragraphs 3 to 10.

The text which follows has been updated based on the above discussions.

  - Robin



Longer Critique V2
------------------

IRON-RANGER (hereafter "IRON") uses principles from RANGER, VET and
SEAL to construct a Core-Edge Separation scalable routing solution.
Separate IRON networks would be used for IPv4 and IPv6, but perhaps
they could be combined in some way if this was desired.

IRON does not have a mapping system such as that of Ivip and the term
"mapping system" does not appear in the IDs.  However, the IRON
architecture does in some ways resemble LISP-ALT, with a flat
ALT-structure, with traffic packets being used as map requests and in
which the initial traffic packets are delivered to the destination
network.  Please see (msg05996) for discussion of this.

A single global network of IRON routers communicate over tunnels,
each using their own BGP instance, to form the IRON BGP control
plane.  This is unrelated to the DFZ's BGP control plane.  IRON
routers may be DFZ routers, but here they are assumed not to be.

While each IRON router advertises all "edge" prefixes in the routing
system of the networks they are based in (of ISPs and large
corporations, universities etc.), the current IDs do not call for
them to advertise any such prefixes in the DFZ.  Therefore, as
currently described, IRON could only support packets sent by all
hosts if it was adopted by all such networks.  However, IRON could
easily be adapted to do this by having multiple widely-dispersed IRON
routers advertise the complete set of "edge" prefixes in the DFZ.

Each IRON router processes packets addressed to "edge" addresses by
forwarding them to a particular IRON router which, inside the IRON
BGP control plane, advertises a particular Virtual Prefix.  There may
be one or more of these VP routers for a given prefix, and the number
of VP prefixes for the entire "edge" subset of the global unicast
address space would be limited, in part, but the ability of the IRON
BGP control plane to handle this number of prefixes.

IRON routers peer with topologically nearby IRON routers to be their
BGP neighbours.  When the traffic packet arrives at the VP router, it
is forwarded, again via a VET/SEAL tunnel to the IRON router which
can deliver the packet to the destination network.

The VP router also sends a SEAL redirect message to the first
(ITR-like) IRON router and thereafter, that first IRON router tunnels
the packets directly to the IRON router which connects to the
destination end-user network.

The VP router's FIB for has more-specific routes for each end-user
network prefix which is covered by this VP.

Please see (msg05996) for discussion of how two or more ETR-like IRON
routers D and E somehow, continually and securely, register their
ability to accept packets for an end-user network prefix, along with
their priorities in respect of each other for which should be used if
both are reachable - and optionally some instructions for
load-sharing between them.

The FIB entry for this end-user network prefix in each VP router
contains this information.  This information is conveyed to an
ITR-like IRON router which tunneled the initial packet to the VP
router, so that IRON router subsequently tunnels packets to one or
both of these ETR-like routers.  There is a caching time and an
inactivity timer for purging these more-specific routes from the FIB
of the ITR-like IRON router.  ("ITR" and "ETR" do not appear in IRON
- and "ITR-like" means the ITR-like function of an IRON router, since
they can also perform ETR-like functions and some of them also
perform as VP routers.)

There are unresolved design and scaling questions regarding:

  1 - The ability of the initial IRON router to handle in its
      FIB the temporarily installed more-specific routes due
      to the redirect messages it receives from VP routers.

  2 - Likewise, questions of FIB and/or route processor ability
      to handle the churn in these, since they will typically
      last for seconds or minutes, before having to be withdrawn
      and perhaps replaced after a further redirect.

  3 - The number of VP routers - more than one would be necessary
      for robustness.

  4 - So far there is no detailed explanation, for IPv4 or IPv6, of
      how the ETR-like functions of IRON routers continually and
      securely register each end-user network prefix they handle -
      together with priority and load sharing information - with one
      or more VP routers which could be located anywhere in the
      world.  Only once a detailed description is available could
      the scalability, robustness, responsiveness and security of
      this process be estimated.

IRON is not yet described in sufficient detail for these questions to
be answered.  Mobility support is apparently limited to mobile IPv6
networks with prefixes up to /56 in length, with mobility of devices
to be handled by conventional MIPv6 processes.

There is no current description of the business relationships between
the various users and operators of routers - so it is difficult to
envisage business arrangements in which costs are generally borne by
those who benefit, without unfair burdens being placed on any
participants.  Nor is there a description of how IRON could be
introduced so as to provide portability, multihoming etc. for all
packets received by an adopting network, before all networks have
their own IRON routers.

IRON is a novel CES architecture in an early stage of its design
process.  It can be decentralised in every respect, and uses
data-driven "redirect" messages as a form of mapping distribution.
However, it is not yet clear how the VP routers learn the mapping for
the end-user prefixes in their VP.  If this can be done in a secure,
fast and scalable fashion - then IRON may be worth considering as a
scalable routing system, at least for providing portability and
multihoming to non-mobile end-user networks.




468 word critique V2
--------------------

IRON-RANGER (hereafter "IRON") uses principles from RANGER, VET and
SEAL to construct a Core-Edge Separation scalable routing solution.
Separate IRON networks would be used for IPv4 and IPv6, but perhaps
they could be combined in some way if this was desired.

IRON does not have a mapping system such as that of Ivip and the term
"mapping system" does not appear in the IDs.  However, the IRON
architecture does in some ways resemble LISP-ALT, with a flat
ALT-structure, with traffic packets being used as map requests and in
which the initial traffic packets are delivered to the destination
network.

There are unresolved design and scaling questions regarding:

  1 - The ability of the initial IRON router to handle in its
      FIB the temporarily installed more-specific routes due
      to the redirect messages it receives from VP routers.

  2 - Likewise, questions of FIB and/or route processor ability
      to handle the churn in these, since they will typically
      last for seconds or minutes, before having to be withdrawn
      and perhaps replaced after a further redirect.

  3 - The number of VP routers - more than one would be necessary
      for robustness.

  4 - So far there is no detailed explanation, for IPv4 or IPv6, of
      how the ETR-like functions of IRON routers continually and
      securely register each end-user network prefix they handle -
      together with priority and load sharing information - with one
      or more VP routers which could be located anywhere in the
      world.  Only once a detailed description is available could
      the scalability, robustness, responsiveness and security of
      this process be estimated.

IRON is not yet described in sufficient detail for these questions to
be answered.  Mobility support is apparently limited to mobile IPv6
networks with prefixes up to /56 in length, with mobility of devices
to be handled by conventional MIPv6 processes.

There is no current description of the business relationships between
the various users and operators of routers - so it is difficult to
envisage business arrangements in which costs are generally borne by
those who benefit, without unfair burdens being placed on any
participants.  Nor is there a description of how IRON could be
introduced so as to provide portability, multihoming etc. for all
packets received by an adopting network, before all networks have
their own IRON routers.

IRON is a novel CES architecture in an early stage of its design
process.  It can be decentralised in every respect, and uses
data-driven "redirect" messages as a form of mapping distribution.
However, it is not yet clear how the VP routers learn the mapping for
the end-user prefixes in their VP.  If this can be done in a secure,
fast and scalable fashion - then IRON may be worth considering as a
scalable routing system, at least for providing portability and
multihoming to non-mobile end-user networks.