MPLS - Preparing an RFP (Dos and Don'ts)

This week's tip will discuss the areas of focus for developing a request for proposal (RFP) for VPN services from an MPLS service provider. This week I will focus on areas that should be included, and next week I will discuss areas that do not add any value.

When an organization decides that it is going to utilize MPLS VPNs as a replacement for their traditional VPN, it is highly recommended that an RFP be issued to the major MPLS VPN service providers. This includes SBC, Sprint, Qwest, AT&T, and MCI at a minimum. The competitive landscape for VPN services is such that a multitude of carriers can be used to provide VPN services on a nationwide basis. By issuing an RFP, the organization can narrow down the carrier choices based on written response information from the carrier. It is important to write the RFP so that you are soliciting the correct information regarding the VPN services from the carriers.

I have worked at several service provider organizations and have responded to multiple RFPs for MPLS VPN services. There have been some painful responses and some were less painful. A common thread that I have seen in RFPs is a request for information that is totally irrelevant to the overall service that the provider can offer. In preparing a RFP for distribution, you want the carriers to focus on areas that add value to your effort and provide solutions to the environment you currently have. So having said that, I will discuss some dos and don'ts for RFPs. This week will be the dos.

Dos

Do query the service provider's capabilities to support all of the protocols that traverse your WAN today. This can include legacy protocols such as Decnet, SNA, IPX and Appletalk. These non-IP protocols will need to be encapsulated in an IP virtual tunnel (such as GRE or DLSW) before they can be delivered over the MPLS VPN. You will want to clearly understand the provider's transport solution for these protocols. The provider may or may not support them.

Do query the provider on costs of alternative transport options for multiple speeds and feeds for the WAN access capabilities you currently support. If you are moving towards a new access technology, you may have to upgrade the WAN edge routers. Have them quote a price for bundled WAN CPE and access technology as well as an option matrix for alternative access without the router bundle.

Do ask about the upgrades needed to CPE to support the new solution. If QoS is being considered, it really helps if the provider knows what your capabilities are to support new features on your current WAN CPE. Either way, the WAN CPE devices will need to be evaluated for access support. There are tremendous costs associated with WAN refresh.

Do ask about end-to-end QoS if you anticipate putting real-time traffic over the VPN. Ask how the provider can ensure end-to-end QoS over local access circuits it does not own. (Carriers do not own local access out of their regions and may not own it within regions in some cases). Ask about probes or other mechanisms for creating synthetic traffic to proactively measure network performance.

Do ask about performance metrics, SLAs and guarantees. Ask about the reporting format and customer portals. Query the provider on whether it is proactive versus reactive when there is an SLA missed.

Ask about the migration plan and how the carrier will mitigate risk of migration. Ask for step-by-step processes. Be wary of carriers simply responding that they have project management organizations and multiple engineers. Migration requires a joint effort by the customer and the carrier. Ensure that you understand the carrier and customer roles.

Do ask about customer references and follow up with these.

Do ask about the cost of outsourcing the VPN solution from the router CPE to the cloud. Give the provider a chance to respond with a fully managed service. You may be surprised at the cost. Be sure to understand what it costs you today so you can compare.

Do ask the providers what their network convergence times are. If the carrier is transporting real time applications such as voice and video over IP, convergence of the backbone routing protocols may create delay that could impact these applications.

There are many more details, but these areas should be considered no matter what your plan is. You will notice there are no technical questions regarding a provider's support for MPLS technology itself. This is one of the don'ts, and we will go into many of these in detail next time.

Robbie Harrell (CCIE#3873) is the National Practice Lead for Advanced Infrastructure Solutions for SBC Communications. He has over 10 years of experience providing strategic, business, and technical consulting services to clients. Robbie resides in Atlanta, and is a graduate of Clemson University. His background includes positions as a Principal Architect at International Network Services, Lucent, Frontway and Callisma.