Short version:  I am replying to messages from Tony Li, Elliot Lear,
                Scott Brim and Joel Halpern.

                An attempt to find the earliest use of "Core-Edge
                Separation" and "Core-Edge Elimination" (search for
                "Jari" below).  These seem to have arisen in July
                2008, with Dan Jen and colleagues.

                Eliot has joined Joel, Lixia and Ran in stating that
                they believe the CES / CEE distinction to be
                unimportant and/or not architectural.  None of them
                have yet explained why they believe this.

                Tony and Noel wrote that they think "CEE" means
                anything that is not "CES".  However, they don't
                say why they think "CEE" is being used in this way.



Tony wrote, quoting Noel:

>> Someone pointed out to me that although I've been using the
>> terms CEE and CES as synonomous for the terms 'host-centric' and
>> 'edge-centric' (and 'network-centric' completes the list), that
>> for others they seemingly aren't exactly synonomous, but subtly
>> different.
>>
>> Can someone confirm this, and explain what the differences are?
>>
>> I'll be using 'host-centric', etc from now on. My apologies if I
>> have inadvertently caused any confusion by using them as
>> synonyms for 'host-centric' and 'edge-centric'.
>
> To me, CES seemed to be 'map-and-encap' and CEE was 'everything
> else'.

A number of people regard CES as a better term for the architectures
previously known as "map-and-encaps".  I certainly prefer it because
Ivip, in the long-term at least, will not use encapsulation to tunnel
packets from ITRs to ETRs.

A number of people think CEE is a better term for those architectures
which implement "Locator / Identity Separation" in order to provide
portability, multihoming and inbound TE in a scalable fashion.

Can you point to an instance of someone stating that CEE is "not-CES"?

There are other potential solutions to the scaling problem, such as
replacing BGP and the DFZ with something which can happily handle
millions or billions of mobile and non-mobile PI prefixes.  It so
happens that no-one has proposed this - because everyone believes it
to be impractical.

If you read:

  CES & CEE are completely different (graphs)
  http://www.ietf.org/mail-archive/web/rrg/current/msg05865.html

you will understand my arguments for why the CES / CEE distinction is
architectural and important.  You will see why I believe CEE doesn't
mean "everything but CES".


> While that's certainly a distinction, it's clearly not the only
> one and perhaps not the optimally constructive one.

I think you are referring to Noel's mention of
host-/network-centricity.  I agree this is not the most important
difference between the two classes of architecture,


To me, the importance of the CES / CES distinction is very largely
based on the distinction between retaining the current 2 level IP
naming model (which CES does), or adopting the Locator / Identity
Separation model, which is all CEE architectures do.

I would really appreciate you writing about your agreement or
disagreement with my value judgements about this distinction:

  Today's "IP addr. = ID = Loc" naming model should be retained
  http://www.ietf.org/mail-archive/web/rrg/current/msg05864.html


The CES / CEE choice is the first on in my list of architectural
choices for Ivip:

  http://tools.ietf.org/html/draft-whittle-ivip-arch-03#section-4

I am keen to know your reasons for agreeing or disagreeing with my
architectural choices.


Eliot, replying to Ran's (msg05940), you wrote:

> +1.

So now you, in addition to Joel, Lixia and Ran, have stated on the
list that you think the CES / CEE distinction to be unimportant.

None of you have written why.  I would really appreciate you writing
about why you disagree with:

  CES & CEE are completely different (graphs)
  http://www.ietf.org/mail-archive/web/rrg/current/msg05865.html


Ran, you wrote, quoting Noel:

>> ...[the term CEE/CES] tells you whether one needs to modify hosts
>> or not.
>
> I don't believe that is necessarily true. Others seem to agree
> with me.

It is an observation that all architectures which are of the CEE type
require host changes, because they all require that all hosts and
applications adopt the "Locator / Identifier Separation" naming model.

It is an observation that all CES architectures so far proposed do
not require any host changes.

I am unclear about whether Aggregation with Increasing Scopes and
hIPv4 can be classified as one of these or the other, because I
haven't read them yet.

The following proposals are definitely CES:

   LISP, Ivip, ILNP, RANGER.

The following are definitely CEE:

   ILNP, Name Based Sockets.

While I have not yet read them, I understand that these are also CEE
architectures:

   GLI-Split, NOL (Name Overlay), RANGI.

You say that you don't believe it is necessarily true that a CEE
architecture requires host changes and that a CES architecture
doesn't - but you haven't explained why you believe this.

