Re: [rrg] CES & CEE: GLI-Split; GSE, Six/One Router; 2008 sep./elim. paper
Robin Whittle <rw@firstpr.com.au> Thu, 18 February 2010 02:52 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 7CD5528C0E0 for <rrg@core3.amsl.com>; Wed, 17 Feb 2010 18:52:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.267
X-Spam-Level:
X-Spam-Status: No, score=-1.267 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_43=0.6, SARE_MILLIONSOF=0.315]
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 4McjVxFZ6rss for <rrg@core3.amsl.com>; Wed, 17 Feb 2010 18:52:39 -0800 (PST)
Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id F34093A75FC for <rrg@irtf.org>; Wed, 17 Feb 2010 18:52:36 -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 928FB175BB1; Thu, 18 Feb 2010 13:54:16 +1100 (EST)
Message-ID: <4B7CABD6.9070807@firstpr.com.au>
Date: Thu, 18 Feb 2010 13:54:14 +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: <4B7545E5.2070909@firstpr.com.au>
In-Reply-To: <4B7545E5.2070909@firstpr.com.au>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Subject: Re: [rrg] CES & CEE: GLI-Split; GSE, Six/One Router; 2008 sep./elim. paper
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, 18 Feb 2010 02:52:40 -0000
Short version: "Separation" is a verb and "core" and "edge" are adjectives. The important terms: CES - Core-Edge Separation CEE - Core-Edge Elimination do not specify a subject. The above terms are meaningful and highly useful if the subject is "address", with further description of exactly what is being separated or eliminated. It is not meaningful to consider the subject to be "networks", except in one particular sense, which is unrelated to scalable routing. Obviously it makes no sense to talk of "Eliminating core and edge networks" or to eliminating the distinctions between them. The DFZ and end-user networks are already separate and will remain forever distinct and separate. The use of "network" in "Separation of the core network (DFZ) from (all) edge networks" has a specific narrow meaning which only applies to APT and is not relevant to scalable routing. The 2008 paper mentioned separation in two ways: 1 - Separation of *address space*: global unicast addresses into a new, scalable, "edge" subset with the remainder being known as "core", which includes the addresses of DFZ and other ISP routers, ITRs, ETRs and Default Mappers. But in reality, in terms of achieving all the goals of scalable routing, the "core" addresses can still include all those end-user networks which are on PA space, which don't need portability, including hundreds of millions of residential, SOHO and other end-user networks. This sense of "separation" is applies to all the CES architectures - APT, LISP, Ivip, TRRP, TIDR and IRON-RANGER - and is vital to their ability to solve the routing scaling problem. So this "address" sense of "separation" is the important one in understanding the meaning and use of the term "Core-Edge Separation". 2 - The separation of all edge *networks* from the "core". They they are already separate, but this second "network" sense of separation refers to the the prevention of packets sent from any "edge" network from arriving at the addresses of any core device: (DFZ router, other routers, ITRs, ETRs, DMs etc. This has also been referred to as: Universal division line, between "the core" and all edges which is part of the title of a subsequent message. This second sense is a long-term goal of APT, but not of the other architectures. It is not at all required for APT or any other CES architecture to be able to solve the routing scaling problem. Further to my message: http://www.ietf.org/mail-archive/web/rrg/current/msg06009.html Here are few more thoughts on the 2008 paper: Towards a Future Internet Architecture: Arguments for Separating Edges from Transit Core Dan Jen, Lixia Zhang, Lan Wang, Beichuan Zhang http://conferences.sigcomm.org/hotnets/2008/papers/18.pdf - Robin Initial CES and CEE definitions ------------------------------- In the introduction, page 1 leading into page 2, here is the initial definitions of CEE and CES. CEE: Solutions in the elimination category require that edge networks take address assignments from their providers; as a result a multihomed edge network will use multiple PA addresses internally and must modify end hosts to support multihoming. This is not at all about elimination of the distinction between of edge and core networks. It is about there being no more need for the current kind of unscalable "edge" space: PI prefixes advertised in the DFZ. Instead, all end-user networks run on one or more PA prefixes, and the new CEE arrangements - typically upgraded stack and applications, and for IPv6 only - enable the end-user networks and their hosts to achieve portability (of Identifiers), multihoming and inbound TE. "Elimination" is of a previously existing (PI) "edge" class of *address* space, and furthermore the solution of the routing scaling problem without the generation of a new subset of "edge" space, in contrast to CES architectures which do create such a new subset of scalable "edge" space. So with CEE, the "elimination" term is used in respect of *addresses*. With CES, there is a sense in which this paper refers to separation in terms of *networks* (preventing packets sent from any "edge" network from reaching any device with a "core" address), but this only applies to APT and is not important to its ability to solve the routing scaling problem. LISP and Ivip at least are CES architectures which have no such goal. None of the CES architectures need to achieve this "networks" sense of separation in order to solve the routing scaling problem. CES: Solutions in the separation category insert a control and management layer between edge networks and today’s DFZ, which we refer to as the Internet’s transit core; edge networks would no longer participate in transit core routing nor announce their prefixes into it. Neither the first or second parts of this sentence directly concern the prevention of packets flowing between devices with "core" addresses and those with "edge" addresses, which is what is meant by: Universal division line, between "the core" and all edges I write more about this in a message to follow. The first part refers to the ITRs, ETRs or whatever. The second refers to those edge networks which today advertise their PI space as prefixes in the DFZ, no longer doing so once they adopt the CES managed scalable "edge" space. The first part of the sentence doesn't refer specifically to "separation", but does involve placing something "between" "edge" networks and the (transit) "core": the DFZ. The "edge" end-user networks are already separate from the core, in that they are different, independent, routing systems and within themselves are not involved in the DFZ. Today, the only way of multihoming and "edge" end-user network is for it to have PI space (or perhaps to advertise some PA space from one ISP via another, which amounts to the same thing in terms of impact on the DFZ) and to advertise this via two or more ISPs to the DFZ, or perhaps via its own DFZ routers. So these PI-using end-user "edge" networks are placing burdens on the DFZ routing system, but they are not really part of it. They don't advertise prefixes of any other networks - if they did, then we would consider them transit providers, or ISPs. So "edge" networks are already "separate" from the DFZ. Some of them (PI-using end-user networks) advertise their own space. The rest use space from their ISPs, which they receive as "PA" space. Only the PI-using end-user networks directly drive the routing scaling problem today. But the hidden part of the routing scaling problem is the subset of the non-PI-using end-user networks which want or need portability, mulithoming and inbound TE, but can't get it. The first part of the sentence again: Solutions in the separation category insert a control and management layer between edge networks and today’s DFZ, which we refer to as the Internet’s transit core; This doesn't imply that the edge networks are not already separate from the "core". It just states that a new system is added in between them. The second part: edge networks would no longer participate in transit core routing nor announce their prefixes into it. refers to the separation of *address space* (not networks), with the edge network's space being part of an implicitly "edge" subset of the global unicast address range which is not advertised (at least directly) into the core=DFZ. In fact, to handle packets sent by hosts in non-upgraded networks, a CES architecture does need to advertise the "edge" space in the core. However, it doesn't need to advertise every such end-user "edge" prefix individually in the core. All that is needed is a "coarse" prefix (as Dino recently referred to these otherwise unnamed things in LISP) or what is known in Ivip as a Mapped Address Block (MAB). One MAB can cover thousands of individual prefixes, of thousands of different end-user networks - and so solve the routing scaling problem by burdening the DFZ with just one prefix, rather than the thousands which would be required if these were all conventional PI prefixes. There is no mention in this original definition of a "separation" between the core and all edge networks which would result in the prohibition of packets being sent from "edge" addresses to "core" addresses. For a discussion of what that might involve, please see a forthcoming message: "APT: Universal division line, between 'the core' and all edges". In the previous message in the current thread, I discussed to some extent of the goals set forth in the 2008 paper which could supposedly be achieved with this "prevention of packets from edge to core", AKA "Universal division line" approach to separating edge from core *networks*. Search for "4.3" in that message. The are titled: Rolling out new protocols DDoS mitigation Ingress traffic engineering The last of these - "Ingress traffic engineering" - does not require any particular level of adoption of a CES architecture, as long as the architecture supports all packets sent by non-upgraded hosts, which LISP, Ivip and in principle APT can do. This goal certainly doesn't depend on the "network" separation of being able to prevent "edge" hosts from sending packets to routers or other devices in the "core". The "Rolling out new protocols" goal could well be supported by widespread or perhaps universal adoption of CES by the end-user networks - but I don't see how it could rely upon prevention of edge hosts from sending packets to core routers. Likewise the paper's discussion of the "DDoS mitigation" goal (to whatever extent this loose proposal is actually feasible) could be achieved by using the mapping system and ITRs, ETRs etc. of any CES architecture, irrespective of whether "edge" hosts were prevented from sending packets to "core" routers. So I think this section 4.3, to the extent it is true (and I think third goal is definitely realistic) applies to all CES architectures in the "separation of *address space* into edge and core subsets" sense, and is not at all dependent on the "Universal division line separation of *networks* to prevent edge hosts sending packets to core routers". Likewise, in the other sections regarding "separation": 4.1 Aligning Cost with Benefits 4.2 Accommodating Heterogeneity 5. SEPARATION IS COMPATIBLE WITH MULTIPATH TRANSPORT seem to depend only on CES in terms of separating addresses into edge and core subsets, and not at all on the "Universal division line separation of *networks* to prevent edge hosts sending packets to core routers". I conclude .... I put my conclusion at the start as "Short version".
- [rrg] CES & CEE: GLI-Split; GSE, Six/One Router; … Robin Whittle
- Re: [rrg] CES & CEE: GLI-Split; GSE, Six/One Rout… Robin Whittle
- [rrg] CES & CEE: GLI-Split; GSE, Six/One Router; … Robin Whittle
- [rrg] CES & CEE: GLI-Split; GSE, Six/One Router; … Robin Whittle