1 / 7

Delivering MPLS Services Over L3VPN: End-to-End Paths and Scalability Requirements

This document discusses the requirements for delivering MPLS services over L3VPN, focusing on end-to-end paths, robustness, and scalability. It outlines the motivation, benefits, and key considerations for offering CE-to-CE MPLS TE LSPs between customer sites. The draft emphasizes the need to ensure bandwidth guarantee, fast protection, and diverse routing paths, while maintaining security through VRF instances per customer. It also covers specific requirements such as FRR support, policy control, optimal path routing, DS-TE support, and MPLS OAM support. The document seeks feedback and comments for further refinement and acceptance as a working group document.

corange
Download Presentation

Delivering MPLS Services Over L3VPN: End-to-End Paths and Scalability Requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Requirements for delivering MPLS services Over L3VPNdraft-kumaki-l3VPN-e2e-mpls-rsvp-te-reqts-00.txt Kenji Kumaki ke-kumaki@kddi.com 65th IETF Dallas March 2006

  2. Overview • Motivation • Provide robust MPLS services to customers • Can offer end-to-end paths using LDP • Can’t offer end-to-end paths using RSVP extensions • Offer CE-to-CE MPLS TE LSPs between customer sites • 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 65th IETF Dallas March 2006

  3. Overview (cont.) • This draft is to: • Clarify issues for e2e MPLS TE LSP over BGP/MPLS IP-VPNs • Describe reference model for e2e MPLS TE LSP over BGP/MPLS IP-VPNs • Describe specific requirements for e2e MPLS TE LSP over BGP/MPLS IP-VPNs 65th IETF Dallas March 2006

  4. Reference model SP’s MPLS TE LSPs e2e MPLS TE LSPs Vrf instances Customer’s or another SP’s network Customer’s or another SP’s network Service Provider’s network 65th IETF Dallas March 2006

  5. Summary of Requirements • Establish CE-to-CE MPLS TE LSPs over BGP/MPLS IP-VPN (i.e. vrf instance) • Offer scalable and robust CE-to-CE MPLS TE LSPs over vrf instance • Provide these LSPs in carrier’s carrier environments as well as basic BGP/MPLS IP-VPN environments • Detailed requirements [See in section 5.] • FRR support • Policy control support • Optimal path support • DS-TE support • MPLS OAM support • etc 65th IETF Dallas March 2006

  6. Remaining Issues • Add application scenarios ? • Add P2MP e2e TE LSPs ? • Separated draft or same draft • Any other specific requirements? 65th IETF Dallas March 2006

  7. Next Actions • Need more comments and feedback from WG • Got some comments and feedback from Raymond of BT infonet • Will work with him in next version • Request WG to accept this I-D as a WG document 65th IETF Dallas March 2006

More Related