[100152] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: more-specifics via IX

daemon@ATHENA.MIT.EDU (David Ulevitch)
Thu Oct 18 17:24:10 2007

Date: Thu, 18 Oct 2007 14:03:36 -0700
From: David Ulevitch <davidu@everydns.net>
To: Stephen Wilcox <steve.wilcox@packetrade.com>, Nanog <nanog@merit.edu>
In-Reply-To: <B5438D03-38E0-4CE5-B201-44F8BB760D7D@packetrade.com>
Errors-To: owner-nanog@merit.edu






Stephen Wilcox wrote:
> 
> 
> On 17 Oct 2007, at 20:55, Bradley Urberg Carlson wrote:
> 
>>
>> Thanks for the suggestions.
>>
>> On Oct 17, 2007, at 6:06 PM, Stephen Wilcox wrote:
>>> well.. the problem of course is that you pull in the traffic from the 
>>> aggregate transit prefix which costs you $$$ but then you offload it 
>>> to the customer via a peering link for which you are not being paid
>>
>> A bigger problem is that my IX peer pays less to my customer for 
>> transit.  If my customer notices that transit traffic has been going 
>> around him, he may be grumpy.  I prefer happy customers.
> 
> Okay but:
> 
> 1. Your customer/customer's customer is the one doing the broken routing 
> here not you.. if he wants to be grumpy you should point him in the 
> direction of the guy who is announcing the bad routes in the first place!

s/broken// and s/bad//

'broken' and 'bad' are all a matter of perspective here.

> 
> 2. If I'm following this, your peer pays your customer? So you are 
> peering with your customer's customer? If that was me I would either 
> depeer them or tell them that you have an issue and need it resolving 
> urgently or you my depeer them.

It's an MLPA policy based exchange (and probably just using a central 
route-server) not bi-lateral peering.  De-peering isn't possible here.

It's not an excuse for lack of filters, but as the OP pointed out, the 
filters weren't expecting the routes from their customer's customer.

-david

home help back first fref pref prev next nref lref last post