Can you articulate a set of principles which justifies your belief -
or point to any examples?


Scott wrote:

NC>> Someone pointed out to me that although I've been using the
NC>> terms CEE and CES as synonomous for the terms 'host-centric'
NC>> and 'edge-centric' (and 'network-centric' completes the list),
NC>> that for others they seemingly aren't exactly synonomous, but
NC>> subtly different.
NC>>
NC>> Can someone confirm this, and explain what the differences
NC>> are?
NC>>
NC>> I'll be using 'host-centric', etc from now on. My apologies if
NC>> I have inadvertently caused any confusion by using them as
NC>> synonyms for 'host-centric' and 'edge-centric'.

TL> To me, CES seemed to be 'map-and-encap' and CEE was 'everything
TL> else'.


> To me, they are different ways to take a step from where we are
> now.  We currently have edge sites injecting their prefixes
> upstream at various points in the topology -- either PI or PA --
> and having them routed instead of being aggregated immediately.
> CES refers to getting rid of that by not having edge site prefixes
> seen upstream at all.  CEE refers to getting rid of that by having
> pure PA-based aggregatation (multiply connected sites get multiple
> PA aggregates).

I agree.

> CEE implies some changes to both hosts and edge site operations,
> but isn't "host-centric".  I'm not sure that term is useful when
> talking about routing and addressing architecture.  Changes to
> hosts might derive from the changes to routing and addressing but
> aren't central to them.

I think it is reasonable to describe CEE architectures as being
"host-centric" and CES architectures as being "network-centric".

CEE leaves the network untouched - all existing routers can still be
used.  The DFZ with its BGP control plane will work as it does today.
 There are no new network elements handling traffic - no ITRs or ETRs
etc. I think most or all CEE architecture need a to be able to map
from Identifier to Locator(s), so maybe there will be a new mapping
system or an extension to the DNS - but that is the only global
addition to the entire Internet.

CEE adds things to the network.  For LISP and Ivip, this are new ITR
and ETR functions and a fancy mapping system to control the ITR's
tunneling behaviour.  TIDR has the ITR and ETR concepts, but doesn't
have a mapping system as such - the ITRs learn where to tunnel
packets to via messages passed along by DFZ routers.  I am hope soon
to understand RANGER properly, but as best I understand it, it has
two stages of tunneling, or two stages of packet redirection compared
to the current system - and doesn't have anything quite like a
"mapping system".

One of the things which all CES architectures do is tunnel packets,
typically across the DFZ and frequently in and out of some deeper
level within ISP or end-user networks.  As long as this is done with
encapsulation - which is the only method available without upgrading
all DFZ routers (for Modified Header Forwarding) - then there is
going to be some serious difficulties with Path MTU Discovery.  See
Fred's recent research (msg05910).  CEE involves no tunneling, and so
no PMTUD problems.


CES architectures do not require any changes to host stacks or
applications.  CES involves adding things to the Network.

CEE architectures require all host stacks and applications to be
changed.  CEE does not involve adding anything to the network.

So unless there are some exceptions to what we observe in these
architectures, I think it is correct and helpful to refer to CEE as
"host-centric" and CES as "network-centric" - while remembering these
are observations about these proposals, not the criteria for deciding
whether a proposal fits into one of these classifications.


>> While that's certainly a distinction, it's clearly not the only
>> one and perhaps not the optimally constructive one.
>
> I think it's one clear metric for evaluating next steps from where
> we are, but it seems that some approaches just don't fit in it.  I
> think it's still useful if an approach does fall in it, in that it
> bundles up implications.  "such-and-such is CES.  Oh, so that
> means it has the following issues to figure out ..."

I agree.


Joel, you wrote:

> I believe it has now been demonstrated that the terms CEE and CES
> are being used by different people to mean different things. That
> is even less useful than when I thought I knew what they meant.

Why do you believe this?  Please give some examples.

> PS: The statement from Robin recently leads me to conclude that I
> don't even know what he means by the terms CEE, and CES.

As far as I know, you have never articulated an understanding of the
distinction between, or the meaning of, these terms.  You have stated
that the terms either are meaningless / useless, and that the
distinctions between them are not important.

Yet you have not yet explained why you believe this.  A good way of
doing this would be to explain to what extent you disagree with:

  CES & CEE are completely different (graphs)
  http://www.ietf.org/mail-archive/web/rrg/current/msg05865.html

and most importantly, exactly why you disagree.


> And he coined them.

I most certainly did not.  The terms were used well before I ever
used them:

  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

