Requirements for Inter Domain Pseudo Wires draft-martini-pwe3-mh-pw-requirements-01.txt

1. Requirements for Inter Domain Pseudo Wiresdraft-martini-pwe3-mh-pw-requirements-01.txt Luca Martini (Cisco) Nabil Bitar (Verizon) Matthew Bocci (Alcatel)

2. Scope • Describe the necessary requirements to allow a service provider to extend the reach of PWs across multiple domains and PSN tunnels. Domains are: • ASs under one provider administrative control • IGP areas in one autonomous system • Different ASs under the administrative control of two or more service providers • administratively established PW domains

3. Single Segment PWs (SS-PWs): Reference Architecture

4. Multi-Segment PWs (MS-PWs): Reference Architecture

5. Multi-Segment Pseudo Wire Concept • A pseudo wire is composed of segments • Each segment is independently routed • Allow a pseudo wire to be stitched from one PSN tunnel to another at the end of one segment and the beginning of the next segment • But, the concatenation of segments must connect the two endpoints of a pseudo wire • The endpoints of a pseudo wire are called Ultimate PEs (U-PEs) • Intermediate segments (neither end of a segment is a PW endpoint) are delimited by Switching PEs (S-PEs)

6. Terminology Definition • Ultimate PE (U-PE): PE where customer-facing ACs are bound to a PW forwarder • SS-PW: Direct connection between two U-PEs. That is what PWE3 currently defines • MS-PW: A static or dynamically configured set of two or more contiguous PW segments that function as a single pt-pt PW. MS-PWs endpoints are on U-PEs • PW Switching Provider Edge (S-PE): A PE capable of switching the control and data planes of the preceding and succeeding PW segments in a MS-PW • PW Segment: A part of a single-segment or multi-segment PW, which is set up between two U-PEs and/or S-PEs

7. Applications • MS-PWs to alleviate scalability concerns in large Service provider networks • RSVP-TE tunnel meshness among the PEs for bandwidth-managed PWs • Number of targeted LDP sessions maintained by PEs for setting up PWs over an MPLS PSN • MS-PWs for Extending PWs to metro and access networks: • Conform to today’s network management practices • Deal with the increase in number of PEs – scalability concern • MS-PWs for extending PWs across provider boundaries to deal with: • Confidentiality and security requirements: • U-PE addresses in one provider domain not advertised to other-providers’ domains • Number of “authenticated” sessions that need to be managed between providers • The desire not to extend contiguous PSN tunnels (e.g., TE tunnels) between one provider and another provider • Interworking between different PSN tunneling technologies (e.g., MPLS and L2TP) • Mainly applies in interconnecting different providers’ networks

8. Architecture Requirements • S-PEs MAY only support switching PWs of the same PW type. • The PWs MUST remain transparent to the P-routers. A P-router is not an S-PE or an U-PE from the MS-PW architecture viewpoint. • The MS-PWs MUST use the same encapsulation modes specified for SS-PWs. • S-PEs MAY change the type or encapsulation mode • A MS-PW SHOULD be able to pass across PSNs of all technologies specified by PWE3 for SS-PWs. • Both directions of a PW segment MUST terminate on the same S-PE/U-PE.

9. Setup Mechanisms Requirements • Setup mechanisms • Mechanism1: • Static endpoint PW provisioning at U-PEs • Static PW segment endpoint configuration at S-PEs • PW segment signaling between a U-PE and S-PE or between an S-PE and S-PE • Mechanism 3: • Static end-point provisioning at U-PEs • Dynamic S-PE discovery and dynamic PW-segment placement between a U-PE and S-PE and between S-PEs. • A hybrid of mechanism1 and mechanism2

