Subject: [rrg] ID / Loc trouble - is the fundamental problem in the hosts?

From: Robin Whittle <[email-masked]>
Date: Tue, 25 Nov 2008 15:34:32 +1100

Hi Tony,

In:
   Re: Fundamental objections to a host-based scalable
   routing solution
   http://www.irtf.org/pipermail/rrg/2008-November/000266.html

You wrote, quoting Eric Fleischman:

>| My personal belief is that I'd like us to converge soon on a
>| routing-only solution. I think that it is time to begin to wrap
>| the theoretical discussions up and proceed to modeling and
>| simulation and limited deployment experimentation.  Failing
>| that, I would like to better understand why the RRG community
>| hasn't yet converged on the desirability of map-and-encaps as a
>| desirable RRG vector.
>
> There is a portion of the community (significant, IMHO) that feels
> that there are significant drawbacks to the map-&-encap strategy.
> While I can't claim to represent all of them or even a significant
> breadth of their opinions, there are some issues that have been
> raised.
>
> - Map-&-encap doesn't solve the problem where it truly occurs: at
> the host. The convolution of locator and identifier happens
> precisely because the transport layer has reused the address as
> part of the connection identifier. Until we change this, we're
> simply band-aiding around the problem.  And band-aids really
> aren't the way to create a lasting architecture.  Please note that
> this also implies that routing-only solutions aren't the correct
> direction.

I understand your last sentence means that souping up BGP to cope
with arbitrary numbers of PI addresses would not be the correct solution.

I think there are at least two interpretations of this ID / LOC question.

  1 - The routing system forwards packets according to a LOC
      address.

      Due to outages in links between ISPs and multihomed end-user
      networks, (TE too?) and due to choices of different ISPs etc,
      the physical location of an end-user network's connection to
      the core changes from time to time.

      Therefore, to keep a session going, the LOC sometimes has
      to change for packets in a given session.

      With current protocols, host stacks and applications, hosts
      use the ID address as an ID for other hosts, and for
      themselves, and create sessions based entirely upon this
      ID address.

      So far, no problem.

      The problem is that the routing system and the hosts both
      use the one thing for both purposes - the "IP address".

      Therefore, since we can't or don't want to change the
      routing system, we should change the protocols, host
      stacks and applications so that hosts and their sessions
      are identified by some ID thing which is separate from
      what the routing system uses (a LOC) for forwarding
      packets.

  2 - At present, Internet protocols use a single thing - the
      IP address - for identifying hosts, for establishing and
      continuing sessions and for forwarding packets.

      While we could change hosts as described above, there
      are objections to this on grounds of extra traffic, extra
      complexity, extra dependence on fast, reliable carriage of
      this extra traffic etc.

      So we could say that the problem is in the hosts as noted
      above, and also in the slow, costly, unreliable links they
      operate over which make it impractical to solve the problem
      by changing host stacks and applications so they separate ID
      and LOC.

      Restating this: We could say the problem is that hosts don't
      all have arbitrary CPU and RAM resources, and that they don't
      all have the fast, 100% reliable, global, communications
      needed to implement host-based multihoming, such as with an
      effective ID / LOC split implemented in the stack, with all
      applications using a hostname based API.

      Instead, we say the problem is in the routing system which
      can't cope with the very large numbers of separately
      advertised prefixes and the changes to where packets addressed
      to each prefix should be forwarded to, which result from the
      current use of IP address for both LOC and ID purposes.

      Therefore, since we think pushing the solution to the hosts
      has serious problems, we resolve to revamp the routing system
      in the DFZ, and in ISPs, to the end-user networks' CE routers,
      to cope with the current usage of IP addresses.

      One way to do this is for the routing system to dynamically
      generate and attach a LOC to all packets being sent to end-user
      networks, and then to forward the packets to those networks
      based on this LOC, rather than the IP address.

      This is the approach of the core-edge separation schemes:
      LISP, APT, Ivip, TRRP and Six/One Router.

I like the second view.  I support the existing division of labour
between:

    1 - Hosts and all but the CE routers in end-user networks.
        (Thanks Noel for prompting me to add these routers.)

    2 - The routing system: the DFZ, the ISP's network, the PE
        routers of the ISP and the CE routers of the end-user
        networks they connect to.

I think the routing system should rise to the occasion, give hosts
and most of the end-user network what they have already - stable IP
addresses - and handle mulithoming, TE and portability within the
core of the network, with some involvement of the end-user network's
CE routers.

I will respond to your critiques of map-encap in a separate message.

  - Robin

_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg