1 / 14

Setup and Maintenance of Pseudo-Wires Using RSVP-TE

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). Agenda. Why RSVP-TE ?

Download Presentation

Setup and Maintenance of Pseudo-Wires Using RSVP-TE

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. 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

More Related