Hi Paul, Thanks for your reply, in which you wrote:
>> According to Noel Chiappa, the LISP team will soon be turning to a >> DNS-based global mapping resolution system: >> >> http://www.ietf.org/mail-archive/web/rrg/current/msg05772.html > > Interesting. Noel just wrote that the DNS approach will be an alternative. While I believe that DNS would be a better approach than ALT, I can't speak for the LISP people and I don't know what their plans are. My point was that just because there is a WG with a bunch of people working on LISP-ALT doesn't mean that the system will actually work in a way which is suitable for global adoption. > I have to say, I don't really know the details of LISP. I just know a > lot of work has gone into it, and I have no reason to doubt that it can > be deployed, and can solve at least a few problems. Here's at least one reason: ALT structure, robustness and the long-path problem http://www.ietf.org/mail-archive/web/lisp/current/msg01801.html I haven't kept this up to date, but here are some others: http://www.firstpr.com.au/ip/ivip/lisp-links/#critiques > I might not be too > keen on its apparent complexity, but given the amount of engineering > gone into it, it seems a deployable system. Perhaps you are assuming that if a lot of people work hard enough on something then it will do what it is supposed to do. I don't think this at all. >> This is not a common idea among all RRG proposals. This >> "Locator/Identifier Separation" approach is used by all the Core-Edge >> Separation (CES) approaches: > >> "Locator/Identifier Separation" means that separate objects, in >> separate namespaces are used for uniquely Identifying hosts and for >> specifying their Location (either exactly, or down to the level of a >> particular ISP or end-user network). > > I don't follow RRG closely enough to be completely au fait with its > somewhat extensive ontology (which, I have to say, seems to change > significantly even from month to month - the traffic here can sometimes > seems from mars if you fail to follow the list closely for even a short > while). :) A sign of the breadth of different, proposed solutions I guess. I don't understand how "ontology" applies to the RRG. The terminology is developing, and that is part of what I am writing about - since some of the terminology used at present is misleading, and this leads to genuine misunderstandings about the proposals. > I didn't realise there were proposals that did not split the ID space in > some way. I know there are some proposals that use an implicit space, > leaving the 2 separate spaces still combined in one greater space, e.g. > for protocol compatibility reasons, but the split is still there. > > I.e. I don't mind if an existing space is effectively split up, or if 2 > explicitly separate spaces are used - they're both splits to me. There are fundamental and important differences. The CES architectures create an "edge" subset of the range of global unicast addresses and add special mechanisms (such as ITRs, a mapping system and ETRs) to make addresses in this subset suitable for scalably providing portability, multihoming, inbound TE and perhaps mobility to millions or billions of End-User Networks (EUNs). All these "edge" addresses and all the "core" addresses (the rest of those in the global unicast range) are still interpreted according to the same namespace: the global unicast address namespace, for whichever of IPv4 or IPv6 this is. IP addresses from both subsets are still performing both Identifier and Locator roles. Its just that there is a new mechanism for transporting packets addressed to "edge" addresses across the DFZ (and often across parts of the edge networks of the sending host and the ISP used by the receiving host's EUN) - tunnelling from ITR to ETR, rather than the usual process of a router forwarding the plain packet to a neighbour. This is not at all "Locator/Identifier Separation". It is Core-Edge Separation - separation of one subset of "edge" addresses from the remaining "core" addresses. No new namespaces are involved. CEE architectures involve a separation of the currently combined roles of Identifier and Locator. Hosts no longer use IP addresses to Identify and Locate other hosts. They use something else - what it is depends on the CEE architecture - to Identify hosts. Sessions are established by this Identifier and are continued on this basis, no matter what IP addresses both hosts have or change to during the session. So this supports multihoming. Portability is of the Identifiers, not of the IP addresses a network uses - so they use whatever space their one or more ISPs give them as PA prefixes. Core-Edge Elimination architectures always involve "Locator/Identifier Separation". This is not at all the separation of one subset of global unicast IP addresses from the rest, as "edge" space, as is done with CES architectures. So "split" and "separation" can be used to describe both processes - but what is being separated is completely different in the two approaches. > [snip interesting overview of proposals] > >> This is true of CEE architectures. This is because hosts are then >> Identified by something different from IP addresses. So the >> host-to-host sessions survive changes in the IP addresses used by the >> hosts, and renumbering a network when choosing a new ISP does not >> alter the identity of the hosts. CEE architectures multihome by >> giving each host two or more IP addresses, one from each ISP. > >> Your statement does not apply to CES architectures. For CES, the DFZ >> routers are primarily concerned with the ISP's prefixes, which use >> the "core" subset of the global unicast address space, which is what >> remains after a new subset of scalable "edge" addresses have been >> removed. > > Right, it's still a hierarchical split. Sometimes too much > categorisation is not useful. I.e. I see there's a distinction, but that > distinction is not in the general concept of there being a split, but in > whatever practical details of it. The details of what is being split are absolutely crucial! > So I recognise there are 2 different things, call them CES and CEE if > you want, but I don't see the utility in argueing one that one has a > split and the other does not. Anyway, doesn't matter (to me ;) ). I believe that once you understood the proposals in detail, the question of what is being split or separated would matter to you. >> PJ> We will note that some proposals, in order to be as >> transparent and invisible to end-host transport protocols >> as possible, use a "map and encap" approach – effectively >> tunneling packets over the core of the internet. >> >> These are all CES architectures. CEE architectures have no need for >> tunneling. > > I think I'll stick with "map-and-encap" and "rewriting". I have to say, > I sometimes wish this WG would try adopt labels that are semi-evocative > of their meaning where possible, rather than all these acronyms. Very > confusing! :) You can do this and so ignore what I wrote - but you haven't argued why anyone else should do the same or why I or anyone else should respect your choices. >> PJ> Some other proposals use a NAT-like approach, like Six-One or >> GSE, with routers translating from inside to outside. >> >> "Six/One" is an earlier host-based proposal from Christian Vogt - >> arguably an improved version of Shim6. I think you are referring to >> "Six/One Router", also from Christian Vogt. > > Ah, perhaps I do - thanks! I recall that Six/One itself hasn't been discussed since around 2007, and without knowing it was different, it would be easy to shorten "Six/One Router" to "Six/One". >> CES architectures do not require any additional complexity, or any >> other changes, in host stacks or applications. They work by adding >> some new elements to the routing system - and a mapping system - but >> do not require alterations to most routers. > > They tend to be complex themselves though. They certainly do. >> These differences, and the fact the CES maintains the current IP >> naming system while CEE completely changes it, means that the >> distinctions between these two types of solution are highly >> significant and helpful when discussing scalable routing solutions. > > Sure, but do we really need to use acronyms? :) No - you can use "Core-Edge Separation" and "Core-Edge Elimination". I am trying to be concise. >> Good CES architectures provide immediate benefits to adopters, by >> supporting all their traffic, and provides scaling benefits in >> proportion to the adoption rate. > > If that's so, then the map-encap systems will see adoption. I believe that the only proposals which should be seriously contemplated are CES. Firstly because I think it is a mistake to think the "Locator/Identifier Separation" naming model is superior and secondly because there's no way the world will alter all its host stacks or (for most CEE architectures) rewrite its applications *completely* - which is what is required before there would be significant benefits to CEE adoptors or significant routing scalability benefits. > I'd have my > doubts about the "immediate benefits to adopters" though. Doesn't CES > have a path-MTU problem though? Fred Templin and I have been discussing this. It requires extra complexity in the ITRs and ETRs, but we think it can be done. Please see the "IRON: SEAL summary V2" thread and my approach: http://www.firstpr.com.au/ip/ivip/pmtud-frag/ >> CEE architectures can only provide substantial benefits to adoptors >> and only provide real scaling benefits, when all, or almost all, >> networks adopt the new architecture. This means moving everyone to >> IPv6 and altering all host stacks to implement the particular CEE >> architecture's alteration of IPv6. > > I'd disagree with this. If you read the blog entry I'm outlining a > scenario where the immediate problem to be solved is pressure on NAT > (not multi-homing), leading to hacks being deployed which benefit both > customer and ISP together. These hacks then can be later, slowly, > extended to things like multi-homing. I don't see how the above paragraph relates to you disagreeing with the paragraph of mine before it. What you are proposing is neither a CEE nor a CES architecture. You are proposing to extend the port range of IPv4 TCP and perhaps UDP protocols, as a means of enabling NAT boxes to serve more hosts from a single IPv4 address. This doesn't solve the routing scaling problem in any way. It is an attempt to cope with a situation where there is such a shortage of IPv4 space that there's not enough to run NAT boxes with whatever limitations they have from the current 16 bit TCP/UDP port numbering system. > I think it's plausible that IPv4 space for multi-homers will continue to > be available for long enough to stave off map-encap deployment > (particularly if map-encap connectivity has PMTU problems). This could > be facilitated partly by ever greater use of NAT, such that the *first* > problem that ISPs and end-users really clamour to have solved (and will > upgrade for) is NAT port space pressure. Some big NAT using networks > have already noticed such pressre problems today, e.g., so it's not such > a hand-wavy scenario. NAT has nothing to do with multihoming. I don't understand how you see your suggestion as relating to the goals of scalable routing which are, roughly: How to accommodate much larger numbers of end-user networks (10 million is a figure Brian Carpenter and I have independently suggested) with portability, multihoming and inbound TE, in a scalable manner: with far less impact on the DFZ control plane and the DFZ routers' RIBs and FIBs than the current practice of having each such end-user network advertise one or more PI prefixes. > Everything else follows logically from that. Just saying :) I don't understand your reasoning - and I can't see where you have explained your reasoning. >> LISP and Ivip both require considerable complexity. This is not >> surprising, since we are planning a once in several decades >> enhancement for the IPv4 and IPv6 Internets - with the work to be done >> in the network, without requiring host changes. > > I have to say, I'm not a fan of complex networks. There seem to be good > economic reasons why a dumb inter-network of smarts hosts won out over a > plethora of smart networks of dumbish terminals (to varying degrees). I think most people feel the same way. The Internet is a far more powerful and adaptable system than the phone system, where the network does everything and the end-user devices are quite dumb. I think this is a big part of the attraction of CEE architectures, especially those such as ILNP which involve no additional things in the network at all. However, to do ILNP, you have to rewrite all the applications, and change all the stacks (and get everyone off IPv4 to the ILNP-modified IPv6 Internet). And then you need to accept that all hosts need to be more complex, and that there will generally be more delays in establishing communications - with more management packets flowing back and forth etc. Arguments against doing this are in: Today's "IP addr. = ID = Loc" naming model should be retained http://www.ietf.org/mail-archive/web/rrg/current/msg05864.html > Not convinced myself that avoiding changing host software is a long-term > holy grail. Particularly if the correct place economically and > technically is to change the hosts. As Brian Carpenter has said here > regarding IPv6, changing the host software is /not/ that hard - changing > the /network/ is the hard part. Please take a look at the graphs here: CES & CEE are completely different (graphs) http://www.ietf.org/mail-archive/web/rrg/current/msg05865.html about how with CEE you have to change essentially all stacks and applications (no application changes needed for GLI-Split, but that requires GLI-gateways to handle all packets entering and leaving each EUN), and get everyone off IPv4 and onto this modified version of IPv6, before adopters get real benefits and before there are any real routing scaling benefits. If you disagree with this, then please write why. CES involves adding some things to the network. This is easier than changing all the apps. The benefits accrue directly to adopters and progressively for routing scaling benefits according to the level of adoption. The end-result, I believe, is better, since it retains the current IP naming model, which I believe is superior to the one many RRG people want: "Locator/Identifier Separation". > I can't see customers clamouring for "LISP" (what do customers care > about how the network works) and the path of least resistance for ISPs > is to support their hosting and multi-homing businesses by using NAT to > reclaim address space from access customers. NAT does not provide multihoming. Multihoming is the ability to continue communication sessions no matter which of two or more ISPs an end-user network is using. > However, that's all debatable, and I'll guess we'll see. I don't think you have debated anything. You have stated you disagreed with some things I wrote, but not why you disagreed. I am wondering if you understood all that I wrote. > My bets are on end-host extensions like Shim (Shim6 if IPv6 becomes > popular, something similar for v4 if not) and, possibly, extensions to > facilitate the dumbest possible network middle-boxes - like the NAT > extension described in my blog entry. OK - that is your belief. But why do you believe this? >> You mention options for the IP header. As far as I know, IPv6 >> extension headers can be used. > > The assumption in my blog post is that IPv6 deployment continues to > stall, and people start looking for ways to band-aid problems with IPv4 > to allow it to be continue to used. I think this is an entirely realistic expectation. > I show that such an approach, by solving immediate problems > incrementally, could iterate toward a new address family that solves > internet scaling problems while remaining somewhat backward compatible > with IPv4 as this development process goes on. I.e. change the end-host > software by all means, but remain compatible with the network. But increasing the number of hosts a NAT box can handle from a single IPv4 address has nothing to do with the routing scaling problem, or multihoming, portability, inbound TE or mobility. > With the hindsight available to us today, this is probably the approach > that should have guided IPng. I think it may well have been better to plan a new addressing system, based on the IPv4 one, which could use the IPv4 address space as a subset - probably with a new IP version with a different header, or perhaps with IPv4 headers with option headers. It would take a few years for routers to be made or upgraded to handle the new format properly, but I think this would have had a better chance of being adopted widely than the completely new and separate addressing system of IPv6. However, many of the same problems would have been faced - and I would not claim that any arrangement would have been satisfactory in the long-term or have been widely adopted by now. Unfortunately, IPv4 was not designed to have any upgrade path. >> Unfortunately the same is not true of IPv4 header options. One of the >> RRG proposals (hIPv4) relied on these, but DFZ routers handle such >> packets on the "slow path", making this entirely impractical: > >> End-to-end measurements on performance penalties of IPv4 options >> Fransson, P.; Jonsson, A. >> Global Telecommunications Conference, 2004. GLOBECOM apos;04. IEEE >> Volume 3, Issue , 29 Nov.-3 Dec. 2004 Page(s): 1441 - 1447 Vol.3 >> 10.1109/GLOCOM.2004.1378221 >> http://www.sm.luth.se/csee/csn/publications/end_to_end_measurements.pdf >> >> most routers process such packets on the "slow path" with software. > > Yes, I mentioned that. Thanks for the references though. However, I also > claim that if an IP option became popular that newer hardware would > fast-path certain common cases. Unfortunately it couldn't become even a little popular since it is impractical to use it through the DFZ, or probably with most routers. > We should perhaps take care to avoid making long-term architectural > decisions based on trivialities of todays implementations. It is not a triviality that a few billion people use and rely on the IPv4 Internet, and that we can't force anyone to adopt anything. Please take a look at my attempt to list the constraints we face due to the need for widespread voluntary adoption: http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/ These are not trivialities. If you want to debate an ideal networking system without concern for the installed base, then that's fine - you would be debating "clean slate" designs, with no concern about what exists or how or why anyone would adopt it. This is not the purpose of the RRG. The purpose of the RRG is to solve a very real scaling problem which exists today with the IPv4 Internet, and can be expected to arise in the IPv6 Internet if and when it becomes very widely adopted. This has nothing to do with "clean slate" design exercises - unless you can suggest how we can have most people adopt, on a purely voluntary basis, your clean-slate design, and have people invest in designing and building it first. >> From the analysis it can be concluded that there is a slight >> increase in delay and jitter and a severe increase in loss rate. >> >> I think the latter part of your article is focussed on IPv4, since >> your aim is to make NAT more workable. Unfortunately, it seems that >> the "slow path" handling of packets with IPv4 option headers rules >> out any solution along the lines you are suggesting. > > I think I covered this in the blog post. > > a) Today: "slow connectivity" trumps "no connectivity, cause a NAT > box in the middle is maxed out". Its not just slow - it involves such packet loss rates that communication would be impractical. Even being slow would be enough to ensure no-one wants it. We are a long way from being so desperate for IPv4 address space that we need to think of ways of making a NAT box handle 100 hosts, rather than 10, or whatever the limit is today due to the 16 bit nature of TCP and UDP port numbers. > b) Longer-term: IP options are slow-path only cause they're uncommon. > There is no reason why a popular option, reliably placed in the > packet could not stay on the fast path. (E&OE, IANAEE) In the long term, I agree - five, ten years or more - routers can be upgraded or replaced. As this debate goes on, year after year, I think the number of routers in the DFZ which can't have their FIB functionality significantly upgraded by firmware updates will diminish. There may come a point where everyone decides it is easiest to upgrade most of the DFZ routers and to replace the few which can't be upgraded, than to do whatever else is the alternative. But until such upgrades are done, there's no way anyone can reliably communicate across the IPv4 DFZ with a new kind of protocol, or with IPv4 packets with option headers. Once we can contemplate such upgrades to DFZ and other routers, then we could do a CES architecture (Ivip) without encapsulation: http://tools.ietf.org/html/draft-whittle-ivip-etr-addr-forw-00 As you note in the "pjakma said" addition to your page: http://pjakma.wordpress.com/2010/02/12/making-the-internet-scale-through-nat/ your proposal would also depend on upgrading applications. I agree with your assessment of this aspect of your proposal "This is the most obviously crack-full part of it all."! - Robin _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
