I am replying to Tony Li and David Conrad - and requesting the views of the LISP and APT developers on my proposed text:
http://psg.com/lists/rrg/2008/msg01444.html Tony wrote: > |There is currently only one routing scaling problem - in the IPv4 > |Internet. There's no hurry about solving the IPv6 routing scaling > |problem because it will only occur if and when IPv6 is widely adopted. > > I have a lot of sympathy for where you're coming from, but I have to > disagree. Yes, we have one routing scaling problem, but it's the IP routing > architecture, and it's common for both v4 and v6 because both use exactly > the same routing architecture. There is a potential routing scaling problem because the IPv4 and IPv6 routing systems are identical in respect of the limitations which give rise to the problem. However the IPv6 system does not have the physical problem so far because very few people use it. This is a routing and addressing scaling problem and I think it is is only solvable by creating some new kind of address space which provides multihoming etc. in a scalable way. The fact that IPv4 and IPv6 use exactly the same routing structure does not mean that the solution needs to be the same, because there are significant differences in the addressing systems: IPv6 has 96 more bits and a vast, currently largely uninhabited space. This enables that compared to an IPv4 solution, an IPv6 solution can involve different assignment policies and new protocols making more creative use of address bits. For instance IPv6's larger address space makes it practical to have duplicate address ranges going to a translation router, such as with Six One Router: one from each upstream ISP, each of the same length as the end-user prefix. See: http://psg.com/lists/rrg/2008/msg01314.html > There's no hurry to fixing it for IPv4 > because frankly, we can scale the hardware to support the usual PI prefix > sizes (/24 -> 2^24 routes == 16M routes). Yes, it will cost a bit more, but > over the long run, that's probably a lot cheaper than upgrading every CPE or > PE router. If your view reflects consensus in the RRG, then perhaps we could form rough consensus on something like this: While some architectural enhancements could solve the routing and addressing problem by creating a new kind of address space which is portable, multihomable etc. without significantly burdening the BGP system, we believes that none of them could be practical or cost-effective enough to warrant development or deployment for IPv4, compared with letting the current system saturate towards 16M individually routed /24s. If so - and if I believed this was a viable solution - then I would mothball Ivip until about 2020. You are suggesting the current DFZ size of 250k: http://bgp.potaroo.net Ooops make that ~260k . . . should be allowed to grow a factor of up to 64 without any changes in the BGP system or any architectural enhancements. If this could be done, then we could split up the IPv4 space finely and make pretty good use of it, without any new map-encap scheme etc. Quite a large number of end user networks could work fine with a /24. However, map-encap would be much better because a much larger number of end-user networks could scalably have their own portable, multihomable space, in any address size - 1, 2, 4 etc. through 256 IP addresses and beyond. The right map-encap system could also support a new global form of mobility. I understand that for considerable, but perhaps not unthinkable, expense the 200k+ (and more in the future) DFZ routers could be upgraded to have FIBs to handle this. My first suggestion (early 2007, now abandoned) for the routing scaling problem: http://www.firstpr.com.au/ip/sram-ip-forwarding/ was just this, when I thought that the FIB was the problem, not the RIB and the associated BGP communications. My understanding of your suggestion is that it is much the same as my now-abandoned solution: flat routing to /24 with souped up SRAM-based FIBs and hoping that Moore's Law would affordably provide the extra CPU and RIB RAM grunt required to handle the up-to 64 times increase in the number of conversations each DFZ router needs to have with each of its peers. No-one would have gone to the trouble of developing a map-encap proposals if we thought that it was acceptable to let the IPv4 system degenerate as you suggest without any new architectural system for taking the load off the BGP system. None of the map-encap systems were made with the intention that IPv4 be left to fester in a swamp ten or more times bigger than its current predicament. They are all described initially in terms of fixing IPv4. Surely enough was agreed at RAWS about problems with BGP stability and the load on CPUs and RAM to make your suggestion of leaving IPv4 alone a non-starter. > Where we have major issues is (and, admittedly, if we transition to) v6. > Since the canonical PI prefix is a /48, we will have a very serious problem > on our hands. Now, I'm no lover of v6 and I think my views on it are pretty > well known. While you may not take v6 very seriously, there are those that > do, and frankly it's our joint responsibility to plan for its adoption. I totally agree we should plan for widespread IPv6 adoption. My text reflects the facts that the IPv6 solution is not so urgently required and that an IPv6 solution could take advantage of a number of IPv6-specific conditions which unfortunately don't apply to IPv4. > We have had one 'success disaster' with v4 and we need to prevent the same > thing from happening to our grandchildren. I'll happily stipulate that we > don't know when a solution will be necessary. OK - we don't yet know when an IPv6 solution will be necessary. > V6 deployment has been about > 15 years running so far and shows no signs of reaching critical mass anytime > soon. However, this is also partly why this is considered a _research_ > topic, not an engineering one. As I suggested, I think we would be doing our job well if we suggested several promising approaches to IPv6, since there is no urgency about deciding on which should be developed and deployed. I think the situation with IPv4 is urgent enough that we should find the most promising solution, or class of solutions, and recommend that for immediate development. Perhaps we won't reach consensus on one, but there may be considerable support for two solutions. If so, that is the best we can recommend. If we can't reach much consensus on anything, then I think our report should reflect that. > |However, I can't rule out that there may be some fancier, better and > |more ambitious approaches to solving the IPv6 routing scaling > |problem. This includes fundamentally different approaches, > |especially if we contemplate changing the IPv6 protocols. > > ... And that's exactly what we are chartered to explore. Yes, but I would be surprised if there is consensus that the IPv4 routing and addressing problem is so inconsequential that we don't need to recommend a more specific and better researched solution for IPv4 than we do for IPv6. David Conrad wrote: > Um. 433 words instead of 28? In order to reach rough consensus on > the direction the group is taking? Do you, perhaps, get paid by > word? :-) I wish. > More seriously, while I understand some of your concerns (and > disagree with others), I think we need to plant a stake in the > ground to demonstrate at least some progress has been made. Yes, but not if the statement involves shortcuts that fence us off from the optimal combination of recommendations. Nor if the statement is insufficiently meaningful to constitute progress, for instance by not eliminating any significant part of the solution space. Despite its length, I think my text has a good signal-to-noise ratio because it: Usefully fences off certain parts of the solution space for IPv4 (host changes, except perhaps for minor performance enhancements). Emphasises that the IPv4 solution needs to involve immediate and lasting benefits over costs for ISPs and end-user networks. (Implicitly, this is because without coercive powers, the only way the IETF can ensure sufficiently widespread adoption to substantially solve the problem is by making the solution directly attractive according to costs and needs of a large majority of potential adopters. Almost no-one will adopt it simply because it is a solution to the scaling problem if it involves any costs or disruption, which it certainly will.) Commits us to devising an IPv4 solution for immediate development and for deployment in what I think is the earliest practical time frame. Gives us more flexibility in the IPv6 solution space, because it is a broader space and because there is no urgency. > The statement Tony provided is pretty watered down with respect to > saying much of anything, but it at least points to a > prioritization and one that I'm comfortable with. As such, I'm OK > with the wording as is (although I might prefer "Our > recommendation must be ..." since it "must" appears in the second > sentence). OK. Based on recent messages of support for Tony's text, I am surprised by how many people seem to think we don't need to solve the IPv4 problem. Where are the LISP and APT developers on this question? (Bill Herrin supports my text.) I think we all went to a lot of trouble to develop our solutions because we believe something really is needed ASAP for IPv4. That was the impetus behind the RAWS workshop 20 months ago. In my view, there are no other potentially practical solutions for IPv4 than the map-encap systems. If the map-encap developers are outvoted in some sense by other folk who believe there isn't a need to solve the IPv4 routing scaling problem, then I think that the consensus view would have resulted from the views of people who haven't yet devised an IPv4 solution prevailing over those of people who think they have. If so, folks outside the RRG - who are seriously concerned about the IPv4 problem in terms of costs and stability now and in the years to come - will regard the IPv6-centric work of the RRG as irrelevant. If this eventuates, then the RAM list and later the RRG list will have been productive in terms of supporting the development of a bunch of map-encap solutions for IPv4 which the RRG chose not to recommend. - Robin -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
