IETF Logo Mail Archive

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

Iljitsch van Beijnum <iljitsch@muada.com> Sat, 25 October 2014 14:07 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 911D11A0023; Sat, 25 Oct 2014 07:07: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 2kyx0P4dVsiJ; Sat, 25 Oct 2014 07:07:12 -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 2E3041A0015; Sat, 25 Oct 2014 07:07:12 -0700 (PDT)
Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:5c73:24de:d860:bd40] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id s9PE6vFT001411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Oct 2014 16:06:57 +0200 (CEST) (envelope-from iljitsch@muada.com)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <544BA11F.7050102@globis.net>
Date: Sat, 25 Oct 2014 16:07:00 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <31FED6FF-5398-4793-87F3-AC873811FD64@muada.com>
References: <F5C06CAF-0AD2-4225-8EE7-FC72CE9913F0@muada.com> <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <011101cfe935$d0e8a600$72b9f200$@riw.us> <544BA11F.7050102@globis.net>
To: Ray Hunter <v6ops@globis.net>
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/8IrX-PH0vB11OPmxky6x97CGsjU
Cc: Russ White <russw@riw.us>, 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: Sat, 25 Oct 2014 14:07:15 -0000

On 25 Oct 2014, at 15:09, Ray Hunter <v6ops@globis.net> wrote:

> This is natural behaviour, unless there's a less blunt instrument applied to managing BGP routing table size than simply restricting maximum prefix length per peer.

Please have a look at my draft. I think that establishing an aggregate of last resort coupled with BGP communities that allow for selectively filtering deaggregates covered by an aggregate in the places where they aren't desired helps both big organizations and network operators.

If a big organization hires two tier-1 ISPs, for instance, and then makes sure that the ISPs that its organizational subunits select for their connectivity interconnect with the ISPs announcing the AoLR (as peers or as customers), only networks that get paid need to carry the deaggregates. Which is good for the ISPs that get paid (obviously), for the ones that don't get paid (no deaggregates) and for the organization (they know who to blame for connectivity issues).

v2.23.0 | Report a Bug | By Email