Deployment of MPLS VPN in Large ISP Networks

Luyuan Fang

IP Network Architecture

AT&T

2NANOG21, February 2001, Atlanta

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

3NANOG21, 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

Scalability Scaleable to large number of provider-based VPN Network of network VPN services

Carrier’s Carrier and Inter-provider backbone VPN Satisfaction of customers’ security requirements Proactive management and fast restoration in

case of failure

4NANOG21, 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

5NANOG21, 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

6NANOG21, 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

7NANOG21, 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

Step 4. Expand the MPLS VPN footprint Enable MPLS LDP in more (or all) router

locations Enable VPN in additional PE routers as needed

Step 5. MPLS VPN General Availability

8NANOG21, 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 Step 7. QoS-enabled MPLS VPN

Enable QoS features for the MPLS network, including VPN

Using QoS VPN for potential VoIP, Video services

MPLS VPN - Implementation Options

10NANOG21, February 2001, Atlanta

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 PE’s• VPN configured on VPN PE’s• PE-CE can be e-BGP, OSPF, RIP or Static

• 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

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

VPN A

VPN A

VPN B

VPN A

VPN B

VPN

LDPVPN

LDPVPN

LDPVPN

P1

P2

P3

P4

P5

LSP - Label Switched Path

PHP LDP

PHP: Penultimate Hop Popping

11NANOG21, February 2001, Atlanta

• 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

VPN A

VPN A

VPN B

VPN A

VPN B

VPNP1

P2

P3

P4

P5

TEVPN TE

VPNTEVPN

OSPF area 0 OSPF area 1 OSPF area 2

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

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

PHP TE

12NANOG21, February 2001, Atlanta

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)

• Requires RSVP TE interoperability • Requires VPN/LDP inter-working, LDP/TE inter-working• Provides feasible solutions when cases 1 and 2 cannot be realized

Case Study 3: VPN + LDP + RSVP TE Tunnel

VPN A

VPN A

VPN B

VPN A

VPN B

VPNP1

P2

P3

P4

P5

OSPF area 0 OSPF area 1 OSPF area 2

LDPVPN

LDPVPN

TELDPVPN

P3PHP LDP

PHP TE

13NANOG21, February 2001, Atlanta

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

ISP B - Site Y

ISP B’s Customers

PE2

ISP A Carrier Backbone

ISP B - Site X

ISP B’s CustomersCE2

CE1 PE1

ASBR1, RR ASBR2, RR

iBGP

MP- iBGP

LDP

VPN B

VPN B

VPN AVPN B

LDPVPN AVPN B

LDPVPN AVPN B

LDP

VPN B

LDPVPN AVPN B

LDP

VPN B

Carrier’s Carrier VPN Case 3

Carrier’s Carrier VPN

14NANOG21, February 2001, Atlanta

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

15NANOG21, February 2001, Atlanta

Inter-Providers Backbone VPN

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

PE-ASBR1 PE-ASBR2

AS B

CE1 CE2

PE1

PE2

RR-A RR-B

LDP

VPN B

VPN B

LDPVPN A LDP

VPN A

VPN AB

AS A

MP- eBGP

MP- iBGPMP- iBGP

16NANOG21, February 2001, Atlanta

MPLS VPN Deployment Issues MPLS Feature availability

VPN, LDP, RSVP, CR-LDP: individually, and Inter-working amongst subsets of these

Coping with reality of feature availability Multi-vendor inter-operability

Required in an heterogeneous IP network Deployment strategy

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

17NANOG21, 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

Load sharing between PE-CE links Assign different RDs to different sites vs. single RD

for each VPN Security

One VPN’s route does not exist in other non-connected VPN’s VRF or the global routing table

FR/ATM equivalent security - more study needed

18NANOG21, February 2001, Atlanta

MPLS VPN Network Management

Available MIBs today LSR MIB, LDP MIB, VPN MIB, MBGP

MIB, RSVP TE MIB, FTN MIB,… Configuration and Provisioning

Auto-provisioning tools needed for large scale VPN deployment

19NANOG21, February 2001, Atlanta

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

Security management Authentication, control access, monitoring

20NANOG21, February 2001, Atlanta

Traffic Management/Engineering Characterize traffic for VPN’s Profiling, correlation, and optimization

Fault management Monitoring and troubleshooting VPN failure detection and recovery

MPLS VPN Network Management (3)

PE1

PE3 P1

P3

P2

P4

PE2

PE4

CE1

VPN AX

CE2

VPN AY

Example:

Config: LDP in the core for all P and PE router; IGP: OSPF; iBGP full mesh between PE’s 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

21NANOG21, February 2001, Atlanta

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

22NANOG21, February 2001, Atlanta

Summary (2)

Future work Resolve open issues on scalability,

load sharing, and security Better understand service

deployment and management

Thank You

Luyuan Fang

Principal Technical Staff Member

IP Network Architecture

AT&T

luyuanfang@att.com