[RRG] Hosts, DFZ, purity & incremental deployment

[Robin Whittle <rw@firstpr.com.au>]

Short version:    In case anyone actually doubts this . . .

                  I try to show why architectural purity of having
                  a completely independent namespace is bound to be
                  incompatible with incremental deployability in the
                  current Internet.

                  This is long and pernickety, but it still may not
                  cover every possible option.

                  In short, since we can't upgrade the entire DFZ
                  to forward packets which use the new namespace
                  in a destination address, we can't use a new
                  addressing space for location information.

                  If we used a new space for identification, that
                  would require major changes to operating systems
                  and applications on the hosts at both ends of a
                  communication - which is not incrementally
                  deployable.


In "Re: On 'jack-down' models", Victor Grishchenko wrote:

> Hypothetically, if some new **layer** of routing is able to
> a) substitute the need for "serious tools" (AS, PI addresses)
> b) eat other layers upwards and downwards
> Then you'll get both purity and incremental deployment.
> Just a counter-example.

OK - I didn't write that it couldn't be done - just that I couldn't
imagine it.

This rough diagram of the Net divides it into hosts, edge networks
(end-user networks and those parts of ISP networks which directly
support customers such as home/office DSL users) and the DFZ.

  (For an explanation of DFZ etc. search for "Newbies"
   in http://psg.com/lists/rrg/2008/maillist.html.)


  ******** = DFZ links

      ------------------                       -----------
  H--|                  |                     |           |--H
  H--|      ISP1        |*********************|   EU3     |--H
  H--|                  |*                    |           |--H
      ------------------  *********     ******|           |--H
                     *             *   *      |           |--H
                    ---------    ---------     -----------
      ----------   |         |  |         |         *
  H--|          |  |  ISP2   |**|   TP1   |    -----------
  H--|   EU1    |--|         |  |         |***|           |--H
  H--|          |  |         |   ---------    |   EU4     |--H
      ----------   |         |       *        |           |--H
                   |         |   ---------    |           |--H
                H--|         |  |         |***|           |--H
                H--|         |**|  TP2    |    -----------
                   |         |  |         |*
      ----------  *|         |   ---------  *  -----------
  H--|          |*  ---------        *       *|           |--H
  H--|          |       *            *        |   EU5     |--H
  H--|   EU2    |   ----------------------    |           |--H
  H--|          |  |                      |***|           |--H
  H--|          |**|        ISP3          |    -----------
  H--|          |  |                      |
      ----------    ----------------------
                     |  |  |  |  |  |  |
                     H  H  H  H  H  H  H


  TP1, TP3:  Transit Providers - no hosts connected.

  EU1:       Singlehomed end-user network, may be on PI address or
             PA address, may or may not use BGP - but is not part
             of DFZ because if it uses BGP, there is only one
             upstream link.   For instance a small company.

  EU2:       End-user network, such as a corporation, multihomed
             with BGP to two upstream ISPs.

  EU4, EU5, EU6:  Multihomed end-user networks, such as universities
             banks, corporations, larger companies, government
             departments etc.

In the "On jack-down models" thread, Tony Li wrote of architectural
purity, involving the introduction of an independent namespace.

I responded that the only proposals which looked incrementally
deployable to me were not "architecturally pure" by his definition.

Here is why I can't imagine any genuinely independent namespace
being incrementally deployable.

 1 - A solution which requires host changes in both communicating
     hosts is not incrementally deployable, since benefits only
     accrue to a tiny proportion of end-users (people who use hosts)
     due to the fact that initially, very few hosts have the
     upgrades.

     Eg. SHIM6 and Six/One.

 2 - A solution which provides benefits for the host which is
     upgraded, but does not require upgrades in the other host
     is incrementally deployable.

     Eg. Mobile IP, relying on all traffic from and probably
     to non-upgraded correspondent hosts going via the home-agent
     router.  (This also involves an upgrade to a router in the
     home network.)

 3 - Likewise for networks: if the networks of both hosts need
     to be upgraded before either host or network experiences a
     benefit, the scheme is not incrementally deployable.

     As with point 1, inconsistent behavior with benefits for
     communications with some correspondent hosts but not others
     could be more trouble than the benefits themselves.

 4 - If the network of one host needs to be upgraded, but not of
     the other, for the one host to experience benefits, then the
     scheme is incrementally deployable.

     I don't know of any routing and addressing scaling solutions
     of this kind.

 5 - We can't suddenly upgrade the entire DFZ, because that
     involves upgrades to all the major networks.  Any scheme
     which relies on an end-to-end upgrade of DFZ routers is
     not incrementally deployable.

     For example, Six/One Router which requires DFZ routers
     to handle IPv4 header options at full speed - but most
     do not.

 6 - The above rules out these types of solution:

     a - Upgrade both hosts.
     b - Upgrade both networks.
     c - Upgrade both hosts and networks.
     d - Upgrade the DFZ (all major networks).

 7 - This leaves the following types of solution:

     e - Upgrade only one host - if benefits accrue to
         that host when communicating with non-upgraded
         hosts.

     f - Likewise, upgrade only one network, if benefits
         accrue to that network and/or its hosts when
         communicating with non-upgraded hosts in non-upgraded
         networks.

     g - Likewise, upgrade both hosts and networks to
         achieve immediate benefits for one or probably
         both, when communicating with non-upgraded
         hosts in non-upgraded networks.

     h - Upgrade some routers in the DFZ, which support
         communications from all non-upgraded networks to
         all upgraded networks, and then upgrade some
         networks so that those networks and the hosts in
         those networks (also the end-user networks which
         connect to those upgraded networks) experience
         immediate benefits.

         Ivip, LISP with Proxy Tunnel Routers, APT and
         (I guess) TRRP fit this description.


I will now examine e, f, g and h above regarding the question of a
completely new namespace.

The new namespace must be for locating the end-point of a
communication.  If it was for identifying it, then both hosts would
need to be upgraded (operating system and applications) - so it
would not be incrementally deployable.

So how could a new namespace work with e, f, g or h?

LISP, Ivip, APT and TRRP do not use a new namespace.  They simply
use a subset of the existing IPv4 or IPv6 space for the purpose of
addressing ETRs, and leave most of the rest usable by applications
for endpoint identifiers.

This diagram depicts the upgraded host HA, its edge network, the
DFZ, the edge network of the other host and the other host, HB.

         /----------\
         |   DFZ    |

   HA---NA==========NB---HB

The DFZ routers can't all be upgraded, but it would be allowable for
a few of them to be, such as with Ivip's "anycast ITRs in the
core/DFZ" or LISP's "Proxy Tunnel Routers".  APT does the same thing
with border routers of upgraded networks advertising prefixes
containing APT-mapped address space.

  e - HA is upgraded.  It has a concept of a new namespace for
      locating itself and perhaps the other host.  But this can't
      work since NA, the DFZ and NB have no way of understanding
      packets sent by HA which involve bits which specify anything
      according to the new namespace.

  f - NA is upgraded.  Likewise, its use of a new namespace for
      locating endpoints (HA or HB) is no use because no routers
      in the DFZ or in NB understand packets with bits which use
      this namespace.

  g - HA, NA and perhaps some DFZ routers are upgraded.  The same
      problem.

  h - NA and some DFZ routers are upgraded.  The same problem as
      for f - NB and HB doesn't understand the new types of
      packets which include bits which use the new namespace.


Point 5 is the key to all this.

  An upgrade to every DFZ router is not incrementally deployable.

  We need the DFZ routers to get packets from any one host to any
  other host.

  The non-upgraded DFZ routers can't handle any packets which
  use the new namespace.

  So no amount of work in the hosts or networks which use a new
  namespace will result in the ability to send packets from any
  such host and network to any other such host or network.

Introducing multihoming and portability on an incremental basis,
without directly involving BGP, involves allowing existing host
applications and potentially upgraded host operating systems on one
end (not both) to communicate in new ways.

Since this involves the DFZ, since we can't upgrade the entire DFZ
to handle packets which use a new namespace and since incremental
deployability means benefits must accrue to early adoptors, a fresh
namespace for location is not incrementally deployable, since the
DFZ can't handle the packets.

  - Robin


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg