Deployment of MPLS VPN in Large ISP Networks

IP Network Architecture

Outline


 

Requirements Associated with the Deployment of MPLS VPN in an ISP Network Strategy for the Incremental Deployment of MPLS VPN MPLS VPN - Implementation Options Carrier s Carrier and Inter-provider Backbone VPN Deployment Issues and Future Work
2

NANOG21, February 2001, Atlanta

Requirements Associated with the Deployment of MPLS VPN in an ISP Network



Preservation of network integrity



the new service features must not entail the risk of degrading the reliability and availability of the existing network Scaleable to large number of provider-based VPN Network of network VPN services


Scalability
 

Carrier s Carrier and Inter-provider backbone VPN

 

Satisfaction of customers security requirements Proactive management and fast restoration in case of failure
3

NANOG21, February 2001, Atlanta

Strategy for the Incremental Deployment of MPLS VPN



The steps described here are simplified for illustrative purposes The steps may not be followed in the exact order proposed in a production environment Different steps may also be taken simultaneously, depending on the business needs, feature availability, and interoperability

NANOG21, February 2001, Atlanta

Strategy for the Incremental Deployment of MPLS VPN (2)



Step 1. Preparation:


Extensive lab test: feature, regression, network integration Potential hardware and software upgrade on all routers (P s - Provider backbone routers, and PE s - Provider Edge routers) for supporting MPLS LDP, VPN, RSVP features Routing
 

IGP - link state protocol, e.g. OSPF or IS-IS BGP - multiple BGP sessions for VPN PE routers
5

NANOG21, February 2001, Atlanta

Strategy for the Incremental Deployment of MPLS VPN (3)



Step 2. Enable MPLS in the core



Enable LDP on all backbone routers if possible MPLS TE may be enabled in certain areas as necessary The distribution and access routers may not be all MPLS enabled at this time

NANOG21, February 2001, Atlanta

Strategy for the Incremental Deployment of MPLS VPN (4)



Step 3. Basic MPLS VPN connectivity with limited sites and limited number of VPN s:


Upgrade the hardware and software on the VPN PE routers only Enable LDP and VPN on the selected PE s Enable MPLS LDP in more (or all) router locations Enable VPN in additional PE routers as needed

Step 4. Expand the MPLS VPN footprint

 

Step 5. MPLS VPN General Availability

7

NANOG21, February 2001, Atlanta

Strategy for the Incremental Deployment of MPLS VPN (5)



Step 6. Inter-AS MPLS VPN and Carrier s Carrier



Interconnect different AS s of the same provider providing MPLS VPN services Interconnect with international partners for Global reachability Provide VPN services to other ISP s Carrier s Carrier VPN Enable QoS features for the MPLS network, including VPN


Step 7. QoS-enabled MPLS VPN



Using QoS VPN for potential VoIP, Video services

NANOG21, February 2001, Atlanta

MPLS VPN - Implementation Options

Case Study 1: VPN (PE) + LDP (P, PE)

Configuration: IGP (e.g. OSPF, or IS-IS) routing in the core MPLS (e.g. LDP) enabled for all P and PE routers MP-iBGP fully meshed between PEs VPN configured on VPN PEs PE-CE can be e-BGP, OSPF, RIP or Static
LSP - Label Switched Path PHP: Penultimate Hop Popping VPN A
LDP VPN LDP VPN LDP VPN PHP LDP

VPN B

VPN B P1 VPN A P2

P3 P5
VPN

VPN A P4

Setting up LSP through LDP, LSP path = IGP path - Simplicity Requires LDP interoperability; VPN/LDP inter-working No control on LSP, label failure on IGP path can cause VPN failure
NANOG21, February 2001, Atlanta 10

Case Study 2: VPN (PE) + RSVP TE Tunnel (PE-PE)

Configuration: Using RSVP TE Tunnel (PE-PE) to set up the LSP Set up back-up tunnel for failure protection IGP, BGP, VPN, and PE-CE link configuration as in Case 1
OSPF area 1 VPN A
TE VPN

OSPF area 0

OSPF area 2 VPN B

TE VPN

TE VPN PHP TE

VPN B P1 VPN A P2

P3 P5
VPN

VPN A P4

Requires RSVP TE tunnel, potentially across multi-OSPF areas Requires RSVP TE interoperability; VPN / TE inter-working End-to-end LSP control - better failure protection, fast re-route may be used
NANOG21, February 2001, Atlanta 11

Case Study 3: VPN + LDP + RSVP TE Tunnel

Configuration: LDP enabled on all routers, except P4 and P5 RSVP TE Tunnels used only in OSPF area 0 (P1-P3-P5), with back-up tunnel (P1-P2-P4-P5)
OSPF area 1 VPN A
LDP VPN TE LDP VPN PHP TE LDP VPN PHP LDP

OSPF area 0

OSPF area 2 VPN B

VPN B P1 VPN A P2

P3 P5
VPN

VPN A P3

P4