10. Setup Requirements • Static S-PE selection and PSN tunnel selection MUST be provided. • The MS-PW path MUST have the ability to be dynamically setup between the U-PEs by provisioning only the U-PEs. • Dynamic MS-PW pseudo wire setup requires that a unique identifier be associated with a PW and that contains sufficient information to determine the path to the remote U-PE • Procedures MUST be provided to allow dynamic setup of MS-PWs across providers when the providers do not advertise IP reachability information to routers in their network • Solutions MUST strive to minimize amount of configuration to setup an MS-PW. • MS-PW signaling procedures MUST define clear rules for triggering the setup of segments of a MS-PW. • The signaling procedures MUST be defined such that the setup of a MS-PW is considered successful if and only if all segments of the MS-PW are successfully setup. • Mechanisms MUST be developed to propagate setup explicit failure indications to the S-PEs and U-PEs associated with the failed MS-PW.

11. Resiliency Requirements • The ability to configure an end-end backup PW path for a primary PW path MUST be supported • The ability to configure a backup PW for a primary PW • PSN tunnel reroute MUST be transparent to the PW segments carried within the tunnel • Automatic Mechanisms to perform fast switchover from a primary PW to a backup PW upon failure detection SHOULD be provided to minimize packet loss. • Configuration Mechanisms to perform a switchover from a primary PW to a backup PW upon failure detection SHOULD be provided. • A mechanism to automatically revert to a primary PW from a backup PW MAY be provided and should be enable/disabled by administrative control. • Mechanisms for PW segment failure detection and notification to other segments of a MS-PW MUST be provided.

12. Traffic Engineering and QoS Requirements • Per PW/QoS class setup priority should be provided. • In case the PSN tunnel lacks the resources necessary to accommodate the new PW • a PW setup failure message MUST be returned and the PW MUST fail to setup. • Alternatively: an attempt to signal an new PSN tunnel, or increase the capacity of the existing PSN tunnel MUST be made. Failure of such attempts MUST result in PW setup failure • PW traffic parameter representations MUST be the same for all types of PW. • The PW signaling MUST enable separate traffic parameter values to be specified for the forward and reverse directions of the PW. • When setting up a MS-PW, S-PEs and U-PEs MUST be able to select a tunnel across the PSN that satisfies MS-PW QoS and bandwidth requirements • PW admission control into a PSN tunnel MUST be configurable. • S-PEs and U-PEs SHOULD be able to perform Admission control into a PSN tunnel to ensure that PW bandwidth and QoS requirements can be satisfied.

13. Routing Requirements • MUST support the setup of a statically configured segment of a MS-PW. ( static S-PE selection ) • The MS-PW MUST have the ability to automatically select the S-PEs along the MS-PW path. Some of the S-PEs MAY be statically selected • The PW Routing function MUST support dynamic re-routing around failure points when segments are setup using the dynamic setup method. • The PW Routing function MUST support re-routing around failures that occur between the statically configured segment endpoints. • Routing MUST support the operation of backup protection of primary paths. • Manual routing SHOULD be supported to allow diversity for 1:1 protected PWs. MS-PW MUST be able to traverse multiple IGP domains

14. OAM Requirements • MS-PW OAM SHOULD be supported end-to-end across the network • OAM activation/deactivation SHOULD be tied to MS-PW setup/tear down • The MS-PW SHOULD support a Forward Defect Indicator (FDI) • Single ended monitoring SHOULD be supported for both directions of the MS-PW • MS-PW OAM SHOULD support switch over between 1:1 protected LSPs end-to-end • End-end and segment-based In-band monitoring SHOULD be provided • At the S-PE, defect notifications on the upstream segment of PWs must be propagated to the downstream PW segment • All PE routers along the MS-PW MUST agree on a common PW OAM mechanism • At the S-PE, defects on an PSN tunnel must be propagated to all PWs that utilize that particular PSN tunnel • The directionality of defect notifications must be maintained across the S-PE • The S-PE should be able to behave as a segment endpoint for PW OAM mechanisms • The S-PE MUST be able to pass U-PE to U-PE PW OAM messages transparently

15. Next Steps and Questions • Add Security requirements • Add policy requirements • Consideration for any further refinement of the requirements based on group feedback • WG opinion on using the Multi-Segment terminology vs. Multi-Hop • Request WG to accept this document as a WG document