[rrg] CES & CEE are completely different (graphs)
Robin Whittle <rw@firstpr.com.au> Mon, 01 February 2010 13:36 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 8691D28C180 for <rrg@core3.amsl.com>; Mon, 1 Feb 2010 05:36:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.939
X-Spam-Level:
X-Spam-Status: No, score=-0.939 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_05=-1.11, 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 zPT6heZ90+pc for <rrg@core3.amsl.com>; Mon, 1 Feb 2010 05:36:16 -0800 (PST)
Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 5BBFC28C1AD for <rrg@irtf.org>; Mon, 1 Feb 2010 05:32:59 -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 C519D1759F8; Tue, 2 Feb 2010 00:33:32 +1100 (EST)
Message-ID: <4B66D829.4070502@firstpr.com.au>
Date: Tue, 02 Feb 2010 00:33:29 +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: <20100130184020.9C7AB6BE556@mercury.lcs.mit.edu> <4B6481A0.3020109@joelhalpern.com>
In-Reply-To: <4B6481A0.3020109@joelhalpern.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Noel Chiappa <jnc@mercury.lcs.mit.edu>
Subject: [rrg] CES & CEE are completely different (graphs)
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: Mon, 01 Feb 2010 13:36:18 -0000
Short version: CES architectures are completely different from CEE architectures - and CES is very much superior to CEE. There are no proposals which combine elements of both. I argue in a companion message: Today's "IP addr. = ID = Loc" naming model should be retained that the current 2-level naming structure - in which the IP address performs the roles of both Identifier and Locator - is superior to the CEE Loc/ID separation approach in which these roles are played by two different objects, in different namespaces. While CEE makes life easy for the routing system, it burdens all hosts with extra work, extra traffic and extra delay just to establish almost any communication session. CES is superior to CEE because it maintains the current naming system. CES is also much easier to adopt than CEE. CES provides immediate full benefits to all adoptors - and provides routing scaling benefits in direct proportion to the level of adoption. CEE only provides substantial benefits to adopters - or significant scaling benefits - after all, or almost all networks have fully adopted it. This means upgrading essentially every host stack and rewriting essentially every application to use the new CEE Identifier-based method of communication. Hi Joel, In "Re: [rrg] Multiple critiques, choice of single proposal, ..." (msg05846) you wrote: > If someone wants to add text on Identifier / Locator separation as a > useful architectural principle, I guess I can't object. Do you mean Core-Edge Elimination (CEE) or Core-Edge Separation (CES)? Please see this recent message for my concerns about how this term means different things to different people: Terminology: Loc/Id sep., LISP, CEE & CES, namespace http://www.ietf.org/mail-archive/web/rrg/current/msg05858.html > And I consider the CEE / CES debate to be missing the point. I completely disagree. These are both capable of solving the scaling problem, but they are completely different approaches with completely different costs and methods of achieving their goals. A CES architecture (LISP, APT, Ivip, TRRP, TIDR or RANGER): 1 - Maintains the current 2 level naming arrangement - where the FQDN is performs the "Text name" role and the Identifier and Locator roles are both performed by the IP address. Role Level Conventional IP & with CES Text name <---- FQDN Identifier <---] IP address Locator <---] 2 - Scalable routing is achieved by creating an "edge" subset of the global unicast address range - the remainder of which is known as the core. The "edge" addresses are all covered by DFZ-advertised prefixes, but these are few in number, since each such prefix (a MAB - Mapped Address Block in Ivip) covers a large number of "edge" addresses. This means the "edge" addresses are not much of a burden on the DFZ control plane - and do not add much to the numbers of routes to handled by the RIBs and FIBs of DFZ routers. A new set of network elements - ITRs, ETRs and a mapping system - handle all packets addressed to an "edge" address - by tunneling them across the DFZ to an ETR, which is always on a "core" address. This is done in a way which supports the portability, multihoming, inbound TE and ideally mobility needs of end-user networks of all sizes. Furthermore, this system enables the edge space to be divided much more finely than is possible with the DFZ, since with the IPv4 DFZ at least, there is a widely supported convention not to propagate prefixes longer than /24. Ivip and LISP can divide "edge" space down to single IPv4 addresses. Ivip for IPv6 manages "edge" space in units of /64. 3 - Requires no change to host stacks, APIs or applications. (Nonetheless, in Ivip the ITR function can optionally be implemented in the sending host.) 4 - Does not affect most internal and DFZ routers, but requires the new ITR and ETR functions to be performed in new devices and/or existing routers. 5 - Provides benefits for adoptors immediately - full portability, multihoming, inbound TE and ideally mobility benefits to each adoptor, irrespective of how many other networks have adopted it: ^ B |********* Core-Edge Separation (CES) e |********* n |********* e |********* f |********* i |********* t |********* |********* |********* 0---------> Effort ~= level of adoption 6 - Provides routing scaling benefits in direct proportion to how widely it is adopted, by two mechanisms. Firstly, more end-user networks get the portability, multihoming etc. they want/need. Secondly, they get these benefits without significant load on the DFZ. This will lead to some reduction in the number of PI prefixes in the DFZ as current PI-using networks adopt the CES architecture. PI-using networks could either convert their PI prefixes to "edge" space and being able to use this space more flexibly, in finer slices - or they could relinquish their PI space and rent some "edge" space. Since "edge" space can be more finely divided, they probably don't need as much of it as with PI space, for which the finest chunk is /24. ^ B | * Core-Edge Separation (CES) e | ** n | *** e | **** f | ***** i | ****** t | ******* | ******** |********* 0---------> Effort ~= level of adoption A CEE architecture (ILNP, GLI-split, Name Based Sockets, HIP etc.): 1 - Changes the current naming arrangement so there are separate objects, with separate namespaces, for the Identifier and Locator roles. I think most CEE approaches use 3 levels - FQDNs for the "Text names", and separate levels to perform the Identifier and Locator roles. In some CEE architectures such as ILNP, the lower part of the IPv6 address performs the Identifier role and the upper part of performs the Locator role. Role Level Some CEE architectures such as HIP Text name <---- FQDN Identifier <---- HIT Locator <---- IPv6 address Role Level Some CEE architectures such as ILNP Text name <---- FQDN Identifier <---- IIII IIII } Combined into Locator <---- LLLL LLLL } one IPv6 address I don't yet fully understand Name Based Sockets, but it has a naming structure something like this. In practice, I think the Identifier role may be performed by a combination of Identifier and Locator, so a single text FQDN can be used with "round-robin DNS" to select one of several separate hosts, each of which must have a separate Identifier. Role Level Name Based Sockets? Text name <---] FQDN Identifier <---] Locator <---- IPv6 address 2 - Scalable routing is achieved by applications no longer being dependent on stable IP addresses for session continuity. This is because they use an Identifier to determine the host to which each communication session is established and maintained. The CEE stack figures out which of potentially multiple Locators to use, and Locators can usually be added to and deleted from the set of allowable Locators for any one Identifier, as the session continues. Identifiers are portable. Multihoming is achieved by the stack managing multiple Locators to continue the session if the end-user network becomes unreachable by the currently used Locator. Inbound TE is achieved by which Locator is used in outgoing packets - since in general the other host will send packets back to this host using the Locators this host most recently used in outgoing packets. Mobility is achieved by doing all this, and maintaining sessions, despite frequent, ad-hoc, changes of Locators. When (almost) all a network's hosts are having (almost) all their communications occurring with the new CEE arrangement, then portability, multihoming and ideally mobility can be provided just as well on PA prefixes as on PI. At this point the routing scaling benefits finally occur - all networks can do portability multihoming etc. Those which used to do these things via conventional PI space no longer need this PI space. 3 - Before there can be substantial scaling benefits, all host stacks and all applications must be upgraded to use the CEE "Loc/ID separation" naming structure. 4 - Requires no changes to internal of DFZ routers. There is typically a need for a new mapping system by which hosts can look up an Identifier and receive the one or more Locators that host is using. (Name Based Sockets uses the existing DNS.) 5 - Provides portability, multihoming, inbound TE and ideally mobility benefits to each adoptor, in proportion to how many other networks have adopted it. This is because the CEE host and its CEE applications can only provide these benefits when communicating with other CEE applications in other CEE hosts. (A good CES system provides these benefits to packets sent by all hosts, including those in networks without the CES's ITRs.) For an adoptor (assuming their hosts communicate, in general, with a mix of hosts in all other networks), the proportion of communications with the benefits (portability, multihoming, TE and ideally mobility) increases linearly with the level of adoption. However, for most networks, I think it is fair to say that they only get real usable benefits when all, or nearly all, of their communications are using the new system. Only then can their network be fully portable and multihomed without the need for PI space. ^ 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 6 - Provides routing scaling benefits in two forms: A - When most or all networks which have PI space can abandon it and use PA space instead. This is when (almost) all of their communications use the new system - which is when (almost) all other networks have fully upgraded all their host stacks and all their applications. B - When those without PI space have all, or almost all of their communications using the new system, for the same reasons as above. In both cases, the curve is: ^ B | * Core-Edge Elimination (CEE) e | * n | * e | * f | * i | * t | * | * | * 0---------> Effort ~= level of adoption CES and CEE are *completely* different ways of solving the routing scaling problem. I think everyone agrees that a good CES architecture is easier to introduce on a voluntary basis than any CEE architecture, since the adopting networks get full benefits immediately, don't need to alter their host stacks, or require upgraded versions of their applications. I think many people believe that the final state of the Internet with good CEE architecture is a better than could be achieved with the best CES architecture. I think this is because of two interdependent beliefs: 1 - The routing system should be kept simple, if there is any way hosts can be changed to achieve this. 2 - The current 2 level IP naming structure - making the IP address perform both the Identifier and Locator roles - is architecturally flawed and should be fixed to make these independent levels, each with a different namespace. The practical benefits of this are largely that the routing system can be made to scale well, while remaining as simple as it is today. The hosts themselves, with the aid of an Identifier -> Locator mapping system, will do all the portability, multihoming, TE and mobility work themselves. I disagree with this viewpoint. I think the routing system should serve the hosts - and that it will be easier to upgrade the routing system to make it scalable with a CES architecture, than to upgrade all hosts and all their applications to implement CEE. I think the current 2 level IP naming structure is better than the Loc/ID Separation CEE approach, as explained in the companion message. Here is my understanding of the arguments for why CEE is the best long-term arrangement for the Internet: 1 - Adding new network elements (as are required by CES) is inefficient, expensive and contrary to the principle of keeping the network simple and elegant, while implementing as much of the total functionality of the Net in the hosts. Host CPU power is inexpensive. Host software can be upgraded without the need to buy new hardware or establish the commercial mechanisms for building and running the ITRs, ETRs and mapping system which is required for CES. 2 - The current IP naming model is fundamentally broken, because it makes the one object - the one level of a 2 level system - the IP address, play the roles of both Identifier and Locator. This is architecturally wrong and it makes it difficult or impossible to create a routing system which support large numbers of end-user networks with portability, multihoming, inbound TE and mobility. The right way (as Tony would say) to do it is to create new protocols so all hosts communicate with the use of independent Identifiers and Locators. Here are my arguments for why CES is superior to CEE: 1 - While CES involves adding significant new things to the routing system, this is a lot easier than upgrading all host stacks rewriting all applications. CES early adopters get full benefits, no matter how many other networks adopt it. So a CES is far easier to have adopted at all, and then to have fully adopted, than any CEE architecture. While a CES architecture needs a mapping system, so do most CEE architectures. The CES mapping system is arguably more efficient and so can be less costly than that of a CEE mapping system because: a - The CES mapping system is only used by ITRs - and each ITR caches the mapping and will frequently use the same mapping to support the communications of multiple hosts. b - A CES mapping lookup is only required at the start of communications sessions where the destination address is in the "edge" subset. Even if CES is adopted by all end-user networks which want or need portability, multihoming etc. there will still be a large number of hosts using PA space. This includes almost all home, SOHO and small commercial customers who are doing fine, and will continue to be happy with, their one IPv4 (or later an IPv6 /64) of PI space. A CEE lookup is needed by both the initiating and responding hosts for almost all new communication sessions. The only exceptions are where the responding host - such as a DNS server - doesn't care if the packet it sends goes to a host which has a different Identifier to that used in the request packet. CEE can't be useful for IPv4, since multihoming a /18 network would require a /18 of PI space from one ISP and another /18 from another ISP. So it would at least double address consumption. CEE can't work with hosts behind NAT. Ideally NAT won't be used with IPv6, but this cannot be assured. There is another difficulty which I foresee, which I don't think has been discussed much - how a CEE copes with a host which has one or more Locators on global unicast space and one or more locators on one or more private address spaces. Global unicast Locators can be used to communicate with other global unicast Locators - but not private Locators. Two hosts with Locators in the same private network space can use them to communicate. This would probably be preferred over using the global unicast Locators. The CEE stack and the various protocols between hosts will need to cope with the various complications which arise from this. CEE hosts may need to inform a very large number of other hosts they are communicating with if they adopt a new Locator and stop using another. This information also needs to be securely uploaded into the DNS and into the Identifier -> Locator mapping system. This is a lot of work, particularly for hosts on slow links which are subject to congestion and packet loss due to radio difficulties. IPv6 addresses can have their lower 64 bits frequently changed in order to make it difficult for anyone outside the network to trace activity, such as to web servers, to individual computers - and so by implications to individual people. However, to be able to do this with CEE would also involve each such host changing its Identifier as well. This could be done, but it involves the creation and deletion of state in the public global DNS and Identifier -> Locator mapping systems. This would be onerous and may compromise the privacy benefits of the technique. For CEE architectures in which the lower 64 bits of an IP address is the Identifier and where Identifiers must be globally unique, then this means the randomization of Identifiers can only be within a range restricted by whatever range of Identifier space the network has been allocated. 2 - While CEE does involve a simpler network, this benefit is far to slight to make up for greater effort hosts must make when beginning new sessions. Please see the companion message: Today's "IP addr. = ID = Loc" naming model should be retained for more details. This is particularly the case for the future, in which most hosts will be running continually from small batteries and will generally rely on 3G or similar wireless links. So while both CES and CEE architectures can both, in principle, solve the routing scaling problem, they do so in completely different ways, involve completely different adoption hurdles and result in completely different host protocols in the final system. > Firstly, many of the solutions and not purely one or the other. As Noel > has observed, one can migrate LISP (ostensibly a CES solution) into the > host. Whether or not this is done, LISP remains entirely a CES architecture. Just because a LISP MN can be its own ETR and ITR doesn't mean that LISP in any way resembles a CEE system. The ITR and ETR functions in such a host would be simple additions to th the stack. The IP stack, its API and all applications would remain unchanged. The two-layer IP naming structure remains unchanged. > Architecturally, and in terms of the end state, I think that CEE is a > much better target. I hope you will respond to my arguments to the contrary. > In terms of deployability and related issues, CES techniques tend to > have a big advantage. Yes. > Hence, I have a personal preference for solutions which straddle this > boundary, What are these? I don't know of any such solutions. > rather than seeing utility in arguing about which one we want. There are huge differences between CEE and CES architectures. > And I don't the the RG has a clear agreement on this at all. Not yet. - Robin
- [rrg] Multiple critiques, choice of single propos… Robin Whittle
- Re: [rrg] Multiple critiques, choice of single pr… Joel M. Halpern
- Re: [rrg] Multiple critiques, choice of single pr… Joel M. Halpern
- Re: [rrg] Multiple critiques, choice of single pr… John E Drake
- Re: [rrg] Multiple critiques, choice of single pr… Dino Farinacci
- Re: [rrg] Multiple critiques, choice of single pr… Robin Whittle
- [rrg] Include constraints due to the need for wid… Robin Whittle
- Re: [rrg] Multiple critiques, choice of single pr… Noel Chiappa
- Re: [rrg] Multiple critiques, choice of single pr… Noel Chiappa
- Re: [rrg] Multiple critiques, choice of single pr… Joel M. Halpern
- [rrg] Widespread involuntary adoption Brian E Carpenter
- Re: [rrg] Multiple critiques, choice of single pr… Tony Li
- Re: [rrg] Multiple critiques, choice of single pr… Flinck, Hannu (NSN - FI/Espoo)
- Re: [rrg] Multiple critiques, choice of single pr… Tony Li
- Re: [rrg] Multiple critiques, choice of single pr… Lixia Zhang
- Re: [rrg] Multiple critiques, choice of single pr… Robin Whittle
- Re: [rrg] Multiple critiques, choice of single pr… Noel Chiappa
- Re: [rrg] Multiple critiques, choice of single pr… Patrick Frejborg
- [rrg] CES & CEE are completely different (graphs) Robin Whittle
- [rrg] SIP will work fine with CES, CEE won't work… Robin Whittle
- Re: [rrg] Multiple critiques, choice of single pr… Joel M. Halpern
- Re: [rrg] Multiple critiques, choice of single pr… Scott Brim
- Re: [rrg] Multiple critiques, choice of single pr… Scott Brim
- Re: [rrg] Multiple critiques, choice of single pr… Noel Chiappa
- Re: [rrg] Multiple critiques, choice of single pr… Joel M. Halpern
- Re: [rrg] Multiple critiques, choice of single pr… Scott Brim
- Re: [rrg] Multiple critiques, choice of single pr… Scott Brim
- Re: [rrg] Multiple critiques, choice of single pr… Mark Handley
- Re: [rrg] SIP will work fine with CES, CEE won't … Patrick Frejborg
- Re: [rrg] SIP will work fine with CES, CEE won't … Robin Whittle
- Re: [rrg] SIP will work fine with CES, CEE won't … Patrick Frejborg
- Re: [rrg] SIP will work fine with CES, CEE won't … Robin Whittle
- Re: [rrg] SIP will work fine with CES, CEE won't … Patrick Frejborg
- Re: [rrg] Multiple critiques, choice of single pr… Lixia Zhang
- Re: [rrg] Multiple critiques, choice of single pr… Scott Brim