Hi Robin, comments in-line
On Mon, Feb 1, 2010 at 4:34 PM, Robin Whittle <[email protected]> wrote: > > These CEE and CES terms are more recent - the last two years or so, I > think. I think the most important document which uses these terms is: > > 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 > Great paper, now I understand better the CEE&CES terms You will find it hard to categorize hIPv4, it is partly CES because it is splitting up the address space in core and edge addresses - but without any new mapping databases and the change should be applied at the hosts - not a map&encap solution. Also partly CEE, in order to achieve dynamic multi-homing a multi-path transport protocol should be used. So hIPv4 is an odd bird...an unorthodox approach but in research work that should be allowed... > >> We know that there are overloaded applications, which are carrying >> Identifier&Locator information in there headers&payload. You can >> detect them by forcing them to traverse a NAT device - two most common >> applications that I can think of is IPsec and SIP. These protocols >> will work nicely in a CES approach but in a CEE where a true >> Identifier/Locator separation is applied you get into trouble. > > You correctly state that CEE is Locator/Identifier separation. > > As far as I know, CEE won't work with NAT. That is not necessarily a > bad thing with IPv6, since it has long been hoped that NAT would not > infest IPv6. NAT is evil, no doubt about that. But if we wouldn't have had NAT most likely the application people would have written more applications that are relying directly on IP-addresses and a migration of application to e.g. IPv6 would be much harder. So it is bad but there is something good also. > > >> It is >> also a well known fact that architecturally IPsec and SIP are broken, >> both are relying on IP addresses > > I think the current 2 layer IP naming model is *better* than the more > "architectural correct" arrangement of having independent levels of > separate objects, in separate namespaces, for Identifier and Locator. > > My recent message > > Today's "IP addr. = ID = Loc" naming model should be retained > http://www.ietf.org/mail-archive/web/rrg/current/msg05864.html > > will be heresy to many RRG folks. > Here I get confused again about the usage of the identifier term. If you split up the addresses into two parts as in CES you will have an IP address block that is visible in the DFZ (in LISP that is RLOC) so why not give it the name e.g. Global Locator. Then the edge IP address space is only visible inside the local network (in LISP that is EID) so why not give it the name e.g. Local Locator - both are used for routing purposes anyway and resides in the IP header. But let us not start an argument about this, it is like it is - but it is very confusing for beginners (like me) on the list. > >> - so actually it is not the CEE's >> fault that you get into trouble with these kind of applications. And a >> new architecture comes with a cost, not everything can be preserved as >> such - if everything is preserved, then it can't be a new >> architecture. > > Yes, but the only benefit of CEE I know of, apart from architectural > purity, is that it enables multihoming and perhaps mobility on a > scalable basis without the need to upgrade the routing system at all. > > This is impressive and interesting, but it comes at a cost, as I > argue in my recent message about how CES is very different from CEE: > more delays in establishing most communication sessions, more work > for hosts, more packets going back and forth between hosts, more > lookups by hosts into slow, less then 100% reliable global query > server systems (such as DNS) - and all this is made worse still for > any host which is on a wireless link with congestion, delay, dropped > packets etc. > > Then there is the fact that CEE only delivers substantial benefits to > adopters and to scalable routing after everyone has adopted it in > their hosts and after essentially all applications have been > rewritten to use the new CEE API in the stack. > > This is never going to happen. The Internet is not so broken that we > have to rewrite the apps. True, but NAT has done us a favor here. The application which works well over NAT shouldn't care what is happening on the network layer and most of the applications working over Internet shouldn't be a big issue. But then when you have a look on what is used inside an enterprises' Intranet it is a different story - there is quite a lot of applications that has been tailored for businesses and if you change that it will be expensive, very expensive > > The current IP address = Identifier = Locator arrangement works and > has major advantages in terms of being faster and lighter-weight for > all hosts. Scalable routing and global mobility can be done better > and more easily with CES than CEE. CES preserves the current IP > address model and does not require us to alter host stacks or rewrite > any applications. The current address model is soon running out of addresses, what then? When you are there you have to go after the host stack and some applications needs to be rewritten anyway. Sooner or later you need to deal with this problem, now there is a chance to do something more intelligent with IPv6, before it is getting more deployed. > > >> So is NAT really that evil as its reputation? > > I think NAT is very evil. The any-to-any connectivity model of the > Internet is an excellent thing. It is evil, no doubt - but it is today part of the package. -- patte _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
