sorry about long latency but andre did some analysis that's relevant to joe's message during this nanog thread earlier this month. include joe's message for context and andre's response below. (andre's response relates to last paragraph of joe's message) k ================================================== Date: Mon, 6 May 2002 14:14:34 -0400 From: Joe Abley <jabley@automagic.org> Subject: Re: IP renumbering timeframe To: David Conrad <david.conrad@nominum.com> Cc: grant@tnarg.org, nanog <nanog@merit.edu> On Mon, May 06, 2002 at 10:41:09AM -0700, David Conrad wrote: > On 5/6/02 10:20 AM, "Grant A. Kirkwood" <grant@tnarg.org> wrote: > > I'm sorry, but ARIN's policy practically _encourages_ the "efficient > > wasting" of space to qualify for PI space. This is one of the most > > frustrating things to deal with. > > As someone who used to run a registry, one of the most frustrating things to > deal with was watching ISPs pee in their own pool and then scream at the > registries 'cause the water was yellow. > > Just how big should the DFZ be? > > Given the Internet is not (yet, at least) a fascist state, the registries > rely on ISPs to be aware of the environment in which they are operating. As > it is unlikely any of the registries will be hiring independent auditing > firms to verify true utilization, there is need for a certain level of > trust. If an ISP is too small to justify the allocation of a /20, then they > should obtain address space from an upstream provider so that they do not > add yet another entry to the DFZ. A multi-homed ISP who advertises PA space to multiple transit providers adds state to the DFZ. It is common practice for PA-delegating transit providers to punch a whole in their covering supernet advertisements in order to facilitate this. The PI/PA distinction seems unhelpful in the case of a multi-homed ISP. > The term "tragedy" in "the tragedy of the commons" is not a mistake... It would be interesting to see multi-homed ISPs take the time to classify the parts of the infrastructure which are hard to renumber, versus those that are easy to renumber. It may be quite trivial to renumber large dial/cable/DSL address pools every now and then, as and when transit providers change. It may be a minor nightmare to renumber nameservers that report authoritatively for domains in a large collection of separately-managed TLDs. I wonder whether the average small, multi-homed ISP who currently lusts after PI space would find all their renumbering nightmares reduced to entirely manageable levels by the delegation of (say) 1 x /24 PI netblock to number nameservers and mail exchangers, and n x /whatever netblocks to number everything else. If the justification requirements for PI space were relaxed to accommodate this kind of scenario (or if ISPs were more inclined to use the existing requirements in this way), perhaps fewer multi- omed ISPs would feel obliged to tell lies to RIRs to obtain address delegations they don't really need. But the DFZ still accumulates additional state every time an edge network multi-homes. It would be interesting to compare the growth in the numbers of single-homed vs. multi-homed edge networks. If the edge of the network is becoming predominantly multi-homed, the goals of the RIRs wrt DFZ state containment might usefully be modified to better serve other objectives. Joe ----- End forwarded message ----- From: broido@caida.org Joe, We tracked this trend in "Internet expansion, refinement and churn" -- http://www.caida.org/outreach/papers/2002/EGR/ We also just looked at the data available from RouteViews for May 15, 2001. We selected 36 tables (each from a different RouteViews peer) that each had over 109K prefixes. We define prefixes representing DFZ ('default free zone') as those present in 19 or more tables ("semiglobal prefixes"). (See above paper for details on terminology/methodology). Multihoming was on the rise in 1997-1999, but slowed in 2000-2002. As of May 15, 2002, multihomed ASes make up 63% of all ASes. This is an increase of 1.4% since November 2001 (in 6 months). Currently available BGP data sheds doubt on the assumption that multihoming is the dominant contributor to growth of DFZ state. Note that when people refer to the "[problem of] multi-homed ASes" (i.e., ASes with multiple adjacent upstream ASes), they usually mean "nontransit multihomed" since most (over 75%) transit ASes are multihomed, and single homed transit ASes (i.e. ASes with only one upstream AS -- 541 out of 13281 ASes found in these BGP tables) may be an artifact of the undercoverage of BGP AS connectivity data. Multihomed nontransit ASes make up 60% of all non-transit ASes. So, as it stands now, A. The share of DFZ prefixes announced by non-transit multihomed ASes remained at 30% throughout 2000-2002, whereas the share of non-transit multihomed ASes grew 4.7%: May 2000 May 2001 15 May 2002 %ASes: 45.66 48.61 50.36 %prefixes: 29.43 31.30 30.15 This data shows that non-transit multhomed ASes contribute less than their `fair share' of prefixes to the DFZ BGP table. Multihoming would thus seem _not_ to be the primary cause of DFZ BGP table growth. B. As of 15 May 2002, multihomed transit and non-transit ASes originate 77.3% of all prefixes and 75.4% of all more specifics. These ASes announce their `fair' share of more specifics, i.e., proportionate to the total share of their prefixes in the table. The implication is that more specifics and multihoming are independent notions. C. The largest pool of prefixes (47.2%) is announced by transit multihomed ASes (as opposed to transit single-homed, or multi- and single- homed nontransit ASes.) Note that there is an inherent ambiguity in BGP data caused by availability of only a handful of representative tables, which leads us to suspect that there may be more multihomed ASes than this collection of BGP tables suggest. There may also be trends associated with prefixes carried from one group to another, e.g., when an AS becomes transit from non-transit or vice versa. As it stands now, however, we can only say that the largest set of DFZ prefixes, almost 1/2 of total, is announced by transit multihomed ASes (likely on behalf of their customers whose individual degree of multi- or single homing cannot be estimated using BGP tables.) The ultimate conclusion is that available data does not support the statement that multihoming is the dominant source of core BGP table growth. Andre, kc ps: last arin presentation may also be of interest http://www.caida.org/outreach/presentations/arin0402/