Re: [v6ops] [GROW] Deaggregation data
Christopher Morrow <christopher.morrow@gmail.com> Mon, 20 October 2014 21:59 UTC
Return-Path: <christopher.morrow@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18B81ACF64; Mon, 20 Oct 2014 14:59:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3
X-Spam-Level: ***
X-Spam-Status: No, score=3 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MANGLED_PAIN=2.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8j-ztS9lvM8; Mon, 20 Oct 2014 14:59:06 -0700 (PDT)
Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F2451ACF6C; Mon, 20 Oct 2014 14:58:51 -0700 (PDT)
Received: by mail-yh0-f46.google.com with SMTP id f73so4153771yha.5 for <multiple recipients>; Mon, 20 Oct 2014 14:58:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IJSGlD0IcSaHmst6F14p+dAWasOywL3dCKWO3W7QG8g=; b=FnwHcJ/OASdfdTgpqCoZ7HbNAbO8a7eChVhEU/CnVgmwalp12ri6k2PBmhEHeoQRYL nRWBJZvsJ+k1bWm3J8I7Y4cuhls7x+nYf18tCV2I2AueN7vWzJDu8LSNDmUnK3swvA/B qWsW4f6O0mJjPSZAcRjAjs6wqtktzuoI8Acj0vF2g4N4b0lJrQTRXJO2V1XbRbg0PKA6 sVe4EH9ijU8xmA65Zb326dj8MmX/DsPY9wjom4kJtx8oGFomwIlPL0r9RQz5Fd9XzoJp KyTzhRTL0G3sJ5VZxget3xi5HxK1tiPtHWvpGpLXLDgqeaZSeJeDN/RrgxXrf8BnCuvS BE3Q==
MIME-Version: 1.0
X-Received: by 10.220.97.72 with SMTP id k8mr25719389vcn.5.1413842330781; Mon, 20 Oct 2014 14:58:50 -0700 (PDT)
Received: by 10.221.44.8 with HTTP; Mon, 20 Oct 2014 14:58:50 -0700 (PDT)
In-Reply-To: <54417FF4.3000907@foobar.org>
References: <F5C06CAF-0AD2-4225-8EE7-FC72CE9913F0@muada.com> <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <543FA152.4080907@foobar.org> <9C220463-4D0E-465B-ADF5-390518F180C7@muada.com> <54403599.6040205@foobar.org> <m27fzypr93.wl%randy@psg.com> <54417FF4.3000907@foobar.org>
Date: Mon, 20 Oct 2014 17:58:50 -0400
Message-ID: <CAL9jLaZXdU0gn2C7o_uf8KNGPCr5_A8K6wnr5fnjmNE6U0dBUQ@mail.gmail.com>
From: Christopher Morrow <christopher.morrow@gmail.com>
To: Nick Hilliard <nick@foobar.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/5N9kMZvXmmNSf9ipC-Nf2Epyjfc
Cc: V6 Ops List <v6ops@ietf.org>, grow <grow@ietf.org>
Subject: Re: [v6ops] [GROW] Deaggregation data
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Oct 2014 21:59:09 -0000
On Fri, Oct 17, 2014 at 4:45 PM, Nick Hilliard <nick@foobar.org> wrote: > On 17/10/2014 17:58, Randy Bush wrote: >> [ not pickin' on you, nick ] >> >> trying to find protein in this whole thread. > > thin pickings :-( > >> in the long run, why will v6 not suffer the <your expletive about >> reasons goes here> same deaggregation which is about half of the v4 >> routing table? > > It might, but it won't matter as much because the number of baseline ipv6 > allocations will be a whole pile lower. Here's why. > > 1. retrospectively: the RIR policies of not handing out piecemeal > allocations based on 2Y policy means that most organisations will never > need a second allocation outside their /32. If you look at existing RIR > allocations, many of them are to the same organisations. Looking at: > > ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt > > There are: > > 7564 LIRs with ipv4 allocations outside 185/8 > 19856 ipv4 allocations outside 185/8 > > so the average # of allocations per LIR is ~2.62 for pre-last /8 addresses. wow, there are 4454 LIR allocations inside 185/8 :) with: 4568 distinct prefixes. (that's probably reasonably expected though) > Over all allocations, the numbers are 24416 allocations and 10134 LIRs. > I.e. the last /8 policy has dramatically increased the number of LIRs with > a single allocation. Possibly this is related to lack of PI space. is this also skewed because 'space is getting short, make sure to get your requests in NOW!' behavior? (or 'scarcity got people's attention') I guessed (so probably not the best judge for science) that 62/8 was being allocated for a longer bit of time, it seems: Apr 1997 -> Mar 2011 There are 671 allocations in this space though, across 457 LIRs or 1.49 prefixes/LIR... so it seems that the numbers oscillate a bit inside of the buckets, interesting I suppose. (perhaps not super germaine though) NOTE: why don't v6 allocations in that file have 'ALLOCATED PA' in their entries? 20121123 185.11.8.0/22 ALLOCATED PA 20101023 2a02:2718::/29 despite: inet6num: 2a02:2718::/29 netname: YE-PTC-20101023 descr: Public Telecommunication Corporation country: ye org: ORG-PTC4-RIPE admin-c: YAA330-RIPE admin-c: IIA13-RIPE tech-c: MRA220-RIPE status: ALLOCATED-BY-RIR mnt-by: RIPE-NCC-HM-MNT > RIPE has allocated 8069 ipv6 prefixes to 7849 LIRs, i.e. an allocation rate > of 1.02. This includes last /8 assignments from RIPE's silly policy of > requiring an ipv6 allocation for a last /8 assignment. > > This indicates that virtually all LIRs are staying within the bounds of > their original allocations. This will reduce future pressure on the number > of prefixes in the dfz. I also wonder how much the spread of LIR/org really is? for MDN or other uses of 'oops, I need another /32'. > 2. in future: there are 10398 LIRs listed in alloclist. Of these, 7849 or > almost exactly 75% of LIRs already have IPv6 allocations. So assuming that > all RIPE LIRs will have an ipv6 allocation in future, that's growth from > 8069 to ~10700 + one for each new LIR. > > 3. further deaggregation of the ipv4 dfz will be driven by the market > economics of address holders splitting up their net blocks. > > 4. down the road, if we can get RIPE to stop its silly policy of requiring > an ipv6 allocation in order to get an ipv4 allocation from the last /8, > this will further reduce pressure on the overall number of allocations, > which leads to: > >> maybe if we start filtering now. but we know how well that went in ipv4 >> when their suits called our suits and said "we pay you to let us contact >> <deaggregator>. > > The baseline for starting to deaggregate will be much lower for ipv6 and > there will be much less pressure in future to deaggregate. why is that? I thought geoff's numbers/reasons for deaggregation were linked more to TE (perceived or supposed) than anything else? (maybe a bunch of 'redistributed connected' as well) -chris > I haven't looked at the other RIR figures. No doubt they differ in > numbers, but my hunch is that they tell a similar story. > > Nick > > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow
- [v6ops] Deaggregation by large organizations Iljitsch van Beijnum
- Re: [v6ops] [GROW] Deaggregation by large organiz… Iljitsch van Beijnum
- Re: [v6ops] [GROW] Deaggregation by large organiz… Nick Hilliard
- Re: [v6ops] [GROW] Deaggregation by large organiz… Nick Hilliard
- Re: [v6ops] Deaggregation by large organizations Ted Lemon
- Re: [v6ops] [GROW] Deaggregation by large organiz… Brian E Carpenter
- Re: [v6ops] [GROW] Deaggregation by large organiz… Christopher Morrow
- Re: [v6ops] Deaggregation by large organizations Owen DeLong
- Re: [v6ops] [GROW] Deaggregation by large organiz… Mikael Abrahamsson
- Re: [v6ops] [GROW] Deaggregation by large organiz… Iljitsch van Beijnum
- Re: [v6ops] [GROW] Deaggregation by large organiz… Iljitsch van Beijnum
- Re: [v6ops] [GROW] Deaggregation by large organiz… Nick Hilliard
- Re: [v6ops] [GROW] Deaggregation by large organiz… Alvaro Retana (aretana)
- Re: [v6ops] [GROW] Deaggregation by large organiz… Christopher Morrow
- Re: [v6ops] [GROW] Deaggregation by large organiz… Gert Doering
- Re: [v6ops] [GROW] Deaggregation by large organiz… Christopher Morrow
- Re: [v6ops] [GROW] Deaggregation by large organiz… Gert Doering
- Re: [v6ops] [GROW] Deaggregation by large organiz… Christopher Morrow
- Re: [v6ops] [GROW] Deaggregation by large organiz… joel jaeggli
- Re: [v6ops] [GROW] Deaggregation by large organiz… Iljitsch van Beijnum
- Re: [v6ops] [GROW] Deaggregation by large organiz… Nick Hilliard
- Re: [v6ops] [GROW] Deaggregation by large organiz… Jeroen Massar
- Re: [v6ops] [GROW] Deaggregation by large organiz… Iljitsch van Beijnum
- Re: [v6ops] [GROW] Deaggregation by large organiz… Enno Rey
- Re: [v6ops] [GROW] Deaggregation by large organiz… Nick Hilliard
- Re: [v6ops] [GROW] Deaggregation by large organiz… Jeroen Massar
- Re: [v6ops] [GROW] Deaggregation by large organiz… Enno Rey
- Re: [v6ops] [GROW] Deaggregation by large organiz… Owen DeLong
- Re: [v6ops] [GROW] Deaggregation by large organiz… Owen DeLong
- Re: [v6ops] [GROW] Deaggregation by large organiz… Gert Doering
- Re: [v6ops] [GROW] Deaggregation by large organiz… Jeroen Massar
- Re: [v6ops] [GROW] Deaggregation by large organiz… Christopher Morrow
- Re: [v6ops] [GROW] Deaggregation by large organiz… Russ White
- Re: [v6ops] [GROW] Deaggregation by large organiz… Alvaro Retana (aretana)
- Re: [v6ops] [GROW] Deaggregation by large organiz… Nick Hilliard
- Re: [v6ops] [GROW] Deaggregation by large organiz… Enno Rey
- Re: [v6ops] [GROW] Deaggregation by large organiz… Jeroen Massar
- Re: [v6ops] [GROW] Deaggregation data (was: Deagg… Nick Hilliard
- Re: [v6ops] [GROW] Deaggregation by large organiz… Mark Andrews
- Re: [v6ops] [GROW] Deaggregation by large organiz… Matthew Petach
- Re: [v6ops] [GROW] Deaggregation by large organiz… Owen DeLong
- Re: [v6ops] [GROW] Deaggregation by large organiz… Mark Andrews
- Re: [v6ops] [GROW] Deaggregation by large organiz… Matthew Petach
- Re: [v6ops] [GROW] Deaggregation data (was: Deagg… Marc Binderberger
- Re: [v6ops] [GROW] Deaggregation data (was: Deagg… Iljitsch van Beijnum
- Re: [v6ops] [GROW] Deaggregation data (was: Deagg… Randy Bush
- Re: [v6ops] [GROW] Deaggregation by large organiz… Gert Doering
- Re: [v6ops] [GROW] Deaggregation data Brian E Carpenter
- Re: [v6ops] [GROW] Deaggregation data Randy Bush
- Re: [v6ops] [GROW] Deaggregation data Nick Hilliard
- Re: [v6ops] [GROW] Deaggregation data (was: Deagg… Robert Raszuk
- Re: [v6ops] [GROW] Deaggregation data Nick Hilliard
- Re: [v6ops] [GROW] Deaggregation data Christopher Morrow
- Re: [v6ops] [GROW] Deaggregation data Nick Hilliard
- Re: [v6ops] [GROW] Deaggregation data Randy Bush
- Re: [v6ops] [GROW] Deaggregation data Nick Hilliard
- Re: [v6ops] [GROW] Deaggregation data (was: Deagg… Marc Binderberger
- Re: [v6ops] [GROW] Deaggregation data (was: Deagg… Pedro Andres Aranda Gutierrez
- Re: [v6ops] [GROW] Deaggregation by large organiz… Gert Doering
- [v6ops] renumbering [was Deaggregation by large o… Brian E Carpenter
- Re: [v6ops] [GROW] Deaggregation by large organiz… Ray Hunter
- Re: [v6ops] [GROW] Deaggregation by large organiz… Iljitsch van Beijnum
- Re: [v6ops] [GROW] Deaggregation by large organiz… Ray Hunter
- Re: [v6ops] [GROW] Deaggregation by large organiz… Matthew Petach
- Re: [v6ops] [GROW] Deaggregation by large organiz… Iljitsch van Beijnum