I sometimes wonder if we couldn’t sue Service Providers under the Trades Description Act. I really don’t think they have the same idea of ‘Service’ as I do. One of my customers has been having intermittent problemsfor months with multicast over their MPLS WAN. It used to work just fine, but things just seem to have been getting worse over the past four months or so. To begin with it looked like it was tied to a couple of dodgy tail circuits that kept bouncing—when the traffic failed over to the backup circuits the multicast broke. And then during an upgrade at one of the remote sites, multicast just wouldn’t work at all on the new faster links. They reverted back to the old circuits—still nothing. Then all of a sudden it started working again, and when the new circuits were cut back in again, everything was fine. The support guys have been really struggling to get to grips with the problem, but just couldn’t figure out what on the WAN was causing all the issues. They’re running Auto-RP, and sometimes the remote sites just couldn’t see the RPs in the Data Centres. Some sites had to have static RPs configured, and even then there were issues. Nothing consistent, nothing that you could say ‘if we do X it breaks’ , sometimes it would work fine for weeks, then a hiccup, and you were never quite sure what the Service Provider guys had done to fix it. The Service Delivery Manager has been yelling at the Service Provider for weeks now (I’m naming no names here, but no, it wasn’t BT for a change). Finally last week an email came through from the Service Provider’s Customer Representative, or whatever they’re called. And the wording of the email? Apparently the Service Provider has, over the past year, been changing out its MPLS Edge infrastructure, from a Cisco-based PE infrastructure to a non-Cisco-based one. I’m not going to say which vendor they’ve moved to, because it’ll just get me in trouble. Anyway, the new PE kit “doesn’t support Auto-RP properly”. However, reasons the Service Provider, Auto-RP isn’t a standard, so that means they don’t have to. The fact that my customer has been using this Service Provider for over six years, multicast has been working over the MPLS network just fine until relatively recently, and the Service Provider has changed their equipment and can no longer provide the service my customer requires, doesn’t seem to matter. My customer has been told that it’s now up to them to change their configuration to suit the Provider’s network, as there will be no more work done on trying to fix the problem. Okay, maybe Auto-RP isn’t a standard, but it was working fine before. Nobody said it was going to be an issue. Am I being cynical in thinking that the Service Provider has grasped the “non-standard” label with both hands as an easy out because they couldn’t find the real root cause? They haven’t actually been able to define which bit of Auto-RP their new kit doesn’t do “properly”, nor explain how this deficiency ties up with the problems we’ve been seeing. It’ll be awfully interesting to see if all these errors really do away when the customer network is changed (as it will have to be) to meet the Provider requirements. The customer is always right? Not nowadays it seems. I wonder what the next change the Provider makes on its network will be and what that will break?