Re: [v6ops] [GROW] Deaggregation by large organizations
Ray Hunter <v6ops@globis.net> Sat, 25 October 2014 14:44 UTC
Return-Path: <v6ops@globis.net>
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 10BDD1A0016; Sat, 25 Oct 2014 07:44:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.511
X-Spam-Level:
X-Spam-Status: No, score=-0.511 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_PASS=-0.001, 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 zus-Bl317sE5; Sat, 25 Oct 2014 07:43:59 -0700 (PDT)
Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAC81A000B; Sat, 25 Oct 2014 07:43:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id D723D871613; Sat, 25 Oct 2014 16:43:57 +0200 (CEST)
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuKq8c1LPg6f; Sat, 25 Oct 2014 16:43:57 +0200 (CEST)
Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id A1F15871612; Sat, 25 Oct 2014 16:43:57 +0200 (CEST)
Message-ID: <544BB713.8000803@globis.net>
Date: Sat, 25 Oct 2014 16:43:31 +0200
From: Ray Hunter <v6ops@globis.net>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Iljitsch van Beijnum <iljitsch@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> <31FED6FF-5398-4793-87F3-AC873811FD64@muada.com>
In-Reply-To: <31FED6FF-5398-4793-87F3-AC873811FD64@muada.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/0QieoLzP-wpU2NMegfLRWT5Yjzc
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:44:01 -0000
> Iljitsch van Beijnum <mailto:iljitsch@muada.com> > 25 October 2014 16:07 > > 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). > I'm not convinced your draft is in line with my own understanding of how multinationals I know either use, or want to use the Internet, and why the de-aggregation occurs in the first place. I'd thus like to see more data on where/why the de-aggregation is occurring. Particularly my perception does not seem to fit the assumption of Section 2. > For reasons of cost and routing efficiency it's not possible or desired to use an internal network between the subunits or locations to transport traffic to/from the internet from one organizational subunit to another. Internet "offload" is a common requirement for low value traffic, in conjunction with a private high quality internal Intranet for corporate apps like design tools, with both networks active simultaneously. My thinking is that SADR, and running multiple (PA) prefixes within an enterprise will address this requirement. So each sub unit would carry both the multinational/global PI space and one or more local PA space prefixes obtained from the local ISP. Only the local PA space would be advertised out of each break out. That would be and prevent the need for de-aggregate routes to be advertised back into the individual ISPs serving the sub unit satellite sites. Equally GRE tunnels or IPSEC tunnels over Internet are already common-practice to create virtual enterprise networks. > This way, deaggregates only have to be carried by ISPs providing the aggregate of last resort service and the ISPs connecting subunits of the organization. I don't think enterprises want to be tied to ISP's at all. The hope/ dream is that once a prefix enters the global routing table, then it will be globally reachable. I don't know of any small set of ISPs that can economically provide service in 50+ countries in some sort of coordinated aggregate ISP manner. Equally, Section 3 seems to assumes that the customer/enterprise relationship is regional, which IMVHO is not always the case. www.myenterprise.com needs to be world wide reachable, but with local content delivered by CDN or local servers. > In theory, a user in Tokyo could connect to the internet in Madrid. In practice, this is is exceedingly rare. I don't agree with this observation. I know of many cases e.g. where a break in/out for a 3rd party from China is made in Europe. Or where a US based company manages systems remotely in Europe, LATAM, Asia Pacific, and the US and has regional links to the customer (with a break in/out per region). My particular worry with aggregates of last resort would be that with longest prefix match matching, it's becoming increasingly easy for longer prefixes to hijack important enterprise aggregates. So advertising an aggregate of last resort, whilst allowing sub units to advertise longer prefixes to other ISPs, might not be such a great idea for security. -- Regards, RayH
- [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