Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: BCP Question: Handling trouble reports from non-customers

  • From: Steve Gibbard
  • Date: Fri Sep 01 18:50:30 2006

On Fri, 1 Sep 2006, Owen DeLong wrote:

I think my previous post may have touched on a more global issue.

Given the number of such posts I have seen over time, and, my experiences trying to report problems to other ISPs in the past, it seems to me that a high percentage of ISPs, especially the larger ones, simply don't allow for the possibility of a non-customer needing to report a problem with the ability to reach one of their customers.
Anybody trying to put together such a BCP should first give some consideration to what sorts of calls from non-customers a service provider should be expected to accept. Based solely on Owen's earlier post, this looks to me like a good example of why service providers are sometimes reluctant to accept trouble reports from non-customers.

From DNS and whois, it looks like the IP address Owen sited earlier is an
individual DSL customer. The equipment Owen says is dropping packets looks like DSL concentration equipment in a local POP. Owen says he's having trouble reaching the address from multiple locations. If we look at this from the service provider's perspective, we see some random person calling up to complain that somebody else, whose phone number the caller doesn't know, is having trouble with their DSL service. That's probably not a call they get a lot of, and it probably seems pretty strange. If that DSL customer were really having problems getting anywhere, wouldn't they call it in themselves? If there were a problem with the whole POP, the random outside person calling in would be more believable, but the people in the call center would probably have their hands full dealing with actual customers.

There are DSL customers who use their DSL circuits to host actual services that others might want to access, or IP phones that somebody might want to call. There are big hosting companies who specialize in making content available to lots and lots of end users, who still don't like taking calls from non-customers. In those cases, it's at least obvious why a non-customer might call and complain, but there are scaling issues because of which somebody might not want to accept such a call. The cost of passing bits through to somebody with thousands or millions of customers may be significantly less than the cost of taking phone calls from the customers' customers. Transit providers therefore tend to expect such organizations to handle their own customer support, and to call the transit provider themselves if there's a problem. That way the transit provider knows who they're dealing with, and only has to explain things once.

This isn't to say there aren't valid reasons for network operators to contact other network operators they don't have relationships with. Packet loss affecting only the providers' customers may not count, but a call saying "hi, your customer, who isn't answering their phone, is sourcing unauthorized routes to my address space" probably should be taken seriously. Of course, the challenge there is determining that the person calling *is* authorized to tell you not to announce the space. Same for customers sourcing attacks, and the like.

Some questions you might want to consider would be:

What sorts of problems should a non-customer legitimately be reporting?

Which non-customers should be reporting such things? Affected individuals? Other network operators (as defined by who?)? CERTs? Law enforcement?

What channels should be used for such contacts? Phone? E-mail? INOC-DBA? Where should the contact information be published and who should have access to it?

How should identity of callers be determined?

Also, note that lots of solutions to many of these problems have already been tried at various times with varying degrees of success, and that some of them are working fairly well. You'd probably do better to build on existing systems and practices than to start from scratch.

-Steve




Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.