idnits 2.17.1 draft-ietf-pce-lsp-extended-flags-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 8, 2021) is 1138 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Q. Xiong 3 Internet-Draft ZTE Corporation 4 Intended status: Standards Track March 8, 2021 5 Expires: September 9, 2021 7 LSP Object Flag Extension of Stateful PCE 8 draft-ietf-pce-lsp-extended-flags-00 10 Abstract 12 RFC 8231 describes a set of extensions to Path Computation Element 13 Communication Protocol (PCEP) to enable stateful control of MPLS-TE 14 and GMPLS Label Switched Paths(LSPs) via PCEP. One of the extensions 15 is the LSP object which includes a Flag field of the length of 12 16 bits. However, 11 bits of the Flag field have already been assigned 17 in RFC 8231, RFC 8281 and RFC 8623. 19 This document proposes to define a new LSP-EXTENDED-FLAG TLV for the 20 LSP object for an extended flag field. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 9, 2021. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions used in this document . . . . . . . . . . . . . . 3 58 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 3. PCEP Extension . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. The LSP-EXTENDED-FLAG TLV . . . . . . . . . . . . . . . . 3 62 3.2. Processing . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 4 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 65 5.1. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 4 66 5.1.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . 4 67 5.1.2. LSP Extended Flags Field . . . . . . . . . . . . . . 4 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 70 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 5 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 73 9.2. Informative References . . . . . . . . . . . . . . . . . 6 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 76 1. Introduction 78 [RFC5440] describes the Path Computation Element Protocol (PCEP) 79 which is used between a Path Computation Element (PCE) and a Path 80 Computation Client (PCC) (or other PCE) to enable computation of 81 Multi-protocol Label Switching (MPLS) for Traffic Engineering Label 82 Switched Path (TE LSP). 84 PCEP Extensions for the Stateful PCE Model [RFC8231] describes a set 85 of extensions to PCEP to enable active control of MPLS-TE and 86 Generalized MPLS (GMPLS) tunnels. One of the extensions is the LSP 87 object which contains a flag field; bits in the flag field are used 88 to indicate delegation, syncronization, removal, etc. 90 As defined in [RFC8231], the length of the flag field is 12 bits and 91 the value from bit 5 to bit 11 is used for operational, 92 administrative, remove, synchronize and delegate bits respectively. 93 The bit value 4 is assigned in [RFC8281] for create for PCE-Initiated 94 LSPs. The bits from 1 to 3 is assigned in [RFC8623] for Explicit 95 Route Object (ERO)-compression, fragmentation and Point-to-Multipoint 96 (P2MP) respectively. Almost all bits of the Flag field has been 97 assigned already. Thus, it is required to extend the flag field for 98 the LSP Object for future use. 100 This document proposes to define a new LSP-EXTENDED-FLAG TLV for an 101 extended flag field in the LSP object. 103 2. Conventions used in this document 105 2.1. Terminology 107 The terminology is defined as [RFC5440] and [RFC8231]. 109 2.2. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in BCP 114 14 [RFC2119] [RFC8174] when, and only when, they appear in all 115 capitals, as shown here. 117 3. PCEP Extension 119 The LSP Object is defined in Section 7.3 of [RFC8231]. This document 120 proposes to define a new LSP-EXTENDED-FLAG TLV for an extended flag 121 field in the LSP object. 123 3.1. The LSP-EXTENDED-FLAG TLV 125 The format of the LSP-EXTENDED-FLAG TLV is as shown in the Figure 1. 127 0 1 2 3 128 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Type=TBD | Length | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | | 133 // LSP Extended Flags // 134 | | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 Figure 1: LSP-EXTENDED-FLAG TLV Format 139 Type (16 bits): the value is TBD1 by IANA. 141 Length (16 bits): multiple of 4 octets. 143 LSP Extended Flags: this contains an array of units of 32-bit flags 144 numbered from the most significant as bit zero, where each bit 145 represents one LSP operation, feature, or state. Currently no bits 146 are assigned. Unassigned bits MUST be set to zero on transmission 147 and MUST be ignored on receipt. 149 3.2. Processing 151 The LSP Extended Flags field is an array of units of 32 flags and to 152 be allocated starting from the most significant bit. No bits are 153 currently assigned in this document and the bits of the LSP Extended 154 Flags field will be assigned by future documents. 156 4. Backward Compatibility 158 The LSP-EXTENDED-FLAG TLV defined in this document does not introduce 159 any interoperability issues. 161 A router that does not understand or support the LSP-EXTENDED-FLAG 162 TLV will silently ignore the TLV as per [RFC5440]. It is expected 163 that future document that define bits in the LSP-EXTENDED-FLAG TLV 164 would also define the error case handling required for missing LSP- 165 EXTENDED-FLAG TLV. 167 5. IANA Considerations 169 5.1. LSP Object 171 5.1.1. PCEP TLV Type Indicators 173 IANA is requested to allocate the following TLV Type Indicator value 174 within the "PCEP TLV Type Indicators" subregistry of the "Path 175 Computation Element Protocol (PCEP) Numbers" registry: 177 Value Description Reference 178 TBD1 LSP-EXTENDED-FLAG [This document] 180 5.1.2. LSP Extended Flags Field 182 IANA is requested to create a new subregistry called "LSP-EXTENDED- 183 FLAG TLV Flag Field", within the "Path Computation Element Protocol 184 (PCEP) Numbers" registry to manage the LSP Extended Flags field of 185 the LSP-EXTENDED-FLAG TLV. New values are assigned by Standards 186 Action [RFC8126]. Each bit should be tracked with the following 187 qualities: 189 o Bit number (counting from bit 0 as the most significant bit) 190 o Capability description 192 o Defining RFC 194 No values are currently defined. 196 6. Security Considerations 198 For LSP Object procssing security considerations, see [RFC8231]. 200 No additional security issues are raised in this document beyond 201 those that exist in the referenced documents. 203 7. Acknowledgements 205 The authors would like to thank Loa Andersson and Adrian Farrel for 206 their review, suggestions and comments to this document. 208 8. Contributors 210 The following people have contributed to this document: 212 Dhruv Dhody 214 EMail: dhruv.ietf@gmail.com 216 9. References 218 9.1. Normative References 220 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 221 Requirement Levels", BCP 14, RFC 2119, 222 DOI 10.17487/RFC2119, March 1997, 223 . 225 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 226 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 227 DOI 10.17487/RFC5440, March 2009, 228 . 230 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 231 Writing an IANA Considerations Section in RFCs", BCP 26, 232 RFC 8126, DOI 10.17487/RFC8126, June 2017, 233 . 235 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 236 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 237 May 2017, . 239 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 240 Computation Element Communication Protocol (PCEP) 241 Extensions for Stateful PCE", RFC 8231, 242 DOI 10.17487/RFC8231, September 2017, 243 . 245 9.2. Informative References 247 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 248 Computation Element Communication Protocol (PCEP) 249 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 250 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 251 . 253 [RFC8623] Palle, U., Dhody, D., Tanaka, Y., and V. Beeram, "Stateful 254 Path Computation Element (PCE) Protocol Extensions for 255 Usage with Point-to-Multipoint TE Label Switched Paths 256 (LSPs)", RFC 8623, DOI 10.17487/RFC8623, June 2019, 257 . 259 Author's Address 261 Quan Xiong 262 ZTE Corporation 263 No.6 Huashi Park Rd 264 Wuhan, Hubei 430223 265 China 267 Email: xiong.quan@zte.com.cn