idnits 2.17.1 draft-bao-mpls-tp-path-transfer-reqs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The MPLS-TP path transfer process MUST NOT cause any disruption of user traffic flowing over the path whose control is being transferred or over any other path in the network. If transfer fails, it's affection SHOULD be limited to the control plane or management plane, and the data plane MUST not be affected. -- The document date (February 28, 2010) is 5171 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'MPLS-TP-Fwk' is mentioned on line 75, but not defined == Missing Reference: 'RFC3031' is mentioned on line 78, but not defined == Missing Reference: 'RFC5085' is mentioned on line 78, but not defined == Unused Reference: 'RFC4447' is defined on line 186, but no explicit reference was found in the text == Unused Reference: 'RFC5036' is defined on line 190, but no explicit reference was found in the text == Unused Reference: 'DYNAMIC-MS-PW' is defined on line 201, but no explicit reference was found in the text == Unused Reference: 'MPLS-TP-CP' is defined on line 206, but no explicit reference was found in the text == Unused Reference: 'SEG-PW' is defined on line 211, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-22) exists of draft-ietf-pwe3-dynamic-ms-pw-10 == Outdated reference: A later version (-02) exists of draft-abfb-mpls-tp-control-plane-framework-01 == Outdated reference: A later version (-18) exists of draft-ietf-pwe3-segmented-pw-13 Summary: 3 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Yuanlin Bao 3 Internet-Draft Faming Yang 4 Intended status: Informational Xihua Fu 5 Expires: September 1, 2010 ZTE Corporation 6 February 28, 2010 8 Requirements For Path Ownership Transfer Between Management Plane And 9 Control Plane In A MPLS-TP Network 10 draft-bao-mpls-tp-path-transfer-reqs-00.txt 12 Abstract 14 From a carrier perspective, the possibility of transferring the 15 ownership and control of an existing and in-use path between the 16 management plane and the control plane, without actually affecting 17 data plane traffic being carried over it, is a valuable option. This 18 memo sets out the requirements for such procedures. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on September 1, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Conventions used in this document . . . . . . . . . . . . . 3 62 2. Requirements for MPLS-TP Path Transfer . . . . . . . . . . . . 3 63 2.1. General Requirements for LSP and PW . . . . . . . . . . . . 4 64 2.2. Special Requirements for LSP . . . . . . . . . . . . . . . 4 65 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 66 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 67 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 5.1. Normative References . . . . . . . . . . . . . . . . . . . 5 69 5.2. Informative References . . . . . . . . . . . . . . . . . . 5 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Introduction 74 As described in the architecture for Multi-Protocol Label Switching 75 Transport Profile (MPLS-TP) [MPLS-TP-Fwk], the overall architecture 76 framework for MPLS-TP is based on a profile of the MPLS and 77 Pseudowire (PW) procedures as specified for the MPLS and (MS-)PW 78 architectures defined in [RFC3031], [RFC3985] and [RFC5085]. Thus 79 MPLS-TP path includes LSP and PW which is beared in LSP. MPLS-TP 80 path can be configured and controlled by means of a Network 81 Management System (NMS) operating within the Management Plane (MP). 82 NMS/MP is the owner of MPLS-TP path, being responsible of it's set 83 up, tear down and maintenance. 85 The adoption of control plane in a MPLS-TP network that is already in 86 service - controlled by NMS at MP level - introduces the need for a 87 procedure able to coordinate a controlled transfer of PW from MP to 88 CP. In addition, the control transfer in the opposite direction, 89 from CP to MP should be possible as well. 91 This memo considers the requirements of MPLS-TP path ownership 92 transfer between management plane and control plane. Note, some 93 aspects of a control-plane-initiated connection must be capable of 94 being queried/controlled by the management plane. These aspects 95 should be independent of how the connection was established. 97 1.1. Conventions used in this document 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 2. Requirements for MPLS-TP Path Transfer 105 [RFC5493] describes the requirements for the conversion between 106 permanent connection (PC) and switched connection (SC) in a GMPLS 107 Network. However, MPLS-TP network supports unidirectional, 108 associated bidirectional, co-routed bidirectional point-to-point 109 transport paths and unidirectional point-to-multipoint transport 110 paths. So, some requirements listed in [RFC5493] also apply to 111 MPLS-TP path transfer. However, due to the particularity of MPLS-TP 112 path including LSP and PW, there are still some different 113 requirements. This section will lists all the requirements for the 114 MPLS-TP path transfer. 116 2.1. General Requirements for LSP and PW 118 This section lists the general requirements for LSP and PW. 120 1) No disruption of user traffic 122 The MPLS-TP path transfer process MUST NOT cause any disruption 123 of user traffic flowing over the path whose control is being 124 transferred or over any other path in the network. If transfer 125 fails, it's affection SHOULD be limited to the control plane or 126 management plane, and the data plane MUST not be affected. 128 The MPLS-TP path ownership transfer SHALL occur without 129 generating alarms towards the end users or the NMS. 131 2) Data Plane PW Consistency 133 The MPLS-TP transport path MUST stay in place throughout the 134 whole control transfer process. That is to say, LSP and PW MUST 135 follow the same transport path through the network and MUST use 136 the same network resources. 138 3) Synchronization of State among Nodes during Conversion 140 It MUST be assured that the state of the LSP and PW is 141 synchronized among all nodes traversed by it before the 142 conversion is considered complete. 144 4) Transfer between Management Plane and Control Plane 146 It MUST be possible to transfer the ownership of a MPLS-TP path 147 from the management plane to the control plane. It SHOULD be 148 possible to transfer the ownership of a MPLS-TP path from the 149 control plane to the management plane. 151 5) Revertion after Transfer Failure 153 It's possible that PW transfer may fail. If PW fails to transfer 154 from one plane to the other, a revertion mechnism MUST be 155 possible to ensure LSP and PW status revert to the initial one 156 before the transfer process starts. 158 2.2. Special Requirements for LSP 160 For associated bidirectional LSP, it is comprised of two independent 161 unidirectional LSP. The edge nodes and transit nodes belonging to 162 the same associated bidirectional transport path, must be aware about 163 the pairing relationship of the forward and the backward directions 164 belonging to the same associated bidirectional transport path. So, 165 the pairing relationship MUST be created in CP when the associated 166 bidirectional LSP from management transfers from MP to CP. s 168 3. Security Considerations 170 TBD. 172 4. Acknowledgements 174 The RFC text was produced using Marshall Rose's xml2rfc tool. 176 5. References 178 5.1. Normative References 180 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 181 Requirement Levels", BCP 14, RFC 2119, March 1997. 183 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 184 Edge (PWE3) Architecture", RFC 3985, March 2005. 186 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 187 Heron, "Pseudowire Setup and Maintenance Using the Label 188 Distribution Protocol (LDP)", RFC 4447, April 2006. 190 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 191 Specification", RFC 5036, October 2007. 193 [RFC5493] Caviglia, D., Bramanti, D., Li, D., and D. McDysan, 194 "Requirements for the Conversion between Permanent 195 Connections and Switched Connections in a Generalized 196 Multiprotocol Label Switching (GMPLS) Network", RFC 5493, 197 April 2009. 199 5.2. Informative References 201 [DYNAMIC-MS-PW] 202 Luca Martini, Matthew Bocci, and Florin Balus, "Dynamic 203 Placement of Multi Segment Pseudo Wires", 204 draft-ietf-pwe3-dynamic-ms-pw-10.txt . 206 [MPLS-TP-CP] 207 Loa Andersson, Lou Berger, and Luyuan Fang, "MPLS-TP 208 Control Plane Framework", 209 draft-abfb-mpls-tp-control-plane-framework-01.txt . 211 [SEG-PW] Luca Martini and Chris Metz, "Segmented Pseudowire", 212 draft-ietf-pwe3-segmented-pw-13.txt . 214 Authors' Addresses 216 Yuanlin Bao 217 ZTE Corporation 218 5F, R&D Building 3, ZTE Industrial Park, XiLi LiuXian Road 219 Nanshan District, Shenzhen 518055 220 P.R.China 222 Phone: +86 755 26773731 223 Email: bao.yuanlin@zte.com.cn 224 URI: http://www.zte.com.cn/ 226 Faming Yang 227 ZTE Corporation 228 4F, R&D Building 3, ZTE Industrial Park, XiLi LiuXian Road 229 Nanshan District, Shenzhen 518055 230 P.R.China 232 Phone: +86 755 26773731 233 Email: yang.faming@zte.com.cn 234 URI: http://www.zte.com.cn/ 236 Xihua Fu 237 ZTE Corporation 238 West District,ZTE Plaza,No.10,Tangyan South Road,Gaoxin District 239 Xi An 710065 240 P.R.China 242 Phone: +8613798412242 243 Email: fu.xihua@zte.com.cn 244 URI: http://www.zte.com.cn/