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 _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg