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