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