Networking

07:00 AM
Orhan Ergun
Orhan Ergun
Commentary
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail
50%
50%

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?

Orhan Ergun, CCIE, CCDE, is a network architect mostly focused on service providers, data centers, virtualization and security. He has more than 10 years in IT, and has worked on many network design and deployment projects. View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
MarciaNWC
50%
50%
MarciaNWC,
User Rank: Strategist
4/28/2014 | 11:28:39 AM
SLAs
Could the SLA include requirements to provide details into root causes of outages and unplanned downtime?
OrhanErgun
50%
50%
OrhanErgun,
User Rank: Moderator
4/28/2014 | 11:44:34 AM
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.
Susan Fogarty
50%
50%
Susan Fogarty,
User Rank: Strategist
4/28/2014 | 12:52:54 PM
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?
OrhanErgun
50%
50%
OrhanErgun,
User Rank: Moderator
4/28/2014 | 1:05:51 PM
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 http://www.ietf.org/proceedings/56/I-D/draft-ietf-ppvpn-l3vpn-auth-03.txt.

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.

 
ahuggins
50%
50%
ahuggins,
User Rank: Apprentice
4/30/2014 | 1:02:14 PM
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.
OrhanErgun
50%
50%
OrhanErgun,
User Rank: Moderator
4/30/2014 | 2:10:59 PM
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.

 
Cartoon
Slideshows
Audio Interviews
Archived Audio Interviews
Jeremy Schulman, founder of Schprockits, a network automation startup operating in stealth mode, joins us to explore whether networking professionals all need to learn programming in order to remain employed.
White Papers
Register for Network Computing Newsletters
Current Issue
2014 Private Cloud Survey
2014 Private Cloud Survey
Respondents are on a roll: 53% brought their private clouds from concept to production in less than one year, and 60% ­extend their clouds across multiple datacenters. But expertise is scarce, with 51% saying acquiring skilled employees is a roadblock.
Video
Twitter Feed