More Cisco Press book chapters from new and classic Cisco Press books.
Rate your favorite Cisco Press books.
This chapter covers the following topics:
Topics to consider for inclusion in RFP documents
Turning the RFP into a joint planning document for implementation with selected vendors
Defining the SLAs
Training network operations staff on the new network
Planning site installation
Site handover requirements
Case study selections
Having examined the options available for implementing provider-provisioned Layer 3 virtual private networks (VPNs) and how the technology affects the enterprise network after it's implemented, we now consider how migrating from a traditional WAN to a Layer 3 VPN WAN can be managed. The procedures, mechanisms, and forms provided in this chapter are very similar to those used to successfully migrate the Cisco internal network from Frame Relay connectivity to a Layer 3 VPN with only the planned outages affecting end user service.
Network Planning
Assuming that the decision has been made (based on business, technical, and operational considerations, as outlined in previous chapters) to migrate to a Layer 3 VPN, planning is required to successfully implement that migration. This section examines the issues of writing Request for Proposal (RFP) documents, issues to discuss with the selected provider(s) and how these relate to service-level agreements (SLAs), training operators in the new network, and recommendations for how to project-manage the migration.
Writing the RFP
After the decision to implement a Layer 3 VPN has been made, the provider currently delivering WAN connectivity should be assessed to determine whether that provider has the service model, geographic coverage, SLA commitment, support infrastructure, and track record necessary to deliver the new network. In many cases, having an existing relationship with a provider may count against that provider. Undoubtedly, there will have been service issues in the past, and other providers won't have that baggage associated with them. In other respects, the attitude of "better the devil you know than the one you don't" prevails. Neither option is completely objective, so actually writing down the requirements and evaluating all potential providers equally is the best course of action.
The first job is to select a short list of potential providers for supplying WAN connectivity that you will invest time into, send an RFP to them, and fully evaluate their responses. You should send RFPs to a reasonable number to make sure that you are getting a good feel for what is competitive in the market at that time. What that number is will vary depending on requirements, but between 5 and 15 is reasonable.
The first thing to consider is what type of information will be put into the RFP. You can base your RFP on this comprehensive table of contents:
| 1 Introduction 2 Scope and objectives 3 Nondisclosure agreement 4 Company contact information 5 Applicable law 6 General RFP conditions 6.1 RFP conditions 6.2 Timescale 6.3 Delivery of the proposal 6.4 Questions and answers 6.5 Evaluation criteria 7. Service provider introduction 7.1 RFP contact details 7.2 Customers/sales information 7.3 Reference accounts/customers 8 Architecture fundamentals 8.1 Quality of service (QoS) considerations 8.1.1 QoS technologies 8.1.2 QoS mapping 8.1.3 MPLS/IP VPN QoS architecture 8.1.4 MPLS/IP VPN routing protocol support 8.1.5 MPLS/IP VPN multicast support 8.2 Core locations 8.2.1 Core circuits 8.2.2 Internet Data Center (IDC) facilities 8.2.3 Higher rates or lambda services coverage 8.2.4 MPLS/IP VPN service coverage 8.2.5 MPLS/IP VPN service road map 8.3 Hub locations 8.3.1 IDC facilities 8.3.2 Higher rates or lambda services coverage 8.3.3 MPLS/IP VPN service coverage 8.3.4 MPLS/IP VPN service road map 8.3.5 Reposition of hub locations 8.4 Regional satellite locations 8.4.1 Reposition of satellite-to-hub connectivity 8.4.2 Engineering sites coverage 8.4.3 Large satellite sites coverage 8.4.4 ATM coverage to 80% of all satellite locations 8.4.5 E1 coverage to 80% of all satellite locations 8.4.6 MPLS/IP VPN service coverage 8.5 Backup considerations 8.5.1 Backup service coverage 8.5.2 Backup service solution 8.6 Telco hotel or IDC needs 8.6.1 IDC rack requirements for larger core/hub sites 8.6.2 IDC rack requirements for smaller hub sites 8.6.3 IDC rack requirements for satellite sites 8.6.4 Remote hands and eyes 8.6.5 IDC physical security 8.6.6 IDC disaster recovery/contingency planning 9 Technical requirements matrix 9.1 Scalability/manageability 9.2 Resilience 9.3 Circuit features 9.4 Performance/capacity 10 Vendor's network/solution 10.1 Geographic layout diagrams 10.2 Ownership (fiber infrastructure) 10.3 Ownership (secondary network) 10.4 Network equipment used 10.5 Vendor's network solution 11 SLAs and network performance 11.1 General condition 11.2 SLA requirement 11.3 Availability on the hub links (core to hub) 11.4 Availability on the satellite links (hub to satellite sites) 11.5 Delay variance (DV) 11.6 Round-trip delay (RTD) 11.7 Vendor meetings 11.8 Help desk support 11.9 On-site support 11.10 Installation implementation times 11.11 Performance failure credits 11.11.1 Installation lead times 11.11.2 Upgrade lead times 11.11.3 Delay variance and RTD 11.11.4 Availability 12 Operations 12.1 Account team 12.2 Network management 12.3 Network availability and performance reporting 12.4 Reports submission 12.5 Operations review 12.5.1 Monthly operations reviews 12.5.2 Root cause analysis 12.6 Response time to outages and escalation procedures 12.7 Service provider's local partners 12.8 Vendor network management 13 Pricing requirements 13.1 Price protection 13.2 Currency 13.3 Revenue commitment 13.4 Monthly circuit costs 13.5 Monthly backup costs 13.6 Telco co-location monthly costs 13.7 Installation costs 13.8 Future sites 14 Billing and invoice management 14.1 Billing media 14.2 Billing frequency 14.3 Monthly invoice accuracy report 14.4 Invoicing elements 14.5 Late and back-bill invoice charges 14.6 No back-bill invoicing greater than three months 14.7 Discount price rule |
This table of contents is only a guideline; some elements may not apply to all networks. However, it is a good starting point for the things to consider that will be important to your network. For each of the technical issues previously described in this book, this framework allows you to identify what you want as a solution to fit your corporation's needs and how you want the providers to respond to those needs.
Note - It is worthwhile to decide ahead of time how you will rate the providers' responses by allocating some sort of marking or weighting scheme that places more importance on your corporate network needs than issues that are not so important. For example, you may determine that, because of operational reasons, you need the provider edge-customer edge (PE-CE) protocol to be Enhanced Interior Gateway Routing Protocol (EIGRP) rather than any alternative, so the marks awarded for offering this functionality may be greater than, say, multicast support if you do not make extensive use of multicast applications.
Architecture and Design Planning with the Service Providers
With the RFP written, responses gathered, and a selection made, a detailed design document must be created that documents the technical definition for the future WAN topology and services in the new network. This document forms the basis of the future design based on a peer-to-peer network architecture provided for by the new Layer 3 MPLS IP VPNs. This is a working document for both the VPN provider and those managing the network migration so that a common understanding of the technical requirements can be achieved. Clearly, this will closely resemble the requirements defined in the RFP. However, because compromises are always required in accepting proposals to RFPs, different trade-offs will be required when evaluating each provider's offerings. After the provider(s) are selected, this document replaces the RFP as a source of technical description and takes into account what the chosen provider(s) can actually offer and how that will be implemented in the enterprise network to deliver the desired service. The following is a sample of a table of contents for a design document:
| Detailed design objective QoS IP multicast Routing integration Using two independent IP/MPLS networks Key design elements Network today Roles and responsibilities WAN RFP design implications WAN carriers SP1 SP2 Next-generation network (NGN) network topology overview Current network topology New network topology Core/IDC site topology Core sites Regional hub site topology—IP VPN Satellite site topology—type 1 Satellite site topology—type 2 Satellite site topology—type 3 Satellite site topology—type 4 Satellite site topology—type 6 Partner sites IDCs/co-location connectivity IDC overview Infrastructure requirements Cabling specifications Environmental conditions Power requirements Security requirements Access control to the IDC rooms On-site assistance IDC and circuit topology MPLS IP VPN architecture and theory Routing over IP VPNs IPV4 address/routing hierarchy Routing overview Default routing BGP weight attribute change Mechanisms to avoid routing anomalies Network management subnets BGP configuration for CE gateways QoS Edge-to-edge SLA Latency Jitter Loss Number of service provider classes of service Per-class admission criteria (DSCP/IPP) Policing treatment (per-class markdown or drop) Enterprise-to-SP mapping model Remarking requirements (CE to PE) MPLS/DiffServ tunneling mode in use (Uniform/Pipe/Short Pipe) Remarking requirements (CE from PE) MPLS traffic engineering MPLS DiffServ traffic engineering Multicast Network management Enterprise monitor Router real-time monitor Router latency monitor Traps and syslogs SLAs Address management Addressing schema Security Hardware and software specifications CE device for connectivity greater than STM-1 For connectivity less than E3 (0–multiple E1s) Core router backbone switches Out-of-band routers Core site metro gateways Hub site metro gateways Port adaptors Software specifications Lab testing Future considerations |
This list only suggests topics to consider for the working document that defines how the network will be designed and how it will operate. The implementation teams from both the provider and the corporation need intimate working knowledge of the network's design and operations.
Should a systems integrator be used to manage the transition from frame-to-MPLS VPN connectivity, the systems integrator should be able to demonstrate to you a good understanding of these topics. Beyond basic understanding, a good systems integrator will be able to tell you about how different options that exist within each of these topics will affect your network after they are implemented.
Project Management
Converting a network from a Layer 1 time-division multiplexer (TDM), or from a Layer 2 offering, to a Layer 3 IP VPN is a significant task for any corporation. To successfully manage that transition, some minimal project management is advisable. Many project-management methods are available. A suitable one can efficiently do the following:
Define the order process.
Track orders against delivery dates.
Track changes to designs and contractual commitments.
Maintain reporting on risks to project success and provide an escalation path when needed.
Provide an updated Gantt chart of planned activities and resource allocation.
Track contracted to actual performance and keep track of project budgets.
SLAs with the Service Providers
This is one of the most contentious topics in negotiation between providers and their customers. It is natural that a customer paying for a service will want the delivered service to be measured against what is being paid for and will want a penalty to be in effect if the delivered service does not match what he paid for. With point-to-point Layer 2 connections, this is relatively simple. It's relatively easy to measure the path's availability and the delivered capacity on that path. However, after the any-to-any connectivity of an IP VPN is delivered, with support for multiple classes of service (CoSs), the situation is more complex.