Calling LinkedIn, Amazon and Akamai @ DE-CIX NY

Thu Jan 31 14:22:21 UTC 2019

A prefix is a prefix. A route is a prefix plus a next-hop. Your next hop for your PNI is different than your IX. 

I don't believe I advocated running IX links hot. Financially, as an IX operator, I'd prefer that people ran all their bits over an IX and that all links were best kept below 10% utilization. ;-) Obviously I know that's not good engineering or fiscally responsible on the network's behalf. Just going to the extreme to support my point. 

----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

----- Original Message -----

From: "Mark Tinka" <mark.tinka at seacom.mu> 
To: "Mike Hammett" <nanog at ics-il.net> 
Cc: nanog at nanog.org 
Sent: Thursday, January 31, 2019 8:14:44 AM 
Subject: Re: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY 

On 31/Jan/19 15:54, Mike Hammett wrote: 

Not all routes are created equal. If you have a PNI and an IX connection of equal capacity, obviously the IX connection will fill up first given that there is more opportunity there. 

I think you meant to say not all "paths" are equal. Routes are routes. Where they lead to is another matter. 

The presence of a PNI does not preclude good governance of an exchange point link. If you are going to (willingly or otherwise) ignore the health of your public peering links over your private ones (or vice versa), then I wish upon you all the hell you'll face that comes with taking that position. 

Our policy is simple - 50% utilized, you upgrade. Doesn't matter what type of link it is; WDM Transport, IP, peering (public or private), Metro, core backbone, protection paths, e.t.c. Choosing to let your public peering links run hot because your "major" peers are taken care of by the private links is irresponsible. Do a lot of networks do it; hell yes, and for reasons you'd not think are obvious. 

<blockquote>

Also, there are more moving parts in an IX (and accompanying route servers), thus more to go wrong. 

</blockquote>

Agreed, but that's not the crux of this thread (even though it's one of the reasons we do not relay solely on RS's). 

Mark. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190131/cc1b9078/attachment.html>