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

Iljitsch van Beijnum <iljitsch@muada.com> Thu, 16 October 2014 09:41 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 8C1151A6FE9; Thu, 16 Oct 2014 02:41:14 -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 c1ZnICz2zEet; Thu, 16 Oct 2014 02:41:11 -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 0EB061A904D; Thu, 16 Oct 2014 02:41:09 -0700 (PDT)
Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:5562:b8bc:1f02:25a8] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id s9G9cx1h059811 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 Oct 2014 11:38:59 +0200 (CEST) (envelope-from iljitsch@muada.com)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <CAL9jLaZLWG5cKPPhTtLtvn9OQOYwYjdgHCUXsWi3pZJjK+nAbQ@mail.gmail.com>
Date: Thu, 16 Oct 2014 11:40:58 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <903173CE-64D6-4FE5-98DB-B408C9586A02@muada.com>
References: <F5C06CAF-0AD2-4225-8EE7-FC72CE9913F0@muada.com> <CAL9jLaZLWG5cKPPhTtLtvn9OQOYwYjdgHCUXsWi3pZJjK+nAbQ@mail.gmail.com>
To: Christopher Morrow <christopher.morrow@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/05V1iGMDutGzHd9psnfbZeAk93U
Cc: IPv6 Operations <v6ops@ietf.org>, "grow@ietf.org grow@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 09:41:14 -0000

On 16 Oct 2014, at 0:04, Christopher Morrow <christopher.morrow@gmail.com> wrote:

>> This practice, especially if/when it becomes more common, presents two challenges:

>> 1. Large numbers of prefixes may show up in the global routing table. For instance, there is a number plan for all of the German government, which could potentially inject more than 5000 municipality prefixes into the global IPv6 routing table.

> ok <1% growth.

What do you mean?

>> Ideally, a set of best practices would be developed that strike a good balance between the needs of large organizations and the needs of the global routing system, and allow everyone to predict the consequences of different kinds of behavior and thus avoid unpleasant surprises.

> i feel like we sort of have that already, or we know how the global
> table works and people live within those constraints.

I've only heard from a few people who do this / want to do this so far, but from what I hear they really want some clarity in this area. Spending a lot of time and money to set all of this up and then discovering your prefixes are filtered is rather suboptimal.

Iljitsch