idnits 2.17.1 draft-chen-pce-bier-06.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([I-D.ietf-bier-te-arch], [RFC8279]), 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 (November 4, 2019) is 1633 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) == Unused Reference: 'RFC2119' is defined on line 335, but no explicit reference was found in the text == Unused Reference: 'RFC8408' is defined on line 380, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-bier-te-arch-05 ** Downref: Normative reference to an Informational RFC: RFC 4657 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group Ran. Chen 3 Internet-Draft Zheng. Zhang 4 Intended status: Standards Track ZTE Corporation 5 Expires: May 7, 2020 Senthil. Dhanaraj 6 Huawei 7 Fengwei. Qin 8 China Mobile 9 November 4, 2019 11 PCEP Extensions for BIER-TE 12 draft-chen-pce-bier-06 14 Abstract 16 Bit Index Explicit Replication (BIER)-TE shares architecture and 17 packet formats with BIER as described in [RFC8279]. BIER-TE forwards 18 and replicates packets based on a BitString in the packet header, but 19 every BitPosition of the BitString of a BIER-TE packet indicates one 20 or more adjacencies as described in [I-D.ietf-bier-te-arch].BIER-TE 21 Path can be derived from a Path Computation Element (PCE). 23 This document specifies extensions to the Path Computation Element 24 Protocol (PCEP) that allow a PCE to compute and initiate the path for 25 the BIER-TE. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 7, 2020. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Conventions used in this document . . . . . . . . . . . . . . 3 63 3. Overview of PCEP Operation in BIER Networks . . . . . . . . . 3 64 4. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 3 65 4.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 3 66 4.1.1. The BIER-TE PCE Capability sub-TLV . . . . . . . . . 3 67 4.2. The RP/SRP Object . . . . . . . . . . . . . . . . . . . . 4 68 4.3. END-POINTS object . . . . . . . . . . . . . . . . . . . . 4 69 4.4. ERO Object . . . . . . . . . . . . . . . . . . . . . . . 4 70 4.4.1. BIER-ERO Subobject . . . . . . . . . . . . . . . . . 5 71 4.4.2. BIER-ERO Processing . . . . . . . . . . . . . . . . . 6 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 74 6.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 6 75 6.1.1. BIER-TE-PCE-CAPABILITY Sub-TLV Type Indicators . . . 7 76 6.1.2. New Path Setup Type . . . . . . . . . . . . . . . . . 7 77 6.1.3. BIER-ERO Subobject . . . . . . . . . . . . . . . . . 7 78 6.1.4. PCEP-Error Objects and Types . . . . . . . . . . . . 7 79 7. Normative references . . . . . . . . . . . . . . . . . . . . 8 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Introduction 84 Bit Index Explicit Replication (BIER)-TE shares architecture and 85 packet formats with BIER as described in [RFC8279]. BIER-TE forwards 86 and replicates packets based on a BitString in the packet header, but 87 every BitPosition of the BitString of a BIER-TE packet indicates one 88 or more adjacencies as described in [I-D.ietf-bier-te-arch].BIER-TE 89 Path can be derived from a Path Computation Element (PCE). 91 [RFC8231] specifies a set of extensions to PCEP that allow a PCE to 92 compute and recommend network paths in compliance with [RFC4657] and 93 defines objects and TLVs for MPLS-TE LSPs. 95 This document uses a PCE for computing one or more BIER-TE paths 96 taking into account various constraints and objective functions. 98 2. Conventions used in this document 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC2119. 104 3. Overview of PCEP Operation in BIER Networks 106 BIER-TE forwards and replicates packets based on a BitString in the 107 packet header, and every BitPosition of the BitString of a BIER-TE 108 packet indicates one or more adjacencies as described in 109 [I-D.ietf-bier-te-arch]. In a PCEP session, An ERO object specified 110 in [RFC5440] can be extended to carry a BIER-TE path consists of one 111 or more BIER-ERO subobject(s). BIER-TE computed by a PCE can be 112 represented in the following forms: 114 o An ordered set of adjacencies BitString(s) in which each bit 115 represents that the adjacencies to which the BFR should replicate 116 packets to in the domain. 118 In this document, we define a set of PCEP protocol extensions, 119 including a new PCEP capability,a new Path Setup Type (PST) ,a new 120 BIER END-POINT Object, new ERO subobjects, new PCEP error codes and 121 procedures. 123 4. Object Formats 125 4.1. The OPEN Object 127 4.1.1. The BIER-TE PCE Capability sub-TLV 129 [RFC8408]defines the PATH-SETUP-TYPE-CAPABILITY TLV for use in the 130 OPEN object. The PATH-SETUP-TYPE-CAPABILITY TLV contains an optional 131 list of sub-TLVs which are intended to convey parameters that are 132 associated with the path setup types supported by a PCEP speaker. 134 This document defines a new Path Setup Type (PST) for BIER as 135 follows: 137 o PST = TBD2: Path is setup using BIER Traffic Engineering 138 technique. 140 A PCEP speaker MUST indicate its support of the function described in 141 this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN 142 object with this new PST included in the PST list. 144 This document also defines the BIER-TE-PCE-CAPABILITY sub-TLV. PCEP 145 speakers use this sub-TLV to exchange BIER capability. If a PCEP 146 speaker includes PST=TBD1 in the PST List of the PATH-SETUP-TYPE- 147 CAPABILITY TLV then it MUST also include the BIER-TE-PCE- CAPABILITY 148 sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY TLV. 150 The format of the BIER-TE-PCE-CAPABILITY sub-TLV is shown in the 151 following figure: 153 0 1 2 3 154 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Type=TBD1 | Length | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Reserved | Flags | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 Figure 1 BIER-TE-PCE-CAPABILITY sub-TLV format 163 The code point for the TLV type is to be defined by IANA. 165 Length: 4 bytes. 167 The "Reserved" (2 octet) and "Flags" (2 octet) fields are currently 168 unused, and MUST be set to zero on transmission and ignored on 169 reception. 171 4.2. The RP/SRP Object 173 In order to setup an BIER-TE, a new PATH-SETUP-TYPE TLV MUST be 174 contained in RP/SRP object. This document defines a new Path Setup 175 Type (PST=TBD2) for BIER-TE. 177 4.3. END-POINTS object 179 The END-POINTS object which is defined in [RFC8306]is used in a PCReq 180 message to specify the BIER information of the path for which a path 181 computation is requested. To represent the end points for a BIER 182 path efficiently, we reuse the P2MP END-POINTS object body for 183 IPv4(Object-Type 3) and END-POINTS object body for IPv6 (Object-Type 184 4) which is defined in [RFC8306]. 186 4.4. ERO Object 188 BIER-TE consists of one or more adjacencies BitStrings where every 189 BitPosition of the BitString indicates one or more adjacencies, as 190 described in([RFC8279]). 192 The ERO object specified in [RFC5440] is used to encode the path of a 193 TE LSP through the network.The ERO is carried within a PCRep message 194 to provide the computed TE LSP if the path computation was 195 successful.In order to carry BIER-TE explicit paths, this document 196 defines a new ERO subobjects referred to as "BIER-ERO subobjects" 197 whose formats are specified in the following section. An BIER-ERO 198 subobjects carrying a adjacencies BitStrings consists of one or more 199 BIER-ERO subobject(s). 201 4.4.1. BIER-ERO Subobject 203 0 1 2 3 204 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 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 |L| Type=TBD3 | Length | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | BS Length | subdomain-id | SI | Reserved | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Adjacency BitString (first 32 bits) ~ 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 ~ ~ 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 ~ Adjacency BitString (last 32 bits) | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 Figure 3 219 The 'L' Flag: Indicates whether the subobject represents a loose-hop 220 in the LSP[RFC3209]. If the bit is not set, the subobject represents 221 a strict hop in the explicit route. 223 Type: TBD3 225 Length: 1 octet ([RFC3209]). Contains the total length of the 226 subobject in octets. The Length MUST be at least 8, and MUST be a 227 multiple of 4. 229 BS Length: A 1 octet field encodes the length in bits of the 230 BitString as per [RFC8296], the maximum length of the BitString is 5, 231 it indicates the length of BitString is 1024.It is used to refer to 232 the number of bits in the BitString. 234 subdomain-id: Unique value identifying the BIER subdomain. 1 octet. 236 SI: Set Identifier (Section 1 of [RFC8279] used in the encapsulation 237 for this BIER subdomain for this BitString length, 1 octet. 239 The "Reserved" (1 octets) fields are currently unused, and MUST be 240 set to zero on transmission and ignored on reception. 242 Adjacency BitString: a variable length field encoding the Adjacency 243 BitString where every BitPosition of the BitString indicates one or 244 more adjacencies.the length of this field is according the BS length. 245 The minimum value of this field is 64 bits, and the maximum value of 246 this field is 1024 bits. 248 Notice: 250 The maximum value of BS Length is limited to the 1024 bits, in case 251 the BIER-ERO Subobject is too long. 253 4.4.2. BIER-ERO Processing 255 The ERO and SR-ERO subobject processing remains as per [RFC5440]. 257 If a PCC receives an BIER-ERO subobject in which either 258 BitStringLength or Adjacency BitString or SI is absent, it MUST 259 consider the entire BIER-ERO subobject invalid and send a PCErr 260 message with Error-Type = 10 ("Reception of an invalid object"), 261 Error-Value = TBD5 ("BitStringLength is absent ") or Error-Value = 262 TBD6 ("Adjacency BitString is absent")or Error-Value = TBD7("SI is 263 absent "). 265 If a PCC receives an BIER-ERO subobject in which BitStringLength 266 values are not chosen from: 64, 128, 256, 512, 1024, as it described 267 in ( [RFC8279]). The PCC MUST send a PCErr message with Error-Type 268 =10 ("Reception of an invalid object") and Error-Value = TBD8 269 ("Invalid BitStringLength"). 271 5. Security Considerations 273 TBD. 275 6. IANA Considerations 277 6.1. PCEP Objects 279 IANA has made the following Object-Type allocations from the "PCEP 280 Objects" sub-registry. 282 6.1.1. BIER-TE-PCE-CAPABILITY Sub-TLV Type Indicators 284 vlaue Meaning Reference 285 -------------- ----------------------- ------------- 286 TBD1 BIER-TE-PCE-CAPABILITY This Document 288 6.1.2. New Path Setup Type 290 vlaue Meaning Reference 291 -------------- ----------------------- ------------- 292 TBD2 Path is setup using BIER 293 Traffic Engineering technique This Document 295 6.1.3. BIER-ERO Subobject 297 This document defines a new subobject type for the BIER explicit 298 route object (ERO),The code points for subobject types of these 299 objects is maintained in the RSVP parameters registry. 301 Object Sub-Object Sub-Object Type 302 ----------------- ----------------------- ----------------- 303 EXPLICIT_ROUTE BIER-ERO (PCEP-specific) TBD3 305 6.1.4. PCEP-Error Objects and Types 307 IANA is requested to allocate code-points in the "PCEP-ERROR Object 308 Error Types and Values" subregistry for the following new error-types 309 and error-values: 311 Error-Type Meaning Reference 312 --------- --------------------------- ---------------- 313 10 Reception of an invalid object RFC5440 315 Error-value = TBD4 This document 316 BitStringLength is absent 318 Error-value = TBD5 This document 319 Adjacency BitString is absent 321 Error-value = TBD6 This document 322 SI is absent 324 Error-value = TBD7 This document 325 Invalid BitStringLength 327 7. Normative references 329 [I-D.ietf-bier-te-arch] 330 Eckert, T., Cauchie, G., and M. Menth, "Traffic 331 Engineering for Bit Index Explicit Replication (BIER-TE)", 332 draft-ietf-bier-te-arch-05 (work in progress), November 333 2019. 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, 337 DOI 10.17487/RFC2119, March 1997, 338 . 340 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 341 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 342 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 343 . 345 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 346 Element (PCE) Communication Protocol Generic 347 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 348 2006, . 350 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 351 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 352 DOI 10.17487/RFC5440, March 2009, 353 . 355 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 356 Computation Element Communication Protocol (PCEP) 357 Extensions for Stateful PCE", RFC 8231, 358 DOI 10.17487/RFC8231, September 2017, 359 . 361 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 362 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 363 Explicit Replication (BIER)", RFC 8279, 364 DOI 10.17487/RFC8279, November 2017, 365 . 367 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 368 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 369 for Bit Index Explicit Replication (BIER) in MPLS and Non- 370 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 371 2018, . 373 [RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King, 374 "Extensions to the Path Computation Element Communication 375 Protocol (PCEP) for Point-to-Multipoint Traffic 376 Engineering Label Switched Paths", RFC 8306, 377 DOI 10.17487/RFC8306, November 2017, 378 . 380 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 381 Hardwick, "Conveying Path Setup Type in PCE Communication 382 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 383 July 2018, . 385 Authors' Addresses 387 Ran Chen 388 ZTE Corporation 390 Email: chen.ran@zte.com.cn 392 Zheng Zhang 393 ZTE Corporation 395 Email: zhang.zheng@zte.com.cn 397 Senthil Dhanaraj 398 Huawei 400 Email: senthil.dhanaraj.ietf@gmail.com 401 Fengwei Qin 402 China Mobile 404 Email: qinfengwei@chinamobile.com