Re: [rrg] Why won't supporters of Loc/ID Separation (CEE) argue their case? (Summary of differences)

Robin Whittle <rw@firstpr.com.au> Thu, 11 March 2010 00:55 UTC

Return-Path: <rw@firstpr.com.au>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C11143A69F5 for <rrg@core3.amsl.com>; Wed, 10 Mar 2010 16:55:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.842
X-Spam-Level:
X-Spam-Status: No, score=-1.842 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJNsBV0yHdmS for <rrg@core3.amsl.com>; Wed, 10 Mar 2010 16:55:05 -0800 (PST)
Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 188193A63EC for <rrg@irtf.org>; Wed, 10 Mar 2010 16:55:05 -0800 (PST)
Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 5E041175DD8; Thu, 11 Mar 2010 11:55:09 +1100 (EST)
Message-ID: <4B983F70.9010501@firstpr.com.au>
Date: Thu, 11 Mar 2010 11:55:12 +1100
From: Robin Whittle <rw@firstpr.com.au>
Organization: First Principles
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: RRG <rrg@irtf.org>
References: <C7B9BCE8.4FA7%tony.li@tony.li> <4B94D6EA.3000800@firstpr.com.au> <4B97D602.6050303@gmail.com>
In-Reply-To: <4B97D602.6050303@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Ran Atkinson <rja@extremenetworks.com>, Scott Brim <scott.brim@gmail.com>
Subject: Re: [rrg] Why won't supporters of Loc/ID Separation (CEE) argue their case? (Summary of differences)
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Mar 2010 00:55:06 -0000

Short version:   It seems I have been unable to tempt people to
                 read and respond to msg05865, so here are the
                 distinguishing points between Core-Edge Elimination
                 and Core-Edge Separation architectures as briefly
                 as they can be mentioned.


Hi Scott,

You wrote:

>> Other people think it is an important and meaningful distinction.  To
>> see why I think it is architecturally important please see the
>> messages I link to in msg06187.  My attempt to trace the history of
>> the terms and to discuss some ambiguities in what is being
>> "separated" in Core-Edge Separation can be found in msg06110.
> 
> CES/CEE is a useful dimension for comparison but (1) it's not binary,
> despite our wishes, and (2) there are other dimensions that are also
> important.  We just couldn't figure out how to use them for effective
> comparisons.  See the various taxonomy attempts.

I am not suggesting that all proposals are either CES or CEE.  In
msg06219, after listing the "mapping only" proposals, I wrote that
these three were neither CES or CEE:

   hIPv4
   Name overlay (NOL)
   Evolution - Aggregation with Increasing Scopes (AIS)

I don't think any of these can achieve the scaling benefits we need
for, say 10^7 non-mobile end-user networks and 10^9 to 10^10 mobile
devices.

The four CEE proposals are:

   GLI-Split
   ILNP - Identifier-Locator Network Protocol
   Name-Based Sockets
   RANGI

The four CES proposals are:

   IRON-RANGER
   Ivip
   LISP
   TIDR

There is a very clear distinction between these two sets.  Please see

   CES & CEE are completely different (graphs)
   http://www.ietf.org/mail-archive/web/rrg/current/msg05865.html

for a complete explanation of the following summary.

