idnits 2.17.00 (12 Aug 2021) /tmp/idnits9959/draft-ietf-pce-segment-routing-14.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 (October 13, 2018) is 1315 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: draft-ietf-6man-segment-routing-header has been published as RFC 8754 == Outdated reference: draft-ietf-idr-bgp-ls-segment-routing-msd has been published as RFC 8814 == Outdated reference: draft-ietf-isis-segment-routing-extensions has been published as RFC 8667 == Outdated reference: draft-ietf-isis-segment-routing-msd has been published as RFC 8491 == Outdated reference: draft-ietf-ospf-segment-routing-extensions has been published as RFC 8665 == Outdated reference: draft-ietf-ospf-segment-routing-msd has been published as RFC 8476 == Outdated reference: A later version (-18) exists of draft-ietf-pce-pcep-yang-08 == Outdated reference: draft-ietf-spring-segment-routing-mpls has been published as RFC 8660 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-01 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE S. Sivabalan 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: April 16, 2019 J. Tantsura 6 Apstra, Inc. 7 W. Henderickx 8 Nokia 9 J. Hardwick 10 Metaswitch Networks 11 October 13, 2018 13 PCEP Extensions for Segment Routing 14 draft-ietf-pce-segment-routing-14 16 Abstract 18 Segment Routing (SR) enables any head-end node to select any path 19 without relying on a hop-by-hop signaling technique (e.g., LDP or 20 RSVP-TE). It depends only on "segments" that are advertised by Link- 21 State Interior Gateway Protocols (IGPs). A Segment Routed Path can 22 be derived from a variety of mechanisms, including an IGP Shortest 23 Path Tree (SPT), explicit configuration, or a Path Computation 24 Element (PCE). This document specifies extensions to the Path 25 Computation Element Communication Protocol (PCEP) that allow a 26 stateful PCE to compute and initiate Traffic Engineering (TE) paths, 27 as well as a PCC to request a path subject to certain constraints and 28 optimization criteria in SR networks. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 34 "OPTIONAL" in this document are to be interpreted as described in BCP 35 14 [RFC2119] [RFC8174] when, and only when, they appear in all 36 capitals, as shown here. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on April 16, 2019. 55 Copyright Notice 57 Copyright (c) 2018 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 3. Overview of PCEP Operation in SR Networks . . . . . . . . . . 5 75 4. SR-Specific PCEP Message Extensions . . . . . . . . . . . . . 7 76 5. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 7 77 5.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 7 78 5.1.1. The SR PCE Capability sub-TLV . . . . . . . . . . . . 7 79 5.2. The RP/SRP Object . . . . . . . . . . . . . . . . . . . . 8 80 5.3. ERO . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 5.3.1. SR-ERO Subobject . . . . . . . . . . . . . . . . . . 9 82 5.3.2. NAI Associated with SID . . . . . . . . . . . . . . . 11 83 5.4. RRO . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 5.5. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 13 85 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 6.1. Exchanging the SR PCE Capability . . . . . . . . . . . . 14 87 6.2. ERO Processing . . . . . . . . . . . . . . . . . . . . . 15 88 6.2.1. SR-ERO Validation . . . . . . . . . . . . . . . . . . 15 89 6.2.2. Interpreting the SR-ERO . . . . . . . . . . . . . . . 17 90 6.3. RRO Processing . . . . . . . . . . . . . . . . . . . . . 19 91 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 19 92 8. Management Considerations . . . . . . . . . . . . . . . . . . 20 93 8.1. Controlling the Path Setup Type . . . . . . . . . . . . . 20 94 8.2. Migrating a Network to Use PCEP Segment Routed Paths . . 21 95 8.3. Verification of Network Operation . . . . . . . . . . . . 22 96 8.4. Relationship to Existing Management Models . . . . . . . 23 97 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 98 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 99 10.1. PCEP ERO and RRO subobjects . . . . . . . . . . . . . . 24 100 10.2. New NAI Type Registry . . . . . . . . . . . . . . . . . 24 101 10.3. New SR-ERO Flag Registry . . . . . . . . . . . . . . . . 24 102 10.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 25 103 10.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 26 104 10.6. New Path Setup Type . . . . . . . . . . . . . . . . . . 26 105 10.7. New Metric Type . . . . . . . . . . . . . . . . . . . . 27 106 10.8. SR PCE Capability Flags . . . . . . . . . . . . . . . . 27 107 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 108 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 109 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 110 13.1. Normative References . . . . . . . . . . . . . . . . . . 28 111 13.2. Informative References . . . . . . . . . . . . . . . . . 29 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 114 1. Introduction 116 Segment Routing (SR) leverages the source routing paradigm. Using 117 SR, a source node steers a packet through a path without relying on 118 hop-by-hop signaling protocols such as LDP or RSVP-TE. Each path is 119 specified as an ordered list of instructions called "segments". Each 120 segment is an instruction to route the packet to a specific place in 121 the network, or to perform a specific service on the packet. A 122 database of segments can be distributed through the network using a 123 routing protocol (such as IS-IS or OSPF) or by any other means. 124 Several types of segment are defined. A node segment represents an 125 ECMP-aware shortest-path to a specific node, and is always identified 126 uniquely within the SR/IGP domain. An adjacency segment represents a 127 unidirectional adjacency. An adjacency segment is local to the node 128 which advertises it. Both node segments and adjacency segments can 129 be used for SR Traffic Engineering (SR-TE). 131 [RFC8402] describes the SR architecture. The corresponding IS-IS and 132 OSPF extensions are specified in 133 [I-D.ietf-isis-segment-routing-extensions] and 134 [I-D.ietf-ospf-segment-routing-extensions], respectively. 136 The SR architecture can be implemented using either an MPLS 137 forwarding plane [I-D.ietf-spring-segment-routing-mpls] or an IPv6 138 forwarding plane [I-D.ietf-6man-segment-routing-header]. The MPLS 139 forwarding plane can be applied to SR without any change, in which 140 case an SR path corresponds to an MPLS Label Switching Path (LSP). 141 This document is relevant to the MPLS forwarding plane only. In this 142 document, "Node-SID" and "Adjacency-SID" denote Node Segment 143 Identifier and Adjacency Segment Identifier respectively. 145 A Segment Routed path (SR path) can be derived from an IGP Shortest 146 Path Tree (SPT). SR-TE paths may not follow an IGP SPT. Such paths 147 may be chosen by a suitable network planning tool and provisioned on 148 the ingress node of the SR-TE path. 150 [RFC5440] describes the Path Computation Element Communication 151 Protocol (PCEP) for communication between a Path Computation Client 152 (PCC) and a Path Computation Element (PCE) or between a pair of PCEs. 153 A PCE computes paths for MPLS Traffic Engineering LSPs (MPLS-TE LSPs) 154 based on various constraints and optimization criteria. [RFC8231] 155 specifies extensions to PCEP that allow a stateful PCE to compute and 156 recommend network paths in compliance with [RFC4657] and defines 157 objects and TLVs for MPLS-TE LSPs. Stateful PCEP extensions provide 158 synchronization of LSP state between a PCC and a PCE or between a 159 pair of PCEs, delegation of LSP control, reporting of LSP state from 160 a PCC to a PCE, controlling the setup and path routing of an LSP from 161 a PCE to a PCC. Stateful PCEP extensions are intended for an 162 operational model in which LSPs are configured on the PCC, and 163 control over them is delegated to the PCE. 165 A mechanism to dynamically initiate LSPs on a PCC based on the 166 requests from a stateful PCE or a controller using stateful PCE is 167 specified in [RFC8281]. This mechanism is useful in Software Defined 168 Networking (SDN) applications, such as on-demand engineering, or 169 bandwidth calendaring. 171 It is possible to use a stateful PCE for computing one or more SR-TE 172 paths taking into account various constraints and objective 173 functions. Once a path is chosen, the stateful PCE can initiate an 174 SR-TE path on a PCC using PCEP extensions specified in [RFC8281] 175 using the SR specific PCEP extensions specified in this document. 176 Additionally, using procedures described in this document, a PCC can 177 request an SR path from either a stateful or a stateless PCE. 179 This specification relies on the procedures specified in [RFC8408] to 180 exchange the segment routing capability and to specify that the path 181 setup type of an LSP is segment routing. 183 This specification provides a mechanism for a network controller 184 (acting as a PCE) to instantiate candidate paths for an SR Policy 185 onto a head-end node (acting as a PCC) using PCEP. For more 186 information on the SR Policy Architecture, see 187 [I-D.ietf-spring-segment-routing-policy]. 189 2. Terminology 191 The following terminologies are used in this document: 193 ERO: Explicit Route Object 195 IGP: Interior Gateway Protocol 197 IS-IS: Intermediate System to Intermediate System 199 LSR: Label Switching Router 201 MSD: Maximum SID Depth 203 NAI: Node or Adjacency Identifier 205 OSPF: Open Shortest Path First 207 PCC: Path Computation Client 209 PCE: Path Computation Element 211 PCEP: Path Computation Element Communication Protocol 213 RRO: Record Route Object 215 SID: Segment Identifier 217 SR: Segment Routing 219 SR-DB: Segment Routing Database (as defined in 220 [I-D.ietf-spring-segment-routing-policy]) 222 SR-TE: Segment Routing Traffic Engineering 224 3. Overview of PCEP Operation in SR Networks 226 In an SR network, the ingress node of an SR path prepends an SR 227 header to all outgoing packets. The SR header consists of a list of 228 SIDs (or MPLS labels in the context of this document). The header 229 has all necessary information so that, in combination with the 230 information distributed by the IGP, the packets can be guided from 231 the ingress node to the egress node of the path; hence, there is no 232 need for any signaling protocol. 234 In PCEP messages, LSP route information is carried in the Explicit 235 Route Object (ERO), which consists of a sequence of subobjects. In 236 SR networks, an ingress node of an SR path prepends an SR header to 237 all outgoing packets. The SR header consists of a list of SIDs (or 238 MPLS labels in the context of this document). SR-TE paths computed 239 by a PCE can be represented in an ERO in one of the following forms: 241 o An ordered set of IP addresses representing network nodes/links. 243 o An ordered set of SIDs, with or without the corresponding IP 244 addresses. 246 o An ordered set of MPLS labels, with or without corresponding IP 247 address. 249 The PCC converts these into an MPLS label stack and next hop, as 250 described in Section 6.2.2. 252 This document defines a new ERO subobject denoted by "SR-ERO 253 subobject" capable of carrying a SID as well as the identity of the 254 node/adjacency represented by the SID. SR-capable PCEP speakers 255 should be able to generate and/or process such ERO subobject. An ERO 256 containing SR-ERO subobjects can be included in the PCEP Path 257 Computation Reply (PCRep) message defined in [RFC5440], the PCEP LSP 258 Initiate Request message (PCInitiate) defined in [RFC8281], as well 259 as in the PCEP LSP Update Request (PCUpd) and PCEP LSP State Report 260 (PCRpt) messages defined in [RFC8231]. 262 When a PCEP session between a PCC and a PCE is established, both PCEP 263 speakers exchange their capabilities to indicate their ability to 264 support SR-specific functionality. 266 A PCE can update an LSP that is initially established via RSVP-TE 267 signaling to use an SR-TE path, by sending a PCUpd to the PCC that 268 delegated the LSP to it ([RFC8231]). A PCC can update an undelegated 269 LSP that is initially established via RSVP-TE signaling to use an SR- 270 TE path as follows. First, it requests an SR-TE Path from a PCE by 271 sending a PCReq message. If it receives a suitable path, it 272 establishes the path in the data plane, and then tears down the 273 original RSVP-TE path. If the PCE is stateful, then the PCC sends 274 PCRpt messages indicating that the new path is set up and the old 275 path is torn down, per [RFC8231]. 277 Similarly, a PCE or PCC can update an LSP initially created with an 278 SR-TE path to use RSVP-TE signaling, if necessary. This capability 279 is useful for rolling back a change when a network is migrated from 280 RSVP-TE to SR-TE technology. 282 A PCC MAY include an RRO containing the recorded LSP in PCReq and 283 PCRpt messages as specified in [RFC5440] and [RFC8231], respectively. 284 This document defines a new RRO subobject for SR networks. The 285 methods used by a PCC to record the SR-TE LSP are outside the scope 286 of this document. 288 In summary, this document: 290 o Defines a new ERO subobject, a new RRO subobject and new PCEP 291 error codes. 293 o Specifies how two PCEP speakers can establish a PCEP session that 294 can carry information about SR-TE paths. 296 o Specifies processing rules for the ERO subobject. 298 o Defines a new path setup type to be used in the PATH-SETUP-TYPE 299 and PATH-SETUP-TYPE-CAPABILITY TLVs ([RFC8408]). 301 o Defines a new sub-TLV for the PATH-SETUP-TYPE-CAPABILITY TLV. 303 The extensions specified in this document complement the existing 304 PCEP specifications to support SR-TE paths. As such, the PCEP 305 messages (e.g., Path Computation Request, Path Computation Reply, 306 Path Computation Report, Path Computation Update, Path Computation 307 Initiate, etc.,) MUST be formatted according to [RFC5440], [RFC8231], 308 [RFC8281], and any other applicable PCEP specifications. 310 4. SR-Specific PCEP Message Extensions 312 As defined in [RFC5440], a PCEP message consists of a common header 313 followed by a variable length body made up of mandatory and/or 314 optional objects. This document does not require any changes in the 315 format of the PCReq and PCRep messages specified in [RFC5440], 316 PCInitiate message specified in [RFC8281], and PCRpt and PCUpd 317 messages specified in [RFC8231]. 319 5. Object Formats 321 5.1. The OPEN Object 323 5.1.1. The SR PCE Capability sub-TLV 325 This document defines a new Path Setup Type (PST) for SR, as follows: 327 o PST = 1: Path is setup using Segment Routing Traffic Engineering. 329 A PCEP speaker SHOULD indicate its support of the function described 330 in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the 331 OPEN object with this new PST included in the PST list. 333 This document also defines the SR-PCE-CAPABILITY sub-TLV. PCEP 334 speakers use this sub-TLV to exchange information about their SR 335 capability. If a PCEP speaker includes PST=1 in the PST List of the 336 PATH-SETUP-TYPE-CAPABILITY TLV then it MUST also include the SR-PCE- 337 CAPABILITY sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY TLV. 339 The format of the SR-PCE-CAPABILITY sub-TLV is shown in the following 340 figure: 342 0 1 2 3 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Type=26 | Length=4 | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Reserved | Flags |N|L| MSD | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 Figure 1: SR-PCE-CAPABILITY sub-TLV format 352 The code point for the TLV type is 26. The TLV length is 4 octets. 354 The 32-bit value is formatted as follows. 356 Reserved: MUST be set to zero by the sender and MUST be ignored by 357 the receiver. 359 Flags: This document defines the following flag bits. The other 360 bits MUST be set to zero by the sender and MUST be ignored by the 361 receiver. 363 * N: A PCC sets this bit to 1 to indicate that it is capable of 364 resolving a Node or Adjacency Identifier (NAI) to a SID. 366 * L: A PCC sets this bit to 1 to indicate that it does not impose 367 any limit on the MSD. 369 Maximum SID Depth (MSD): specifies the maximum number of SIDs (MPLS 370 label stack depth in the context of this document) that a PCC is 371 capable of imposing on a packet. Section 6.1 explains the 372 relationship between this field and the L bit. 374 5.2. The RP/SRP Object 376 To set up an SR-TE LSP using SR, the RP or SRP object MUST include 377 the PATH-SETUP-TYPE TLV, specified in [RFC8408], with the PST set to 378 1 (path setup using SR-TE). 380 The LSP-IDENTIFIERS TLV MAY be present for the above PST type. 382 5.3. ERO 384 An SR-TE path consists of one or more SIDs where each SID MAY be 385 associated with the identifier that represents the node or adjacency 386 corresponding to the SID. This identifier is referred to as the 387 'Node or Adjacency Identifier' (NAI). As described later, a NAI can 388 be represented in various formats (e.g., IPv4 address, IPv6 address, 389 etc). Furthermore, a NAI is used for troubleshooting purposes and, 390 if necessary, to derive SID value as described below. 392 The ERO specified in [RFC5440] is used to carry SR-TE path 393 information. In order to carry SID and/or NAI, this document defines 394 a new ERO subobject referred to as "SR-ERO subobject" whose format is 395 specified in the following section. An ERO carrying an SR-TE path 396 consists of one or more ERO subobjects, and MUST carry only SR-ERO 397 subobjects. Note that an SR-ERO subobject does not need to have both 398 SID and NAI. However, at least one of them MUST be present. 400 When building the MPLS label stack from ERO, a PCC MUST assume that 401 SR-ERO subobjects are organized as a last-in-first-out stack. The 402 first subobject relative to the beginning of ERO contains the 403 information about the topmost label. The last subobject contains 404 information about the bottommost label. 406 5.3.1. SR-ERO Subobject 408 An SR-ERO subobject is formatted as shown in the following diagram. 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 |L| Type=36 | Length | NT | Flags |F|S|C|M| 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | SID (optional) | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 // NAI (variable, optional) // 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 Figure 2: SR-ERO subobject format 422 The fields in the SR-ERO Subobject are as follows: 424 The 'L' Flag: Indicates whether the subobject represents a loose-hop 425 in the LSP [RFC3209]. If this flag is set to zero, a PCC MUST NOT 426 overwrite the SID value present in the SR-ERO subobject. 428 Otherwise, a PCC MAY expand or replace one or more SID values in 429 the received SR-ERO based on its local policy. 431 Type: Set to 36. 433 Length: Contains the total length of the subobject in octets, 434 including the L, Type and Length fields. The Length MUST be at 435 least 8, and MUST be a multiple of 4. An SR-ERO subobject MUST 436 contain at least one of a SID or an NAI. The length should 437 include the SID and NAI fields if and only if they are not absent. 438 The flags described below indicate whether the SID or NAI fields 439 are absent. 441 NAI Type (NT): Indicates the type and format of the NAI contained in 442 the object body. This document describes the following NT values: 444 NT=0 The NAI is absent. 446 NT=1 The NAI is an IPv4 node ID. 448 NT=2 The NAI is an IPv6 node ID. 450 NT=3 The NAI is an IPv4 adjacency. 452 NT=4 The NAI is an IPv6 adjacency. 454 NT=5 The NAI is an unnumbered adjacency with IPv4 node IDs. 456 Flags: Used to carry additional information pertaining to the SID. 457 This document defines the following flag bits. The other bits 458 MUST be set to zero by the sender and MUST be ignored by the 459 receiver. 461 * M: If this bit is set to 1, the SID value represents an MPLS 462 label stack entry as specified in [RFC3032]. Otherwise, the 463 SID value is an administratively configured value which 464 represents an index into an MPLS label space (either SRGB or 465 SRLB) per [RFC8402]. 467 * C: If the M bit and the C bit are both set to 1, then the TC, 468 S, and TTL fields in the MPLS label stack entry are specified 469 by the PCE. However, a PCC MAY choose to override these values 470 according its local policy and MPLS forwarding rules. If the M 471 bit is set to 1 but the C bit is set to zero, then the TC, S, 472 and TTL fields MUST be ignored by the PCC. The PCC MUST set 473 these fields according to its local policy and MPLS forwarding 474 rules. If the M bit is set to zero then the C bit MUST be set 475 to zero. 477 * S: When this bit is set to 1, the SID value in the subobject 478 body is absent. In this case, the PCC is responsible for 479 choosing the SID value, e.g., by looking up in the SR-DB using 480 the NAI which, in this case, MUST be present in the subobject. 481 If the S bit is set to 1 then the M and C bits MUST be set to 482 zero. 484 * F: When this bit is set to 1, the NAI value in the subobject 485 body is absent. The F bit MUST be set to 1 if NT=0, and 486 otherwise MUST be set to zero. The S and F bits MUST NOT both 487 be set to 1. 489 SID: The Segment Identifier. Depending on the M bit, it contains 490 either: 492 * A 4 octet index defining the offset into an MPLS label space 493 per [RFC8402]. 495 * A 4 octet MPLS label, where the 20 most significant bits encode 496 the label value per [RFC3032]. 498 NAI: The NAI associated with the SID. The NAI's format depends on 499 the value in the NT field, and is described in the following 500 section. 502 At least one of the SID and the NAI MUST be included in the SR-ERO 503 subobject, and both MAY be included. 505 5.3.2. NAI Associated with SID 507 This document defines the following NAIs: 509 'IPv4 Node ID' is specified as an IPv4 address. In this case, the 510 NT value is 1 and the NAI field length is 4 octets. 512 'IPv6 Node ID' is specified as an IPv6 address. In this case, the 513 NT value is 2 and the NAI field length is 16 octets. 515 'IPv4 Adjacency' is specified as a pair of IPv4 addresses. In this 516 case, the NT value is 3 and the NAI field length is 8 octets. The 517 format of the NAI is shown in the following figure: 519 0 1 2 3 520 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 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Local IPv4 address | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Remote IPv4 address | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 Figure 3: NAI for IPv4 adjacency 529 'IPv6 Adjacency' is specified as a pair of IPv6 addresses. In this 530 case, the NT value is 4 and the NAI field length is 32 octets. 531 The format of the NAI is shown in the following figure: 533 0 1 2 3 534 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 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 // Local IPv6 address (16 octets) // 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 // Remote IPv6 address (16 octets) // 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 Figure 4: NAI for IPv6 adjacency 543 'Unnumbered Adjacency with IPv4 NodeIDs' is specified as a pair of 544 Node ID / Interface ID tuples. In this case, the NT value is 5 545 and the NAI field length is 16 octets. The format of the NAI is 546 shown in the following figure: 548 0 1 2 3 549 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 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Local Node-ID | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Local Interface ID | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Remote Node-ID | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Remote Interface ID | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 Figure 5: NAI for Unnumbered adjacency with IPv4 Node IDs 562 5.4. RRO 564 A PCC reports an SR-TE LSP to a PCE by sending a PCRpt message, per 565 [RFC8231]. The RRO on this message represents the SID list that was 566 applied by the PCC, that is, the actual path taken by the LSP. The 567 procedures of [RFC8231] with respect to the RRO apply equally to this 568 specification without change. 570 An RRO contains one or more subobjects called "SR-RRO subobjects" 571 whose format is shown below: 573 0 1 2 3 574 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 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | Type=36 | Length | NT | Flags |F|S|C|M| 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | SID | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 // NAI (variable) // 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 Figure 6: SR-RRO Subobject format 585 The format of the SR-RRO subobject is the same as that of the SR-ERO 586 subobject, but without the L flag. 588 A PCC MUST order the SR-RRO subobjects such that the first subobject 589 relative to the beginning of the RRO identifies the first segment 590 visited by the SR-TE LSP, and the last subobject identifies the final 591 segment of the SR-TE LSP, that is, its endpoint. 593 5.5. METRIC Object 595 A PCC MAY request that PCE optimizes an individual path computation 596 request to minimize the SID depth of the computed path by using the 597 METRIC object defined in [RFC5440]. This document defines a new type 598 for the METRIC object to be used for this purpose, as follows: 600 o T = 11: Maximum SID Depth of the requested path. 602 If the PCC includes a METRIC object of this type on a path 603 computation request, then the PCE MUST minimize the SID depth of the 604 computed path. If the B (bound) bit is set to to 1 in the METRIC 605 object, then the PCE MUST NOT return a path whose SID depth exceeds 606 the given metric-value. If the PCC did not set the L bit in its SR- 607 PCE-CAPABILITY TLV, then it MUST set the B bit to 1. If the PCC set 608 the L bit in its SR-PCE-CAPABILITY TLV, then it MAY set the B bit to 609 1 or zero. 611 If a PCEP session is established with a non-zero default MSD value, 612 then the PCC MUST NOT send an MSD METRIC object with an MSD greater 613 than the session's default MSD. If the PCE receives a path 614 computation request with an MSD METRIC object on such a session that 615 is greater than the session's default MSD, then it MUST consider the 616 request invalid and send a PCErr with Error-Type = 10 ("Reception of 617 an invalid object") and Error-Value 9 ("MSD exceeds the default for 618 the PCEP session"). 620 6. Procedures 622 6.1. Exchanging the SR PCE Capability 624 A PCC indicates that it is capable of supporting the head-end 625 functions for SR-TE LSP by including the SR-PCE-CAPABILITY sub-TLV in 626 the Open message that it sends to a PCE. A PCE indicates that it is 627 capable of computing SR-TE paths by including the SR-PCE-CAPABILITY 628 sub-TLV in the Open message that it sends to a PCC. 630 If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a 631 PST list containing PST=1, and supports that path setup type, then it 632 checks for the presence of the SR-PCE-CAPABILITY sub-TLV. If that 633 sub-TLV is absent, then the PCEP speaker MUST send a PCErr message 634 with Error-Type 10 (Reception of an invalid object) and Error-Value 635 TBD1 (to be assigned by IANA) (Missing PCE-SR-CAPABILITY sub-TLV) and 636 MUST then close the PCEP session. If a PCEP speaker receives a PATH- 637 SETUP-TYPE-CAPABILITY TLV with a SR-PCE-CAPABILITY sub-TLV, but the 638 PST list does not contain PST=1, then the PCEP speaker MUST ignore 639 the SR-PCE-CAPABILITY sub-TLV. 641 If a PCC sets the N flag to 1, then the PCE MAY send an SR-ERO 642 subobject containing NAI and no SID (see Section 6.2). Otherwise, 643 the PCE MUST NOT send an SR-ERO subobject containing NAI and no SID. 645 The number of SIDs that can be imposed on a packet depends on the 646 PCC's data plane's capability. If a PCC sets the L flag to 1 then 647 the MSD is not used and MUST be set to zero. If a PCE receives an 648 SR-PCE-CAPABILITY sub-TLV with the L flag set to 1 then it MUST 649 ignore the MSD field and MUST assume that the sender can impose a SID 650 stack of any depth. If a PCC sets the L flag to zero, then it sets 651 the MSD field to the maximum number of SIDs that it can impose on a 652 packet. If a PCE receives an SR-PCE-CAPABILITY sub-TLV with the L 653 flag and MSD both set to zero then it MUST assume that the PCC is not 654 capable of imposing a SID stack of any depth and hence is not SR-TE 655 capable, unless it learns a non-zero MSD for the PCC through some 656 other means. 658 Note that the MSD value exchanged via the SR-PCE-CAPABILITY sub-TLV 659 indicates the SID/label imposition limit for the PCC node. However, 660 if a PCE learns the MSD value of a PCC node via different means, e.g 661 routing protocols, as specified in: 662 [I-D.ietf-isis-segment-routing-msd]; 664 [I-D.ietf-ospf-segment-routing-msd]; 665 [I-D.ietf-idr-bgp-ls-segment-routing-msd], then it ignores the MSD 666 value in the SR-PCE-CAPABILITY sub-TLV. Furthermore, whenever a PCE 667 learns the MSD for a link via different means, it MUST use that value 668 for that link regardless of the MSD value exchanged in the SR-PCE- 669 CAPABILITY sub-TLV. 671 Once an SR-capable PCEP session is established with a non-zero MSD 672 value, the corresponding PCE MUST NOT send SR-TE paths with a number 673 of SIDs exceeding that MSD value. If a PCC needs to modify the MSD 674 value, it MUST close the PCEP session and re-establish it with the 675 new MSD value. If a PCEP session is established with a non-zero MSD 676 value, and the PCC receives an SR-TE path containing more SIDs than 677 specified in the MSD value, the PCC MUST send a PCErr message with 678 Error-Type 10 (Reception of an invalid object) and Error-Value 3 679 (Unsupported number of Segment ERO subobjects). If a PCEP session is 680 established with an MSD value of zero, then the PCC MAY specify an 681 MSD for each path computation request that it sends to the PCE, by 682 including a "maximum SID depth" metric object on the request, as 683 defined in Section 5.5. 685 The N flag, L flag and MSD value inside the SR-PCE-CAPABILITY sub-TLV 686 are meaningful only in the Open message sent from a PCC to a PCE. As 687 such, a PCE MUST set the N flag to zero, the L flag to 1 and MSD 688 value to zero in an outbound message to a PCC. Similarly, a PCC MUST 689 ignore any MSD value received from a PCE. If a PCE receives multiple 690 SR-PCE-CAPABILITY sub-TLVs in an Open message, it processes only the 691 first sub-TLV received. 693 6.2. ERO Processing 695 6.2.1. SR-ERO Validation 697 If a PCC does not support the SR PCE Capability and thus cannot 698 recognize the SR-ERO or SR-RRO subobjects, it will respond according 699 to the rules for a malformed object per [RFC5440]. 701 On receiving an SR-ERO, a PCC MUST validate that the Length field, 702 the S bit, the F bit and the NT field are consistent, as follows. 704 o If NT=0, the F bit MUST be 1, the S bit MUST be zero and the 705 Length MUST be 8. 707 o If NT=1, the F bit MUST be zero. If the S bit is 1, the Length 708 MUST be 8, otherwise the Length MUST be 12. 710 o If NT=2, the F bit MUST be zero. If the S bit is 1, the Length 711 MUST be 20, otherwise the Length MUST be 24. 713 o If NT=3, the F bit MUST be zero. If the S bit is 1, the Length 714 MUST be 12, otherwise the Length MUST be 16. 716 o If NT=4, the F bit MUST be zero. If the S bit is 1, the Length 717 MUST be 36, otherwise the Length MUST be 40. 719 o If NT=5, the F bit MUST be zero. If the S bit is 1, the Length 720 MUST be 20, otherwise the Length MUST be 24. 722 If a PCC finds that the NT field, Length field, S bit and F bit are 723 not consistent, it MUST consider the entire ERO invalid and MUST send 724 a PCErr message with Error-Type = 10 ("Reception of an invalid 725 object") and Error-Value = 11 ("Malformed object"). 727 If a PCC does not recognise or support the value in the NT field, it 728 MUST consider the entire ERO invalid and MUST send a PCErr message 729 with Error-Type = 10 ("Reception of an invalid object") and Error- 730 Value = TBD2 ("Unsupported NAI Type in Segment ERO subobject"). 732 If a PCC receives an SR-ERO subobject in which the S and F bits are 733 both set to 1 (that is, both the SID and NAI are absent), it MUST 734 consider the entire ERO invalid and send a PCErr message with Error- 735 Type = 10 ("Reception of an invalid object") and Error-Value = 6 736 ("Both SID and NAI are absent in SR-ERO subobject"). 738 If a PCC receives an SR-ERO subobject in which the S bit is set to 1 739 and the F bit is set to zero (that is, the SID is absent and the NAI 740 is present), but the PCC does not support NAI resolution, it MUST 741 consider the entire ERO invalid and send a PCErr message with Error- 742 Type = 4 ("Not supported object") and Error-Value = 4 ("Unsupported 743 parameter"). 745 If a PCC receives an SR-ERO subobject in which the S bit is set to 1 746 and either or both of the M or C bits is set to 1, it MUST consider 747 the entire ERO invalid and send a PCErr message with Error-Type = 10 748 ("Reception of an invalid object") and Error-Value = 11 ("Malformed 749 object"). 751 If a PCC receives an SR-ERO subobject in which the S bit is set to 752 zero and the M bit is set to 1, then the subobject contains an MPLS 753 label. The PCC MAY choose not to accept a label provided by the PCE, 754 based on it local policy. The PCC MUST NOT accept MPLS label value 3 755 (Implicit NULL), but it MAY accept other special purpose MPLS label 756 values. If the PCC decides not to accept an MPLS label value, it 757 MUST send a PCErr message with Error-Type = 10 ("Reception of an 758 invalid object") and Error Value = 2 ("Bad label value"). 760 If both M and C bits of an SR-ERO subobject are set to 1, and if a 761 PCC finds erroneous setting in one or more of TC, S, and TTL fields, 762 it MAY overwrite those fields with values chosen according to its own 763 policy. If the PCC does not overwrite them, it MUST send a PCErr 764 message with Error-Type = 10 ("Reception of an invalid object") and 765 Error-Value = 4 ("Bad label format"). 767 If the M bit of an SR-ERO subobject is set to zero but the C bit is 768 set to 1, then the PCC MUST consider the entire ERO invalid and MUST 769 send a PCErr message with Error-Type = 10 ("Reception of an invalid 770 object") and Error-Value = 11 ("Malformed object"). 772 If a PCC receives an SR-ERO subobject in which the S bit is set to 773 zero and the M bit is set to zero, then the subobject contains a SID 774 index value. If the SID is an Adjacency-SID then the L flag MUST NOT 775 be set. If the L flag is set for an Adjacency-SID then the PCC MUST 776 send a PCErr message with Error-Type = 10 ("Reception of an invalid 777 object") and Error-Value = 11 ("Malformed object"). 779 If a PCC detects that the subobjects of an ERO are a mixture of SR- 780 ERO subobjects and subobjects of other types, then it MUST send a 781 PCErr message with Error-Type = 10 ("Reception of an invalid object") 782 and Error-Value = 5 ("ERO mixes SR-ERO subobjects with other 783 subobject types"). 785 The SR-ERO subobjects can be classified according to whether they 786 contain a SID representing an MPLS label value, a SID representing an 787 index value, or no SID. If a PCC detects that the SR-ERO subobjects 788 are a mixture of more than one of these types, then it MUST send a 789 PCErr message with Error-Type = 10 ("Reception of an invalid object") 790 and Error-Value = TBD9 ("Inconsistent SIDs in SR-ERO / SR-RRO 791 subobjects"). 793 If an ERO specifies a new SR-TE path for an existing LSP and the PCC 794 determines that the ERO contains SR-ERO subobjects that are not 795 valid, then the PCC MUST NOT update the LSP. 797 6.2.2. Interpreting the SR-ERO 799 The SR-ERO contains a sequence of subobjects. According to 800 [I-D.ietf-spring-segment-routing-policy], each SR-ERO subobject in 801 the sequence identifies a segment that the traffic will be directed 802 to, in the order given. That is, the first subobject identifies the 803 first segment the traffic will be directed to, the second SR-ERO 804 subobject represents the second segment, and so on. 806 The PCC interprets the SR-ERO by converting it to an MPLS label stack 807 plus a next hop. The PCC sends packets along the segment routed path 808 by prepending the MPLS label stack onto the packets and sending the 809 resulting, modified packet to the next hop. 811 The PCC uses a different procedure to do this conversion, depending 812 on the information that the PCE has provided in the subobjects. 814 o If the subobjects contain SID index values, then the PCC converts 815 them into the corresponding MPLS labels by following the procedure 816 defined in [I-D.ietf-spring-segment-routing-mpls]. 818 o If the subobjects contain NAI only, then the PCC first converts 819 each NAI into a SID index value by looking it up in its local 820 database, and then proceeds as above. 822 o If the subobjects contain MPLS labels, then the PCC looks up the 823 offset of the first subobject's label in its SRGB or SRLB. This 824 gives the first SID. The PCC pushes the labels in any remaining 825 subobjects onto the packet (with the final subobject specifying 826 the bottom-of-stack label) and then directs the packet to the 827 segment identified by the first SID. 829 6.2.2.1. Handling Errors During SR-ERO Conversion 831 There are several errors that can occur during the process of 832 converting an SR-ERO sequence to an MPLS label stack and a next hop. 833 The PCC deals with them as follows. 835 o If the PCC cannot find a SID index in the SR-DB, it MUST send a 836 PCErr message with Error-Type = 10 ("Reception of an invalid 837 object") and Error-Value = TBD3 ("Unknown SID"). 839 o If the PCC cannot find an NAI in the SR-DB, it MUST send a PCErr 840 message with Error-Type = 10 ("Reception of an invalid object") 841 and Error-Value = TBD4 ("NAI cannot be resolved to a SID"). 843 o If the PCC needs to convert a SID into an MPLS label value but 844 cannot find the corresponding router's SRGB in the SR-DB, it MUST 845 send a PCErr message with Error-Type = 10 ("Reception of an 846 invalid object") and Error-Value = TBD5 ("Could not find SRGB"). 848 o If the PCC finds that a router's SRGB is not large enough for a 849 SID index value, it MUST send a PCErr message with Error-Type = 10 850 ("Reception of an invalid object") and Error-Value = TBD6 ("SID 851 index exceeds SRGB size"). 853 o If the PCC needs to convert a SID into an MPLS label value but 854 cannot find the corresponding router's SRLB in the SR-DB, it MUST 855 send a PCErr message with Error-Type = 10 ("Reception of an 856 invalid object") and Error-Value = TBD7 ("Could not find SRLB"). 858 o If the PCC finds that a router's SRLB is not large enough for a 859 SID index value, it MUST send a PCErr message with Error-Type = 10 860 ("Reception of an invalid object") and Error-Value = TBD8 ("SID 861 index exceeds SRLB size"). 863 o If the number of labels in the computed label stack exceeds the 864 maximum number of SIDs that the PCC can impose on the packet, it 865 MUST send a PCErr message with Error-Type = 10 ("Reception of an 866 invalid object") and Error-Value = 3 ("Unsupported number of 867 Segment ERO subobjects"). 869 If an ERO specifies a new SR-TE path for an existing LSP and the PCC 870 encounters an error while processing the ERO, then the PCC MUST NOT 871 update the LSP. 873 6.3. RRO Processing 875 The syntax checking rules that apply to the SR-RRO subobject are 876 identical to those of the SR-ERO subobject, except as noted below. 878 If a PCEP speaker receives an SR-RRO subobject in which both SID and 879 NAI are absent, it MUST consider the entire RRO invalid and send a 880 PCErr message with Error-Type = 10 ("Reception of an invalid object") 881 and Error-Value = 7 ("Both SID and NAI are absent in SR-RRO 882 subobject"). 884 If a PCE detects that the subobjects of an RRO are a mixture of SR- 885 RRO subobjects and subobjects of other types, then it MUST send a 886 PCErr message with Error-Type = 10 ("Reception of an invalid object") 887 and Error-Value = 10 ("RRO mixes SR-RRO subobjects with other 888 subobject types"). 890 The SR-RRO subobjects can be classified according to whether they 891 contain a SID representing an MPLS label value or a SID representing 892 an index value, or no SID. If a PCE detects that the SR-RRO 893 subobjects are a mixture of more than one of these types, then it 894 MUST send a PCErr message with Error-Type = 10 ("Reception of an 895 invalid object") and Error-Value = TBD9 ("Inconsistent SIDs in SR-ERO 896 / SR-RRO subobjects"). 898 7. Backward Compatibility 900 A PCEP speaker that does not support the SR PCEP capability cannot 901 recognize the SR-ERO or SR-RRO subobjects. As such, it responds 902 according to the rules for a malformed object, per [RFC5440]. 904 Some implementations, which are compliant with an earlier version of 905 this specification, do not send the PATH-SETUP-TYPE-CAPABILITY TLV in 906 their OPEN objects. Instead, to indicate that they support SR, these 907 implementations include the SR-CAPABILITY-TLV as a top-level TLV in 908 the OPEN object. Unfortunately, some of these implementations made 909 it into the field before this document was published in its final 910 form. Therefore, if a PCEP speaker receives an OPEN object in which 911 the SR-CAPABILITY-TLV appears as a top-level TLV, then it MUST 912 interpret this as though the sender had sent a PATH-SETUP-TYPE- 913 CAPABILITY TLV with a PST list of (0, 1) (that is, both RSVP-TE and 914 SR-TE PSTs are supported) and with the SR-CAPABILITY-TLV as a sub- 915 TLV. If a PCEP speaker receives an OPEN object in which both the SR- 916 CAPABILITY-TLV and PATH-SETUP-TYPE-CAPABILITY TLV appear as top-level 917 TLVs, then it MUST ignore the top-level SR-CAPABILITY-TLV and process 918 only the PATH-SETUP-TYPE-CAPABILITY TLV. 920 8. Management Considerations 922 This document adds a new path setup type to PCEP to allow LSPs to be 923 set up using segment routing techniques. This path setup type may be 924 used with PCEP alongside other path setup types, such as RSVP-TE, or 925 it may be used exclusively. 927 8.1. Controlling the Path Setup Type 929 The following factors control which path setup type is used for a 930 given LSP. 932 o The available path setup types are constrained to those that are 933 supported by, or enabled on, the PCEP speakers. The PATH-SETUP- 934 TYPE-CAPABILITY TLV indicates which path setup types a PCEP 935 speaker supports. To use segment routing as a path setup type, it 936 is a prerequisite that the PCC and PCE both include PST=1 in the 937 list of supported path setup types in this TLV, and also include 938 the SR-PCE-CAPABILITY sub-TLV. 940 o When a PCE initiates an LSP, it proposes which path setup type to 941 use by including it in the PATH-SETUP-TYPE TLV in the SRP object 942 of the PCInitiate message. The PCE chooses the path setup type 943 based on the capabilities of the network nodes on the path and on 944 its local policy. The PCC MAY choose to accept the proposed path 945 setup type, or to reject the PCInitiate request, based on its 946 local policy. 948 o When a PCC requests a path for an LSP, it can nominate a preferred 949 path setup type by including it in the PATH-SETUP-TYPE TLV in the 950 RP object of the PCReq message. The PCE MAY choose to reply with 951 a path of the requested type, or to reply with a path of a 952 different type, or to reject the request, based on the 953 capabilities of the network nodes on the path and on its local 954 policy. 956 The operator can influence the path setup type as follows. 958 o Implementations MUST allow the operator to enable and disable the 959 segment routing path setup type on a PCEP-speaking device. 960 Implementations MAY also allow the operator to enable and disable 961 the RSVP-TE path setup type. 963 o PCE implementations MUST allow the operator to specify that an LSP 964 should be instantiated using segment routing or RSVP-TE as the 965 proposed path setup type. 967 o PCE implementations MAY allow the operator to configure a 968 preference for the PCE to propose paths using segment routing or 969 RSVP-TE in the absence of a specified path setup type. 971 o PCC implementations MUST allow the operator to specify that a path 972 requested for an LSP nominates segment routing or RSVP-TE as the 973 path setup type. 975 o PCC implementations MAY allow the operator to configure a 976 preference for the PCC to nominate segment routing or RSVP-TE as 977 the path setup type if none is specified for an LSP. 979 o PCC implementations SHOULD allow the operator to configure a PCC 980 to refuse to set up an LSP using an undesired path setup type. 982 8.2. Migrating a Network to Use PCEP Segment Routed Paths 984 This section discusses the steps that the operator takes when 985 migrating a network to enable PCEP to set up paths using segment 986 routing as the path setup type. 988 o The operator enables the segment routing PST on the PCE servers. 990 o The operator enables the segment routing PST on the PCCs. 992 o The operator resets each PCEP session. The PCEP sessions come 993 back up with segment routing enabled. 995 o If the operator detects a problem, they can roll the network back 996 to its initial state by disabling the segment routing PST on the 997 PCEP speakers and resetting the PCEP sessions. 999 Note that the data plane is unaffected if a PCEP session is reset. 1000 Any LSPs that were set up before the session reset will remain in 1001 place and will still be present after the session comes back up. 1003 An implementation SHOULD allow the operator to manually trigger a 1004 PCEP session to be reset. 1006 An implementation MAY automatically reset a PCEP session when an 1007 operator reconfigures the PCEP speaker's capabilities. However, note 1008 that if the capabilities at both ends of the PCEP session are not 1009 reconfigured simultaneously, then the session could be reset twice, 1010 which could lead to unnecessary network traffic. Therefore, such 1011 implementations SHOULD allow the operator to override this behaviour 1012 and wait instead for a manual reset. 1014 Once segment routing is enabled on a PCEP session, it can be used as 1015 the path setup type for future LSPs. 1017 User traffic is not automatically migrated from existing LSPs onto 1018 segment routed LSPs just by enabling the segment routing PST in PCEP. 1019 The migration of user traffic from existing LSPs onto segment routing 1020 LSPs is beyond the scope of this document. 1022 8.3. Verification of Network Operation 1024 The operator needs the following information to verify that PCEP is 1025 operating correctly with respect to the segment routing path setup 1026 type. 1028 o An implementation SHOULD allow the operator to view whether the 1029 PCEP speaker sent the segment routing PST capability to its peer. 1030 If the PCEP speaker is a PCC, then the implementation SHOULD also 1031 allow the operator to view the values of the L and N flags that 1032 were sent, and the value of the MSD field that was sent. 1034 o An implementation SHOULD allow the operator to view whether the 1035 peer sent the segment routing PST capability. If the peer is a 1036 PCC, then the implementation SHOULD also allow the operator to 1037 view the values of the L and N flags and MSD fields that the peer 1038 sent. 1040 o An implementation SHOULD allow the operator to view whether the 1041 segment routing PST is enabled on the PCEP session. 1043 o If one PCEP speaker advertises the segment routing PST capability, 1044 but the other does not, then the implementation SHOULD create a 1045 log to inform the operator of the capability mismatch. 1047 o An implementation SHOULD allow the operator to view the PST that 1048 was proposed, or requested, for an LSP, and the PST that was 1049 actually used. 1051 o If a PCEP speaker decides to use a different PST to the one that 1052 was proposed, or requested, for an LSP, then the implementation 1053 SHOULD create a log to inform the operator that the expected PST 1054 has not been used. The log SHOULD give the reason for this choice 1055 (local policy, equipment capability etc.) 1057 o If a PCEP speaker rejects a segment routed path, then it SHOULD 1058 create a log to inform the operator, giving the reason for the 1059 decision (local policy, MSD exceeded etc.) 1061 8.4. Relationship to Existing Management Models 1063 The PCEP YANG module [I-D.ietf-pce-pcep-yang] should include: 1065 o advertised PST capabilities and MSD per PCEP session. 1067 o the PST configured for, and used by, each LSP. 1069 The PCEP MIB [RFC7420] could also be updated to include this 1070 information. 1072 9. Security Considerations 1074 The security considerations described in [RFC5440], [RFC8281] and 1075 [RFC8408] are applicable to this specification. No additional 1076 security measure is required. 1078 Note that this specification enables a network controller to 1079 instantiate a path in the network without the use of a hop-by-hop 1080 signaling protocol (such as RSVP-TE). This creates an additional 1081 vulnerability if the security mechanisms of [RFC5440] and [RFC8281] 1082 are not used, because an attacker could create a path which is not 1083 subjected to the further verification checks that would be performed 1084 by the signaling protocol. 1086 Note that this specification adds the MSD field to the OPEN message 1087 (see Section 5.1.1) which discloses how many MPLS labels the sender 1088 can push onto packets that it forwards into the network. If the 1089 security mechanisms of [RFC5440] and [RFC8281] are not used then an 1090 attacker could use this new field to gain intelligence about the 1091 capabilities of the edge devices in the network. 1093 10. IANA Considerations 1095 10.1. PCEP ERO and RRO subobjects 1097 This document defines a new subobject type for the PCEP explicit 1098 route object (ERO), and a new subobject type for the PCEP record 1099 route object (RRO). The code points for subobject types of these 1100 objects is maintained in the RSVP parameters registry, under the 1101 EXPLICIT_ROUTE and ROUTE_RECORD objects. IANA is requested to 1102 confirm the early allocation of the following code points in the RSVP 1103 Parameters registry for each of the new subobject types defined in 1104 this document. 1106 Object Subobject Subobject Type 1107 --------------------- -------------------------- ------------------ 1108 EXPLICIT_ROUTE SR-ERO (PCEP-specific) 36 1109 ROUTE_RECORD SR-RRO (PCEP-specific) 36 1111 10.2. New NAI Type Registry 1113 IANA is requested to create a new sub-registry within the "Path 1114 Computation Element Protocol (PCEP) Numbers" registry called "PCEP 1115 SR-ERO NAI Types". The allocation policy for this new registry 1116 should be by IETF Review. The new registry should contain the 1117 following values: 1119 Value Description Reference 1121 0 NAI is absent. This document 1122 1 NAI is an IPv4 node ID. This document 1123 2 NAI is an IPv6 node ID. This document 1124 3 NAI is an IPv4 adjacency. This document 1125 4 NAI is an IPv6 adjacency. This document 1126 5 NAI is an unnumbered This document 1127 adjacency with IPv4 node IDs. 1129 10.3. New SR-ERO Flag Registry 1131 IANA is requested to create a new sub-registry, named "SR-ERO Flag 1132 Field", within the "Path Computation Element Protocol (PCEP) Numbers" 1133 registry to manage the Flag field of the SR-ERO subobject. New 1134 values are to be assigned by Standards Action [RFC8126]. Each bit 1135 should be tracked with the following qualities: 1137 o Bit number (counting from bit 0 as the most significant bit) 1139 o Capability description 1140 o Defining RFC 1142 The following values are defined in this document: 1144 Bit Description Reference 1146 0-7 Unassigned 1147 8 NAI is absent (F) This document 1148 9 SID is absent (S) This document 1149 10 SID specifies TC, S This document 1150 and TTL in addition 1151 to an MPLS label (C) 1152 11 SID specifies an MPLS This document 1153 label (M) 1155 10.4. PCEP-Error Object 1157 IANA is requested to confirm the early allocation of the code-points 1158 in the PCEP-ERROR Object Error Types and Values registry for the 1159 following new error-values: 1161 Error-Type Meaning 1162 ---------- ------- 1163 10 Reception of an invalid object. 1165 Error-value = 2: Bad label value 1166 Error-value = 3: Unsupported number 1167 of SR-ERO 1168 subobjects 1169 Error-value = 4: Bad label format 1170 Error-value = 5: ERO mixes SR-ERO 1171 subobjects with 1172 other subobject 1173 types 1174 Error-value = 6: Both SID and NAI 1175 are absent in SR- 1176 ERO subobject 1177 Error-value = 7: Both SID and NAI 1178 are absent in SR- 1179 RRO subobject 1180 Error-value = 9: MSD exceeds the 1181 default for the 1182 PCEP session 1183 Error-value = 10: RRO mixes SR-RRO 1184 subobjects with 1185 other subobject 1186 types 1188 Error-value = TBD1: Missing PCE-SR- 1189 CAPABILITY sub-TLV 1190 Error-value = TBD2: Unsupported NAI 1191 Type in SR-ERO 1192 subobject 1193 Error-value = TBD3: Unknown SID 1194 Error-value = TBD4: NAI cannot be 1195 resolved to a SID 1196 Error-value = TBD5: Could not find SRGB 1197 Error-value = TBD6: SID index exceeds 1198 SRGB size 1199 Error-value = TBD7: Could not find SRLB 1200 Error-value = TBD8: SID index exceeds 1201 SRLB size 1202 Error-value = TBD9: Inconsistent SIDs 1203 in SR-ERO / SR-RRO 1204 subobjects 1206 Note to IANA: this draft originally had an early allocation for 1207 Error-value=11 (Malformed object) in the above list. However, we 1208 have since moved the definition of that code point to RFC8408. 1210 Note to IANA: some Error-values in the above list were defined after 1211 the early allocation took place, and so do not currently have a code 1212 point assigned. Please assign code points from the indicated 1213 registry and replace each instance of "TBD1", "TBD2" etc. in this 1214 document with the respective code points. 1216 Note to IANA: some of the Error-value descriptive strings above have 1217 changed since the early allocation. Please refresh the registry. 1219 10.5. PCEP TLV Type Indicators 1221 IANA is requested to confirm the early allocation of the following 1222 code point in the PCEP TLV Type Indicators registry. 1224 Value Meaning Reference 1225 ------------------------- ---------------------------- -------------- 1226 26 SR-PCE-CAPABILITY This document 1228 10.6. New Path Setup Type 1230 [RFC8408] requests that IANA creates a sub-registry within the "Path 1231 Computation Element Protocol (PCEP) Numbers" registry called "PCEP 1232 Path Setup Types". IANA is requested to allocate a new code point 1233 within this registry, as follows: 1235 Value Description Reference 1236 ------------------------- ---------------------------- -------------- 1237 1 Traffic engineering path is This document 1238 setup using Segment Routing. 1240 10.7. New Metric Type 1242 IANA is requested to confirm the early allocation of the following 1243 code point in the PCEP METRIC object T field registry: 1245 Value Description Reference 1246 ------------------------- ---------------------------- -------------- 1247 11 Segment-ID (SID) Depth. This document 1249 10.8. SR PCE Capability Flags 1251 IANA is requested to create a new sub-registry, named "SR Capability 1252 Flag Field", within the "Path Computation Element Protocol (PCEP) 1253 Numbers" registry to manage the Flag field of the SR-PCE-CAPABILITY 1254 TLV. New values are to be assigned by Standards Action [RFC8126]. 1255 Each bit should be tracked with the following qualities: 1257 o Bit number (counting from bit 0 as the most significant bit) 1258 o Capability description 1259 o Defining RFC 1261 The following values are defined in this document: 1263 Bit Description Reference 1265 0-5 Unassigned 1266 6 Node or Adjacency This document 1267 Identifier (NAI) is 1268 supported (N) 1269 7 Unlimited Maximum SID This document 1270 Depth (L) 1272 11. Contributors 1274 The following people contributed to this document: 1276 - Lakshmi Sharma 1277 - Jan Medved 1278 - Edward Crabbe 1279 - Robert Raszuk 1280 - Victor Lopez 1282 12. Acknowledgements 1284 We thank Ina Minei, George Swallow, Marek Zavodsky, Dhruv Dhody, Ing- 1285 Wher Chen and Tomas Janciga for the valuable comments. 1287 13. References 1289 13.1. Normative References 1291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1292 Requirement Levels", BCP 14, RFC 2119, 1293 DOI 10.17487/RFC2119, March 1997, 1294 . 1296 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1297 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1298 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 1299 . 1301 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1302 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1303 DOI 10.17487/RFC5440, March 2009, 1304 . 1306 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1307 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1308 May 2017, . 1310 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1311 Computation Element Communication Protocol (PCEP) 1312 Extensions for Stateful PCE", RFC 8231, 1313 DOI 10.17487/RFC8231, September 2017, 1314 . 1316 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1317 Computation Element Communication Protocol (PCEP) 1318 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1319 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1320 . 1322 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1323 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1324 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1325 July 2018, . 1327 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 1328 Hardwick, "Conveying Path Setup Type in PCE Communication 1329 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 1330 July 2018, . 1332 13.2. Informative References 1334 [I-D.ietf-6man-segment-routing-header] 1335 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 1336 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 1337 (SRH)", draft-ietf-6man-segment-routing-header-14 (work in 1338 progress), June 2018. 1340 [I-D.ietf-idr-bgp-ls-segment-routing-msd] 1341 Tantsura, J., Chunduri, U., Mirsky, G., and S. Sivabalan, 1342 "Signaling MSD (Maximum SID Depth) using Border Gateway 1343 Protocol Link-State", draft-ietf-idr-bgp-ls-segment- 1344 routing-msd-02 (work in progress), August 2018. 1346 [I-D.ietf-isis-segment-routing-extensions] 1347 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 1348 Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, 1349 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 1350 segment-routing-extensions-19 (work in progress), July 1351 2018. 1353 [I-D.ietf-isis-segment-routing-msd] 1354 Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 1355 "Signaling MSD (Maximum SID Depth) using IS-IS", draft- 1356 ietf-isis-segment-routing-msd-19 (work in progress), 1357 October 2018. 1359 [I-D.ietf-ospf-segment-routing-extensions] 1360 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1361 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1362 Extensions for Segment Routing", draft-ietf-ospf-segment- 1363 routing-extensions-25 (work in progress), April 2018. 1365 [I-D.ietf-ospf-segment-routing-msd] 1366 Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 1367 "Signaling MSD (Maximum SID Depth) using OSPF", draft- 1368 ietf-ospf-segment-routing-msd-23 (work in progress), 1369 October 2018. 1371 [I-D.ietf-pce-pcep-yang] 1372 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1373 YANG Data Model for Path Computation Element 1374 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1375 yang-08 (work in progress), June 2018. 1377 [I-D.ietf-spring-segment-routing-mpls] 1378 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 1379 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1380 data plane", draft-ietf-spring-segment-routing-mpls-14 1381 (work in progress), June 2018. 1383 [I-D.ietf-spring-segment-routing-policy] 1384 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 1385 bogdanov@google.com, b., and P. Mattes, "Segment Routing 1386 Policy Architecture", draft-ietf-spring-segment-routing- 1387 policy-01 (work in progress), June 2018. 1389 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1390 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1391 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1392 . 1394 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 1395 Element (PCE) Communication Protocol Generic 1396 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 1397 2006, . 1399 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1400 Hardwick, "Path Computation Element Communication Protocol 1401 (PCEP) Management Information Base (MIB) Module", 1402 RFC 7420, DOI 10.17487/RFC7420, December 2014, 1403 . 1405 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1406 Writing an IANA Considerations Section in RFCs", BCP 26, 1407 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1408 . 1410 Authors' Addresses 1412 Siva Sivabalan 1413 Cisco Systems, Inc. 1414 2000 Innovation Drive 1415 Kanata, Ontario K2K 3E8 1416 Canada 1418 Email: msiva@cisco.com 1419 Clarence Filsfils 1420 Cisco Systems, Inc. 1421 Pegasus Parc 1422 De kleetlaan 6a, DIEGEM BRABANT 1831 1423 BELGIUM 1425 Email: cfilsfil@cisco.com 1427 Jeff Tantsura 1428 Apstra, Inc. 1429 444 San Antonio Rd, 10A 1430 Palo Alto, CA 94306 1431 USA 1433 Email: jefftant.ietf@gmail.com 1435 Wim Henderickx 1436 Nokia 1437 Copernicuslaan 50 1438 Antwerp 2018, CA 95134 1439 BELGIUM 1441 Email: wim.henderickx@alcatel-lucent.com 1443 Jon Hardwick 1444 Metaswitch Networks 1445 100 Church Street 1446 Enfield, Middlesex 1447 UK 1449 Email: jonathan.hardwick@metaswitch.com