MPLS - Preparing an RFP, Part 2

The don'ts of preparing an RFP.

This week's tip will discuss developing a Request For Proposal (RFP) for VPN services from an MPLS service provider.

The last article I wrote focused on the items that should be included (The Dos); this one will focus on several items that should not be included (The Don'ts).

As I discussed in the last article, it is recommended that enterprise organizations solicit information from carriers regarding Layer 3 MPLS VPN capabilities in the form of an RFP. The RFP serves several purposes. It allows you, the customer, to adequately evaluate a provider's capabilities and it gives you the ability to compare the provider's solution against other providers. It is important to get all of the information relevant to your desired solution and environment, but at the same time you want the information to be concise enough that the providers can respond in a timely manner. I cannot tell you how many times I have developed RFP responses on the provider side that required information that would in no way impact the delivery of the desired solution. This is critical because providers will feel that if they do not answer all of the questions, they will not receive the appropriate consideration. This creates a situation where the providers are not focusing on solution aspects of the response, but just answering questions, no matter how irrelevant.

Having said all of that, what are some of the Don'ts in terms of questions regarding MPLS service provider RFP questions?

Unless you are asking an emerging provider, don't include questions regarding financial viability in the Market Place. All providers will answer in a positive manner. They will never disclose that they are floundering or on the verge of bankruptcy. I would recommend only utilizing the major MPLS Layer 3 VPN vendors in the short term as MPLS is still in a state of transition in the market and the large carriers have more to offer.

Don't ask about technical details regarding the carrier's technical implementation of MPLS on their backbone. This does not mean you don't ask questions about service delivery capabilities over the carrier's backbone via MPLS. The carriers have standardized based on RFC 2547 for Layer 3 VPN services. The MPLS architecture provides the transparent transport of VPN capabilities and having the provider outline how they have implemented this capability is a waste of time. This is analogous to asking a Frame or ATM carrier how they provide PVCs on their backbone. You don't need this information. You will want to know if they can provide things like QoS, any-to-any and point-to-point reachability, but details of the MPLS implementation is standardized for the most part and does not represent a differentiator.

Don't ask the provider to provide solutions regarding technical aspects of your internal environment as part of the solution. In other words, when asking about routing, IP addressing, migration, keep your questions focused on the backbone capabilities, not how the provider solves internal routing issues and such. Asking the provider to re-address your network or optimize your routing is fruitless as the carriers typically do not have the resources to handle this. If you do ask, expect to see consulting charges.

Please keep in mind that you want the provider to solve a problem you have, not discuss irrelevant information that distracts them from their purpose and provides you additional content to sort through.


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.


This was first published in October 2004

Dig deeper on VPN design

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchNetworking

SearchUnifiedCommunications

SearchTelecom

SearchSDN

Close