November th Requirements for supporting Customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN draft-kumaki-l3VPN-e2e-mpls-rsvp-te-reqts-05.txt Kenji Kumaki KDDI, Editor Raymond Zhang BT

November th Summary of this draft Motivation –Customers expect to run triple play services through BGP/MPLS IP-VPNs –Need to provide end-to-end RSVP paths and/or end-to-end RSVP-TE LSPs to customers An end-to-end RSVP path can be used to provide for bandwidth and QoS guarantees. An end-end MPLS TE path may be used to guarantee bandwidth, and provide for MPLS fast reroute around node and link failures. Can’t offer end-to-end RSVP paths and MPLS TE LSPs between customer sites –Provide all of the benefits of an IP-VPN 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

November th Summary of this draft (contd.) This draft is to: –Clarify issues for an e2e RSVP path and e2e MPLS TE LSP over IP-VPNs –Describe a reference model, application scenarios and specific requirements for these LSPs The important thing is that –Most carriers and service providers deploy L3VPNs (IP-VPNs) (not L1VPNs) –Don’t see L1VPN solutions

November th Reference model Service Provider’s network (BGP/MPLS IP-VPN) Customer’s or another SP’s network Customer’s or another SP’s network P-TE LSPs Vrf instances C-TE LSPs CE C C PE PP C-RSVP path

November th Application Scenarios Fast recovery over IP-VPN Strict C-TE LSP QoS guarantees Load balance of CE-to-CE traffic RSVP Aggregation over MPLS TE Tunnels

November th Major Changes from -04 Changed a title Modified an introduction Added a native RSVP model (between PE and CE) in Section 4 and 5 –RSVP Aggregation over MPLS TE Tunnels

November th Next Steps Need more comments and feedback Request WG to accept this I-D as a WG document