Re: [v6ops] [GROW] Deaggregation by large organizations
Christopher Morrow <christopher.morrow@gmail.com> Thu, 16 October 2014 15:20 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 917741A1BF4; Thu, 16 Oct 2014 08:20:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.6
X-Spam-Level:
X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 1G7Bp6ewaNpx; Thu, 16 Oct 2014 08:20:50 -0700 (PDT)
Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 096AE1A1BC0; Thu, 16 Oct 2014 08:20:49 -0700 (PDT)
Received: by mail-lb0-f169.google.com with SMTP id 10so2987968lbg.14 for <multiple recipients>; Thu, 16 Oct 2014 08:20:48 -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:content-transfer-encoding; bh=0z89qqxScjReCiBUtpWo2m1Ear8fCavMT5ERJCQBDG8=; b=APu+EcIntC06Lsdc+mskwVrdOO3YzvuRE1XILCauxRWX4v/sUWGVuiL77HwQFDdpkW tYWLaf3qXRaWht8ckCYFc6BXGGEvpZ3HzAq3dGyT6SqkIO5BUBXPAeuCUul5PIQOKq99 CwiCmqHXa5D8QIyq2UDL33Z5pMV//sIhOsf6+bK/zbfy4LEAooAHbVg/hfcH0q4I0kEX xEnpedxLKy2lKtG35qB+cNySyefjLW2o5nwGNtFnfCLLIY4kDkCyxls0b0FlJvMMFtPl nc6VNHIlvoxuX3LyGazkaO0DnKCQQrp50YBk7ihN+DMbnxVstFTcIZXddYWKUmh0hUCg WTKg==
MIME-Version: 1.0
X-Received: by 10.153.11.133 with SMTP id ei5mr2291514lad.75.1413472848218; Thu, 16 Oct 2014 08:20:48 -0700 (PDT)
Received: by 10.152.88.17 with HTTP; Thu, 16 Oct 2014 08:20:48 -0700 (PDT)
In-Reply-To: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com>
References: <F5C06CAF-0AD2-4225-8EE7-FC72CE9913F0@muada.com> <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com>
Date: Thu, 16 Oct 2014 11:20:48 -0400
Message-ID: <CAL9jLaY3yzrrk5a79kVn2MVxrP7zQyo-Dotrz7BXmB+csE=Vig@mail.gmail.com>
From: Christopher Morrow <christopher.morrow@gmail.com>
To: Iljitsch van Beijnum <iljitsch@muada.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/2w6utCLJCxUlvESqYxPhleNO4zw
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 15:20:54 -0000
(apologies for again not reformatting apple-mail->gmail issues) On Thu, Oct 16, 2014 at 5:43 AM, Iljitsch van Beijnum <iljitsch@muada.com> wrote: > Let me address a few points that were brought up by different people. > > Renumbering: I think the renumbering ship sailed, and like the titanic had a bad voyage. You seem to agree. > A prefix length limit for the IPv6 DFZ: > > Someone mentioned that this didn't work in IPv6. When Sprint decided to make that /18, that didn't really work. But there's a de facto /24 limit that everyone understands. With IPv6, that would translate into a /48. Obviously no router can hold 2^48 or 2^45 I suppose there's a question about: "Is a /24 a LAN (/64) or a SITE (/48)" to be answered still. I believe SITE works better, but :) prefixes, so as a backstop against accidental/malicious IPv6 routing table explosion this doesn't help. Even exploding a /28 or so into individual /48s would kill the IPv6 DFZ. mostly this is from motherhood + apple-pie bgp neighbor configs though, right? (max-prefix in particular). > What COULD work is to have prefix length limits depending on the allocation size by the RIRs. Something like: > > 2100::/16 -> /48 > 2200::/16 -> /32 > 2200::/15 -> /29 This looks, to me, like the 'PA space is >= /32, PI >= /48' in each region's PA/PI splits... which ends up being fairly stable and fairly simple prefix-list/etc configs on devices, right? so that seems kind of sane even. I had thought the cymru folk had something like this in their templates: <https://www.team-cymru.org/ReadingRoom/Templates/IPv6Routers/junos.html> isn't what I was looking for, sadly...and is the only sort of ipv6 / route-filter related thing I quickly find on their site... perhaps some room for improvement in this area exists. Should that be an IETF action or 'get the defacto standards/bcop folk to update their docs based on the best shared wisdom' ? > > However, for this to work well the RIRs would have to group allocations of the same size into separate blocks, with the result that it would no longer be possible to reserve space to grow an allocation. (Things like allocating a /48 but reserving a /44 reduce the opportunities for prefix length filtering because now the strictest filter you can make allows 16 x as many prefixes worst case than average case. The worst and average case need to be as close together as possible.) > my impression (and I stopped paying close attention to ARIN at least 2+ yrs ago) was that RIR's were allocating PA from one large (/23?) block per RIR and PI from a different... For my work-location-provider: 2620:0:1000::/40 - PI /40 2001:4860::/32 - PA /32 2607:F8B0::/32 - PA /32 <http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml> doesn't delineate the difference between 2001:4800::/23 and 2600::/12 and 2620::/23 ... bummer. I suppose this though: <https://www.arin.net/knowledge/ip_blocks.html> is meant to delineate the differences as 'allocation blocks' vs 'assignment blocks'... (I didn't search the same sort of stuff out on ripe/apnic/etc...) > I'd say that allowing two or three extra bits for traffic engineering for PA blocks would be good. So for the part of the IPv6 space where /29s are allocated, allow /31s or /32s. As traffic engineering incoming traffic by deaggregation requires that different parts of the aggregate all generate similar levels of incoming traffic, this wouldn't usually work for organizations using PI so I'd say don't allow deaggregating below /48. > sure, this gets into the above 'give me a default understanding of the iana -> rir ranges + RIR purposes (alloc/assign) and add +N bits for TE. It's not quite answering the other part of your question about: "What will the DE gov't do? how will they run their new shiney network such that they don't have reachability concerns?" > Geographic communities: > > I know this is controversial. "Topology ain't geography". Actually, most of the time there is a significant correlation. If all German cities inject a more specific, do you really need to hear those in Tokyo or Seattle? Just send the traffic to Europe as per the aggregate and let them figure it out there. > this argues for the DE gov't having 1 ISP's for all their cities and putting the aggregate into BGP as well with the more specifics no-export'd from the ISP, not for communities, which won't reliably make it across AS boundaries. > Compiling a list of communities that identify regions/countries/cities would allow for experimentation in this place without any downsides that I can see. Don't like this? Filter the communities. There's a handy list that you can copy and paste into your filter. > > Injecting an aggregate as a point of last resort: > > I think this can be done today and probably is done today. But a document describing how to do it would probably be helpful. I'm thinking along the following lines: > ok > The AoLR (Aggregate of Last Resort) service would entail a service provider announcing the aggregate without necessarily providing connectivity towards all the places announcing more specifics covered by the aggregate. So if ISP A announces the AoLR and ISP B provides connectivity to a more specific, ISP C would send traffic to A as per the aggregate and then A would immediately hand it over to B. > > So as part of the AoLR service, a service provider would agree to accept all more specifics that fall under the aggregate (up to an agreed prefix length) from all the networks providing connectivity towards those more specifics. This would be an attractive service for tier-1s to provide, because presumably, they peer with everyone everywhere, so in the case where they receive the traffic over peering and need to deliver it to another service provider over peering, this could probably happen in the same city, so they wouldn't carry the traffic over long distances. But the (sub-)organization(s) in question still gets to buy connectivity from a wider range of smaller service providers. > > In practice an organization would contract two or more service providers to provide the AoLR service for redundancy. > this doesn't sound unreasonable, make txt pls appear in draft form, then email that to grow@ and see what debate happens there. > Wouldn't they just get PI: > > Yes. That's why I think it's important to find a way to give these organizations what they need in a way that keeps the IPv6 DFZ growth on a workable trajectory. > > AS numbers: > > BGP assumes that an AS always has internal connectivity. This can be accomplished using tunnels, but it's much better to simply have separate AS numbers for each subunit. Would it make sense to allocate ranges of AS numbers to enterprise LIRs? Certainly with 32-bit AS numbers there's no lack of numbers, and this would allow tools to be developed to work on CIDR-like AS number ranges in the future. > it seems like the AS here is really not relevant, unless you were thinking that: "AS is a proxy for GEO data." (or AS == SITE) One thought is that AS provides the mapping to 'authoritative entity for the routing policy surrounding/using the prefixes originated by the AS in question', so is it simpler to remember: "DE govt is AS65534" or "DE gov't could be one of 160 AS numbers" (a range might help, but ranges imply some idea about growth in the future. Would you have planned for RU to add Crimea?) The AoLR (or 'how to be an enterprise that participates in the global routing system') seems like a good start though. -chris
- [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