| An enterprise of any size uses an IGPmost commonly Enhanced Interior Gateway Routing Protocol (EIGRP) or Open Shortest Path First (OSPF). This discussion assumes the use of EIGRP; however, the principles also apply to other IGPs. In an effort to reduce the amount of reengineering that would take place to implement an IP/VPN network architecture, the enterprise requires a service provider to support EIGRP between the CE and PE routers. The enterprise requires that EIGRP metric information be propagated through the service provider VPN service and redistributed into EIGRP on the remote side of the VPN service. This preserves route types and metrics across the VPN service. When per-VPN limits are set up for unicast route entries, the enterprise requires providers to provision for up to 3000 potential routes in the VPN. On a per-site basis, one or two key hub sites may introduce up to 10,000 routes to the VPN, depending on the amount of global infrastructure connected behind these key sites. The following questions address some of the detail requirements for IGP support to the PE: Routing protocol support Do you support EIGRP as a CE-to-PE routing protocol with redistribution of metric information? EIGRP site-of-origin support If EIGRP is supported as a CE-to-PE routing protocol, do you support site-of-origin support to prevent the re-advertisement of routes learned from another site back to the VPN cloud? Routing protocol convergence time, CE to CE From the perspective of a CE, and given a common failure scenario of an access link failing between remote CE and PE routers, what is the maximum time expected for routing protocol convergence? Unicast route limits Do you configure a maximum number of unicast route entries per VPN? Do you configure a maximum number of unicast route entries per site? Can you support up to 3000 routes in the VPN, with the potential for up to 2000 being announced from core hub locations?
Similar questions could be created for OSPF if that applies. However, the use of sham link within OSPF may be required for your migration and therefore needs to be specified. Sham link enables routes across the Multiprotocol Label Switching (MPLS) VPN and routes within the enterprise campus to coexist and both be used to transport packets to remote destinations. SLA Measurement and Monitoring Capability An enterprise requires regular reports on the network's performance compared to the contracted service-level agreement (SLA). Regular measurements of latency, jitter, and per-queue packet delivery should be made available. It is preferable to have per-queue latency and jitter metrics. The enterprise should specify that the SLA be compared to a measurement of latency and jitter for every site's CE-to-PE router link. The PE-to-PE measurements should be reported separately. Additionally, this should be reported giving average figures over 5-minute intervals, not averaged over a month. The following questions can address these issues with providers: Latency measurements Can you offer a regular report on latency between enterprise sites, measured from CE to CE router? The addition of latency measurements from local CE to PE, PE to PE, and remote PE to CE is sufficient. Per-queue latency Can you offer per-queue latency statistics? Jitter measurements Can you offer a regular report on jitter between enterprise sites, measured from CE to CE router? The addition of jitter measurements from local CE to PE, PE to PE, and remote PE to CE is sufficient. Per-queue jitter Can you offer per-queue jitter statistics? Per-queue packet delivery Can you offer per-queue packet delivery statistics, detailing packet drops? Reports for each local CE to PE, PE to PE, and remote PE to CE are sufficient.
SLA Details As mentioned in the section "QoS Capability," an enterprise network is engineered so that its latency is constrained only by the physical topology of the network's underlying fiber paths. An enterprise needs to understand two different latency metrics: Observed nominal latency expected when the network is operating normally (without fault) Contractual maximum latency in the form of a contractual commitment (taking into account the possibility of a network fault)
Availability, as used here, is defined as service availability, including the local loop, the IP routing information exchange, and the reachability of all other enterprise sites on the cloud. For example, an enterprise considers a site to be unavailable if the access circuit is up and routing protocol information is being exchanged but the local site cannot reach several other sites on the VPN service. The following list provides questions to pose to providers on this matter: Average latencies For each pair in the following list of sites, please detail the nominal (95th through 99th percentile) latencies expected between CEs located in each site: Sydney, Singapore, Hong Kong, Tokyo, Beijing, Bangalore, Dubai, San Francisco, Chicago, Dallas, New York, Amsterdam, London, Brussels, Madrid, Munich, and Milan. (It is expected that this list will be replaced with locations specific to the enterprise network locations.) This is intended to capture the usual network latency expected. Maximum expected latencies For each pair in the following list of sites, please detail the maximum expected latencies you would commit to between CEs located in each site: Sydney, Singapore, Hong Kong, Tokyo, Beijing, Bangalore, Dubai, San Francisco, Chicago, Dallas, New York, Amsterdam, London, Brussels, Madrid, Munich, and Milan. This is intended to capture the contractual maximum latency observed in the fault of an underlying network element. Jitter Can you commit to a maximum of 30 ms jitter as measured from CE to CE when properly configured with appropriate LFI configurations? Packet delivery Can you meet the packet delivery requirements for each required CoS, as detailed in the section "QoS Capability"? Availability What percentage of availability can you commit to for your service, including the local loops?
|
