• 04/28/2014
    7:00 AM
  • Rating: 
    0 votes
    Vote up!
    Vote down!

Tech Talk Week 1: Service Provider Network Visibility

Welcome to the first in a series of weekly community discussions, as we explore the lack of visibility enterprise customers often have into the service provider network.

Today we kick off a series of weekly discussions. I'll present an idea or topic, and I invite everyone in the community to add your thoughts in the comments throughout the week. At the end of the discussion, we'll evaluate and see if there are any action items that community members can take on to help advance the issue or solve the problem that currently exists. And we may even be able to award some prizes to those with the best ideas -- stay tuned.

If you would like to lead your own Tech Talk and have an interesting topic, just let us know. Network Computing is looking for more volunteers!

Topic 1: Service provider visibility to the customer

Most of the time, if not always, enterprise customers no have visibility into the service provider side. In the case of an MPLS service at Layer 2 or Layer 3, the customer will be assigned by virtual forwarding instance (VFI) or virtual routing and forwarding (VRF) and have a private context. This allows for good separation and multi-tenancy but still is widely open to operational mistakes.

Change management processes might be in place, and maintenance windows might be scheduled, helping the customer to keep informed. However, I have seen many times when this has not been the case. The service provider should also be performing according to an SLA, but still the customer should see the root cause and understand the reason for any unplanned downtime -- whether due to operational mistakes, wrong configurations, etc. We may need to apply that configuration information to other places or inform other parties of the problems.

Is service provider visibility an issue in your network? How do you deal with it, or how would you solve this problem?



Could the SLA include requirements to provide details into root causes of outages and unplanned downtime?

Re: SLAs

Yes It may, but after some time you will get it. All informations will be given by Service Provider. I am looking for an automated method , maybe within some protocol as TLV or maybe through API calls but we should have this visibility.

Re: SLAs

Orhan, so are you talking about an ability to have a real-time view into the service provider network from the customer side so that you can diagnose problems? Don't you think service providers would object to that, or only allow you very specific information?

Re: SLAs

Actually no , I am not looking for RBAC access , whatever configuration is done at the service provider site for the customer traffic, log information/configuration information should be sent to the customer automatically. This will stress the service provider, they will be more carefull even for single site for individual customer.

As an example, for layer 3 VPN if SP operator wrongly configure RT information for the VPN, two different network unintentionally might be merged. To avoid ONLY this behavior. there is an IETF draft

This might prevent from this type of failure but, I am not talking only for prevention, I am saying that we need to have AUTOMATED visibility. not the Service Provider report.


Re: SLAs

It's reasonable for customers to have visibility of the CE and specific PE configurations. Some SP's will allow RO snmp access to the CE, which can be useful from a troubleshooting perspective.

I think more focus need to be put on how the customer views their own WAN. An intuitive portal that gives information about the live services, bandwidth utilization, planned works, device logs... the list goes on. It should feed into the SP's own inventory and monitoring systems.

In most cases there is a disjoint between the information seen by the SP and the customer.

Re: SLAs

I believe you meant SNMP RO access to PE or CPE which can be think as managed CE. This might somehow can be a solution if we have two links to the service provider,if one link goes down,we can get the link/down message from the other link if it stays up. But also customer may want to see, which configuration changes have been made, and also whichever mechanism is selected , it should be combined with the below draft to prevent misconfiguration for some service IMO.