idnits 2.17.1 draft-ietf-pwe3-mpls-tp-gal-in-pw-01.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 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) No issues found here. 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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC5586]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 11, 2011) is 4727 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2119' is mentioned on line 94, but not defined == Unused Reference: 'RFC2119' is defined on line 194, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3985 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Han Li 2 Internet Draft China Mobile 3 Updates (if published): RFC5586 4 Intended status: Standards Track Luca Martini 5 Cisco System 7 Jia He 8 Huawei 10 Feng Huang 11 Alcatel-Lucent 13 Expires: November 2011 May 11, 2011 15 Using the Generic Associated Channel Label for Pseudowire in MPLS-TP 16 draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on November 11, 2011. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents in effect on the date of 47 publication of this document (http://trustee.ietf.org/license-info). 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. 51 Abstract 53 This document describes the requirements for using the Generic 54 Associated Channel Label (GAL) in Pseudowires (PWs) in MPLS-TP 55 networks, and provides an update to the description of GAL usage in 56 [RFC5586] by removing the restriction that is imposed on using GAL 57 for PWs especially in MPLS-TP environments. 59 . 61 Table of Contents 63 1. Introduction ................................................ 2 64 2. Conventions used in this document ........................... 3 65 2.1. Terminology ............................................ 3 66 3. GAL Usage for MPLS-TP PW .................................... 3 67 4. Security Considerations ..................................... 4 68 5. IANA Considerations ......................................... 4 69 6. Acknowledgments ............................................. 5 70 7. References .................................................. 5 71 7.1. Normative References ................................... 5 72 7.2. Informative References ................................. 5 73 8. Authors' Addresses .......................................... 5 75 1. Introduction 77 [RFC5586] generalizes the associated control channel mechanism of 78 [RFC5085] to be used for Sections, Label Switched Paths (LSPs), and 79 Pseudowires (PWs) in MPLS networks. [RFC5085] defines the Associated 80 Channel Header (ACH), and [RFC5586] generalizes this for use in the 81 Generic Associated Channel (G-ACh). 83 [RFC5586] defines a generalized label-based exception mechanism using 84 the Generic Associated Channel Label (GAL) to work together with the 85 ACH for use with LSPs but places restrictions on GAL usage with PWs. 87 This document removes the restriction imposed by [RFC5586]. 89 2. Conventions used in this document 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC 2119]. 95 2.1. Terminology 97 ACH Associated Channel Header 99 CW Control Word 101 G-ACh Generic Associated Channel 103 GAL G-ACh Label 105 MPLS-TP MPLS Transport Profile 107 OAM Operation, Administration, and Maintenance 109 3. GAL Usage for MPLS-TP PW 111 According to the MPLS-TP requirement document [RFC5654], it is 112 necessary that MPLS-TP mechanisms and capabilities be able to 113 interoperate with the existing IETF MPLS [RFC3031] and IETF PWE3 114 [RFC3985] architectures appropriate. [RFC5586] differentiates between 115 the usage of the GAL with PWs in MPLS and MPLS-TP environments in 116 section 4.2 as follows: 118 In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, 119 Concatenated Segments of LSPs, and with Sections, and MUST NOT be 120 used with PWs. 122 This indicates that the GAL can be used for MPLS-TP LSPs and Sections, 123 but not for PWs using an MPLS-TP PSN. 125 However, there is no restriction imposed on the usage of the GAL in 126 MPLS PWs, which is described immediately afterwards in the same 127 section of [RFC5586] (Section 4.2): 129 However, in other MPLS environments, this document places no 130 restrictions on where the GAL may appear within the label stack 131 or its use with PWs. 133 The inconsistency between the usage of the GAL with MPLS PWs and 134 MPLS-TP PWs may cause unnecessary implementation differences and is 135 in disagreement with the MPLS-TP requirements. 137 Therefore, this document specifies that the GAL can be used with 138 packets on a G-ACh on LSPs, Concatenated Segments of LSPs, Sections, 139 and PWs in both MPLS and MPLS-TP environments without discrimination. 141 [RFC5586] is updated by removing the restrictions on using GAL for PW 142 as follows: 144 - Section 1 (Introduction) in [RFC5586], the original text: 146 The GAL mechanism is defined to work together with the ACH for 147 LSPs and MPLS Sections. 149 is replaced by: 151 The GAL mechanism is defined to work together with the ACH for 152 LSPs and MPLS Sections, and for PWs. 154 - Section 4.2. (GAL Applicability and Usage) in [RFC5586], the 155 original text: 157 In MPLS-TP, the GAL MUST be used with packets on a G-ACh on 158 LSPs, Concatenated Segments of LSPs, and with Sections, and 159 MUST NOT be used with PWs. It MUST always be at the bottom of 160 the label stack (i.e., S bit set to 1). However, in other MPLS 161 environments, this document places no restrictions on where 162 the GAL may appear within the label stack or its use with PWs. 164 is replaced by: 166 In MPLS-TP, the GAL MUST be used with packets on a G-ACh on 167 LSPs, Concatenated Segments of LSPs, and with Sections, and 168 MAY be used with PWs. It MUST always be at the bottom of the 169 label stack (i.e., S bit set to 1). However, in other MPLS 170 environments, this document places no restrictions on where 171 the GAL may appear within the label stack. 173 4. Security Considerations 175 No further security considerations than [RFC5586]. 177 5. IANA Considerations 179 There are no IANA actions required. 181 6. Acknowledgments 183 The authors would like to thank Luyuan Fang, Adrian Farrel, Haiyan 184 Zhang, Guanghui Sun, Italo Busi, Matthew Bocci for their 185 contributions to this work. 187 The authors would also like to thank the authors of [RFC5586] and 188 people who were involved in the development of [RFC5586]. 190 7. References 192 7.1. Normative References 194 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 195 Requirement Levels", BCP 14, RFC 2119, March 1997 197 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 198 Label Switching Architecture", RFC 3031, January 2001. 200 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge 201 (PWE3) Architecture", RFC 3985, March 2005. 203 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 204 Associated Channel", RFC5586, June 2009 206 7.2. Informative References 208 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 209 Connectivity Verification (VCCV): A Control Channel for 210 Pseudowires", RFC 5085, December 2007. 212 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 213 and S. Ueno, "Requirements of an MPLS Transport Profile", 214 RFC 5654, September 2009. 216 8. Authors' Addresses 218 Han Li 219 China Mobile Communications Corporation 220 Email: lihan@chinamobile.com 221 Luca Martini 222 Cisco Systems, Inc. 223 Email: lmartini@cisco.com 225 Jia He 226 Huawei Technologies Co., Ltd. 227 Email: hejia@huawei.com 229 Feng Huang 230 Alcatel-Lucent shanghai Bell 231 Email: feng.f.huang@alcatel-sbell.com.cn 233 Intellectual Property 235 The IETF Trust takes no position regarding the validity or scope of 236 any Intellectual Property Rights or other rights that might be 237 claimed to pertain to the implementation or use of the technology 238 described in any IETF Document or the extent to which any license 239 under such rights might or might not be available; nor does it 240 represent that it has made any independent effort to identify any 241 such rights. 243 Copies of Intellectual Property disclosures made to the IETF 244 Secretariat and any assurances of licenses to be made available, or 245 the result of an attempt made to obtain a general license or 246 permission for the use of such proprietary rights by implementers or 247 users of this specification can be obtained from the IETF on-line IPR 248 repository at http://www.ietf.org/ipr 250 The IETF invites any interested party to bring to its attention any 251 copyrights, patents or patent applications, or other proprietary 252 rights that may cover technology that may be required to implement 253 any standard or specification contained in an IETF Document. Please 254 address the information to the IETF at ietf-ipr@ietf.org. 256 The definitive version of an IETF Document is that published by, or 257 under the auspices of, the IETF. Versions of IETF Documents that are 258 published by third parties, including those that are translated into 259 other languages, should not be considered to be definitive versions 260 of IETF Documents. The definitive version of these Legal Provisions 261 is that published by, or under the auspices of, the IETF. Versions of 262 these Legal Provisions that are published by third parties, including 263 those that are translated into other languages, should not be 264 considered to be definitive versions of these Legal Provisions. 266 For the avoidance of doubt, each Contributor to the IETF Standards 267 Process licenses each Contribution that he or she makes as part of 268 the IETF Standards Process to the IETF Trust pursuant to the 269 provisions of RFC 5378. No language to the contrary, or terms, 270 conditions or rights that differ from or are inconsistent with the 271 rights and licenses granted under RFC 5378, shall have any effect and 272 shall be null and void, whether published or posted by such 273 Contributor, or included with or in such Contribution. 275 Disclaimer of Validity 277 All IETF Documents and the information contained therein are provided 278 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 279 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 280 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 281 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 282 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 283 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 284 FOR A PARTICULAR PURPOSE. 286 Copyright Notice 288 Copyright (c) 2010 IETF Trust and the persons identified as the 289 document authors. All rights reserved. 291 This document is subject to BCP 78 and the IETF Trust's Legal 292 Provisions Relating to IETF Documents 293 (http://trustee.ietf.org/license-info) in effect on the date of 294 publication of this document. Please review these documents 295 carefully, as they describe your rights and restrictions with respect 296 to this document. Code Components extracted from this document must 297 include Simplified BSD License text as described in Section 4.e of 298 the Trust Legal Provisions and are provided without warranty as 299 described in the Simplified BSD License.