Chapter 10: Migration Strategies

Cisco Press

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.

Related:
1 2 3 Page 1
Page 1 of 3
IT Salary Survey 2021: The results are in