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