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

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

Hi Robin,

A few comments below:

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Robin Whittle
> Sent: Wednesday, March 10, 2010 4:55 PM
> To: RRG
> Cc: Ran Atkinson; Scott Brim
> Subject: Re: [rrg] Why won't supporters of Loc/ID Separation (CEE)argue their case? (Summary of
> differences)
> 
> 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.

I am convinced that IRON-RANGER solves the scaling problem,
but I will work on some additional scaling analysis to also
convince you and other readers.

>   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).

IRON-RANGER used to speak of using IPv6 neighbor discovery
as the means for locator liveness testing, dissemination
of routing information, secure redirection, etc. However,
the VET and SEAL mechanisms are being revised to instead
use a different mechanism called the SEAL Control Message
Protocol (SCMP) for tunnel endpoint negotiations that occur
*within* the tunnel sublayer and are therefore not visible
to either the outer IP protocol nor the inner network layer
protocol. Hence, the inner network layer protocol could be
anything, including IPv4, IPv6, OSI CLNP, or any other network
layer protocol that is eligible for encapsulation in IP.

>   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.

IRON-RANGER calls them as ITEs/ETEs because it is possible
to also configure a tunnel endpoint on a host and not just
on routers. In terms of routers, the IRON-RANGER ITE/ETE
are exactly equivalent to what the other proposals are
calling as ITR/ETR.

Thanks - Fred
[e-mail]

> 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
> 
> _______________________________________________
> rrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/rrg