idnits 2.17.1 draft-ietf-pce-segment-routing-ipv6-05.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 (June 21, 2020) is 1404 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) == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-08 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-15 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-07 == Outdated reference: A later version (-14) exists of draft-ietf-idr-bgpls-srv6-ext-02 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group M. Negi 3 Internet-Draft RtBrick India 4 Intended status: Standards Track C. Li 5 Expires: December 23, 2020 Huawei Technologies 6 S. Sivabalan 7 Cisco Systems 8 P. Kaladharan 9 RtBrick Inc 10 Z. Yongqing 11 China Telecom 12 June 21, 2020 14 PCEP Extensions for Segment Routing leveraging the IPv6 data plane 15 draft-ietf-pce-segment-routing-ipv6-05 17 Abstract 19 The Source Packet Routing in Networking (SPRING) architecture 20 describes how Segment Routing (SR) can be used to steer packets 21 through an IPv6 or MPLS network using the source routing paradigm. 22 SR enables any head-end node to select any path without relying on a 23 hop-by-hop signaling technique (e.g., LDP or RSVP-TE). 25 It depends only on "segments" that are advertised by Link- State 26 IGPs. A Segment Routed Path can be derived from a variety of 27 mechanisms, including an IGP Shortest Path Tree (SPT), explicit 28 configuration, or a Path Computation Element (PCE). 30 Since SR can be applied to both MPLS and IPv6 forwarding plane, a PCE 31 should be able to compute SR-Path for both MPLS and IPv6 forwarding 32 plane. This document describes the extensions required for SR 33 support for IPv6 data plane in Path Computation Element communication 34 Protocol (PCEP). The PCEP extension and mechanism to support SR-MPLS 35 is described in RFC 8664. This document extends it to support SRv6 36 (SR over IPv6). 38 Requirements Language 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 42 "OPTIONAL" in this document are to be interpreted as described in BCP 43 14 [RFC2119] [RFC8174] when, and only when, they appear in all 44 capitals, as shown here. 46 Status of This Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at https://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on December 23, 2020. 63 Copyright Notice 65 Copyright (c) 2020 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (https://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 81 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 82 3. Overview of PCEP Operation in SRv6 Networks . . . . . . . . . 5 83 3.1. Operation Overview . . . . . . . . . . . . . . . . . . . 6 84 3.2. SRv6-Specific PCEP Message Extensions . . . . . . . . . . 6 85 4. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 7 86 4.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 7 87 4.1.1. The SRv6 PCE Capability sub-TLV . . . . . . . . . . . 7 88 4.2. The RP/SRP Object . . . . . . . . . . . . . . . . . . . . 8 89 4.3. ERO . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 90 4.3.1. SRv6-ERO Subobject . . . . . . . . . . . . . . . . . 8 91 4.4. RRO . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 92 4.4.1. SRv6-RRO Subobject . . . . . . . . . . . . . . . . . 11 93 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 11 94 5.1. Exchanging the SRv6 Capability . . . . . . . . . . . . . 11 95 5.2. ERO Processing . . . . . . . . . . . . . . . . . . . . . 13 96 5.2.1. SRv6 ERO Validation . . . . . . . . . . . . . . . . . 13 97 5.2.2. Interpreting the SRv6-ERO . . . . . . . . . . . . . . 14 98 5.3. RRO Processing . . . . . . . . . . . . . . . . . . . . . 14 99 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 100 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 101 7.1. PCEP ERO and RRO subobjects . . . . . . . . . . . . . . . 15 102 7.2. New SRv6-ERO Flag Registry . . . . . . . . . . . . . . . 15 103 7.3. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators . . . 16 104 7.4. SRv6 PCE Capability Flags . . . . . . . . . . . . . . . . 16 105 7.5. New Path Setup Type . . . . . . . . . . . . . . . . . . . 17 106 7.6. ERROR Objects . . . . . . . . . . . . . . . . . . . . . . 17 107 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 108 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 109 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 110 9.2. Informative References . . . . . . . . . . . . . . . . . 19 111 Appendix A. Contributor . . . . . . . . . . . . . . . . . . . . 21 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 114 1. Introduction 116 As per [RFC8402], with Segment Routing (SR), a node steers a packet 117 through an ordered list of instructions, called segments. A segment 118 can represent any instruction, topological or service-based. A 119 segment can have a semantic local to an SR node or global within an 120 SR domain. SR allows to enforce a flow through any path and service 121 chain while maintaining per-flow state only at the ingress node of 122 the SR domain. Segments can be derived from different components: 123 IGP, BGP, Services, Contexts, Locater, etc. The list of segment 124 forming the path is called the Segment List and is encoded in the 125 packet header. Segment Routing can be applied to the IPv6 126 architecture with the Segment Routing Header (SRH) 127 [I-D.ietf-6man-segment-routing-header]. A segment is encoded as an 128 IPv6 address. An ordered list of segments is encoded as an ordered 129 list of IPv6 addresses in the routing header. The active segment is 130 indicated by the Destination Address of the packet. Upon completion 131 of a segment, a pointer in the new routing header is incremented and 132 indicates the next segment. 134 Segment Routing use cases are described in [RFC7855] and [RFC8354]. 135 Segment Routing protocol extensions are defined in [RFC8667], and 136 [RFC8666]. 138 As per [I-D.ietf-6man-segment-routing-header], an SRv6 Segment is a 139 128-bit value. "SRv6 SID" or simply "SID" are often used as a 140 shorter reference for "SRv6 Segment". Further details are in an 141 illustration provided in [I-D.ietf-spring-srv6-network-programming]. 143 The SR architecture can be applied to the MPLS forwarding plane 144 without any change, in which case an SR path corresponds to an MPLS 145 Label Switching Path (LSP). The SR is applied to IPV6 forwarding 146 plane using SRH. A SR path can be derived from an IGP Shortest Path 147 Tree (SPT), but SR-TE paths may not follow IGP SPT. Such paths may 148 be chosen by a suitable network planning tool, or a PCE and 149 provisioned on the ingress node. 151 [RFC5440] describes Path Computation Element communication Protocol 152 (PCEP) for communication between a Path Computation Client (PCC) and 153 a Path Computation Element (PCE) or between a pair of PCEs. A PCE or 154 a PCC operating as a PCE (in hierarchical PCE environment) computes 155 paths for MPLS Traffic Engineering LSPs (MPLS-TE LSPs) based on 156 various constraints and optimization criteria. [RFC8231] specifies 157 extensions to PCEP that allow a stateful PCE to compute and recommend 158 network paths in compliance with [RFC4657] and defines objects and 159 TLVs for MPLS-TE LSPs. Stateful PCEP extensions provide 160 synchronization of LSP state between a PCC and a PCE or between a 161 pair of PCEs, delegation of LSP control, reporting of LSP state from 162 a PCC to a PCE, controlling the setup and path routing of an LSP from 163 a PCE to a PCC. Stateful PCEP extensions are intended for an 164 operational model in which LSPs are configured on the PCC, and 165 control over them is delegated to the PCE. 167 A mechanism to dynamically initiate LSPs on a PCC based on the 168 requests from a stateful PCE or a controller using stateful PCE is 169 specified in [RFC8281]. As per [RFC8664], it is possible to use a 170 stateful PCE for computing one or more SR-TE paths taking into 171 account various constraints and objective functions. Once a path is 172 chosen, the stateful PCE can initiate an SR-TE path on a PCC using 173 PCEP extensions specified in [RFC8281] using the SR specific PCEP 174 extensions specified in [RFC8664]. [RFC8664] specifies PCEP 175 extensions for supporting a SR-TE LSP for MPLS data plane. This 176 document extends [RFC8664] to support SR for IPv6 data plane. 177 Additionally, using procedures described in this document, a PCC can 178 request an SRv6 path from either stateful or a stateless PCE. This 179 specification relies on the PATH-SETUP-TYPE TLV and procedures 180 specified in [RFC8408]. 182 This specification provides a mechanism for a network controller 183 (acting as a PCE) to instantiate candidate paths for an SR Policy 184 onto a head-end node (acting as a PCC) using PCEP. For more 185 information on the SR Policy Architecture, see 186 [I-D.ietf-spring-segment-routing-policy]. 188 2. Terminology 190 This document uses the following terms defined in [RFC5440]: PCC, 191 PCE, PCEP Peer. 193 This document uses the following terms defined in [RFC8051]: Stateful 194 PCE, Delegation. 196 The message formats in this document are specified using Routing 197 Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. 199 NAI: Node or Adjacency Identifier. 201 PCC: Path Computation Client. 203 PCE: Path Computation Element. 205 PCEP: Path Computation Element Protocol. 207 SR: Segment Routing. 209 SID: Segment Identifier. 211 SRv6: Segment Routing for IPv6 forwarding plane. 213 SRH: IPv6 Segment Routing Header. 215 SR Path: IPv6 Segment List (List of IPv6 SIDs representing a path in 216 IPv6 SR domain) 218 3. Overview of PCEP Operation in SRv6 Networks 220 Basic operations for PCEP speakers is as per [RFC8664]. SRv6 Paths 221 computed by a PCE can be represented as an ordered list of SRv6 222 segments of 128-bit value. "SRv6 SID" or simply "SID" are often used 223 as a shorter reference for "SRv6 Segment" in this document. 225 [RFC8664] defined a new Explicit Route Object (ERO) subobject denoted 226 by "SR-ERO subobject" capable of carrying a SID as well as the 227 identity of the node/adjacency represented by the SID. SR-capable 228 PCEP speakers should be able to generate and/or process such ERO 229 subobject. An ERO containing SR-ERO subobjects can be included in 230 the PCEP Path Computation Reply (PCRep) message defined in [RFC5440], 231 the PCEP LSP Initiate Request message (PCInitiate) defined in 232 [RFC8281], as well as in the PCEP LSP Update Request (PCUpd) and PCEP 233 LSP State Report (PCRpt) messages defined in defined in [RFC8231]. 235 This document define new subobjects "SRv6-ERO" and "SRv6-RRO" in ERO 236 and RRO respectively to carry SRv6 SID (IPv6 Address). SRv6-capable 237 PCEP speakers MUST be able to generate and/or process this. 239 When a PCEP session between a PCC and a PCE is established, both PCEP 240 speakers exchange their capabilities to indicate their ability to 241 support SRv6 specific functionality. 243 In summary, this document: 245 o Defines a new PCEP capability for SRv6. 247 o Defines a new subobject SRv6-ERO in ERO. 249 o Defines a new subobject SRv6-RRO in RRO. 251 o Defines a new path setup type carried in the PATH-SETUP-TYPE and 252 PATH-SETUP-TYPE-CAPABILITY TLVs. 254 3.1. Operation Overview 256 In SR networks, an ingress node of an SR path appends all outgoing 257 packets with an SR header consisting of a list of SIDs (IPv6 Prefix 258 in case of SRv6). The header has all necessary information to guide 259 the packets from the ingress node to the egress node of the path, and 260 hence there is no need for any signaling protocol. 262 For IPv6 in control plane with MPLS data-plane, mechanism remains 263 same as [RFC8664] 265 This document describes extensions to SR path for IPv6 data plane. 266 SRv6 Path (i.e. ERO) consists of an ordered set of SRv6 SIDs(see 267 details in Figure 2). 269 A PCC or PCE indicates its ability to support SRv6 during the PCEP 270 session Initialization Phase via a new SRv6-PCE-CAPABILITY sub-TLV 271 (see details in Section 4.1.1). 273 3.2. SRv6-Specific PCEP Message Extensions 275 As defined in [RFC5440], a PCEP message consists of a common header 276 followed by a variable length body made up of mandatory and/or 277 optional objects. This document does not require any changes in the 278 format of PCReq and PCRep messages specified in [RFC5440], PCInitiate 279 message specified in [RFC8281], and PCRpt and PCUpd messages 280 specified in [RFC8231]. However, PCEP messages pertaining to SRv6 281 MUST include PATH-SETUP-TYPE TLV in the RP or SRP object to clearly 282 identify that SRv6 is intended. 284 4. Object Formats 286 4.1. The OPEN Object 288 4.1.1. The SRv6 PCE Capability sub-TLV 290 This document defines a new Path Setup Type (PST) [RFC8408] for SRv6, 291 as follows: 293 o PST = TBD2: Path is setup using SRv6. 295 A PCEP speaker MUST indicate its support of the function described in 296 this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN 297 object with this new PST included in the PST list. 299 This document also defines the SRv6-PCE-CAPABILITY sub-TLV. PCEP 300 speakers use this sub-TLV to exchange information about their SRv6 301 capability. If a PCEP speaker includes PST=TBD2 in the PST List of 302 the PATH-SETUP-TYPE-CAPABILITY TLV then it MUST also include the 303 SRv6-PCE-CAPABILITY sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY 304 TLV. 306 The format of the SRv6-PCE-CAPABILITY sub-TLV is shown in the 307 following figure: 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Type=TBD1 | Length | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Reserved | Flags |N|X| 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | MSD-Type | MSD-Value | MSD-Type | MSD-Value | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 // ... // 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | MSD-Type | MSD-Value | Padding | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Figure 1: SRv6-PCE-CAPABILITY sub-TLV format 325 The code point for the TLV type (TBD1) is to be defined by IANA. The 326 TLV length is variable. 328 The value comprises of - 329 Reserved: 2 octet, this field MUST be set to 0 on transmission, 330 and ignored on receipt. 332 Flags: 2 octet, two bits are currently assigned in this document. 334 N bit: A PCC sets this flag bit to 1 to indicate that it is 335 capable of resolving a Node or Adjacency Identifier (NAI) to a 336 SRv6-SID. 338 X bit: A PCC sets this bit to 1 to indicate that it does not 339 impose any limit on MSD (irrespective of the MSD-Type). 341 Unassigned bits MUST be set to 0 and ignored on receipt. 343 A pair of (MSD-Type, MSD-Value): Where MSD-Type (1 octet) is as 344 per the IGP MSD Type registry created by [RFC8491] and populated 345 with SRv6 MSD types as per [I-D.ietf-lsr-isis-srv6-extensions]; 346 MSD-Value (1 octet) is as per [RFC8491]. 348 This TLV format is compliant with the PCEP TLV format defined in 349 [RFC5440]. That is, the TLV is composed of 2 octets for the type, 2 350 octets specifying the TLV length, and a Value field. The Length 351 field defines the length of the value portion in octets. The TLV is 352 padded to 4-octet alignment, and padding is not included in the 353 Length field. The number of (MSD-Type,MSD-Value) pairs can be 354 determined from the Length field of the TLV. 356 4.2. The RP/SRP Object 358 In order to indicate the SRv6 path, RP or SRP object MUST include the 359 PATH-SETUP-TYPE TLV specified in [RFC8408]. This document defines a 360 new Path Setup Type (PST=TBD2) for SRv6. 362 The LSP-IDENTIFIERS TLV MAY be present for the above PST type. 364 4.3. ERO 366 In order to support SRv6, new subobject "SRv6-ERO" is defined in ERO. 368 4.3.1. SRv6-ERO Subobject 370 An SRv6-ERO subobject is formatted as shown in the following figure. 372 0 1 2 3 373 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 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 |L| Type=TBD3 | Length | NT | Flags |F|S| 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | reserved | Function Code | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | | 380 | SRv6 SID (optional) | 381 | (128-bit) | 382 | | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 // NAI (variable, optional) // 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 Figure 2: SRv6-ERO Subobject Format 389 The fields in the SRv6-ERO Subobject are as follows: 391 The 'L' Flag: Indicates whether the subobject represents a loose-hop 392 (see [RFC3209]). If this flag is set to zero, a PCC MUST NOT 393 overwrite the SID value present in the SRv6-ERO subobject. 394 Otherwise, a PCC MAY expand or replace one or more SID values in the 395 received SRv6-ERO based on its local policy. 397 Type: Set to TBD3. 399 Length: Contains the total length of the subobject in octets. The 400 Length MUST be at least 24, and MUST be a multiple of 4. An SRv6-ERO 401 subobject MUST contain at least one of a SRv6-SID or an NAI. The S 402 and F bit in the Flags field indicates whether the SRv6-SID or NAI 403 fields are absent. 405 NAI Type (NT): Indicates the type and format of the NAI contained in 406 the object body, if any is present. If the F bit is set to zero (see 407 below) then the NT field has no meaning and MUST be ignored by the 408 receiver. This document reuses NT types defined in [RFC8664]: 410 If NT value is 0, the NAI MUST NOT be included. 412 When NT value is 2, the NAI is as per the 'IPv6 Node ID' format 413 defined in [RFC8664], which specifies an IPv6 address. This is 414 used to identify the owner of the SRv6 Identifier. This is 415 optional, as the LOC (the locater portion) of the SRv6 SID serves 416 a similar purpose (when present). 418 When NT value is 3, the NAI is as per the 'IPv6 Adjacency' format 419 defined in [RFC8664], which specify a pair of IPv6 addresses. 420 This is used to identify the IPv6 Adjacency and used with the SRv6 421 Adj-SID. 423 When NT value is 6, the NAI is as per the 'link-local IPv6 424 addresses' format defined in [RFC8664], which specify a pair of 425 (global IPv6 address, interface ID) tuples. It is used to 426 identify the IPv6 Adjacency and used with the SRv6 Adj-SID. 428 SR-MPLS specific NT types are not valid in SRv6-ERO. 430 Flags: Used to carry additional information pertaining to the 431 SRv6-SID. This document defines the following flag bits. The other 432 bits MUST be set to zero by the sender and MUST be ignored by the 433 receiver. 435 o S: When this bit is set to 1, the SRv6-SID value in the subobject 436 body is absent. In this case, the PCC is responsible for choosing 437 the SRv6-SID value, e.g., by looking up in the SR-DB using the NAI 438 which, in this case, MUST be present in the subobject. If the S 439 bit is set to 1 then F bit MUST be set to zero. 441 o F: When this bit is set to 1, the NAI value in the subobject body 442 is absent. The F bit MUST be set to 1 if NT=0, and otherwise MUST 443 be set to zero. The S and F bits MUST NOT both be set to 1. 445 Function Behavior: A 16 bit field representing supported functions 446 associated with SRv6 SIDs. This information is optional and plays no 447 role in the SRH imposed on the packet. It could be included for 448 maintainability and diagnostic purpose. If function code is not 449 defined, 0 is used. Functions codes are defined in 450 [I-D.ietf-spring-srv6-network-programming]. 452 SRv6 SID: SRv6 Identifier is the 128 bit IPv6 addresses representing 453 the SRv6 segment. 455 NAI: The NAI associated with the SRv6-SID. The NAI's format depends 456 on the value in the NT field, and is described in [RFC8664]. 458 At least one of the SRv6-SID or the NAI MUST be included in the 459 SRv6-ERO subobject, and both MAY be included. 461 4.4. RRO 463 In order to support SRv6, new subobject "SRv6-RRO" is defined in RRO. 465 4.4.1. SRv6-RRO Subobject 467 A PCC reports an SRv6 path to a PCE by sending a PCRpt message, per 468 [RFC8231]. The RRO on this message represents the SID list that was 469 applied by the PCC, that is, the actual path taken. The procedures 470 of [RFC8664] with respect to the RRO apply equally to this 471 specification without change. 473 An RRO contains one or more subobjects called "SRv6-RRO subobjects" 474 whose format is shown below: 476 0 1 2 3 477 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 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Type=TBD4 | Length | NT | Flags |F|S| 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | reserved | Function Code | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | | 484 | SRv6 SID | 485 | (128-bit) | 486 | | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 // NAI (variable) // 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 Figure 3: SRv6-RRO Subobject Format 493 The format of the SRv6-RRO subobject is the same as that of the 494 SRv6-ERO subobject, but without the L flag. 496 Ordering of SRv6-RRO subobjects by PCC in PCRpt message remains as 497 per [RFC8664]. 499 5. Procedures 501 5.1. Exchanging the SRv6 Capability 503 A PCC indicates that it is capable of supporting the head-end 504 functions for SRv6 by including the SRv6-PCE-CAPABILITY sub-TLV in 505 the Open message that it sends to a PCE. A PCE indicates that it is 506 capable of computing SRv6 paths by including the SRv6-PCE-CAPABILITY 507 sub-TLV in the Open message that it sends to a PCC. 509 If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a 510 PST list containing PST=TBD2, but the SRv6-PCE-CAPABILITY sub-TLV is 511 absent, then the PCEP speaker MUST send a PCErr message with Error- 512 Type 10 (Reception of an invalid object) and Error-Value TBD5 (to be 513 assigned by IANA) (Missing PCE-SRv6-CAPABILITY sub-TLV) and MUST then 514 close the PCEP session. If a PCEP speaker receives a PATH-SETUP- 515 TYPE-CAPABILITY TLV with a SRv6-PCE-CAPABILITY sub-TLV, but the PST 516 list does not contain PST=TBD2, then the PCEP speaker MUST ignore the 517 SRv6-PCE-CAPABILITY sub-TLV. 519 The number of SRv6 SIDs that can be imposed on a packet depends on 520 the PCC's IPv6 data plane's capability. If a PCC sets the X flag to 521 1 then the MSD is not used and MUST NOT be included. If a PCE 522 receives an SRv6-PCE-CAPABILITY sub-TLV with the X flag set to 1 then 523 it MUST ignore any MSD-Type, MSD-Value fields and MUST assume that 524 the sender can impose any length of SRH. If a PCC sets the X flag to 525 zero, then it sets the SRv6 MSD-Type, MSD-Value fields that it can 526 impose on a packet. If a PCE receives an SRv6-PCE-CAPABILITY sub-TLV 527 with the X flag and SRv6 MSD-Type, MSD-Value fields both set to zero 528 then it is considered as an error and the PCE MUST respond with a 529 PCErr message (Error-Type=1 "PCEP session establishment failure" and 530 Error-Value=1 "reception of an invalid Open message or a non Open 531 message."). In case the MSD-Type in SRv6-PCE-CAPABILITY sub-TLV 532 received by the PCE does not correspond to one of the SRv6 MSD types, 533 the PCE MUST respond with a PCErr message (Error-Type=1 "PCEP session 534 establishment failure" and Error-Value=1 "reception of an invalid 535 Open message or a non Open message."). 537 Note that the MSD-Type, MSD-Value exchanged via the SRv6-PCE- 538 CAPABILITY sub-TLV indicates the SRv6 SID imposition limit for the 539 PCC node. However, if a PCE learns these via different means, e.g 540 routing protocols, as specified in: 541 [I-D.li-ospf-ospfv3-srv6-extensions]; 542 [I-D.ietf-lsr-isis-srv6-extensions]; [I-D.ietf-idr-bgpls-srv6-ext], 543 then it ignores the values in the SRv6-PCE-CAPABILITY sub-TLV. 544 Furthermore, whenever a PCE learns the other advanced SRv6 MSD via 545 different means, it MUST use that value regardless of the values 546 exchanged in the SRv6-PCE-CAPABILITY sub-TLV. 548 Once an SRv6-capable PCEP session is established with a non-zero SRv6 549 MSD value, the corresponding PCE MUST NOT send SRv6 paths with a 550 number of SIDs exceeding that SRv6 MSD value (based on the SRv6 MSD 551 Type). If a PCC needs to modify the SRv6 MSD value, it MUST close 552 the PCEP session and re-establish it with the new value. If a PCEP 553 session is established with a non-zero SRv6 MSD value, and the PCC 554 receives an SRv6 path containing more SIDs than specified in the SRv6 555 MSD value (based on the SRv6 MSD type), the PCC MUST send a PCErr 556 message with Error-Type 10 (Reception of an invalid object) and 557 Error-Value 3 (Unsupported number of Segment ERO subobjects). If a 558 PCEP session is established with an SRv6 MSD value of zero, then the 559 PCC MAY specify an SRv6 MSD for each path computation request that it 560 sends to the PCE, by including a "maximum SID depth" metric object on 561 the request similar to [RFC8664]. 563 The N flag, X flag and (MSD-Type,MSD-Value) pair inside the SRv6-PCE- 564 CAPABILITY sub-TLV are meaningful only in the Open message sent from 565 a PCC to a PCE. As such, a PCE MUST set the flags to zero and not 566 include any (MSD-Type,MSD-Value) pair in the SRv6-PCE-CAPABILITY sub- 567 TLV in an outbound message to a PCC. Similarly, a PCC MUST ignore 568 N,X flag and any (MSD-Type,MSD-Value) pair received from a PCE. If a 569 PCE receives multiple SRv6-PCE-CAPABILITY sub-TLVs in an Open 570 message, it processes only the first sub-TLV received. 572 5.2. ERO Processing 574 The ERO processing remains as per [RFC5440] and [RFC8664]. 576 5.2.1. SRv6 ERO Validation 578 If a PCC does not support the SRv6 PCE Capability and thus cannot 579 recognize the SRv6-ERO or SRv6-RRO subobjects, it will respond 580 according to the rules for a malformed object per [RFC5440]. 582 On receiving an SRv6-ERO, a PCC MUST validate that the Length field, 583 the S bit, the F bit and the NT field are consistent, as follows. 585 o If NT=0, the F bit MUST be 1, the S bit MUST be zero and the 586 Length MUST be 24. 588 o If NT=2, the F bit MUST be zero. If the S bit is 1, the Length 589 MUST be 24, otherwise the Length MUST be 40. 591 o If NT=4, the F bit MUST be zero. If the S bit is 1, the Length 592 MUST be 40, otherwise the Length MUST be 56. 594 o If NT=6, the F bit MUST be zero. If the S bit is 1, the Length 595 MUST be 48, otherwise the Length MUST be 64. 597 o NT types (1,3, and 5) are not valid for SRv6. 599 If a PCC finds that the NT field, Length field, S bit and F bit are 600 not consistent, it MUST consider the entire ERO invalid and MUST send 601 a PCErr message with Error-Type = 10 ("Reception of an invalid 602 object") and Error-Value = 11 ("Malformed object"). 604 If a PCEP speaker that does not recognize the NT value received in 605 SRv6-ERO subobject, it would behave as per [RFC8664]. 607 In case a PCEP speaker receives the SRv6-ERO subobject, when the PST 608 is not set to TBD2 or SRv6-PCE-CAPABILITY sub-TLV was not exchanged, 609 it MUST send a PCErr message with Error-Type = 19 ("Invalid 610 Operation") and Error-Value = TBD5 ("Attempted SRv6 when the 611 capability was not advertised"). 613 If a PCC receives a list of SRv6 segments, and the number of SRv6 614 segments exceeds the SRv6 MSD that the PCC can impose on the packet 615 (SRH), it MUST send a PCErr message with Error-Type = 10 ("Reception 616 of an invalid object") and Error-Value = TBD ("Unsupported number of 617 Segment ERO subobjects") as per [RFC8664]. 619 When a PCEP speaker detects that all subobjects of ERO are not of 620 type TBD3, and if it does not handle such ERO, it MUST send a PCErr 621 message with Error-Type = 10 ("Reception of an invalid object") and 622 Error-Value = TBD ("Non-identical ERO subobjects")as per [RFC8664]. 624 5.2.2. Interpreting the SRv6-ERO 626 The SRv6-ERO contains a sequence of subobjects. According to 627 [I-D.ietf-spring-segment-routing-policy], each SRv6-ERO subobject in 628 the sequence identifies a segment that the traffic will be directed 629 to, in the order given. That is, the first subobject identifies the 630 first segment the traffic will be directed to, the second SRv6-ERO 631 subobject represents the second segment, and so on. 633 The PCC interprets the SRv6-ERO by converting it to an SRv6 SRH plus 634 a next hop. The PCC sends packets along the segment routed path by 635 prepending the SRH onto the packets and sending the resulting, 636 modified packet to the next hop. 638 5.3. RRO Processing 640 The syntax checking rules that apply to the SRv6-RRO subobject are 641 identical to those of the SRv6-ERO subobject, except as noted below. 643 If a PCEP speaker receives an SRv6-RRO subobject in which both SRv6 644 SID and NAI are absent, it MUST consider the entire RRO invalid and 645 send a PCErr message with Error-Type = 10 ("Reception of an invalid 646 object") and Error-Value = TBD6 ("Both SID and NAI are absent in 647 SRv6-RRO subobject"). 649 If a PCE detects that the subobjects of an RRO are a mixture of 650 SRv6-RRO subobjects and subobjects of other types, then it MUST send 651 a PCErr message with Error-Type = 10 ("Reception of an invalid 652 object") and Error-Value = TBD7 ("RRO mixes SRv6-RRO subobjects with 653 other subobject types"). 655 6. Security Considerations 657 The security considerations described in [RFC5440], [RFC8231] and 658 [RFC8281], [RFC8664], are applicable to this specification. No 659 additional security measure is required. 661 7. IANA Considerations 663 7.1. PCEP ERO and RRO subobjects 665 This document defines a new subobject type for the PCEP explicit 666 route object (ERO), and a new subobject type for the PCEP record 667 route object (RRO). The code points for subobject types of these 668 objects is maintained in the RSVP parameters registry, under the 669 EXPLICIT_ROUTE and ROUTE_RECORD objects. IANA is requested to 670 allocate code-points in the RSVP Parameters registry for each of the 671 new subobject types defined in this document. 673 Object Subobject Subobject Type 674 --------------------- -------------------------- ------------------ 675 EXPLICIT_ROUTE SRv6-ERO (PCEP-specific) TBD3 676 ROUTE_RECORD SRv6-RRO (PCEP-specific) TBD4 678 7.2. New SRv6-ERO Flag Registry 680 IANA is requested to create a new sub-registry, named "SRv6-ERO Flag 681 Field", within the "Path Computation Element Protocol (PCEP) Numbers" 682 registry to manage the Flag field of the SRv6-ERO subobject. New 683 values are to be assigned by Standards Action [RFC8126]. Each bit 684 should be tracked with the following qualities: 686 o Bit number (counting from bit 0 as the most significant bit) 688 o Capability description 690 o Defining RFC 692 The following values are defined in this document: 694 Bit Description Reference 695 ----- ------------------ -------------- 696 0-9 Unassigned 697 10 NAI is absent (F) This document 698 11 SID is absent (S) This document 700 7.3. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators 702 IANA maintains a sub-registry, named "PATH-SETUP-TYPE-CAPABILITY Sub- 703 TLV Type Indicators", within the "Path Computation Element Protocol 704 (PCEP) Numbers" registry to manage the type indicator space for sub- 705 TLVs of the PATH-SETUP-TYPE-CAPABILITY TLV. IANA is requested to 706 make the following assignment: 708 Value Meaning Reference 709 ----- ------- --------- 710 TBD1 SRv6-PCE-CAPABILITY This Document 712 7.4. SRv6 PCE Capability Flags 714 IANA is requested to create a new sub-registry, named "SRv6 715 Capability Flag Field", within the "Path Computation Element Protocol 716 (PCEP) Numbers" registry to manage the Flag field of the SRv6-PCE- 717 CAPABILITY sub-TLV. New values are to be assigned by Standards 718 Action [RFC8126]. Each bit should be tracked with the following 719 qualities: 721 o Bit number (counting from bit 0 as the most significant bit) 723 o Capability description 725 o Defining RFC 727 The following values are defined in this document: 729 Bit Description Reference 731 0-13 Unassigned 732 14 Node or Adjacency This document 733 Identifier (NAI) is 734 supported (N) 735 15 Unlimited Maximum SID This document 736 Depth (X) 738 7.5. New Path Setup Type 740 [RFC8408] created a sub-registry within the "Path Computation Element 741 Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". 742 IANA is requested to allocate a new code point within this registry, 743 as follows: 745 Value Description Reference 746 ----- ----------- --------- 747 TBD2 Traffic engineering path is This Document 748 setup using SRv6. 750 7.6. ERROR Objects 752 IANA is requested to allocate code-points in the PCEP-ERROR Object 753 Error Types and Values registry for the following new error-values: 755 Error-Type Meaning 756 ---------- ------- 757 10 Reception of an invalid object 758 Error-value = TBD5 (Missing 759 PCE-SRv6-CAPABILITY sub-TLV) 760 Error-value = TBD6 (Both SID and NAI are absent 761 in SRv6-RRO subobject) 762 Error-value = TBD7 (RRO mixes SRv6-RRO subobjects 763 with other subobject types) 764 19 Invalid Operation 765 Error-value = TBD5 (Attempted SRv6 when the 766 capability was not advertised) 768 8. Acknowledgements 770 The authors would like to thank Jeff Tentsura, Adrian Farrel and 771 Khasanov Boris for valuable suggestions. 773 9. References 775 9.1. Normative References 777 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 778 Requirement Levels", BCP 14, RFC 2119, 779 DOI 10.17487/RFC2119, March 1997, 780 . 782 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 783 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 784 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 785 . 787 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 788 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 789 DOI 10.17487/RFC5440, March 2009, 790 . 792 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 793 Used to Form Encoding Rules in Various Routing Protocol 794 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 795 2009, . 797 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 798 Writing an IANA Considerations Section in RFCs", BCP 26, 799 RFC 8126, DOI 10.17487/RFC8126, June 2017, 800 . 802 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 803 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 804 May 2017, . 806 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 807 Computation Element Communication Protocol (PCEP) 808 Extensions for Stateful PCE", RFC 8231, 809 DOI 10.17487/RFC8231, September 2017, 810 . 812 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 813 Computation Element Communication Protocol (PCEP) 814 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 815 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 816 . 818 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 819 Decraene, B., Litkowski, S., and R. Shakir, "Segment 820 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 821 July 2018, . 823 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 824 Hardwick, "Conveying Path Setup Type in PCE Communication 825 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 826 July 2018, . 828 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 829 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 830 DOI 10.17487/RFC8491, November 2018, 831 . 833 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 834 and J. Hardwick, "Path Computation Element Communication 835 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 836 DOI 10.17487/RFC8664, December 2019, 837 . 839 [I-D.ietf-lsr-isis-srv6-extensions] 840 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 841 Z. Hu, "IS-IS Extension to Support Segment Routing over 842 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-08 843 (work in progress), April 2020. 845 [I-D.ietf-spring-srv6-network-programming] 846 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 847 Matsushima, S., and Z. Li, "SRv6 Network Programming", 848 draft-ietf-spring-srv6-network-programming-15 (work in 849 progress), March 2020. 851 9.2. Informative References 853 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 854 Element (PCE) Communication Protocol Generic 855 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 856 2006, . 858 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 859 Litkowski, S., Horneffer, M., and R. Shakir, "Source 860 Packet Routing in Networking (SPRING) Problem Statement 861 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 862 2016, . 864 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 865 Stateful Path Computation Element (PCE)", RFC 8051, 866 DOI 10.17487/RFC8051, January 2017, 867 . 869 [RFC8354] Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R., 870 Ed., and M. Townsley, "Use Cases for IPv6 Source Packet 871 Routing in Networking (SPRING)", RFC 8354, 872 DOI 10.17487/RFC8354, March 2018, 873 . 875 [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions 876 for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, 877 December 2019, . 879 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 880 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 881 Extensions for Segment Routing", RFC 8667, 882 DOI 10.17487/RFC8667, December 2019, 883 . 885 [I-D.ietf-6man-segment-routing-header] 886 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 887 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 888 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 889 progress), October 2019. 891 [I-D.ietf-spring-segment-routing-policy] 892 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 893 P. Mattes, "Segment Routing Policy Architecture", draft- 894 ietf-spring-segment-routing-policy-07 (work in progress), 895 May 2020. 897 [I-D.li-ospf-ospfv3-srv6-extensions] 898 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 899 "OSPFv3 Extensions for SRv6", draft-li-ospf- 900 ospfv3-srv6-extensions-07 (work in progress), November 901 2019. 903 [I-D.ietf-idr-bgpls-srv6-ext] 904 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 905 daniel.bernier@bell.ca, d., and B. Decraene, "BGP Link 906 State Extensions for SRv6", draft-ietf-idr-bgpls- 907 srv6-ext-02 (work in progress), January 2020. 909 Appendix A. Contributor 911 The following persons contributed to this document: 913 Dhruv Dhody 914 Huawei Technologies 915 Divyashree Techno Park, Whitefield 916 Bangalore, Karnataka 560066 917 India 919 EMail: dhruv.ietf@gmail.com 921 Huang Wumin 922 Huawei Technologies 923 Huawei Building, No. 156 Beiqing Rd. 924 Beijing 100095 925 China 927 Email: huangwumin@huawei.com 929 Shuping Peng 930 Huawei Technologies 931 Huawei Building, No. 156 Beiqing Rd. 932 Beijing 100095 933 China 935 Email: pengshuping@huawei.com 937 Authors' Addresses 939 Mahendra Singh Negi 940 RtBrick India 941 N-17L, Floor-1, 18th Cross Rd, HSR Layout Sector-3 942 Bangalore, Karnataka 560102 943 India 945 EMail: mahend.ietf@gmail.com 947 Cheng Li 948 Huawei Technologies 949 Huawei Campus, No. 156 Beiqing Rd. 950 Beijing 100095 951 China 953 EMail: chengli13@huawei.com 954 Siva Sivabalan 955 Cisco Systems 957 EMail: msiva@cisco.com 959 Prejeeth Kaladharan 960 RtBrick Inc 961 Bangalore, Karnataka 962 India 964 EMail: prejeeth@rtbrick.com 966 Yongqing Zhu 967 China Telecom 968 109 West Zhongshan Ave, Tianhe District 969 Bangalore, Guangzhou 970 P.R. China 972 EMail: zhuyq.gd@chinatelecom.cn