Requires RSVP TE interoperability Requires VPN/LDP inter-working, LDP/TE inter-working Provides feasible solutions when cases 1 and 2 cannot be realized
NANOG21, February 2001, Atlanta 12

Carrier s Carrier VPN

ISP A backbone provides VPN services to ISP B
Case 1. ISP B may not run MPLS in its network Case 2. ISP B may run MPLS (LDP) in its network Case 3. ISP B may run MPLS VPN in its network - Hierarchical VPN s
iBGP

ISP B - Site X
CE1

LDP VPN B

ISP B s Customers
PE1
LDP VPN A VPN B LDP VPN A VPN B LDP VPN A VPN B

LDP

ASBR1, RR

VPN B

VPN A VPN B VPN B

ASBR2, RR

MP- iBGP

PE2

LDP VPN B

CE2

ISP B s Customers ISP A Carrier Backbone

ISP B - Site Y

Carrier s Carrier VPN Case 3

NANOG21, February 2001, Atlanta 13

Carrier s Carrier VPN (2)



 

  

MPLS (LDP) used between PE and CE in all three cases PE-CE routing: OSPF/RIP/Static Security mechanism needed for label spoofing prevention iBGP sessions between ISP B sites Use Route Reflectors to improve scalability ISP A distributes ISP B s internal routes through MPLS-VPN only ISP B s external routes advertised to all ISP B site through ISP B s Route Reflector iBGP session
14

NANOG21, February 2001, Atlanta

Inter-Providers Backbone VPN

RR-A RR-B
LDP

AS A
PE1
VPN B VPN AB

AS B

VPN B

CE1

LDP VPN A

PE-ASBR1
LDP VPN A

PE-ASBR2 MP- eBGP MP- iBGP

CE2 PE2

MP- iBGP

 

Customers have sites connected to different AS s or ISP s PE-ASBR s connect the two AS s
  

E-BGP sessions for VPN-IPv4 single VPN label, no LDP label no VRF assigned, based on policy agreed by the two ISP s (AS s)

 

Route reflectors reflect VPN-IPv4 internal routes within its AS Security, scalability, policies between ISP s
15

NANOG21, February 2001, Atlanta

MPLS VPN Deployment Issues



MPLS Feature availability



VPN, LDP, RSVP, CR-LDP: individually, and Interworking amongst subsets of these Coping with reality of feature availability Required in an heterogeneous IP network Partially enable MPLS vs. Fully enable MPLS in the entire IP backbone TE tunnels, use only as needed vs. fully meshed QoS VPN: map VPN into guaranteed bandwidth tunnels with class of service
16

Multi-vendor inter-operability


Deployment strategy


 

NANOG21, February 2001, Atlanta

MPLS VPN Deployment Issues (2)



Scalability
 

The use of Route Reflectors Performance impact on PE s needs to be measured Carrier of Carriers and Inter-AS backbone Assign different RDs to different sites vs. single RD for each VPN One VPN s route does not exist in other nonconnected VPN s VRF or the global routing table FR/ATM equivalent security - more study needed
17

Load sharing between PE-CE links



Security


NANOG21, February 2001, Atlanta

MPLS VPN Network Management



Available MIBs today



LSR MIB, LDP MIB, VPN MIB, MBGP MIB, RSVP TE MIB, FTN MIB, Auto-provisioning tools needed for large scale VPN deployment

Configuration and Provisioning



NANOG21, February 2001, Atlanta

18

MPLS VPN Network Management (2)



Performance


 

All MPLS features impact on performance, including basic VPN on PE routers, and need to be studied More study needed for VPN supporting QoS Network performance: delay, jitter, loss, throughput, availability Element performance: utilization Authentication, control access, monitoring
19

Security management


NANOG21, February 2001, Atlanta

MPLS VPN Network Management (3)



Traffic Management/Engineering
 

Characterize traffic for VPN s Profiling, correlation, and optimization Monitoring and troubleshooting VPN failure detection and recovery
PE1 VPN A X CE1 PE3 P1 P3 P4 PE4 CE2 P2 PE2 VPN A Y

Fault management
 

Example:

Config: LDP in the core for all P and PE router; IGP: OSPF; iBGP full mesh between PEs LSP: OSPF shortest path: PE1-P1-P3-P4-PE2; no TE tunnels. Failure: All links and nodes are up, but P3 label switching fails, LSP breaks, VPN fails. Solution need: PE1 and PE2 need to to be notified of the LSP failure; LSP needs to be re-established through recovery mechanism, restore VPN
NANOG21, February 2001, Atlanta 20

Summary


Incremental deployment of BGP/MPLS VPN in IP backbone is feasible



   

Implementation alternatives and examples illustrated here are being experimented with through lab testing Deployment Challenges Feature availability Interoperability Manageability
21

NANOG21, February 2001, Atlanta

Summary (2)


Future work


Resolve open issues on scalability, load sharing, and security Better understand service deployment and management

NANOG21, February 2001, Atlanta

22

Thank You
Luyuan Fang Principal Technical Staff Member IP Network Architecture AT&T luyuanfang@att.com