Re: [GROW] draft-white-grow-overlapping-routes-00

"White, Russell" <riwhite@verisign.com> Wed, 11 July 2012 00:06 UTC

Return-Path: <riwhite@verisign.com>
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 380C011E814A for <grow@ietfa.amsl.com>; Tue, 10 Jul 2012 17:06:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.531
X-Spam-Level:
X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 4lxi3Mymlbfd for <grow@ietfa.amsl.com>; Tue, 10 Jul 2012 17:06:40 -0700 (PDT)
Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by ietfa.amsl.com (Postfix) with ESMTP id A353A11E8087 for <grow@ietf.org>; Tue, 10 Jul 2012 17:06:37 -0700 (PDT)
Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKT/zDqg3k1cA721w1hJH0GGRyQFfrTQxI@postini.com; Tue, 10 Jul 2012 17:07:09 PDT
Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q6B073Ei021155 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Jul 2012 20:07:03 -0400
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Tue, 10 Jul 2012 20:07:02 -0400
From: "White, Russell" <riwhite@verisign.com>
To: "robert@raszuk.net" <robert@raszuk.net>
Thread-Topic: [GROW] draft-white-grow-overlapping-routes-00
Thread-Index: AQHNXufZIhLiWShsFEaoV8oecTo8K5cjHohzgABJ1gD//8sS8w==
Date: Wed, 11 Jul 2012 00:07:01 +0000
Message-ID: <3F74C1962631E14292BBF1B1B5F7021E043FCA@BRN1WNEXMBX01.vcorp.ad.vrsn.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>, <4FFCB702.8000202@raszuk.net>
In-Reply-To: <4FFCB702.8000202@raszuk.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.173.152.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 11 Jul 2012 08:43:08 -0700
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
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: Wed, 11 Jul 2012 00:06:41 -0000

>> 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 ?

Advertise the same length route as the other provider is... That's what I would do.

However, if we're blocking the longer prefix route when it no longer impacts traffic flow, then the alternate provider will block the longer prefix when he receives the shorter from the owner of the PA space.

Again, this is all about blocking longer prefixes when they are no longer useful in the routing system as a whole. What we've proposed says that seeing two overlapping routes is the best indication of this condition, and attempts to strike a balance between traffic engineering and reducing table size.

> I don't think we can do much with PI addresses.

You can remove unneeded longer prefix traffic engineering routes with PI space just like you can PA space.

:-)

Russ