Re: [v6ops] [GROW] Deaggregation by large organizations

Iljitsch van Beijnum <iljitsch@muada.com> Thu, 16 October 2014 16:26 UTC

Return-Path: <iljitsch@muada.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 D1A221A87AB; Thu, 16 Oct 2014 09:26:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 Ket8oclLPc20; Thu, 16 Oct 2014 09:26:55 -0700 (PDT)
Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3227E1A876E; Thu, 16 Oct 2014 09:26:50 -0700 (PDT)
Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:8c56:a593:2e64:be71] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id s9GGOPUL061933 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 Oct 2014 18:24:25 +0200 (CEST) (envelope-from iljitsch@muada.com)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <543FECB3.9070600@foobar.org>
Date: Thu, 16 Oct 2014 18:26:24 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9193455D-4666-454B-981C-ABA3B1B42342@muada.com>
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> <543FECB3.9070600@foobar.org>
To: Nick Hilliard <nick@foobar.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/3BfkC8x9DYgztGFZJw5nQv8uSpo
Cc: v6ops@ietf.org, grow@ietf.org
Subject: Re: [v6ops] [GROW] Deaggregation by large organizations
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: Thu, 16 Oct 2014 16:26:57 -0000

On 16 Oct 2014, at 18:05, Nick Hilliard <nick@foobar.org> wrote:

>> Growth in IPv6 more specifics was 57% last year...

> 1y is an interesting data point, but shouldn't form the basis for a new
> policy.  What does the aggregate:more-specifics ratio look like over the
> last 5-8 years?

I haven't checked, but obviously the percentage growth was large and the absolute growth small.

But look at the v4 table. It's a mess, and we have no way to clean it up. Fortunately we can just decommission IPv4 in the foreseeable future. No such luck with IPv6, though, it'll be around for decades to come. And the good thing is that there's so much address space that we CAN make tradeoffs that will keep the routing table healthy, where we weren't in the position to do that with IPv4. It's much better to spend some time making sure we don't repeat the IPv4 mistakes and/or add some new ones rather than wait 10 years and find ourselves in an untenable situation.

Also, from the vantage point of someone who has all their prefixes routed life is good, but there are also people who run into (the possibility) of filtering. A clear message about what can and can't be expected to work with IPv6 would help them a lot.