Setup and Maintenance of Pseudo-Wires Using RSVP-TE

1. Setup and Maintenance of Pseudo-Wires Using RSVP-TE Draft-raggarwa-rsvpte-pw-01.txt Rahul Aggarwal (Juniper) Kireeti Kompella (Juniper) Arthi Ayyangar (Juniper) Dimitri Papadimitriou (Alcatel) Peter Busschbach (Lucent) Nurit Sprecher (Siemens)

2. Agenda • Why RSVP-TE ? • RSVP-TE for Traffic Engineered Multi-Segment PWs - Overview • Traffic Engineered Multi-Segment PWs and RSVP-TE • Discussion

3. Why RSVP-TE ? • Inter-Domain Traffic Engineered Pseudo-wires (PWs) • Intra-domain PSN tunnels are RSVP-TE LSPs • Look at the entire picture with all the pieces • Multi-Segment (MS) PWs and • PW TE and • PW resiliency • RSVP-TE provides existing mechanisms to address all of the above • RSVP-TE (RFC 3209) and LSP-Hierarchy (draft-ietf-mpls-lsp-hierarchy) • Same tools as those used for inter-domain RSVP-TE PSN Tunnels

4. Inter-Domain TE PW Signaling using RSVP-TEOverview • Instantiate a multi-segment PW as a bi-directional RSVP-TE LSP • This “PW LSP” is nested in intra-domain PSN RSVP-TE LSPs between PW segment end-points • Targeted RSVP-TE signaling messages between PW segment end-points • QoS signaling using TSPEC etc • PW Explicit/Record routing using ERO/RRO • Single sided signaling • Resiliency using Fast-Reroute - draft-ietf-mpls-rsvp-te-fast-reroute

5. MS-PW TE using RSVP-TE Example MS-PW partial path computation to next ASBR PATH RESV CE2 Nesting over pre-provisioned intra-region TE PSN LSP CE1 PE1 ASBR1 ASBR3 PE2 P P AS2 AS1 PE3 ASBR2 ASBR4 MS-PW with TE from PE1 to PE2 Dynamic setup of intra-region TE PSN LSP Forward MS-PW setup request to next ASBR

6. RSVP-TE and Traffic Engineered MS-PWs • Recap • RSVP-TE for PW signaling presented at IETF 60. • Traffic Engineered Multi-segment PWs were targeted as a primary motivation • Lead to the MS-PW requirements effort • MS-PW TE Motivation / Requirements – RSVP-TE applicability analysis • Based on MS-PW Requirements effort - draft-martini-pwe3-mh-pw-requirements-01.txt

7. MS-PW TE and RSVP-TEMotivations • Inter-Domain PWs • RSVP-TE already supports inter-domain signaling • draft-ietf-ccamp-inter-domain-framework-01.txt and draft-ietf-ccamp-inter-domain-rsvp-te-00.txt • Not always desirable to setup a direct signaling adjacency between U-PEs • Avoid a full mesh of signaling adjacencies between the U-PEs • Avoid a full mesh of end-to-end PSN tunnels • Instead a U-PE maintains a single adjacency with the neighboring S-PE • U-PE/S-PE can establish a RSVP-TE targeted adjacency with the S-PE of the next PSN domain and explicitly route the MS-PW to the destination U-PE

8. MS-PW TE and RSVP-TERequirements • U-PE signaling the MS-PW must have the ability to select the S-PEs on the MS-PW path • RSVP-TE Explicit routing - RFC 3209 • Dynamic re-routing around failure points • RSVP-TE Fast-reroute - draft-ietf-mpls-rsvp-lsp-fast-reroute

9. MS-PWs and RSVP-TE Requirements - Resiliency • End-to-end backup MS-PW • RSVP-TE shared style reservations – RFC 3209 • RSVP-TE allows primary and backup PWs to be associated with each other and share resources on common segments • Ability to traverse different S-PEs i.e. avoid fate sharing • RSVP-TE Explicit routing • Mechanisms to perform a fast switchover from a primary PW to a backup PW upon failure detection • RSVP-TE global repair mechanisms • S-PEs can also use RSVP-TE fast reroute • Mechanisms to propagate PW segment failure to other MS-PW segments • RSVP-TE PathErr/ResvErr/Notify – Regular procedures

10. MS-PW TE and RSVP-TERequirements - QoS • End-to-end MS-PW bandwidth reservations • RSVP-TE QoS signaling – RFC3209 • RSVP-TE can support for diverse QoS models • RSVP-TE support for diffserv, traffic priorities • RSVP-TE Crankback support - draft-ietf-ccamp-crankback-04.txt • Resource/policy admission control into RSVP-TE PSN Tunnels at U-PE and S-PE • Based on hierarchical RSVP-TE a la draft-ietf-mpls-lsp-hierarchy

11. Use PWE3 encaps/forwarding All the machinery for MS-PW TE exists PW endpoint identifier and control word bit are a missing piece MS-PW TE Potential Protocols RSVP-TE LDP • Use PWE3 encaps/forwarding • SS-PW Signaling exists • TE is a missing piece • Explicit Routing • QoS Signaling • Make-before-break • Fast-reroute…

12. Misconceptions • RSVP-TE doesn’t support targeted signaling • It does – Look at LSP-Hierarchy • RSVP-TE doesn’t have reliability support • No. Look at RSVP reliable messaging in RFC 2961 • RSVP-TE is not scalable • Compare targeted RSVP-TE signaling with targeted LDP sessions • PW signaling with either protocol requires the same information to be signaled, and the same amount of state to be maintained • Scalability is determined by the state required to setup a MS-PW and the overhead required to maintain the state. • So let us focus on the relevant question – Are there really valid reasons to not use RSVP-TE for MS-PW TE signaling?

13. Discussion • Assertion – LDP and L2TPv3 are the only protocols supported by PWE3 and hence MS-PWs must be setup using only these • True today, doesn’t have to be always the case • Requirements for MS-PW are different from SS-PWs, specifically for MS-PW TE [Hence the MS-PW requirements effort] • So why can’t there be potentially different solutions for MS-PWs – specifically for MS-PW TE ? • Requirements/Solution Evolution • CCCSS-PWs LDPSS-PWs L2TPv3->(MS-PW, MS-PW TE) • RSVP-TE MS-PWs use existing PWE3 encapsulation/data plane architecture

14. Discussion… • There are SPs with SS-PWs who see a reason to deploy a different technology for MS-PW TE – namely RSVP-TE • There are multiple vendors who want to implement it • There are no substantive technical issues with it • SPs that deploy RSVP-TE for FRR and/or QoS will want the same features for MS-PWs • Operational ease is a bonus • PWE3 must look at the big picture and address all elements of MS-PW TE • MS-PWs and • PW TE and • PW Resiliency • A piece meal approach would be short-sighted