|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: IP renumbering timeframe
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 <[email protected]>
Subject: Re: IP renumbering timeframe
To: David Conrad <[email protected]>
Cc: [email protected], nanog <[email protected]>
On Mon, May 06, 2002 at 10:41:09AM -0700, David Conrad wrote:
> On 5/6/02 10:20 AM, "Grant A. Kirkwood" <[email protected]> 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: [email protected]
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/
|