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