Savvis Route Server/Looking Glass

2011-12-18 Thread Keegan Holley
Does anyone know of a working Savvis route server or looking glass.  The
http://as3561lg.savvis.net/lg.html site doesn't seem to be able to query
BGP routes.  For example it says they don't have a route to 12.0/9 which
seems to be a pretty common aggregate.  The traceroute tool works normally
though.


Re: local_preference for transit traffic?

2011-12-18 Thread Mark Tinka
On Sunday, December 18, 2011 04:49:46 AM Adam Rothschild 
wrote:

> Indeed, the old adage of "once a customer, never a peer"
> could never be wronger.

Socially, "once a customer, then a peer, then a customer 
again" is even more interesting yet.

The second instance of "customer" could rise during M&A 
situations, where an ISP Z peers with ISP A, but buys 
transit from ISP B. Then ISP A and ISP B decide to merge.

But I suppose this is certainly going way off-topic now :-).

Mark.


signature.asc
Description: This is a digitally signed message part.


Re: local_preference for transit traffic?

2011-12-18 Thread Mark Tinka
On Sunday, December 18, 2011 02:35:37 AM Joel jaeggli wrote:

> In the circumstances where I've seen this are rare... We
> have had transit providers that we used who also peered
> with us on exchange fabrics for v6 that's about it.

Funny, we have something similar :-).

But yes, we've seen this in situations where public exchange 
points are supported by governments, and license holders are 
"urged" to peer with all members.

Mark.


signature.asc
Description: This is a digitally signed message part.


Re: local_preference for transit traffic?

2011-12-18 Thread Mark Tinka
On Sunday, December 18, 2011 12:32:03 AM Matthew Petach 
wrote:

> I've been able to negotiate peering+transit relationships
> with providers, but only by threat of total revenue loss;
> ie "we currently pay you $x million/year; we want your
> on-net routes as settlement-free routes, and will
> continue to pay for off-net transit traffic.  Otherwise,
> we will be transferring all that revenue to your
> competitor, X"

If the customer is taking these on-net routes via an 
exchange point or private peering arrangement, this should 
be fairly easy to do.

If they choose to take it over the same link as their off-
net service, not only does the provider need to support a 
visible way in which these services can be separated over 
the same wire, but it may also not make much sense for the 
customer as there is potential for on-net traffic to hog the 
link, making the case to upgrade the link for traffic that 
may not necessarily incentivise them to do so. But it's hard 
to judge this one, especially if the ISP is large with tons 
of other on-net customers "talking" to the customer 
negotiating such an arrangement.

I can see ISP's accepting to do this if the ratio of on-
net:off-net traffic is disproportionate, in favor of more 
off-net traffic.

> This tends to be effective only for
> content providers, though, where the outbound traffic
> dominates,
> and you don't care if the inbound bits are coming
> over the "pay for" pipe vs the "settlement free" pipe.

It's also mostly useful where the ISP is sufficiently large 
in a meaningful way for their on-net routes to make any 
sense to the downstream customer negotiating such an 
agreement.

> If you're an inbound-heavy shop, though, this won't
> really buy you much benefit.  (And, if the revenue
> point isn't in the $x millions/year for the transit
> provider, they're more likely to just shrug and say
> "too much hassle...please, go be a headache
> for our competitor" rather than configuring a
> dual relationship like that--so it really only works
> for higher-volume relationships.)

Maybe what you meant to say is "if the revenue point isn't 
high enough" :-).

Relatively, different ISP's may be kings in their part of 
town, but still be small enough to accept fewer dollars for 
such a deal.

On the whole, I can envisage cases where trying to fix this 
"peering with customers" issue can end up causing 
inadvertent competition with exchange points.

Mark.


signature.asc
Description: This is a digitally signed message part.