draft-jounay-pwe3-p2mp-pw-requirements-01.txt IETF 70 PWE3 Working Group Vancouver, December 2007 F. Jounay, P. Niger, France Telecom Y. Kamite, NTT Communications S. Delord, Uecomm L. Wang,Telenor L. Martini, Cisco Corp. G. Heron, BT R. Aggarwal, Juniper (new co-author)

IETF70, December Draft Status March 2007 Version v00 submission: draft-ietf-jounay-pwe3-p2mp-pw- requirements Charter review ? Yes, a charter update is necessary to work this new topic

IETF70, December Objectives : reminder Today the PWE3 WG charter is limited to P2P PW "A pseudowire emulates a point-to-point link over an IP/MPLS network, and provides a single service which is perceived by its user as an unshared link or circuit of the chosen service." VPWS is a P2P connectivity defined in L2VPN based on P2P PW "Virtual Private Wire Service (VPWS)--L2 service that provides L2 point-to-point connectivity) across an IP and an MPLS-enabled IP network." This draft aims at describing First the needs, i.e. identified use cases that would be better addressed by a P2MP PW rather than by n x P2P PWs Secondly the requirements for the setup and maintenance of P2MP PW the security, scalability, etc

IETF70, December P2MP PW definition rewording A Point-to-Multipoint (P2MP) Pseudo Wire (PW) is a mechanism that emulates the essential attributes of a unidirectional P2MP Telecommunications service such as P2MP ATM over PSN. One of the applicabilities of a P2MP PW is to deliver a non-IP multicast service that carries multicast frames from a multicast source to one or more multicast receivers. The required functions of P2MP PWs include encapsulating service-specific PDUs arriving at an ingress Attachment Circuit (AC), and carrying them across a tunnel to one or more egress ACs, managing their timing and order, and any other operations required to emulate the behavior and characteristics of the service as faithfully as possible. P2MP PWs extend the PWE3 architecture [RFC3985] to offer a P2MP Telecommunications service. They follow the PWE3 architecture as described in [RFC3985] with modifications as outlined in this document. One notable difference between point-to-point (P2P) PWs as outlined in [RFC3985] and P2MP PWs is that the former emulate a bidirectional service whereas the latter emulate a unidirectional service. Changes since last version

IETF70, December Changes since last version introduction of VPMS "VPMS V irtual P rivate P2MP M ulticast S ervice is the relevant service relying on the use of unidirectional P2MP PWs and on a cross-connect mode at PEs" E.g. Use case: P2MP PWs enable a L2VPN with Ethernet CEs to provide a unidirectional Virtual Private P2MP multicast service (VPMS). This may be in addition to the Virtual Private Wire Service (VPWS) provided by the L2VPN. Such a service may be required when Virtual Private LAN Emulation Service (VPLS) is not desired Currently the only possible service that a Service Provider (SP) can offer to a customer that requires a P2MP unidirectional Ethernet service over a PSN is a VPLS service. VPLS natively requires MAC-based learning and forwarding. However video distribution applications generally require a P2MP distribution and may not require the added expense of MAC learning.

IETF70, December Changes since last version Point-to-Multipoint SS-PW Reference Model Added detailed requirements for traffic replication at the ingress/egress PE Referring to Figure 1, CE2 and CE6 may want to receive multicast traffic from CE1. A PE providing VPMS MUST support the following functions: Ingress PE MUST support traffic replication over its directly connected ACs toward receiver CEs if necessary, in addition to PSN transport. Egress PE MUST support traffic replication over its directly connected ACs toward receiver CEs if necessary.

IETF70, December Changes since last version Removed some text Parts referring to VPLS "the requirements for Multicast Support in VPLS is described in [VPLS MCAST REQ]…" Parts referring to Source/leaf initiated setup "P2MP SS-PW Setup Mechanisms. The PW setup could be either leaf initiated or source initiated… " Parts referring to technical spec. (PW label assignment) "the PW label MUST be upstream assigned by the Ingress PE…" Replaced controversial text Old text: PW Addresses Routing The PW tree could be statically configured at the T-PEs and each S-PE crossed. However it is RECOMMENDED to derive benefit from the use of PW addresses routing procedures (AII addressing used as reachability information) in order to allow dynamic PW tree setup based on principles described in [DYN MS-PW]. New text: Dynamically Instantiated P2MP MS-PW. The PW tree could be statically configured at the T-PEs and each S-PE crossed. However it is RECOMMENDED that a solution provides the ability to dynamically setup a MS-PW tree, by allowing the MS-PW segments to be dynamically stitched.

IETF70, December Next Step Soliciting comments Draft to be presented in L2VPN WG as it defines a new service Discussing for adopting the draft as a WG document