Subject: PWE3 Liaison Response: T-MPLS Date: Sat, 03 Jun 2006 11:04:39 +0100 From: Stewart Bryant To: greg.jones@itu.int, tsbsg15@itu.int CC: statements@ietf.org, sjtrowbridge@lucent.com, Ghani.Abbas@marconi.com, mark.jones@sprint.com, "Betts betts01"@nortel.com, maeda@ansl.ntt.co.jp, sob@harvard.edu, adrian@olddog.co.uk, jari.arkko@piuha.net, townsley@cisco.com, danny@arbor.net, pwe3@ietf.org To: ITU-T Study Group 15 Greg Jones greg.jones@itu.int tsbsg15@itu.int Cc: IETF statements@ietf.org Stephen Trowbridge sjtrowbridge@lucent.com Ghani Abbas Ghani.Abbas@marconi.com Mark Jones mark.jones@sprint.com Malcolm Betts betts01@nortel.com Yoichi Maeda maeda@ansl.ntt.co.jp Scott Bradner Adrian Farrel Jari Arkko Mark Townsley Danny McPherson PWE3 mailing list From: IETF PWE3 Working Group Response contact: Stewart Bryant stbryant@cisco.com Technical contact: Stewart Bryant stbryant@cisco.com Purpose: Information Subject: Response to your liaison on T-MPLS of May 4 and April 2 2006 Thank you for your liaisons of May 4 and April 2 and for the kind invitation to the interim meeting that 19-23 June in Ottawa. We have studied the consented documents from the April liaison and the further clarifications in the May liaisons. We have ensured that IETF technical experts will participate in the Ottawa meeting. You are already in receipt of comments from the IETF MPLS-WG with which we fully concur. These comments refer to G.8110.1/Y.1370.1 Appendix 1: Functional Model for describing PWE3 and MPLS Network Interworking G.8110.1 states: "The IETF PWE3 work group has developed an MPLS transport concept, know as pseudowires." Later G.8110.1 states: "The PSN can be implemented by utilizing a MPLS label switched network." PWE3 has developed methods of transporting services over many different PSNs, one of which is MPLS. G.8110.1 states: "PWE3 is intended to provide only the minimum necessary functionality to emulate a wire with the required degree of faithfulness for the given service definition." The purpose behind the wording "provide only the minimum" was to prevent over engineering. In many cases, PWE3 provides more than just the minimum necessary functionality. We think that to put this quote from RFC3985 in it's proper context you should note that in our view an applicability statement MUST always be provided to clearly describe the extent of the emulation, and that in some cases more than one emulation method may be needed. G.8110.1 states: "A four octet Control Word is added to the MPLS payload field for some encapsulations." The control word is DEFINED for all payload types. Use is optional for HDLC/PPP, Ethernet and some ATM modes, but is REQUIRED in all other cases. G.8110.1 states: "these processes are called "Native Signal Processing (NSP)" NSP stands for Native Service Processing G.8110.1 states: "The NSP function process the Control Word." The NSP does handle the flags (when there are flags defined). However the PW-layer processing handles the sequencing, FRG, etc. G.8110.1 states: "IETF has defined pseudowire encapsulations for Ethernet, Frame Relay, ATM, PPP, PDH, and SDH." The PPP emulation also emulates HDLC, and the SDH design also supports SONET. We also have a design for Fibre- Channel and the IETF AVT WG has a design for header compressed voice samples. G.8110.1 states: "The Forwarder function is called an Interworking Function (IWF)" It is not clear that IWF and forwarder are identical in scope and purpose. G.8110.1 states: In Figure 9 Pseudowire Model G.8110.1 shows the PW as a trail with a T-MPLS trail termination function. This termination is defined here as injecting Y.1710 OAM. The IETF PWE3 specifications use VCCV as the PW OAM. G.8110.1 states: "Pseudowires can be switched by a Subnetwork Connection (SNC). This creates in PWE3 terminology Multi-Segment Pseudowires (MS-PW) as defined in the bibliography reference [1]." Bibliography reference [1] is RFC 3985, which was published prior to our work on MS-PWs. The correct reference is reference [2]. G.8110.1 states: "When the MPLS server layer is an SDH layer network, an SDH path layer may be used instead of the pseudowire PSN transport tunnel. This approach has been called "dry martini" as defined in the bibliography reference [2]." The correct reference is reference [3]. We must however caution you that this work has not been adopted as an IETF PWE3 working group item. The draft was an individual submission which has now expired under the IETF policy of expiring such drafts after six months. Within the scope material you state: "a T-MPLS network will not peer directly with an IP/MPLS network". The data plane behavior of the one currently supported adaptation ("EVC") is intended to be that of an Ethernet pseudowire as specified in Y.1415 and RFC4448. Thus it is possible for "IP/MPLS" and T-MPLS networks to interoperate at the level of the pseudowire, e.g. a multi-segment PW could span adjacent "IP/MPLS" and T-MPLS networks connected by an S-PE. G.8110.1 states: "From an OAM perspective, pseudowires provide service-specific status and alarm management". However PW status signaling and VCCV are agnostic to the native service type. PWE3 members who are also SG13 experts make the following additional observations: G.8110.1 states: "ITU SG 13 has developed a series of recommendations for MPLS / Client Network Interworking for Ethernet (Y.1415), ATM (Cell Mode - Y.1411), ATM (Frame Mode - Y.1412), and TDM (Y.1413). These recommendations are similar in concept to IETF PWE3." You omit X.84 (frame relay PW), which, although developed by SG17, it is now in SG13. These recommendations are are identical in concept, and to the best of the ability of those concerned are identical in detail. We note that in Figure 8 you pick the semi-formal diagram from Y.1415 when the same Recommendation has a G.805 diagram as well. We recommend that you show Figure 6-2 of Y.1415 in its place. G.8110.1 states: "Pseudowires can be used as a packet transport mechanism for emulating LAN Services over a Transport MPLS network. Like in Virtual Private LAN Service (VPLS) a full mesh of T-MPLS trails (PW trails) is used to interconnect split-horizon ETH Flow Domains." We suggest that you reference Appendix I of Y.1415. Stewart Bryant IETF PWE3 Working Group Co-Chair