[rrg] Scalable solution hitting IPv4's limits
Robin Whittle <rw@firstpr.com.au> Sun, 19 April 2009 15:24 UTC
Return-Path: <rw@firstpr.com.au>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC19428C214 for <rrg@core3.amsl.com>; Sun, 19 Apr 2009 08:24:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level:
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[AWL=-0.855, BAYES_50=0.001, FB_NO_MORE_ADS=1.174, GB_I_INVITATION=-2, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9smLPaAoCwbd for <rrg@core3.amsl.com>; Sun, 19 Apr 2009 08:24:53 -0700 (PDT)
Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 520C43A6810 for <rrg@irtf.org>; Sun, 19 Apr 2009 08:24:52 -0700 (PDT)
Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id B27921759D4; Mon, 20 Apr 2009 01:26:06 +1000 (EST)
Message-ID: <49EB4294.2070601@firstpr.com.au>
Date: Mon, 20 Apr 2009 01:26:12 +1000
From: Robin Whittle <rw@firstpr.com.au>
Organization: First Principles
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: RRG <rrg@irtf.org>
References: <49E69AB5.6060409@firstpr.com.au> <FC05B8B8-1E66-4257-AD86-DF97BBB981D0@pch.net> <49E6C0A9.5000606@firstpr.com.au> <5AE46131-A768-4159-8F28-75D1A5CA27B4@pch.net> <49E7F77E.10805@firstpr.com.au> <A0F5D6E2-6CEE-415A-BA5D-B865ACE7317F@pch.net>
In-Reply-To: <A0F5D6E2-6CEE-415A-BA5D-B865ACE7317F@pch.net>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [rrg] Scalable solution hitting IPv4's limits
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Apr 2009 15:24:56 -0000
Short version: Long reply to Tom Vest, discussing his concerns about IPv4, even with a scalable routing solution, hitting the limits of its address range and so causing difficulties for aspiring new ISPs. The same issues are covered more concisely in the footnote to the draft list of constraints. Also, some discussion of the TTR Mobility approach in the hope that people will read it and so not be so alarmed at the mention of mobility with scalable routing. I first described this in June 2007 and this full description, with diagrams, has been available for 8 months: http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf Hi Tom, The list of constraints due to the need for voluntary adoption is at: http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/ I have added a second last paragraph which mentions some of your concerns. As I discuss here and in the Footnote at the above page, I think your concerns are important but that there is no need to change the list itself. I intend it to be a factual list of constraints we can all agree to - even if some of them seem to be at odds with a truly satisfactory outcome in terms of endless address space and the avoidance of barriers to new entrants. Here is a reply to your message in the "Constraints on a solution ..." thread. Thanks again for your thoughtful discussion and constructive suggestions. You wrote: >> Constraints imposed by the need for voluntary adoption * >> >> A successful solution to the routing and addressing >> scaling problem is tightly constrained by the need >> for it to be voluntarily adopted, over a period of * >> years, by the great majority of end-user networks * >> of all sizes who want or need multihoming, inbound >> traffic engineering and/or portability of their >> address space between ISPs. > > Thanks once again Robin. > > My concerns would be fully covered if the above language were changed > slightly... > > A successful solution to the routing and addressing > scaling problem is tightly constrained by the need > for it to be both accessible to, and voluntarily adopted by > the great majority of established and aspiring end-user > networks who want or need multihoming, inbound > traffic engineering and/or portability of their address > space between ISPs. Because this voluntary adoption may > occur over a period of years, the benefits of the solution > itself should be broadly accessible to all end-user networks, > regardless of their size or legacy (pre-solution) protocol > endowments. I have amended the text to: be both accessible to, and voluntarily adopted by and I hope you will find that the new second-last paragraph at least partially mentions your concerns. The benefits resulting from the best imaginable solution for IPv4 may be limited by shortage of IPv4 space and resulting difficulties for new networks in gaining this space. While no such restrictions exist with IPv6, constraints similar to 2, 3, 4 and 5 are likely to continue to be a barrier to widespread migration to IPv6. I want the list of constraints to be a terse description of things we all (ideally) agree are true. The focus is on what is needed for end-user networks and their ISPs to adopt the solution. As a statement of fact, this text does not assume that there is a solution which will meet all these constraints. I think there will be solutions which meet them all in IPv4 - but I agree that during ' adoption and in the decades to come, no matter how ubiquitously the scalable routing solution is adopted and how well it works, the address space shortage is likely to limit the IPv4 Internet's capacity to provide multihoming etc. for all end-user networks which want it. This includes especially those end-user networks which are to be established in the future and/or those whose Internet access would benefit from newly established ISPs who, in practice, may find it difficult to gain the address space they need. I added another paragraph at the end: The above constraints generally apply for IPv4 when end-user networks already have IPv4 space and need to retain full connectivity to all, or almost all, existing hosts. They may not apply in other circumstances, such as if IPv4 space is unobtainable and/or if the functionality of devices in a newly established end-user network does not depend so strongly on connectivity to IPv4 hosts and/or if the hosts in the new network are all purpose built for it. Development of a large IPv6-based cellphone network may exemplify these circumstances. which summarises the example I give in the Footnote about how I can imagine a newly established IPv6-based cell-phone network not being so affected by all these constraints. >> Broadly speaking, this means that at the time of >> introduction: >> >> 1 - The solution must provide immediate and >> compelling benefits to the end-user networks >> who adopt it, irrespective of how many other >> networks have so far adopted it. > > > 1 - The solution must provide immediate and > compelling benefits to any new or existing << > end-user network that adopts it, irrespective > of how many other networks have so far adopted > it. Thanks, I have used this suggestion. Regarding the Footnote, which I have completely rewritten, you wrote: >> Our goal is to solve the routing scaling problem >> in both the IPv4 and IPv6 Internets - and for the >> foreseeable future, the problem only manifests in >> the IPv4 Internet. Similar text is in the new Footnote. > I would prefer something along the lines of: > > Our goal is to solve the routing scaling problem in > in a manner that will accommodate growth of both IPv4 > and IPv6 Internets. Because of the looming exhaustion of > unallocated IPv4 addresses, this dual protocol orientation > represents the narrowest possible scope that any candidate > solution must address in order to have any chance of being > successful. I don't agree with this, for a number of reasons. Firstly, I don't assume that the only alternative to IPv4 is IPv6. Secondly I don't assume there is a solution to the IPv4 address shortage which enables most users to transition to some new protocol without disruption and costs they would in fact accept. I think most end-users would not accept having to abandon applications which work fine on IPv4 or having to use a network which did not give them full access to all hosts, most of which are on IPv4. Can you propose a solution which achieves the goals you want to set for any scalable routing solution? I believe the routing scalability problem can be solved for IPv4 and IPv6 separately, but I am yet to see how any system, involving scalable routing or not, could provide for mass adoption of IPv6 or some other protocol or disruption-free migration to that from IPv4. I think you have argued that a scalable routing solution for IPv4 will not succeed fully if at some point in the future, there is no more address space to accommodate new end-user networks. My counter argument is that in that case, those end-user networks wouldn't be able to get address space they would use in an unscalable way - so the real problem is address shortage and not a deficiency in routing scalability. I think the IPv4 address shortage - in absolute terms and/or in terms of overly concentrated control of usable space in the hands of established networks - will be the biggest limitation on the successful development of the Internet even if the scalable routing problem is fixed. I think IPv4 address exhaustion and fears of (to new entrants) unfair address distribution outcomes is a far better understood problem than the routing scaling problem. Ivip is well suited to making the very best use of IPv4 space - for instance by giving networks 1, 2, 3, 4, 5 or whatever number of contiguous IPv4 addresses they need. I think the most numerous types of end-user networks will be those which use one or a few IPv4 addresses. So theoretically we could have a billion such networks occupying a billion or two addresses with close to 100% utilization efficiency. I think LISP or APT could also be used in much the same way, although their EIDs are restricted to prefixes of 1, 2, 4, 8 etc. IPv4 addresses. The designers of neither proposal seem to be very interested in networks with a handful of addresses. I think the LISP designers in particular are heavily focused on substantial end-user networks which have 256 and more IPv4 addresses. Yet the whole benefit of LISP-ALT is its ability to handle essentially limitless numbers of EIDs and therefore end-user networks. I think LISP-NERD, the fastest and simplest of the proposals, could easily scale to 10 or 20 million EIDs. Yet it is impossible for me to imagine more than this number of fixed (non-mobile) end-user networks ever needing multihoming. With a population of 10B people, 10M end-user networks would be one for every 1000 people. I just cant imagine any more than this number of fixed networks having such a desire for multihoming to get two physically separate links and ISPs. Nor can I imagine more than this number of fixed end-user networks needing portability. So if LISP-ALT is going to be better than LISP-NERD, it is only going to be because LISP-NERD can't scale to the number of EIDs which LISP-ALT can handle with ease. (LISP-NERD, APT and Ivip, is far superior to LISP-ALT or TRRP because these first three involve little or no delay to any packets while the latter two involve often significant delays to initial packets due to the delays and perhaps packet losses inherent in their completely decentralised global query server networks. My point is that if LISP-ALT is to be better than LISP-NERD, then it must be due to LISP-ALT supporting mobile end-user networks. It can do this, with the TTR Mobility approach - as long as the designers accept that this involves the ETR is separate from the end-user network (they currently assume it within the end-user network) and if they accept the ETR not even being in the access network - it is in a network of the TTR company (or some network of an ISP which is where the TTR company has its TTR). The TTR is typically physically close to the access network, such as 100km or less: http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf So if LISP-ALT is to be superior to LISP-NERD for IPv4 - meaning it is going to support 100M, 1B, 2B etc. EIDs (and nearly the same number of end-user networks), then it is going to have to support Mobility - and mobile devices probably only need a single IPv4 address. The same is true of APT and Ivip - both can use the TTR Mobility approach and both must support mobility if they are going to cope with more end-user networks than LISP-NERD could comfortably handle. Ivip is intended to scale well to billions of micronets (EIDs in LISP terminology) and to have many advantages over LISP-ALT/NERD and the other alternatives, including better modularity and better support for the TTR Mobility model. To summarise the above: Ivip should be highly capable of using IPv4 space in a highly efficient manner. While the designers of APT and LISP don't seem to be thinking in these terms, I think their systems could do much the same. So I think the best scalable routing system for IPv4 will enable a very high utilization of IPv4 space. In principle, this may provide considerable leeway for new-entrant end-user networks. With Ivip the new SPI space (Scalable PI space) for each end-user network will be rented from some company which "own" a much larger "Mapped Address Block" (MAB), which is a BGP advertised prefix. A typical MAB may contain 64K to 1M or whatever IPv4 addresses - and this can be used for micronets of all sizes, including in principle 64K or 1M or whatever single IPv4 address micronets. The companies which "own" the MABs and rent out the space will not necessarily be ISPs. They will generally be commercial operations like ISPs, but they don't need an access network. The MAB company needs to ensure there are OITRDs (Open ITRs in the DFZ - like LISP Proxy Tunnel Routers) for its MABs, ideally multiple OITRDs physically distributed all over the Net. If it runs them itself, the MAB company needs to be an AS. However, it could easily pay some other company to run those OITRDs. In a fully developed Ivip system, the global unicast address space would be divided into several types of usage. The actual BGP advertised prefixes for these could be all over the place. 1 - Conventional prefixes for ISPs which use it for their own internal purposes, their servers and routers etc. and for providing PA space to many of their customers. This PA space includes substantial end-user networks which need multiple addresses. It also includes the hundreds of millions of DSL, cable modem etc. customers who currently use a single IPv4 address each. 2 - Conventional prefixes for end-user networks which are ASes and are not using Ivip-mapped space. 3 - MABs which are "owned" by MAB companies and rented out to end-user networks which are using this Ivip-mapped SPI space. If we imagine an idealised situation in which all the end-user networks adopt SPI space then this leaves only three categories of address space: 1a - ISPs use this for their internal purposes, and for ITR and ETR addresses. 1b - That part of ISP's prefixes which are devoted to their numerous PA customers. 3 - MAB space which is used with potentially very high utilization rates approaching 100% for SPI-using end-user networks. In the long-term future, here are some figures: 1a - 100M } ISPs } 1b - 2,000M } 3 - 1,600M } MAB companies, which are not necessarily ISPs. Let's say there are 10M fixed end-user networks using SPI space and that on average they need 80 IPv4 addresses. Most need less, such as 4 or 8 and quite a few need only 1 or 2. However a small number of these are corporations, universities, hospitals, government departments, hosting companies etc. which need thousands or hundreds of thousands of IPv4 addresses. This leaves 800M IPv4 SPI addresses available for mobile end-user networks - physically mobile devices such as cellphones, media players or PCs. There won't be much difference in the near future - an Iphone or Gphone is arguably all these already. These will work fine with a single IPv4 address. These devices can use this address via Ivip and the TTR Mobility system no matter what their connection to the Net, including behind NAT. Many such mobile devices will have their CoA on one of the 1b addresses - they will have a PA address to themselves. Others will be behind NAT, so multiple such devices might be on WiFi etc. behind NAT and sharing a single 1b address. These mobile devices need at least one CoA - and they need their own unique SPI address - type 3, which they rent from the MAB company, which is not necessarily an ISP. I think that in your model of IPv4 adoption, the crucial question is how new entrants: Aspiring ISPs End-user networks which want an AS and their own PI prefixes. gain access to address space when it is all held by either existing ISPs or existing PI-using end-user networks. In the above model of Ivip usage (I think LISP or APT would be the same in principle) the system does provide SPI space for potentially far more end-user networks than could ever have the resources to get their own PI space. 1, 2, 3, 64 to 128 or similar smallish number of IPv4 addresses will surely be less expensive than the full costs of gaining one or more /24 prefixes and having ISPs advertise it in BGP. (Theoretically the current /24 limit on the prefixes routers accept could be loosened to allow 128, 64, 32 etc. address prefixes - but I can't imagine this happening as long as there is already unsustainable growth in the number of DFZ routes.) Mobile end-users are dependent on ISPs in one way or another to give them Internet access and a CoA. They are also dependent on a MAB company from whom they rent probably a single IPv4 address, which they can use via any ISP in the world. They also need to pay a TTR company, which needs its own 1a type of space to run its TTRs (which are ETRs as far as the Ivip system is concerned). However a single TTR on a single IP address can simultaneously handle dozens to hundreds of simultaneous mobile end-users via the one IP address. A non-mobile end-user network does not need any PA space - since it has no CoA. They need one or two ISPs to provide Internet access. No matter how many SPI addresses each end-user network has, these only require a single ETR in each of its ISPs. Each such ETR can simultaneously serve the needs of many such end-user networks. With Ivip, the ETRs for fixed end-user networks are in the ISPs they use. This is totally different than for LISP, in which each end-user network has its own ETR for each ISP. So for LISP, no matter how many EID addressees the end-user network has, it consumes at least one IPv4 address for the ETR it uses for each of its two or more ISPs. These ETR addresses come from the ISP's 1a type space. So an ISP with 10,000 LISP end-user networks needs at least 10,000 separate type 1a IP addresses for all these ETR addresses. With Ivip, the same ISP might handle 100 end-user networks with each of its ETRs, so it only needs 100 type 1a IPv4 addresses. In this model, it is vital that aspiring ISPs AND MAB companies can get the address space they need. To the extent that they can and to the extent that the compete and provide good services, this enables the actual SPI-using end-user networks to get the Internet access they need AND the SPI address space they need. So your concern about IPv4 address space shortage and control by incumbents is just as valid as without Ivip. The details are different, because MAB companies are not necessarily ISPs, with all their physical infrastructure in particular locations. I can imagine Ivip working nicely and providing really high utilization for the IPv4 address space - provided it is made available by whoever currently "owns" it. If, as I suspect, we will be stuck in IPv4 for a very long time, I think there will be increasing regulatory pressures to free up underutilised address space to make it available to ISPs and MAB companies which will use it efficiently. Also, those companies which do use it efficiently will be able to derive profits and so pay a price for the space which makes it attractive for underutilising companies to sell it. Still, depending on the world's population and how important it will be for cellphones/PCs to have a globally mobile IPv4 address, there may well be a point, even with the fairest distribution of the 3.7B global unicast IPv4 addresses, where the demand can only be met by putting some or many mobile devices on IPv6 and/or by forcing some or many DSL etc. customers onto some second-rate kind of NATed service, rather than the current practice of giving each customer their own global unicast IPv4 address. This is a long way of saying that in principle I agree with your concerns, but that I can imagine technical and commercial developments - such as Ivip with TTR mobility - which enable the IPv4 address space to be utilized close to 100%. Since I foresee the barriers to mass IPv6 adoption (except perhaps for cellphones) will remain very high, I think it will generally be cheaper and easier at any one point in time to keep making the most of IPv4 than to for anyone to try to migrate to IPv6 without using an IPv4 address. Arguably, this would be a painful, drawn-out torture. Maybe it would be best if the entire IPv4 Internet evaporated sometime soon and forced everyone to move to IPv6 instead. It is not a popular position, but I think there is a lot of scope for squeezing more and more from IPv4 and that we will probably be depending on it as THE global Internet for decades to come. At the same time, I am keen to facilitate any development which could provide a better alternative. >> Note on IPv6 mobile devices. I am envisaging a situation, such as >> in China or other countries, where cellphones and mobile PCs etc. >> need an IP address in order for various voice and messaging services >> to be provided, and for direct communications between devices in the >> same or similar mobile networks. > > It's not an unimaginable scenario, but if China was truly hampered by a > shortage of public IP addresses, that problem would have manifested > itself years ago, in the course of extending non-mobile, IPv4-based > Internet access. For a variety of reasons, China instead chose to > develop alternative approaches for solving this problem -- mechanisms > that are now coming to be known more widely as "carrier grade NATs." > Scarcity of IPv4 was almost certainly not the primary factor driving > this choice, but I would say that among the less obvious considerations, > the commercial/competitive advantages of operator-imposed addressing > were at least if not more important than more widely remarked-upon > concerns about domestic order and state security. Thus, I would suggest > that the China case tends to point to a quite different future than the > one you suggest -- one that rather usefully illuminates the kind of > concerns that I've tried to articulate in this exchange. I understand from this that what I wrote about widespread IPv6 adoption scenarios is less likely to occur than I suggested. I am keen to know of anything concerning IPv6 adoption or the lack thereof in large mobile networks, in China and in other countries where one might expect the IPv4 address shortage to strongly motivate the adoption of IPv6-only or perhaps dual stack services. I think it is relevant to scalable routing, but perhaps it is too contentious to be put on the RRG list. I see you have some research materials at: http://tinyurl.com/IPliquidity which leads to a page at your site http://www.eyeconomics.com . > (for the record: I had the unique privilege of playing a leading role in > the design, deployment, activation, and shortly thereafter the > dismantling of the only international joint venture Internet access > service in China -- the ill-fated "Legend-AOL"... an absolute commercial > disaster, but an amazing/unique learning experience for me personally). Very interesting. I hope this learning experience somehow pays the bills today! I see http://www.caida.org/home/staff/tvest/ has your your extensive ~2006 CV and I understand you are part of the RIPE NCC Science Group, though I found no web pages for this. >> The huge number of such mobile >> devices precludes giving each an IPv4 global unicast address, and for >> many purposes (but not global IPv4 connectivity) an IPv6 address may >> work fine. >> >> With a sufficiently large number of cellphones etc. on IPv6 like >> this, it would be profitable to deploy many commercial IPv6 servers >> to provide "content" for these devices would also be. This would >> make non-mobile IPv6-only services more attractive. This "mobile >> first" scenario for widespread IPv6 adoption is the most likely one I >> can imagine. A less likely scenario is certain countries providing >> IPv6 only DSL etc. services to customers who cannot access any IPv4 >> service. > > I agree with you that it's the most likely of all the plausible > scenarios that one might imagine today. > Unfortunately, I think that it too is highly unlikely. OK - but see the footnote at: http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/ for why I think the total functionality of a large IPv6 cellphone network wouldn't depend so much on IPv4 connectivity as would conventional Internet services. > Not sure if it was your intent to incorporate the mobile scenario in the > footnote, but I would recommend leaving it out. I wrote a longer footnote which mentions it extensively. I think that for most RRG folks: Scalable_Routing + Mobility = Teeth-itch I hope people will read: http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf and so hopefully realise that a core-edge separation scheme such as LISP, APT or Ivip can directly support a new ETR-like Translating Tunnel Router approach to global IP address mobility, for IPv4 and IPv6. This would be a good complement to existing MIP techniques. It does NOT involve frequent mapping changes - such as every time the MN gets a new CoA. >> Hi Tom, >> >> I will respond more fully to your thoughtful message separately, >> probably with a subject like "Breaking IPv4's constraints". > > I'll look forward to that... I am hoping that this message and the footnote is a good response to the interesting matters you have raised so far. >> ... >> >> While this text embodies what I always meant by "incremental >> deployability" I am not trying to define this term. You wrote >> several times about my text as if it was to become "RRG "incremental >> deployability" recommendations". > > I appreciate the clarification -- was not really clear about the > "normative" content of the deployability text, apart from the obvious > (i.e., no coercive authority, etc. -- already covered). In any case, any > apparent mischaracterizations were the product of uncertainty, and not > of any positive assumptions on my part that are inconsistent with your > response... i.e., please consider them to be idiosyncrasies of phrasing > with no particular relevance. OK. >> ... >> >> I sense you are very concerned about the difficulty of establishing >> Internet services beyond the finite constraints of IPv4. > > That is fair to say! With good reason, I believe. While I can imagine Ivip and fair distribution of IPv4 space creating a better IPv4 outcome than most people think possible, even if these things eventuate as I hope, there will be many years of difficulties beforehand. >> I think there's nothing which could be written now which would >> contribute to a solution to this problem. > > I would hesitate to reach that conclusion, in part for the following > reason(s): > > 1. Any future RRG "final product" is almost certain to come after IPv4 > exhaustion and privatization (de facto and/or de jure). I agree. > 2. If, after that point, RRG solutions are primarily or exclusively > oriented toward IPv4 scaling/perpetuation, that will effectively put RRG > in the novel role of maintainer of private/proprietary resources -- > "proprietary" in a sense not unlike that in which specific branded > commercial hardware or software is proprietary. The owners of the new > proprietary resources may be numerous and widely distributed, but it > will forevermore be a closed group, with something like "membership by > invitation only." Yes - but this assumes that the RRG solution could have done more to enable widespread adoption of IPv6. That is outside the formal scope of the RRG's goals, AFAIK. If I can make Ivip in some way facilitate migration from IPv4 to IPv6 or any better alternative, I will do so. Without any specific suggestion for how a scalable routing solution or anything else could help with easing the dependence on IPv4, I don't think it is fair to insist that the RRG or anyone else should do more to achieve such a goal. I count it as a highly desirable goal, but not a requirement. If I thought there was a way of doing it, then I would change my mind and regard it as a requirement - because it is so important. I am trying to keep the list of constraints and its associated test as terse as possible. The first of the new paragraphs at least acknowledges that in practical terms, the constraints apply entirely within IPv4 and also suggest that constraints similar to 2, 3, 4 and 5 are a major factor in the failure of IPv6 to be widely adopted. Please suggest improvements, but I am really trying to keep it short. It is my experience that anything longer than about 4 paragraphs tends to be largely ignored by some key RRG people. > 3. Over the past decade or so, the population of routing system > participants has been very dynamic, with appx. 5-10% growth in the form > of new entrants each year (based on RIR "initial allocation" > transactions involving IPv4) and a somewhat lower (and much harder to > estimate) rate of departures due to M&A and/or termination of service.* > After IPv4 runout or privatization (whichever comes first), the new add > rate is likely to slow down to a trickle, leaving an ever-growing > population of frustrated would-have-been routing system participants. I know little about these things, but it is easy for me to imagine the big fish eating the small fish - especially with the economic crisis. I guess the most numerous and significant of these aspiring new networks - in terms of competition policy and in terms of development of Internet services in countries which are not well served at present - would be new ISPs and cell-phone companies wanting to be ISPs to give their customers direct Internet access. There would also be a growing number of end-user networks - new and existing - who have the resources and the impetus to get multihoming, TE and portability with existing BGP techniques, if they could only get their own PI space. I think a good scalable routing solution will enable many such end-user networks to use the new kind of address space, without the investment in BGP routers and expertise. Furthermore, many more smaller networks who would never have the resources or justification to get PI prefixes will be able to use the new kind of scalable address space too, for low costs and by using as few IP addresses as they really need. > At the same time, the drop rate is likely to increase as some large, > well-heeled operators accelerate their pursuit of low-hanging IPv4 > acquisition targets. Overall, this change is going to represent a > radical, unprecedented break with the Internet growth processes of the > last two decades. I don't think that it will take long for the general > public to notice, and react. > > If and when all of this comes to pass, "open addressing" will quickly > achieve, at least, the same level salience/urgency as "scalable routing" > in the overall RRG problem space. In anticipation of (at the very least) > this possibility, I would suggest that it would be prudent for RRG to > capitalize on every possible opportunity to reaffirm its commitment to > delivering a solution to both problems, starting now. I fully agree that the RRG should discuss and encourage the design of scalable routing solutions which also help with: 1 - Improving IPv4 address space utilization. I think any decent core-edge separation scheme will be capable of this. 2 - Fairer allocation of IPv4 addresses to new ISPs. I can't see how the RRG can affect this, other than by helping to design a flexible, efficient, scalable routing system which enables finer slicing and dicing of the address space, which is the same thing as 1 above. 3 - Adoption of and transition to IPv6. This nut has never come close to being cracked. I think it may be impossible. I don't assume it is so, but until you or anyone else has a scheme which will work, in part by meeting constraints similar to those I listed, I don't think it is fair to expect anyone else to solve this infernal problem. I also believe that because the TTR mobility approach is so desirable and is such an easy extension of a core-edge separation scheme, that the RRG should take a greater interest in it. Also, mobility is the only way I can imagine that any of the proposals LISP-ALT, APT, Ivip or TRRP will be required to scale beyond the 10M or so EIDs which could easily be handled by the simpler, more direct and optimally fast LISP-NERD. > Thanks again for being receptive to my troublesome and somewhat belated > expressions of concern... > > Tom I really appreciate your messages. This field has many technical, human and commercial complexities. I think progress often results from detailed, thoughtful discussions. - Robin
- [rrg] Constraints on a solution - "incrementally … Robin Whittle
- Re: [rrg] Constraints on a solution - "incrementa… Joel M. Halpern
- Re: [rrg] Constraints on a solution - "incrementa… Tom Vest
- Re: [rrg] Constraints on a solution - "incrementa… Robin Whittle
- Re: [rrg] Constraints on a solution - "incrementa… Robin Whittle
- Re: [rrg] Constraints on a solution - "incrementa… Tom Vest
- Re: [rrg] Constraints on a solution - "incrementa… Robin Whittle
- Re: [rrg] Constraints on a solution - "incrementa… Tom Vest
- [rrg] Scalable solution hitting IPv4's limits Robin Whittle
- Re: [rrg] Scalable solution hitting IPv4's limits… Tom Vest
- Re: [rrg] Scalable solution hitting IPv4's limits… Robin Whittle
- Re: [rrg] Scalable solution hitting IPv4's limits… Tom Vest