We've created a WAN RFP template to meet each of the key areas we know to be important when considering connectivity from MPLS, VPLS to SD-WAN.
Delivering a high-quality WAN RFP document that is built based on your specific requirements is a time-intensive exercise. It requires a breadth of technical and industry experience - from understanding applications and products to industry experience - to force service provider transparency. We’re sharing our RFP template which we hope will provide your Enterprise with a head start.
Of course, your business expects a lot from you and your team when embarking on WAN procurement projects. They expect results. Our free resources will help you solve the most pressing WAN buying issues, problems, new challenges and more.
In this article, we’ll discuss the top 8 WAN RFP template components.
1. Selecting providers to include
Perhaps an obvious component but remains challenging. There are numerous resources we know of; including data on major service providers, resellers and VNO’s (Virtual Network Operators). The task of provider research is further compounded due to the numerous available service options, i.e. SD-WAN services, MPLS, VPLS and Internet IP VPN.
Network Union have researched the market, details of which are available via our provider PDF which is free to all blog readers. Whether you use our data or move forward with providers you already have in mind, what follows is some of the core components to consider. So, get going and challenge providers with regards to their capability!
2. Network Reach (Provider Edge)
With service provider marketing suggesting capability such as ’99% coverage of the UK’, understanding network reach is important. These kind of statements, professing to offer such a high coverage, are typically talking about wholesale agreements with the likes of BT Open Reach, COLT, Virgin Wholesale and so on.
Fig 1 details a small network operator backhauling traffic.
As the graphic demonstrates, a small network operator is able to market their capability offering complete coverage of the UK with only two Provider Edge nodes. PE nodes are a providers entry point into their core network. The greater percentage of PE coverage, the greater their capability to terminate your office connectivity on a more local basis.
Why does this matter?
In the main, latency, cost and diversity are impacted by a greater distance between your site and the prospective providers PE node. If your business is global, the potential issue is compounded due to the need for greater tail distances as offices could be in far flung locations. If we specifically cover latency, the Global Enterprise is typically more at risk because of the potential for longer tail circuits vs a UK organisation. In short, costs are also higher when PE coverage is lower due to the longer distances between office and PE node.
In order to gain clarity, we suggest asking for specific detail on true PE coverage within your RFP.
In the early 2000’s, the typical WAN RFP / ITT revolved around Internet IP VPN - the technology began to replace legacy networks such as Frame Relay and ATM services. As the decade progressed, we witnessed the take-up of MPLS and VPLS services due to their ability to support QoS (Quality of Service) in conjunction with privacy. However, today, we are witnessing an Internet IP VPN resurgence due to the interest in SD-WAN technology. The capability of devices such as Cisco iWAN with security, deep packet firewall inspection, and application prioritisation available within a single box is producing an enticing product offering. In addition, the Internet today is a well scaled, bandwidth-rich platform when compared to a decade ago which translates into a much more viable platform.
The average user is connected on a 24/7 basis to cloud resources via both corporate and BYOD (Bring your own device) hardware. The connection could originate from the office, home, hotel or anywhere with 3G or 4G wireless connections. In the majority of cases, the connection is provided by the Internet to both personal and work cloud resources. With this in mind, it makes sense that the popularity of SD-WAN services via iWAN is increasing. In the majority of cases, the Internet is complimented by main office MPLS or VPLS connectivity where predictability of traffic performance is required.
- SD-WAN is typically associated with Internet-based connectivity - open sourced software is supported in conjunction with vendor features. We’re not quite there yet.
- MPLS VPN is a layer 3 any to any routed private WAN with end to end Quality of Service.
- VPLS VPN VPN is a layer 2 any to any LAN extension service with Quality of Service. Note: VPLS does ultimately have scaling issues with any to any topology.
- IPSec VPN is a security and encryption protocol used to secure packets as they traverse the Internet or other untrusted networks.
4. Project Management and Migration
One of the main reasons for maintaining the status quo and not changing provider is the risk associated with migration. As readers will already know, migrating and managing the process of taking infrastructure to a new WAN provider is problematic for a variety of reasons.
There is often an unwillingness to assist from the losing provider, then there are the resources required from your business to attend calls and work week in and week out on project delivery. Finally, there is the risk of downtime. With the problems comes opportunity, improved uptime, application performance and improved ways of working.
Unfortunately, we would like to say circuit delivery has improved over the last few years but the issues we are all familiar with such as wayleave, council traffic management, building access issues, failed appointments are just as time consuming today as they always were. If the service provider manages the process correctly, you and your team should always know and understand the latest circuit delivery status.
When creating your WAN RFP, we suggest asking for a pre-assigned project manager and a full outline of workflows. We would also request an overview of their perceived top 5 issues when migrating customer networks and the way in which the prospective provider met the challenge.
5. Presales work and technical design authority
The way in which your particular details are captured and processed normally consists of a manual. As an example, the TDA (Technical Design Authority) should be used to discuss both the finer points of your LAN and WAN infrastructure together with detailed documentation of the proposed network design. With respect to the technical areas, questions should be asked regarding how documentation is produced, the processes that are available to obtain the data and an overview of the resources applied to your project. The TDA documentation is growing in term of complexity as most other projects are linked to the main WAN infrastructure, from remote working to security and could access. They all have a dependency. Note, the LAN is also a component of the overall architecture. The LAN is out of scope within the template.
In order to build a complete picture of your business needs, there needs to be a systematic process of evaluating a documenting data.
IP Addressing and Routing protocols: Any detail surrounding how your current LAN and WAN is provisioned will help to make a smoother transition and assist with provider RFP responses. Are there any specific routing protocols or other networks which need to be configured?
Applications: Thorough documentation of application type, port numbers and so on will assist presales with the task of ensuring the new network will perform as required. The level of detail associated with your apps will vary depending on your available statistics. Aspects such as QoS are often very hit and miss in terms of whether or not a) the QoS is actually operating as expected and b) what exactly is configured. These afore mentioned QoS aspects may, to the uninitiated, appear quite surprising since you would expect service providers to well.. know what they are doing. However, our experience is that careful analysis of QoS configuration and settings are important to avoid a detrimental WAN impact. How much detail you decide to include within the RFP template is open to discussion.
Achieving maximum uptime is largely dependent on your specific location and the provider's available services. Fig 2 details the types of diversity and resiliency.
Our advice is to request an overview with examples of diversity which should include the following capability:
- Diverse circuits delivered with no single point of failure where possible.
- Carrier diversity - not a guaranteed method of achieving diversity but may work in some use cases.
- EFM (Ethernet First Mile)
- 3G / 4G
Complete diversity can only be achieved by leveraging the correct product from a single provider. BT offer Secure Plus (or RA02 as it is also known as) which will attempt to deliver dual Ethernet fibre services via two building entry points, dual local Exchanges and dual PE nodes. Of course, delivery is subject to site survey meaning that the end result could be that single points of failure (pinch points) remain.
Further solutions include ADSL and EFM backup. We urge caution with regards to bandwidth vs the primary circuit as congestion could potentially occur.
Lastly, we are seeing growing interest in 3G and 4G due to the fast deployment time and obvious resiliency benefits. While 3G and 4G services sound fairly simplistic in term of design, there are various options including multi-sim load balancing, termination within both the Internet and private based networks and varying levels of support and configuration.
In life support is a critical area to gain service provider transparency with regards to process and ability. All too often, support tickets languish, questions go unanswered and escalations are required to get things done and progressed. Is there an answer to these issues? In the majority of WAN RFP documents, the section labeled support concentrates on SLA fix times rather a tangible process.
The actual success of a project is largely dependent on resources. We’ve known projects experience serious issues and problems because of a single delivery engineer. The engineer simply did not prepare for the work involved and was very hit and miss in terms of expertise. The challenge is, therefore, to ensure you meet resources prior to signing contracts. Whether or not meeting and selecting resources is possible depends on the provider's thoughts on the approach but we strongly recommend asking because the difference between mediocre and great will have an impact on your project.
The last point covers statistics. How is your WAN performing from the perspective of uptime, latency, jitter, QoS, outages, packet loss, bandwidth and more. This section may feel like an exercise in box ticking but blog readers are warned that features do not always equal a benefit. WAN reporting is often so comprehensive that the amount of detail given to IT teams is overwhelming which typically means the stats are not used. The future of statistics and reporting looks bright. With the majority of networks today, there are portals which allow customers to log change requests and register support tickets. The actual end to end reporting process is becoming more user focused based on stats that are able to really understand where bottlenecks occur, even down to a users laptop.
The typical service provider will deliver regular reports which will be split down to priority tickets, network usage, outages and outstanding change requests.
Conclusion - forcing service provider transparency
The outcome of any WAN RFP project should be to achieve service provider transparency vs your own specific challenges and requirements. The success of your project is largely driven by the input of the RFP, the level of detail created and the questions asked based on the problems and opportunities within the business. While our WAN RFP template will certainly get you started, there will be work required to make the content your own.
Our own model is based on decades of research into the pitfalls of WAN procurement. The way in which we achieve the success is fairly simple, documentation of hard-won knowledge.
In general terms, a WAN RFP template should be created based on the scale of your own network infrastructure. As an example, a WAN which consists of 5 sites should not require the release of a 200 page RFP document - do not expect too many replies! As with any business, service providers will ultimately take a decision on whether or not the effort is worth the reward. In other words, the less complex a network is, the more we would recommend scaling down the RFP template.