Re: [GROW] draft-white-grow-overlapping-routes-00
Robert Raszuk <robert@raszuk.net> Tue, 10 July 2012 23:12 UTC
Return-Path: <robert@raszuk.net>
X-Original-To: grow@ietfa.amsl.com
Delivered-To: grow@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30B311E80BF for <grow@ietfa.amsl.com>; Tue, 10 Jul 2012 16:12:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.405
X-Spam-Level:
X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfAEoBUDJBVc for <grow@ietfa.amsl.com>; Tue, 10 Jul 2012 16:12:40 -0700 (PDT)
Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id D001B11E809F for <grow@ietf.org>; Tue, 10 Jul 2012 16:12:39 -0700 (PDT)
Received: (qmail 7949 invoked by uid 399); 10 Jul 2012 23:13:08 -0000
Received: from unknown (HELO ?192.168.1.58?) (pbs:robert@raszuk.net@83.9.118.178) by mail1310.opentransfer.com with ESMTPM; 10 Jul 2012 23:13:08 -0000
X-Originating-IP: 83.9.118.178
Message-ID: <4FFCB702.8000202@raszuk.net>
Date: Wed, 11 Jul 2012 01:13:06 +0200
From: Robert Raszuk <robert@raszuk.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: "White, Russell" <riwhite@verisign.com>
References: <CAL9jLabOs02rOti4tezaZiHyiOD2f9vAhsoE9c-afFb4J1xYXQ@mail.gmail.com> <DCC302FAA9FE5F4BBA4DCAD46569377917449AF235@PRVPEXVS03.corp.twcable.com> <F8659490-D1B2-477D-ADCC-EC6FD7AD073A@rob.sh>, <4FFAD681.70607@raszuk.net> <3F74C1962631E14292BBF1B1B5F7021E043516@BRN1WNEXMBX01.vcorp.ad.vrsn.com>, <4FFBECCE.6050000@raszuk.net> <3F74C1962631E14292BBF1B1B5F7021E043924@BRN1WNEXMBX01.vcorp.ad.vrsn.com>, <4FFC4378.7090505@raszuk.net> <3F74C1962631E14292BBF1B1B5F7021E043E94@BRN1WNEXMBX01.vcorp.ad.vrsn.com>, <4FFCA6B2.3060404@raszuk.net> <3F74C1962631E14292BBF1B1B5F7021E043F33@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
In-Reply-To: <3F74C1962631E14292BBF1B1B5F7021E043F33@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "grow@ietf.org" <grow@ietf.org>, Susan Hares <skh@ndzh.com>
Subject: Re: [GROW] draft-white-grow-overlapping-routes-00
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert@raszuk.net
List-Id: Grow Working Group Mailing List <grow.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/grow>, <mailto:grow-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/grow>
List-Post: <mailto:grow@ietf.org>
List-Help: <mailto:grow-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jul 2012 23:12:41 -0000
Hi Russ, > 1. A provider who is giving a customer PA space in parts, but that PA > space is not being advertised anyplace other than to that provider. > In this case, pulling traffic overlapping routes doesn't matter, > because the provider who allows the use of PA space is going to take > them out by not advertising the longer prefixes from their own space. > In this case, the draft we've proposed would work, as well. This is done today without the need for your draft. That's common practice :) > 2. A provider who is giving a customer PA space and allowing the > customer to advertise that same PA space through another provider. In > this case, if the provider is not advertising the PA space at the > same length as the customer is to an alternate provider, the > alternate provider will consume all the inbound traffic to the > customer. This is dumb on the part of the provider giving out the PA > space. What is the provider supposed to do ? Give ticket to his customer ? Get rid of his customer ? See the PA owner can not do much not to break the business relation with his customer. However his (and another providers) upstreams can suppress the more specifics. This is where the aim should be. Moreover the more specific should be suppressed only where it brings no more value. > 3. A customer who has PI space and is advertising different bits in > different places. Again, best practice would say to advertise a > shorter covering route as well, to guard against failures. If the end > AS is advertising longer and shorter prefixes that overlap, the draft > we've proposed works --even if they're advertising them in different > places, what we've proposed will take the longer prefix out once it > no longer draws traffic along a different path than the shorter > prefix. I don't think we can do much with PI addresses. > So, I'm a bit confused as to what case you think isn't covered... I > thought you were saying it was normal operation for a provider to > give out PA space, allow the customer to break that space up, and I don not understand what do you mean by "allow" If I peer with you and you give me /24 out of your /16 then I pay Alvaro $$$ then he will be happy to advertise this /24. What can you do about that ? Be mad at both of us ? > then only advertise the shorter block covering the space given to the > customer. I don't care how you jiggle local pref if you do this, > longer prefix wins, and the alternate provider consumes the traffic > --even from your AS. Nope. Not from your AS as as I said in the last email you will carry within your AS my /24 and prefer customer routes rather then peer routes (assuming Alvaro is even peering with you) ;-) R.
- [GROW] WGLC: draft-ietf-grow-ops-reqs-for-bgp-err… Christopher Morrow
- Re: [GROW] WGLC: draft-ietf-grow-ops-reqs-for-bgp… Tom Hodgson
- Re: [GROW] WGLC: draft-ietf-grow-ops-reqs-for-bgp… Gaurab Raj Upadhaya
- Re: [GROW] WGLC: draft-ietf-grow-ops-reqs-for-bgp… George, Wes
- Re: [GROW] WGLC: draft-ietf-grow-ops-reqs-for-bgp… John G. Scudder
- Re: [GROW] WGLC: draft-ietf-grow-ops-reqs-for-bgp… Pedro Andres Aranda Gutierrez
- Re: [GROW] WGLC: draft-ietf-grow-ops-reqs-for-bgp… Jakob Heitz
- Re: [GROW] WGLC: draft-ietf-grow-ops-reqs-for-bgp… Pedro Andres Aranda Gutierrez
- Re: [GROW] WGLC: draft-ietf-grow-ops-reqs-for-bgp… Robert Raszuk
- Re: [GROW] WGLC: draft-ietf-grow-ops-reqs-for-bgp… Rob Shakir
- Re: [GROW] WGLC: draft-ietf-grow-ops-reqs-for-bgp… Rob Shakir
- Re: [GROW] WGLC: draft-ietf-grow-ops-reqs-for-bgp… Shane Amante
- Re: [GROW] WGLC: draft-ietf-grow-ops-reqs-for-bgp… Robert Raszuk
- Re: [GROW] WGLC: draft-ietf-grow-ops-reqs-for-bgp… Robert Raszuk
- Re: [GROW] WGLC: draft-ietf-grow-ops-reqs-for-bgp… Robert Raszuk
- Re: [GROW] WGLC: draft-ietf-grow-ops-reqs-for-bgp… Rob Shakir
- Re: [GROW] draft-white-grow-overlapping-routes-00 Robert Raszuk
- Re: [GROW] draft-white-grow-overlapping-routes-00 Robert Raszuk
- Re: [GROW] WGLC: draft-ietf-grow-ops-reqs-for-bgp… White, Russell
- Re: [GROW] WGLC: draft-ietf-grow-ops-reqs-for-bgp… White, Russell
- Re: [GROW] WGLC: draft-ietf-grow-ops-reqs-for-bgp… White, Russell
- Re: [GROW] draft-white-grow-overlapping-routes-00 White, Russell
- Re: [GROW] draft-white-grow-overlapping-routes-00 White, Russell
- Re: [GROW] WGLC: draft-ietf-grow-ops-reqs-for-bgp… Shane Amante
- Re: [GROW] WGLC: draft-ietf-grow-ops-reqs-for-bgp… Rob Shakir
- Re: [GROW] WGLC: draft-ietf-grow-ops-reqs-for-bgp… Christopher Morrow
- Re: [GROW] WGLC: draft-ietf-grow-ops-reqs-for-bgp… rob.shakir
- Re: [GROW] WGLC: draft-ietf-grow-ops-reqs-for-bgp… Christopher Morrow