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.