July 2007 69th IETF@Chicago

Requirements for delivering MPLS services over L3VPN

draft-kumaki-l3VPN-e2e-mpls-rsvp-te-reqts-04.txt

Kenji Kumaki KDDI, Editor

Raymond Zhang BT

Nabil Bitar Verizon

July 2007 69th IETF@Chicago

Summary of this draftSummary of this draft

• Motivation– Provide robust MPLS services to customers as NGN services

• Can offer end-to-end paths using LDP • Can’t offer end-to-end MPLS TE LSPs between customer sites• Want to provide CE-to-CE MPLS TE LSPs

– Guarantee bandwidth, Provide fast protection, diversely routed path ……

– Provide all of the benefits of a L3VPN• Offer vrf instance per customer to avoid security issues

– Customers can not forward packets through the service provider’s general forwarding instance.

– They can not join the service provider’s routing domain and MPLS signaling domain.

• Assign address space that is unique only to a VPN

• The important thing is that– Most carriers and service providers deploy L3VPN (not L1VPN)– Don’t see L1VPN solution

July 2007 69th IETF@Chicago

Summary of this draft (contd.)Summary of this draft (contd.)

• This draft is to:– Clarify issues for an e2e MPLS TE LSP

over BGP/MPLS IP-VPNs– Describe the reference model, application

scenarios and specific requirements for these LSPs

July 2007 69th IETF@Chicago

Reference modelReference model

Service Provider’s network

Customer’s or

another SP’s network

Customer’s or

another SP’s network

P-TE LSPs

Vrf instances

C-TE LSPs

CE

CE

CC

CE

CEPE

PE

PE

PE

P P

July 2007 69th IETF@Chicago

Application ScenariosApplication Scenarios

• Fast recovery over IP-VPN

• Strict C-TE LSP QoS guarantees

• Load balance of CE-to-CE traffic

July 2007 69th IETF@Chicago

Major Changes from -03Major Changes from -03

• Added new co-author, Nabil Bitar, Verizon• Clarified problem statement in Section 3• Modified specific requirements in Section 6 based on

Nabil’s comments

July 2007 69th IETF@Chicago

Next StepsNext Steps

• Request WG to accept this I-D as a WG document