Subject: Re: [rrg] Terminology

From: [email-masked] (Noel Chiappa)
Date: Wed, 3 Feb 2010 22:31:34 -0500 (EST)

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

	Noel

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 04 Feb 2010 11:55:30 +0800

Somebody argues that LISP is an edge-centric (i.e., CES) solution, then what
about LISP-MN? Meanwhile, somebody argues that HIP and RANGI are
host-centric (i.e., CEE) solution, then what about HIP proxy and RANGI proxy
mechanisms? 

IMHO, these two options are not mutually exclusive. On the contrary, they
should be complementary for each other. Each one is suitable for its
corresponding stage of the Internet architecture evolution path.

Xiaohu

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Noel
> Chiappa
> 发送时间: 2010年2月4日 11:32
> 收件人: [email-masked]
> 抄送: [email-masked]
> 主题: Re: [rrg] Terminology
> 
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg

---

From: Robin Whittle <[email-masked]>
Date: Thu, 04 Feb 2010 17:01:25 +1100

I am perplexed that Ran Atkinson (msg05940) has joined Joel Halpern
(msg05867) and Lixia Zhang (msg05897) in questioning the
architectural validity and importance of the distinction between CEE
(Core-Edge Elimination) and CES (Core-Edge Separation) proposals.

Ran, you wrote:

> I don't find the "CES" or "CEE" terms to be very meaningful,
> in that they don't really inform one about the important
> properties of any proposal.

As I wrote to Joel and Lixia, I would really appreciate you writing
why you disagree with:

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

Neither you, nor Joel, nor Lixia have given any explanation why you
think this.  Perhaps the easiest way of doing so would be to point
out what is wrong with (msg05865), in which the architectural
distinctions are made quite explicit, along with their importance to
the RRG.

> Just as Patrick disagrees with how hIP4 has been characterised,
> I don't really agree with how ILNP has been characterised.

OK - its not much good just stating your opinion.  Enquiring minds
want to know why you think this.

What is wrong with me or other people asserting that ILNP is a CEE
architecture?  Like the others, it enables the elimination of "edge"
addresses - PI addresses - and it also does not require the creation
of a new class of "edge" addresses as is done with a Core-Edge
Separation architecture such as LISP or Ivip.

How do you think ILNP should be characterised?

I wrote that hIPv4 was a CEE after looking briefly at the summary.
Patrick tells me I am mistaken, and he has given some descriptions
which make me think that it has at least some things in common with a
CES architecture, without any resemblance to a CEE architecture
(msg05923).  So at present I don't regard it as a CEE proposal.  I
hope to read the whole hIPv4 proposal soon.

> I don't see the value in trying to continue use of those terms
> within the Routing RG context.

OK - but why do you think they don't reflect important distinctions
between proposals?

> Probably best if we all just move on, and keep trying to find
> meaningful ways to characterise the various ideas floating within
> the RG.

I and others have tried to find meaningful ways of characterising the
proposals.  We think the CEE and CES distinction is important.  I
argued why in (msg05865).  You, Lixia and Joel just wrote that you
disagree, without any indication why.

ILNP and the other proposals which I and others regard as being CEE
architectures involve a completely different naming model from that
of today's IPv4 and IPv6, in that the new model has separate objects,
in separate namespaces, for the roles of Identifier and Locator.
Another way of saying this is that CEE architectures, including ILNP,
implement "Locator / Identifier Separation". (Not to be confused with
LISP - which is a CES architecture and does not implement "Loc/ID
Separation".)

Many people on this list, including Tony Li, consider this naming
model to be "doing it right".   I think Tony - and you - believe the
Internet would be so much better with this model that it is worth
upgrading all the host stacks and rewriting all the applications to
support this model.

I disagree - I think it would be a major step in the wrong direction:

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

I don't think everything about CEE is bad.  For instance, it does not
involve tunneling - so there is no problem with Path MTU Discovery,
which I now realise is a terrible mess, thanks to Fred's recent research:

  Fred's IPv4 PMTUD research: RFC1191 support frequently broken
  http://www.ietf.org/mail-archive/web/rrg/current/msg05910.html

Except for Ivip with upgrades to all DFZ routers, any CES
architecture needs to tunnel traffic packets en-masse, and it looks
like it is going to be difficult to handle the PMTUD problems this
raises.

> host-centric (i.e., CEE) solution, then what about HIP proxy and RANGI proxy

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 don't know enough about HIP proxy or RANGI proxy to comment, but if
you understand them, then my (msg05865) gives you a good basis to
decide how closely they resemble either a CES or CEE architecture.

> corresponding stage of the Internet architecture evolution path.

I am not arguing that host changes should not be contemplated.  I
observe that CES architectures do not require any host changes and
that CEE architectures require changes to all host stacks and all
host applications in the world - in order to support any one adopter
having all their communications gain the portability, multihoming and
inbound TE benefits.   But these are observations of two kinds of
architecture - see my (msg05865) for the architectural distinctions
themselves.

 - Robin

---

From: Tony Li <[email-masked]>
Date: Wed, 03 Feb 2010 20:35:09 -0800

> inadvertently caused any confusion by using them as synonyms for

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

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

Tony

---

From: Scott Brim <[email-masked]>
Date: Thu, 04 Feb 2010 09:19:46 -0500

> To me, CES seemed to be 'map-and-encap' and CEE was 'everything 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).

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.

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 04 Feb 2010 09:26:40 -0500

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.

Yours,
Joel

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.  And he coined them.
"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."

---

From: Scott Brim <[email-masked]>
Date: Thu, 04 Feb 2010 09:50:29 -0500

> That is even less useful than when I thought I knew what they meant.

Weren't they written down, in a Lixia et al. draft?

> architecture to achieve scalable routing."

That makes sense to me: the two different approaches it distinguishes
between are to separate edge routing/addressing from non-edge and
eliminating the distinction.  But that's just one criterion, and not
every approach benefits from its use.

Scott

---

From: Robin Whittle <[email-masked]>
Date: Wed, 24 Feb 2010 17:37:08 +1100

As noted in (msg06105), in a number of messages I stated or implied
that ILNP requires upgrades to applications.  This was a mistake.
ILNP works with non-upgraded IPv6 applications.

Still, since AFAIK most applications only work with IPv4, ILNP would
require upgrades to most applications.

> upgrading all the host stacks and rewriting all the applications to

which implies that all CEE architectures require upgraded
applications.  I now understand that GSE, GLI-Split and ILNP work
with non-upgraded IPv6 applications.

  - Robin