All the CEE architectures, in order to achieve substantial benefits
to adoptors and to scalable routing have these in common.

  1 - All CEE architectures require all hosts to use the Locator /
      Identifier Separation naming model.  (Not just hosts in
      end-user networks which want portability, multihoming and
      inbound TE.)

  2   All CEE architectures require changed stacks.  Some also
      require changed applications.  Those which support unmodified
      IPv6 applications are pretty dodgy, I think - because these
      applications assume that the IP addresses they deal with are
      both identifiers and locators, and that when sending a packet
      to a host with a given IP address, the routing system will
      never deliver it to any other host than the one with this IP
      address.

  3 - CEE architectures are only practical for IPv6, for multiple
      reasons but always including the fact that CEE requires each
      multihomed end-user network to use at least twice the number of
      addresses (host locators) from the global unicast address
      space.  Each of its ISPs needs to provide the number of
      addresses the network needs.

  4 - So these architectures can't use IPv4 applications or IPv4
      stacks.  They use either IPv6 applications or require
      rewritten versions of these.  Some apps would require a minor
      rewrite and some would require a lot more work, including in
      some cases a major change to the actual protocols the app
      uses.

  5 - All CEE architectures require hosts to do more work - including
      typically both hosts in an initial communication establishment
      doing ID->Loc lookups via global mapping systems with one or a
      few authoritative servers.  Such lookups are likely to be slow
      and involve higher risks of lost packets.

      This will typically delay the establishment of all
      communication sessions.  The delays and the burdens on hosts
      are worse for devices relying on slow, potentially unreliable,
      links such as 3G - so the new burdens are especially bad for
      many mobile devices.

  6 - Some CEE architectures require sending longer packets between
      hosts.

  7 - Have a really undesirable relationship between adoption levels
      and substantial benefits to adopters (all, or almost all of
      their communications have the benefits of portability,
      multihoming and inbound TE).

           ^
         B  |        *      Core-Edge Elimination (CEE)
         e  |       .*
         n  |      ..*      .  Proportion of communications
         e  |     ...*         with the benefits.
         f  |    ....*
         i  |   .....*      *  Actual total benefits generally
         t  |  ......*         only arise when all, or almost
            | .......*         all, communications have the
            |........*         benefits.
            0--------->
              Effort ~= level of adoption

  8 - As a result of the above, only produce substantial scaling
      benefits after all, or nearly all hosts adopt it:

            ^
         B  |        *      Core-Edge Elimination (CEE)
         e  |        *
         n  |        *
         e  |        *
         f  |        *
         i  |        *
         t  |        *
            |        *
            |        *
            0--------->
              Effort ~= level of adoption

  9 - While no CEE architecture involves tunneling, some involve
      routers rewriting Locators of packets and some involve "split-
      horizon" DNS tricks.  AFAIK (and I haven't yet read all the
      responses to my CEE critiques) none of them appear to be
      suitable for use with ULA addresses.

Whether or not any of these CEE architectures would work as intended
I am not yet sure.  If they did work as intended, they could
certainly solve the routing scaling problem in terms of portability,
multihoming and inbound TE for non-mobile networks.  I do not believe
any of them are suitable for providing mobility.


CES architectures have these features in common, assuming they could
actually work and solve the scaling problem, which is not true of
TIDR - and which I am not yet convinced is true for IRON-RANGER.

  1 - No changes to the current naming model, in which the IP address
      plays the roles of both Identifier and Locator.

  2 - Therefore, requires no changes to host stacks or applications.

  3 - Works fine with IPv4 and IPv6 (for Ivip and LISP at least - I
      think some of IRON-RANGER is IPv6-specific).

  4 - LISP and Ivip at least can support the TTR Mobility
      architecture and so provide scalable mobility - for both IPv4
      and IPv6, without changes to host stacks (except for extra
      tunneling software in the MN).

  5 - Do not require hosts to do more work.  Significant extra delays
      at one or both ends of a communication establishment will
      sometimes, perhaps frequently, occur with LISP-ALT - due to
      ITRs dropping packets until they receive mapping information
      via the ALT global query system.  Ivip with DRTM typically
      involves insignificant delays since authoritative query servers
      are "nearby".  (See draft-whittle-ivip-drtm.)

  6 - With LISP's PTRs and Ivip's DITRs, adopters get full benefits
      of portability, multihoming and inbound TE for all their
      communications irrespective of the level of adoption:

            ^
         B  |*********      Core-Edge Separation (CES)
         e  |*********
         n  |*********
         e  |*********
         f  |*********
         i  |*********
         t  |*********
            |*********
            |*********
            0--------->
              Effort ~= level of adoption

  7 - Because of this, substantial scalable routing benefits accrue
      in direct proportion to the level of adoption:

            ^
         B  |        *      Core-Edge Separation (CES)
         e  |       **
         n  |      ***
         e  |     ****
         f  |    *****
         i  |   ******
         t  |  *******
            | ********
            |*********
            0--------->
              Effort ~= level of adoption

  8 - Apart from Ivip's Modified Header Forwarding arrangements,
      CES architectures involve encapsulation for tunneling packets
      from ITRs to ETRs (IRON-RANGER doesn't have ITRs and ETRs, but
      it still requires encapsulated tunneling).  There are some
      problems with this - but they do not appear to be prohibitive.

What other dimensions can you suggest?

The above dichotomy seems to be significant in many respects,
starting with the basic architectural question of whether hosts
retain the currently used naming model, which saves hosts a lot of
work and results in communication establishment without lookups - or
whether hosts (all hosts) are required to adopt Locator / Identifier
Separation.

Do you think the above CEE/CES distinctions are invalid or
unimportant?  The all look really important to me.

None of the people who have dismissed the architectural or practical
importance of the CEE/CES distinction have explained their reasoning
in any way.  To do so, I think they should argue against the
distinctions listed above.

  - Robin