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.

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

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. 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

You're absolutely right, but your struggle is uphill. Some considerable time ago my "XO" (James Aldridge) had a big hand in RFC2142, but in spite of it being Standards Track and otherwise receiving universal approval, real uptake was patchy. In fact, in spite of most peering contracts (which started to emerge at the time) being very specific about listing 24*7 problem resolution contact information, any issues beyond the truly banal required one to resort to private, carefully maintained lists of names and telephone numbers, many of which were gleaned from business cards (just about the only useful thing to come out of Finance & Administration) exchanged at NANOG meetings. Has anything changed since then? Probably not ... Vive le NANOGue! Probably, in fact, increasingly dense interconnectivity between especially upper level providers has outright masked the absence of out-of-band communication, and a truly catastrophic routing problem could well separate the Net. If a really huge problem were to occur these days, could you expect to be able to email somebody about it? Probably not, in fact. Maybe RFC2142 should be revived and turned into something much more extensive and formal? -- Per