NTAC Peering Working Group

[Darrell Newcomb <>]

Agreed John, my thoughts exactly when seeing the note.  ;-)

On Sep 19, 2012, at 2:26 PM, Michael H Lambert wrote:

> In looking at the TR-CPS routing table, I see a number of routes with 20940 
> (Akamai) in the AS path.  The vast majority of these are NOT "^11164 20940 
> .*".  I can't imagine that these other destinations would serve content to 
> random sources in our community, so is there any reason that they should be 
> accepted into the routing table?  I could imagine their presence leading to 
> some weird return paths.  I'm assuming that "^11164 20940$" would work as 
> expected.

Good question; those announcements are mostly in two camps:

1. Where 20940 was used as origin-as in originations for devices that largely 
service a remote user-population.  
        For example ISP in situation where they can't supply address space, 
but is other-wise hosting the devices.  Then when using that address space 
folks are electing to make 20940 the origin-as for those announcements (20940 
isn't cohesive with intra-domain links, but is cohesively managed).  For 
these you want to be able to deliver origin content from on-net systems to 
those remote caches to have better viewing of say classroom-video archive 
playing back in Brazil.


2.  Where 20940 has some-what general-purpose infrastructure and those 
installations have upstream networks.  Networks that happen to have direct 
interconnection with our networks.
        These are useful for things like specialized object-types which might 
not be widely distributed, origin-content, middle-ware, log systems, and 
so-on.  Some of the examples in prior sentence have steady state uses, but 
not the majority of traffic; and/or help your other on-net devices perform 
better.   The BGP announcements of this type also cover systems that can be 
useful for over-flow when other sources are offline or overloaded.


Discerning between the two remotely via just BGP announcements could be quite 
difficult. (I didn't want to go fish for in-the-wild examples in this quick 
reply)   As well there are probably other cases than those two not 
immediately coming to mind.

But that being said you:
1. want solid connectivity to both of those
2. For most-all US R&E networks I can imagine you don't (generally) want the 
majority of 20940 -> (your-end-user) traffic to be exchanged with those 
endpoints
But (3) they might make up a non-trivial percentage of traffic and certainly 
a non-trivial role in the larger user experience.

-Darrell


P.S. for the extra technical (and I haven't taken time to edit so will 
apologize for the extra wordiness):
        There are times however when the overflow demand gets shifted to 
endpoints that seem odd on first glance.  When you look at examples of this, 
maybe like today's software updates when overflow of individual devices/sites 
is expected, the alternative/overflow location causes some head-scratching.  
Many times those are trading overload of the cache nodes for a less than 
optimal network path and in a few of those cases the realized path is not 
terribly desirable for one or more of the parties along the way.  The easiest 
way to tackle that is more on-net cache capacity, but if they're ever 
particularly painful, sustained, and/or frequent w/much-better alternatives;  
the TR-CPS advisory folks can help talk/work through improving the outcomes.