That paper was finalised on 2008-09-15.  Scott mentioned there might
be some slides too.

Searching my copy of the RRG archives, here the earliest mention I
can find of CES is on 2008-07-24.  Jari Arkko wrote to the list:

  http://www.ietf.org/mail-archive/web/rrg/current/msg02884.html

      I wanted to bring up a few thoughts about the high-level
      design space. This is based on something we did as a group
      exercise in a recent Dagstuhl seminar, with Lixia Zhang, Dave
      Thaler, Bob Briscoe, Christian Vogt, Mikko Särelä, Luise
      Burness, Andreas Windsam, and Wolfgang Mandelbrat -- though I'm
      only speaking for myself in this e-mail.

He referred to a diagram:

  http://www.arkko.com/ietf/rrg/designspace_dataplane.jpg

which includes "Core-Edge Separation", with two branches -
"Encapsulate" (LISP) and "Translate" (Six/one router).

An accompanying message (msg02885) also refers to "core-edge separation".


On the same day, Luigi Iannone wrote to the list:

  http://www.ietf.org/mail-archive/web/rrg/current/msg02881.html

commenting on a document which Lixia announced on 2008-07-21:

  a few draft towards convergence
  http://www.ietf.org/mail-archive/web/rrg/current/msg02821.html

The next day (msg02843), she corrected the typos and mentioned the
authors were:

   "Dan Jen, Michael, Dan Massey, Lan Wang, Beichuan Zhang"

She pointed to this:

  http://www.cs.ucla.edu/~lixia/draft-efit-mapping-multipath-00.txt

but the file is no longer there.  I can find no sign of it as an
actual IETF ID.  Luigi's message includes quotes from it:


     2.  Benefits of Separation via Map & Encap

          Separating the transit core from the edge networks can
          provide the following two major benefits:

     ...

     4.  Elimination or Separation


So it looks like this circa 2008-07-21 document has the first use of
the Core-Edge Separation and Core-Edge Elimination terms.



> "The CES vs. CEE distinction does not arise from
> whether hosts are altered or not.  It arises from the
> fundamentally different mechanisms which are used by these two
> different types of architecture to achieve scalable routing."

I wrote this - and what Scott wrote supports this.  If you read
(msg05865) you will understand why I wrote this.  I shouldn't have to
keep bulking up mailing list messages trying to explain the
distinctions when you can read (msg05865).


Noel, you wrote:

SB>> it seems that some approaches just don't fit in it.
>
> If something represents a set of choices along a number of
> orthagonal axes (e.g. 'map-and-encaps' plus 'invisibly map in
> proxies' plus 'caching mappings' plus etc etc), then it may be
> useful to give that _set_ of choices a name.

Yes - a bunch of things make sense together, and various proposals
have this in common.  The commonality includes some important
architectural distinctions from any other proposals, and we give it a
name.  In this case "Core-Edge Separation".


> However, with terminology which labels one particular set of
> design choices '{set X}', but then goes on to label everything
> else 'not-{set X}', the latter term is not at all useful.

I agree this would not be useful, but AFAIK, no-one is doing this.

While I may have been mistaken to class hIPv4 as "CEE", that was just
based on a quick look at it - so this does not reflect any problem
with the definition of CEE.

As far as I know, there are at least four classes of scalable routing
solution:

  1 - Soup up BGP and the DFZ routers so they can handle millions
      or billions of PI prefixes.

  2 - Replace the DFZ and any other parts of the routing system
      which need replacing with something different - not BGP, and
      perhaps without any Default-Free Zone - with a new system
      which can handle millions or billions of PI prefixes.

  3 - CEE, which means we can keep the existing routing system
      unchanged (but we have to upgrade all hosts and apps.)

  4 - CES, which means we keep all hosts unchanged, but add
      substantially to the routing system.

There may well be other classes too.  I haven't read all the
proposals yet.

It so happens that AFAIK everyone (with the possible exception of
Heiner Hummel) believes that 1 and 2 are completely impractical.

No-one is doing as you suggest:

> It is
> kind of like saying that my name is 'not-Tony-Li'. The problem is
> that in such a system, everyone else (except Tony :-) is also
> named 'not-Tony-Li' - and that is not very useful for
> distinguishing among all the (very different :-) individuals who
> are not 'Tony Li'.
>
> Equally importantly, if you have a design choice _axis_ (e.g.
> caching versus non-caching), different points on that axis can
> usefully be named.
>
> But 'not-{set X}' names are not useful.

Sure - but where do you see anyone on the RRG do this?

  - Robin