idnits 2.17.1 draft-ietf-pce-segment-routing-13.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 12, 2018) is 2016 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 (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-msd-02 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-19 == Outdated reference: A later version (-19) exists of draft-ietf-isis-segment-routing-msd-16 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-25 == Outdated reference: A later version (-25) exists of draft-ietf-ospf-segment-routing-msd-20 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-08 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-14 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-14 == 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 15, 2019 J. Tantsura 6 Individual 7 W. Henderickx 8 Nokia 9 J. Hardwick 10 Metaswitch Networks 11 October 12, 2018 13 PCEP Extensions for Segment Routing 14 draft-ietf-pce-segment-routing-13 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 15, 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 . . . . . . . . . . . . . . . . . 30 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 114 1. Introduction 116 Segment Routing (SR) technology leverages the source routing and 117 tunneling paradigms. A source node can choose a path without relying 118 on hop-by-hop signaling protocols such as LDP or RSVP-TE. Each path 119 is specified as a set of "segments" advertised by link-state routing 120 protocols (IS-IS or OSPF). [RFC8402] provides an introduction to the 121 SR architecture. The corresponding IS-IS and OSPF extensions are 122 specified in [I-D.ietf-isis-segment-routing-extensions] and 123 [I-D.ietf-ospf-segment-routing-extensions], respectively. The SR 124 architecture defines a "segment" as a piece of information advertised 125 by a link-state routing protocols, e.g., an IGP prefix or an IGP 126 adjacency. Several types of segments are defined. A Node segment 127 represents an ECMP-aware shortest-path computed by IGP to a specific 128 node, and is always identified uniquely within the SR/IGP domain. An 129 Adjacency Segment represents a unidirectional adjacency. An 130 Adjacency Segment is local to the node which advertises it. Both 131 Node segments and Adjacency segments can be used for SR Traffic 132 Engineering (SR-TE). 134 The SR architecture can be implemented using either an MPLS 135 forwarding plane [I-D.ietf-spring-segment-routing-mpls] or an IPv6 136 forwarding plane [I-D.ietf-6man-segment-routing-header]. The MPLS 137 forwarding plane can be applied to SR without any change, in which 138 case an SR path corresponds to an MPLS Label Switching Path (LSP). 139 This document is relevant to the MPLS forwarding plane only. In this 140 document, "Node-SID" and "Adjacency-SID" denote Node Segment 141 Identifier and Adjacency Segment Identifier respectively. 143 A Segment Routed path (SR path) can be derived from an IGP Shortest 144 Path Tree (SPT). SR-TE paths may not follow an IGP SPT. Such paths 145 may be chosen by a suitable network planning tool and provisioned on 146 the ingress node of the SR-TE path. 148 [RFC5440] describes the Path Computation Element Communication 149 Protocol (PCEP) for communication between a Path Computation Client 150 (PCC) and a Path Computation Element (PCE) or between a pair of PCEs. 151 A PCE computes paths for MPLS Traffic Engineering LSPs (MPLS-TE LSPs) 152 based on various constraints and optimization criteria. [RFC8231] 153 specifies extensions to PCEP that allow a stateful PCE to compute and 154 recommend network paths in compliance with [RFC4657] and defines 155 objects and TLVs for MPLS-TE LSPs. Stateful PCEP extensions provide 156 synchronization of LSP state between a PCC and a PCE or between a 157 pair of PCEs, delegation of LSP control, reporting of LSP state from 158 a PCC to a PCE, controlling the setup and path routing of an LSP from 159 a PCE to a PCC. Stateful PCEP extensions are intended for an 160 operational model in which LSPs are configured on the PCC, and 161 control over them is delegated to the PCE. 163 A mechanism to dynamically initiate LSPs on a PCC based on the 164 requests from a stateful PCE or a controller using stateful PCE is 165 specified in [RFC8281]. This mechanism is useful in Software Defined 166 Networking (SDN) applications, such as on-demand engineering, or 167 bandwidth calendaring. 169 It is possible to use a stateful PCE for computing one or more SR-TE 170 paths taking into account various constraints and objective 171 functions. Once a path is chosen, the stateful PCE can initiate an 172 SR-TE path on a PCC using PCEP extensions specified in [RFC8281] 173 using the SR specific PCEP extensions specified in this document. 174 Additionally, using procedures described in this document, a PCC can 175 request an SR path from either a stateful or a stateless PCE. 177 This specification relies on the procedures specified in [RFC8408] to 178 exchange the segment routing capability and to specify that the path 179 setup type of an LSP is segment routing. 181 This specification provides a mechanism for a network controller 182 (acting as a PCE) to instantiate candidate paths for an SR Policy 183 onto a head-end node (acting as a PCC) using PCEP. For more 184 information on the SR Policy Architecture, see 185 [I-D.ietf-spring-segment-routing-policy]. 187 2. Terminology 189 The following terminologies are used in this document: 191 ERO: Explicit Route Object 193 IGP: Interior Gateway Protocol 195 IS-IS: Intermediate System to Intermediate System 197 LSR: Label Switching Router 199 MSD: Maximum SID Depth 201 NAI: Node or Adjacency Identifier 203 OSPF: Open Shortest Path First 205 PCC: Path Computation Client 207 PCE: Path Computation Element 209 PCEP: Path Computation Element Communication Protocol 211 RRO: Record Route Object 213 SID: Segment Identifier 215 SR: Segment Routing 217 SR-DB: Segment Routing Database (as defined in 218 [I-D.ietf-spring-segment-routing-policy]) 220 SR-TE: Segment Routing Traffic Engineering 222 3. Overview of PCEP Operation in SR Networks 224 In an SR network, the ingress node of an SR path prepends an SR 225 header to all outgoing packets. The SR header consists of a list of 226 SIDs (or MPLS labels in the context of this document). The header 227 has all necessary information so that, in combination with the 228 information distributed by the IGP, the packets can be guided from 229 the ingress node to the egress node of the path; hence, there is no 230 need for any signaling protocol. 232 In PCEP messages, LSP route information is carried in the Explicit 233 Route Object (ERO), which consists of a sequence of subobjects. In 234 SR networks, an ingress node of an SR path prepends an SR header to 235 all outgoing packets. The SR header consists of a list of SIDs (or 236 MPLS labels in the context of this document). SR-TE paths computed 237 by a PCE can be represented in an ERO in one of the following forms: 239 o An ordered set of IP addresses representing network nodes/links. 241 o An ordered set of SIDs, with or without the corresponding IP 242 addresses. 244 o An ordered set of MPLS labels, with or without corresponding IP 245 address. 247 The PCC converts these into an MPLS label stack and next hop, as 248 described in Section 6.2.2. 250 This document defines a new ERO subobject denoted by "SR-ERO 251 subobject" capable of carrying a SID as well as the identity of the 252 node/adjacency represented by the SID. SR-capable PCEP speakers 253 should be able to generate and/or process such ERO subobject. An ERO 254 containing SR-ERO subobjects can be included in the PCEP Path 255 Computation Reply (PCRep) message defined in [RFC5440], the PCEP LSP 256 Initiate Request message (PCInitiate) defined in [RFC8281], as well 257 as in the PCEP LSP Update Request (PCUpd) and PCEP LSP State Report 258 (PCRpt) messages defined in [RFC8231]. 260 When a PCEP session between a PCC and a PCE is established, both PCEP 261 speakers exchange their capabilities to indicate their ability to 262 support SR-specific functionality. 264 A PCE can update an LSP that is initially established via RSVP-TE 265 signaling to use an SR-TE path, by sending a PCUpd to the PCC that 266 delegated the LSP to it ([RFC8231]). A PCC can update an undelegated 267 LSP that is initially established via RSVP-TE signaling to use an SR- 268 TE path as follows. First, it requests an SR-TE Path from a PCE by 269 sending a PCReq message. If it receives a suitable path, it 270 establishes the path in the data plane, and then tears down the 271 original RSVP-TE path. If the PCE is stateful, then the PCC sends 272 PCRpt messages indicating that the new path is set up and the old 273 path is torn down, per [RFC8231]. 275 Similarly, a PCE or PCC can update an LSP initially created with an 276 SR-TE path to use RSVP-TE signaling, if necessary. This capability 277 is useful for rolling back a change when a network is migrated from 278 RSVP-TE to SR-TE technology. 280 A PCC MAY include an RRO containing the recorded LSP in PCReq and 281 PCRpt messages as specified in [RFC5440] and [RFC8231], respectively. 282 This document defines a new RRO subobject for SR networks. The 283 methods used by a PCC to record the SR-TE LSP are outside the scope 284 of this document. 286 In summary, this document: 288 o Defines a new ERO subobject, a new RRO subobject and new PCEP 289 error codes. 291 o Specifies how two PCEP speakers can establish a PCEP session that 292 can carry information about SR-TE paths. 294 o Specifies processing rules for the ERO subobject. 296 o Defines a new path setup type to be used in the PATH-SETUP-TYPE 297 and PATH-SETUP-TYPE-CAPABILITY TLVs ([RFC8408]). 299 o Defines a new sub-TLV for the PATH-SETUP-TYPE-CAPABILITY TLV. 301 The extensions specified in this document complement the existing 302 PCEP specifications to support SR-TE paths. As such, the PCEP 303 messages (e.g., Path Computation Request, Path Computation Reply, 304 Path Computation Report, Path Computation Update, Path Computation 305 Initiate, etc.,) MUST be formatted according to [RFC5440], [RFC8231], 306 [RFC8281], and any other applicable PCEP specifications. 308 4. SR-Specific PCEP Message Extensions 310 As defined in [RFC5440], a PCEP message consists of a common header 311 followed by a variable length body made up of mandatory and/or 312 optional objects. This document does not require any changes in the 313 format of the PCReq and PCRep messages specified in [RFC5440], 314 PCInitiate message specified in [RFC8281], and PCRpt and PCUpd 315 messages specified in [RFC8231]. 317 5. Object Formats 319 5.1. The OPEN Object 321 5.1.1. The SR PCE Capability sub-TLV 323 This document defines a new Path Setup Type (PST) for SR, as follows: 325 o PST = 1: Path is setup using Segment Routing Traffic Engineering. 327 A PCEP speaker SHOULD indicate its support of the function described 328 in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the 329 OPEN object with this new PST included in the PST list. 331 This document also defines the SR-PCE-CAPABILITY sub-TLV. PCEP 332 speakers use this sub-TLV to exchange information about their SR 333 capability. If a PCEP speaker includes PST=1 in the PST List of the 334 PATH-SETUP-TYPE-CAPABILITY TLV then it MUST also include the SR-PCE- 335 CAPABILITY sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY TLV. 337 The format of the SR-PCE-CAPABILITY sub-TLV is shown in the following 338 figure: 340 0 1 2 3 341 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 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Type=26 | Length=4 | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Reserved | Flags |N|L| MSD | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 Figure 1: SR-PCE-CAPABILITY sub-TLV format 350 The code point for the TLV type is 26. The TLV length is 4 octets. 352 The 32-bit value is formatted as follows. 354 Reserved: MUST be set to zero by the sender and MUST be ignored by 355 the receiver. 357 Flags: This document defines the following flag bits. The other 358 bits MUST be set to zero by the sender and MUST be ignored by the 359 receiver. 361 * N: A PCC sets this bit to 1 to indicate that it is capable of 362 resolving a Node or Adjacency Identifier (NAI) to a SID. 364 * L: A PCC sets this bit to 1 to indicate that it does not impose 365 any limit on the MSD. 367 Maximum SID Depth (MSD): specifies the maximum number of SIDs (MPLS 368 label stack depth in the context of this document) that a PCC is 369 capable of imposing on a packet. Section 6.1 explains the 370 relationship between this field and the L bit. 372 5.2. The RP/SRP Object 374 To set up an SR-TE LSP using SR, the RP or SRP object MUST include 375 the PATH-SETUP-TYPE TLV, specified in [RFC8408], with the PST set to 376 1 (path setup using SR-TE). 378 The LSP-IDENTIFIERS TLV MAY be present for the above PST type. 380 5.3. ERO 382 An SR-TE path consists of one or more SIDs where each SID MAY be 383 associated with the identifier that represents the node or adjacency 384 corresponding to the SID. This identifier is referred to as the 385 'Node or Adjacency Identifier' (NAI). As described later, a NAI can 386 be represented in various formats (e.g., IPv4 address, IPv6 address, 387 etc). Furthermore, a NAI is used for troubleshooting purposes and, 388 if necessary, to derive SID value as described below. 390 The ERO specified in [RFC5440] is used to carry SR-TE path 391 information. In order to carry SID and/or NAI, this document defines 392 a new ERO subobject referred to as "SR-ERO subobject" whose format is 393 specified in the following section. An ERO carrying an SR-TE path 394 consists of one or more ERO subobjects, and MUST carry only SR-ERO 395 subobjects. Note that an SR-ERO subobject does not need to have both 396 SID and NAI. However, at least one of them MUST be present. 398 When building the MPLS label stack from ERO, a PCC MUST assume that 399 SR-ERO subobjects are organized as a last-in-first-out stack. The 400 first subobject relative to the beginning of ERO contains the 401 information about the topmost label. The last subobject contains 402 information about the bottommost label. 404 5.3.1. SR-ERO Subobject 406 An SR-ERO subobject is formatted as shown in the following diagram. 408 0 1 2 3 409 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 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 |L| Type=36 | Length | NT | Flags |F|S|C|M| 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | SID (optional) | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 // NAI (variable, optional) // 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 Figure 2: SR-ERO subobject format 420 The fields in the SR-ERO Subobject are as follows: 422 The 'L' Flag: Indicates whether the subobject represents a loose-hop 423 in the LSP [RFC3209]. If this flag is set to zero, a PCC MUST NOT 424 overwrite the SID value present in the SR-ERO subobject. 426 Otherwise, a PCC MAY expand or replace one or more SID values in 427 the received SR-ERO based on its local policy. 429 Type: Set to 36. 431 Length: Contains the total length of the subobject in octets, 432 including the L, Type and Length fields. The Length MUST be at 433 least 8, and MUST be a multiple of 4. An SR-ERO subobject MUST 434 contain at least one of a SID or an NAI. The length should 435 include the SID and NAI fields if and only if they are not absent. 436 The flags described below indicate whether the SID or NAI fields 437 are absent. 439 NAI Type (NT): Indicates the type and format of the NAI contained in 440 the object body. This document describes the following NT values: 442 NT=0 The NAI is absent. 444 NT=1 The NAI is an IPv4 node ID. 446 NT=2 The NAI is an IPv6 node ID. 448 NT=3 The NAI is an IPv4 adjacency. 450 NT=4 The NAI is an IPv6 adjacency. 452 NT=5 The NAI is an unnumbered adjacency with IPv4 node IDs. 454 Flags: Used to carry additional information pertaining to the SID. 455 This document defines the following flag bits. The other bits 456 MUST be set to zero by the sender and MUST be ignored by the 457 receiver. 459 * M: If this bit is set to 1, the SID value represents an MPLS 460 label stack entry as specified in [RFC3032]. Otherwise, the 461 SID value is an administratively configured value which 462 represents an index into an MPLS label space (either SRGB or 463 SRLB) per [RFC8402]. 465 * C: If the M bit and the C bit are both set to 1, then the TC, 466 S, and TTL fields in the MPLS label stack entry are specified 467 by the PCE. However, a PCC MAY choose to override these values 468 according its local policy and MPLS forwarding rules. If the M 469 bit is set to 1 but the C bit is set to zero, then the TC, S, 470 and TTL fields MUST be ignored by the PCC. The PCC MUST set 471 these fields according to its local policy and MPLS forwarding 472 rules. If the M bit is set to zero then the C bit MUST be set 473 to zero. 475 * S: When this bit is set to 1, the SID value in the subobject 476 body is absent. In this case, the PCC is responsible for 477 choosing the SID value, e.g., by looking up in the SR-DB using 478 the NAI which, in this case, MUST be present in the subobject. 479 If the S bit is set to 1 then the M and C bits MUST be set to 480 zero. 482 * F: When this bit is set to 1, the NAI value in the subobject 483 body is absent. The F bit MUST be set to 1 if NT=0, and 484 otherwise MUST be set to zero. The S and F bits MUST NOT both 485 be set to 1. 487 SID: The Segment Identifier. Depending on the M bit, it contains 488 either: 490 * A 4 octet index defining the offset into an MPLS label space 491 per [RFC8402]. 493 * A 4 octet MPLS label, where the 20 most significant bits encode 494 the label value per [RFC3032]. 496 NAI: The NAI associated with the SID. The NAI's format depends on 497 the value in the NT field, and is described in the following 498 section. 500 At least one of the SID and the NAI MUST be included in the SR-ERO 501 subobject, and both MAY be included. 503 5.3.2. NAI Associated with SID 505 This document defines the following NAIs: 507 'IPv4 Node ID' is specified as an IPv4 address. In this case, the 508 NT value is 1 and the NAI field length is 4 octets. 510 'IPv6 Node ID' is specified as an IPv6 address. In this case, the 511 NT value is 2 and the NAI field length is 16 octets. 513 'IPv4 Adjacency' is specified as a pair of IPv4 addresses. In this 514 case, the NT value is 3 and the NAI field length is 8 octets. The 515 format of the NAI is shown in the following figure: 517 0 1 2 3 518 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 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Local IPv4 address | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Remote IPv4 address | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 Figure 3: NAI for IPv4 adjacency 527 'IPv6 Adjacency' is specified as a pair of IPv6 addresses. In this 528 case, the NT value is 4 and the NAI field length is 32 octets. 529 The format of the NAI is shown in the following figure: 531 0 1 2 3 532 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 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 // Local IPv6 address (16 octets) // 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 // Remote IPv6 address (16 octets) // 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 Figure 4: NAI for IPv6 adjacency 541 'Unnumbered Adjacency with IPv4 NodeIDs' is specified as a pair of 542 Node ID / Interface ID tuples. In this case, the NT value is 5 543 and the NAI field length is 16 octets. The format of the NAI is 544 shown in the following figure: 546 0 1 2 3 547 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 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Local Node-ID | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Local Interface ID | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Remote Node-ID | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Remote Interface ID | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 Figure 5: NAI for Unnumbered adjacency with IPv4 Node IDs 560 5.4. RRO 562 A PCC reports an SR-TE LSP to a PCE by sending a PCRpt message, per 563 [RFC8231]. The RRO on this message represents the SID list that was 564 applied by the PCC, that is, the actual path taken by the LSP. The 565 procedures of [RFC8231] with respect to the RRO apply equally to this 566 specification without change. 568 An RRO contains one or more subobjects called "SR-RRO subobjects" 569 whose format is shown below: 571 0 1 2 3 572 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 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Type=36 | Length | NT | Flags |F|S|C|M| 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | SID | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 // NAI (variable) // 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 Figure 6: SR-RRO Subobject format 583 The format of the SR-RRO subobject is the same as that of the SR-ERO 584 subobject, but without the L flag. 586 A PCC MUST order the SR-RRO subobjects such that the first subobject 587 relative to the beginning of the RRO identifies the first segment 588 visited by the SR-TE LSP, and the last subobject identifies the final 589 segment of the SR-TE LSP, that is, its endpoint. 591 5.5. METRIC Object 593 A PCC MAY request that PCE optimizes an individual path computation 594 request to minimize the SID depth of the computed path by using the 595 METRIC object defined in [RFC5440]. This document defines a new type 596 for the METRIC object to be used for this purpose, as follows: 598 o T = 11: Maximum SID Depth of the requested path. 600 If the PCC includes a METRIC object of this type on a path 601 computation request, then the PCE MUST minimize the SID depth of the 602 computed path. If the B (bound) bit is set to to 1 in the METRIC 603 object, then the PCE MUST NOT return a path whose SID depth exceeds 604 the given metric-value. If the PCC did not set the L bit in its SR- 605 PCE-CAPABILITY TLV, then it MUST set the B bit to 1. If the PCC set 606 the L bit in its SR-PCE-CAPABILITY TLV, then it MAY set the B bit to 607 1 or zero. 609 If a PCEP session is established with a non-zero default MSD value, 610 then the PCC MUST NOT send an MSD METRIC object with an MSD greater 611 than the session's default MSD. If the PCE receives a path 612 computation request with an MSD METRIC object on such a session that 613 is greater than the session's default MSD, then it MUST consider the 614 request invalid and send a PCErr with Error-Type = 10 ("Reception of 615 an invalid object") and Error-Value 9 ("MSD exceeds the default for 616 the PCEP session"). 618 6. Procedures 620 6.1. Exchanging the SR PCE Capability 622 A PCC indicates that it is capable of supporting the head-end 623 functions for SR-TE LSP by including the SR-PCE-CAPABILITY sub-TLV in 624 the Open message that it sends to a PCE. A PCE indicates that it is 625 capable of computing SR-TE paths by including the SR-PCE-CAPABILITY 626 sub-TLV in the Open message that it sends to a PCC. 628 If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a 629 PST list containing PST=1, and supports that path setup type, then it 630 checks for the presence of the SR-PCE-CAPABILITY sub-TLV. If that 631 sub-TLV is absent, then the PCEP speaker MUST send a PCErr message 632 with Error-Type 10 (Reception of an invalid object) and Error-Value 633 TBD1 (to be assigned by IANA) (Missing PCE-SR-CAPABILITY sub-TLV) and 634 MUST then close the PCEP session. If a PCEP speaker receives a PATH- 635 SETUP-TYPE-CAPABILITY TLV with a SR-PCE-CAPABILITY sub-TLV, but the 636 PST list does not contain PST=1, then the PCEP speaker MUST ignore 637 the SR-PCE-CAPABILITY sub-TLV. 639 If a PCC sets the N flag to 1, then the PCE MAY send an SR-ERO 640 subobject containing NAI and no SID (see Section 6.2). Otherwise, 641 the PCE MUST NOT send an SR-ERO subobject containing NAI and no SID. 643 The number of SIDs that can be imposed on a packet depends on the 644 PCC's data plane's capability. If a PCC sets the L flag to 1 then 645 the MSD is not used and MUST be set to zero. If a PCE receives an 646 SR-PCE-CAPABILITY sub-TLV with the L flag set to 1 then it MUST 647 ignore the MSD field and MUST assume that the sender can impose a SID 648 stack of any depth. If a PCC sets the L flag to zero, then it sets 649 the MSD field to the maximum number of SIDs that it can impose on a 650 packet. If a PCE receives an SR-PCE-CAPABILITY sub-TLV with the L 651 flag and MSD both set to zero then it MUST assume that the PCC is not 652 capable of imposing a SID stack of any depth and hence is not SR-TE 653 capable, unless it learns a non-zero MSD for the PCC through some 654 other means. 656 Note that the MSD value exchanged via the SR-PCE-CAPABILITY sub-TLV 657 indicates the SID/label imposition limit for the PCC node. However, 658 if a PCE learns the MSD value of a PCC node via different means, e.g 659 routing protocols, as specified in: 660 [I-D.ietf-isis-segment-routing-msd]; 662 [I-D.ietf-ospf-segment-routing-msd]; 663 [I-D.ietf-idr-bgp-ls-segment-routing-msd], then it ignores the MSD 664 value in the SR-PCE-CAPABILITY sub-TLV. Furthermore, whenever a PCE 665 learns the MSD for a link via different means, it MUST use that value 666 for that link regardless of the MSD value exchanged in the SR-PCE- 667 CAPABILITY sub-TLV. 669 Once an SR-capable PCEP session is established with a non-zero MSD 670 value, the corresponding PCE MUST NOT send SR-TE paths with a number 671 of SIDs exceeding that MSD value. If a PCC needs to modify the MSD 672 value, it MUST close the PCEP session and re-establish it with the 673 new MSD value. If a PCEP session is established with a non-zero MSD 674 value, and the PCC receives an SR-TE path containing more SIDs than 675 specified in the MSD value, the PCC MUST send a PCErr message with 676 Error-Type 10 (Reception of an invalid object) and Error-Value 3 677 (Unsupported number of Segment ERO subobjects). If a PCEP session is 678 established with an MSD value of zero, then the PCC MAY specify an 679 MSD for each path computation request that it sends to the PCE, by 680 including a "maximum SID depth" metric object on the request, as 681 defined in Section 5.5. 683 The N flag, L flag and MSD value inside the SR-PCE-CAPABILITY sub-TLV 684 are meaningful only in the Open message sent from a PCC to a PCE. As 685 such, a PCE MUST set the N flag to zero, the L flag to 1 and MSD 686 value to zero in an outbound message to a PCC. Similarly, a PCC MUST 687 ignore any MSD value received from a PCE. If a PCE receives multiple 688 SR-PCE-CAPABILITY sub-TLVs in an Open message, it processes only the 689 first sub-TLV received. 691 6.2. ERO Processing 693 6.2.1. SR-ERO Validation 695 If a PCC does not support the SR PCE Capability and thus cannot 696 recognize the SR-ERO or SR-RRO subobjects, it will respond according 697 to the rules for a malformed object per [RFC5440]. 699 On receiving an SR-ERO, a PCC MUST validate that the Length field, 700 the S bit, the F bit and the NT field are consistent, as follows. 702 o If NT=0, the F bit MUST be 1, the S bit MUST be zero and the 703 Length MUST be 8. 705 o If NT=1, the F bit MUST be zero. If the S bit is 1, the Length 706 MUST be 8, otherwise the Length MUST be 12. 708 o If NT=2, the F bit MUST be zero. If the S bit is 1, the Length 709 MUST be 20, otherwise the Length MUST be 24. 711 o If NT=3, the F bit MUST be zero. If the S bit is 1, the Length 712 MUST be 12, otherwise the Length MUST be 16. 714 o If NT=4, the F bit MUST be zero. If the S bit is 1, the Length 715 MUST be 36, otherwise the Length MUST be 40. 717 o If NT=5, the F bit MUST be zero. If the S bit is 1, the Length 718 MUST be 20, otherwise the Length MUST be 24. 720 If a PCC finds that the NT field, Length field, S bit and F bit are 721 not consistent, it MUST consider the entire ERO invalid and MUST send 722 a PCErr message with Error-Type = 10 ("Reception of an invalid 723 object") and Error-Value = 11 ("Malformed object"). 725 If a PCC does not recognise or support the value in the NT field, it 726 MUST consider the entire ERO invalid and MUST send a PCErr message 727 with Error-Type = 10 ("Reception of an invalid object") and Error- 728 Value = TBD2 ("Unsupported NAI Type in Segment ERO subobject"). 730 If a PCC receives an SR-ERO subobject in which the S and F bits are 731 both set to 1 (that is, both the SID and NAI are absent), it MUST 732 consider the entire ERO invalid and send a PCErr message with Error- 733 Type = 10 ("Reception of an invalid object") and Error-Value = 6 734 ("Both SID and NAI are absent in SR-ERO subobject"). 736 If a PCC receives an SR-ERO subobject in which the S bit is set to 1 737 and the F bit is set to zero (that is, the SID is absent and the NAI 738 is present), but the PCC does not support NAI resolution, it MUST 739 consider the entire ERO invalid and send a PCErr message with Error- 740 Type = 4 ("Not supported object") and Error-Value = 4 ("Unsupported 741 parameter"). 743 If a PCC receives an SR-ERO subobject in which the S bit is set to 1 744 and either or both of the M or C bits is set to 1, it MUST consider 745 the entire ERO invalid and send a PCErr message with Error-Type = 10 746 ("Reception of an invalid object") and Error-Value = 11 ("Malformed 747 object"). 749 If a PCC receives an SR-ERO subobject in which the S bit is set to 750 zero and the M bit is set to 1, then the subobject contains an MPLS 751 label. The PCC MAY choose not to accept a label provided by the PCE, 752 based on it local policy. The PCC MUST NOT accept MPLS label value 3 753 (Implicit NULL), but it MAY accept other special purpose MPLS label 754 values. If the PCC decides not to accept an MPLS label value, it 755 MUST send a PCErr message with Error-Type = 10 ("Reception of an 756 invalid object") and Error Value = 2 ("Bad label value"). 758 If both M and C bits of an SR-ERO subobject are set to 1, and if a 759 PCC finds erroneous setting in one or more of TC, S, and TTL fields, 760 it MAY overwrite those fields with values chosen according to its own 761 policy. If the PCC does not overwrite them, it MUST send a PCErr 762 message with Error-Type = 10 ("Reception of an invalid object") and 763 Error-Value = 4 ("Bad label format"). 765 If the M bit of an SR-ERO subobject is set to zero but the C bit is 766 set to 1, then the PCC MUST consider the entire ERO invalid and MUST 767 send a PCErr message with Error-Type = 10 ("Reception of an invalid 768 object") and Error-Value = 11 ("Malformed object"). 770 If a PCC receives an SR-ERO subobject in which the S bit is set to 771 zero and the M bit is set to zero, then the subobject contains a SID 772 index value. If the SID is an Adjacency-SID then the L flag MUST NOT 773 be set. If the L flag is set for an Adjacency-SID then the PCC MUST 774 send a PCErr message with Error-Type = 10 ("Reception of an invalid 775 object") and Error-Value = 11 ("Malformed object"). 777 If a PCC detects that the subobjects of an ERO are a mixture of SR- 778 ERO subobjects and subobjects of other types, then it MUST send a 779 PCErr message with Error-Type = 10 ("Reception of an invalid object") 780 and Error-Value = 5 ("ERO mixes SR-ERO subobjects with other 781 subobject types"). 783 The SR-ERO subobjects can be classified according to whether they 784 contain a SID representing an MPLS label value, a SID representing an 785 index value, or no SID. If a PCC detects that the SR-ERO subobjects 786 are a mixture of more than one of these types, then it MUST send a 787 PCErr message with Error-Type = 10 ("Reception of an invalid object") 788 and Error-Value = TBD9 ("Inconsistent SIDs in SR-ERO / SR-RRO 789 subobjects"). 791 If an ERO specifies a new SR-TE path for an existing LSP and the PCC 792 determines that the ERO contains SR-ERO subobjects that are not 793 valid, then the PCC MUST NOT update the LSP. 795 6.2.2. Interpreting the SR-ERO 797 The SR-ERO contains a sequence of subobjects. According to 798 [I-D.ietf-spring-segment-routing-policy], each SR-ERO subobject in 799 the sequence identifies a segment that the traffic will be directed 800 to, in the order given. That is, the first subobject identifies the 801 first segment the traffic will be directed to, the second SR-ERO 802 subobject represents the second segment, and so on. 804 The PCC interprets the SR-ERO by converting it to an MPLS label stack 805 plus a next hop. The PCC sends packets along the segment routed path 806 by prepending the MPLS label stack onto the packets and sending the 807 resulting, modified packet to the next hop. 809 The PCC uses a different procedure to do this conversion, depending 810 on the information that the PCE has provided in the subobjects. 812 o If the subobjects contain SID index values, then the PCC converts 813 them into the corresponding MPLS labels by following the procedure 814 defined in [I-D.ietf-spring-segment-routing-mpls]. 816 o If the subobjects contain NAI only, then the PCC first converts 817 each NAI into a SID index value by looking it up in its local 818 database, and then proceeds as above. 820 o If the subobjects contain MPLS labels, then the PCC looks up the 821 offset of the first subobject's label in its SRGB or SRLB. This 822 gives the first SID. The PCC pushes the labels in any remaining 823 subobjects onto the packet (with the final subobject specifying 824 the bottom-of-stack label) and then directs the packet to the 825 segment identified by the first SID. 827 6.2.2.1. Handling Errors During SR-ERO Conversion 829 There are several errors that can occur during the process of 830 converting an SR-ERO sequence to an MPLS label stack and a next hop. 831 The PCC deals with them as follows. 833 o If the PCC cannot find a SID index in the SR-DB, it MUST send a 834 PCErr message with Error-Type = 10 ("Reception of an invalid 835 object") and Error-Value = TBD3 ("Unknown SID"). 837 o If the PCC cannot find an NAI in the SR-DB, it MUST send a PCErr 838 message with Error-Type = 10 ("Reception of an invalid object") 839 and Error-Value = TBD4 ("NAI cannot be resolved to a SID"). 841 o If the PCC needs to convert a SID into an MPLS label value but 842 cannot find the corresponding router's SRGB in the SR-DB, it MUST 843 send a PCErr message with Error-Type = 10 ("Reception of an 844 invalid object") and Error-Value = TBD5 ("Could not find SRGB"). 846 o If the PCC finds that a router's SRGB is not large enough for a 847 SID index value, it MUST send a PCErr message with Error-Type = 10 848 ("Reception of an invalid object") and Error-Value = TBD6 ("SID 849 index exceeds SRGB size"). 851 o If the PCC needs to convert a SID into an MPLS label value but 852 cannot find the corresponding router's SRLB in the SR-DB, it MUST 853 send a PCErr message with Error-Type = 10 ("Reception of an 854 invalid object") and Error-Value = TBD7 ("Could not find SRLB"). 856 o If the PCC finds that a router's SRLB is not large enough for a 857 SID index value, it MUST send a PCErr message with Error-Type = 10 858 ("Reception of an invalid object") and Error-Value = TBD8 ("SID 859 index exceeds SRLB size"). 861 o If the number of labels in the computed label stack exceeds the 862 maximum number of SIDs that the PCC can impose on the packet, it 863 MUST send a PCErr message with Error-Type = 10 ("Reception of an 864 invalid object") and Error-Value = 3 ("Unsupported number of 865 Segment ERO subobjects"). 867 If an ERO specifies a new SR-TE path for an existing LSP and the PCC 868 encounters an error while processing the ERO, then the PCC MUST NOT 869 update the LSP. 871 6.3. RRO Processing 873 The syntax checking rules that apply to the SR-RRO subobject are 874 identical to those of the SR-ERO subobject, except as noted below. 876 If a PCEP speaker receives an SR-RRO subobject in which both SID and 877 NAI are absent, it MUST consider the entire RRO invalid and send a 878 PCErr message with Error-Type = 10 ("Reception of an invalid object") 879 and Error-Value = 7 ("Both SID and NAI are absent in SR-RRO 880 subobject"). 882 If a PCE detects that the subobjects of an RRO are a mixture of SR- 883 RRO subobjects and subobjects of other types, then it MUST send a 884 PCErr message with Error-Type = 10 ("Reception of an invalid object") 885 and Error-Value = 10 ("RRO mixes SR-RRO subobjects with other 886 subobject types"). 888 The SR-RRO subobjects can be classified according to whether they 889 contain a SID representing an MPLS label value or a SID representing 890 an index value, or no SID. If a PCE detects that the SR-RRO 891 subobjects are a mixture of more than one of these types, then it 892 MUST send a PCErr message with Error-Type = 10 ("Reception of an 893 invalid object") and Error-Value = TBD9 ("Inconsistent SIDs in SR-ERO 894 / SR-RRO subobjects"). 896 7. Backward Compatibility 898 A PCEP speaker that does not support the SR PCEP capability cannot 899 recognize the SR-ERO or SR-RRO subobjects. As such, it responds 900 according to the rules for a malformed object, per [RFC5440]. 902 Some implementations, which are compliant with an earlier version of 903 this specification, do not send the PATH-SETUP-TYPE-CAPABILITY TLV in 904 their OPEN objects. Instead, to indicate that they support SR, these 905 implementations include the SR-CAPABILITY-TLV as a top-level TLV in 906 the OPEN object. Unfortunately, some of these implementations made 907 it into the field before this document was published in its final 908 form. Therefore, if a PCEP speaker receives an OPEN object in which 909 the SR-CAPABILITY-TLV appears as a top-level TLV, then it MUST 910 interpret this as though the sender had sent a PATH-SETUP-TYPE- 911 CAPABILITY TLV with a PST list of (0, 1) (that is, both RSVP-TE and 912 SR-TE PSTs are supported) and with the SR-CAPABILITY-TLV as a sub- 913 TLV. If a PCEP speaker receives an OPEN object in which both the SR- 914 CAPABILITY-TLV and PATH-SETUP-TYPE-CAPABILITY TLV appear as top-level 915 TLVs, then it MUST ignore the top-level SR-CAPABILITY-TLV and process 916 only the PATH-SETUP-TYPE-CAPABILITY TLV. 918 8. Management Considerations 920 This document adds a new path setup type to PCEP to allow LSPs to be 921 set up using segment routing techniques. This path setup type may be 922 used with PCEP alongside other path setup types, such as RSVP-TE, or 923 it may be used exclusively. 925 8.1. Controlling the Path Setup Type 927 The following factors control which path setup type is used for a 928 given LSP. 930 o The available path setup types are constrained to those that are 931 supported by, or enabled on, the PCEP speakers. The PATH-SETUP- 932 TYPE-CAPABILITY TLV indicates which path setup types a PCEP 933 speaker supports. To use segment routing as a path setup type, it 934 is a prerequisite that the PCC and PCE both include PST=1 in the 935 list of supported path setup types in this TLV, and also include 936 the SR-PCE-CAPABILITY sub-TLV. 938 o When a PCE initiates an LSP, it proposes which path setup type to 939 use by including it in the PATH-SETUP-TYPE TLV in the SRP object 940 of the PCInitiate message. The PCE chooses the path setup type 941 based on the capabilities of the network nodes on the path and on 942 its local policy. The PCC MAY choose to accept the proposed path 943 setup type, or to reject the PCInitiate request, based on its 944 local policy. 946 o When a PCC requests a path for an LSP, it can nominate a preferred 947 path setup type by including it in the PATH-SETUP-TYPE TLV in the 948 RP object of the PCReq message. The PCE MAY choose to reply with 949 a path of the requested type, or to reply with a path of a 950 different type, or to reject the request, based on the 951 capabilities of the network nodes on the path and on its local 952 policy. 954 The operator can influence the path setup type as follows. 956 o Implementations MUST allow the operator to enable and disable the 957 segment routing path setup type on a PCEP-speaking device. 958 Implementations MAY also allow the operator to enable and disable 959 the RSVP-TE path setup type. 961 o PCE implementations MUST allow the operator to specify that an LSP 962 should be instantiated using segment routing or RSVP-TE as the 963 proposed path setup type. 965 o PCE implementations MAY allow the operator to configure a 966 preference for the PCE to propose paths using segment routing or 967 RSVP-TE in the absence of a specified path setup type. 969 o PCC implementations MUST allow the operator to specify that a path 970 requested for an LSP nominates segment routing or RSVP-TE as the 971 path setup type. 973 o PCC implementations MAY allow the operator to configure a 974 preference for the PCC to nominate segment routing or RSVP-TE as 975 the path setup type if none is specified for an LSP. 977 o PCC implementations SHOULD allow the operator to configure a PCC 978 to refuse to set up an LSP using an undesired path setup type. 980 8.2. Migrating a Network to Use PCEP Segment Routed Paths 982 This section discusses the steps that the operator takes when 983 migrating a network to enable PCEP to set up paths using segment 984 routing as the path setup type. 986 o The operator enables the segment routing PST on the PCE servers. 988 o The operator enables the segment routing PST on the PCCs. 990 o The operator resets each PCEP session. The PCEP sessions come 991 back up with segment routing enabled. 993 o If the operator detects a problem, they can roll the network back 994 to its initial state by disabling the segment routing PST on the 995 PCEP speakers and resetting the PCEP sessions. 997 Note that the data plane is unaffected if a PCEP session is reset. 998 Any LSPs that were set up before the session reset will remain in 999 place and will still be present after the session comes back up. 1001 An implementation SHOULD allow the operator to manually trigger a 1002 PCEP session to be reset. 1004 An implementation MAY automatically reset a PCEP session when an 1005 operator reconfigures the PCEP speaker's capabilities. However, note 1006 that if the capabilities at both ends of the PCEP session are not 1007 reconfigured simultaneously, then the session could be reset twice, 1008 which could lead to unnecessary network traffic. Therefore, such 1009 implementations SHOULD allow the operator to override this behaviour 1010 and wait instead for a manual reset. 1012 Once segment routing is enabled on a PCEP session, it can be used as 1013 the path setup type for future LSPs. 1015 User traffic is not automatically migrated from existing LSPs onto 1016 segment routed LSPs just by enabling the segment routing PST in PCEP. 1017 The migration of user traffic from existing LSPs onto segment routing 1018 LSPs is beyond the scope of this document. 1020 8.3. Verification of Network Operation 1022 The operator needs the following information to verify that PCEP is 1023 operating correctly with respect to the segment routing path setup 1024 type. 1026 o An implementation SHOULD allow the operator to view whether the 1027 PCEP speaker sent the segment routing PST capability to its peer. 1028 If the PCEP speaker is a PCC, then the implementation SHOULD also 1029 allow the operator to view the values of the L and N flags that 1030 were sent, and the value of the MSD field that was sent. 1032 o An implementation SHOULD allow the operator to view whether the 1033 peer sent the segment routing PST capability. If the peer is a 1034 PCC, then the implementation SHOULD also allow the operator to 1035 view the values of the L and N flags and MSD fields that the peer 1036 sent. 1038 o An implementation SHOULD allow the operator to view whether the 1039 segment routing PST is enabled on the PCEP session. 1041 o If one PCEP speaker advertises the segment routing PST capability, 1042 but the other does not, then the implementation SHOULD create a 1043 log to inform the operator of the capability mismatch. 1045 o An implementation SHOULD allow the operator to view the PST that 1046 was proposed, or requested, for an LSP, and the PST that was 1047 actually used. 1049 o If a PCEP speaker decides to use a different PST to the one that 1050 was proposed, or requested, for an LSP, then the implementation 1051 SHOULD create a log to inform the operator that the expected PST 1052 has not been used. The log SHOULD give the reason for this choice 1053 (local policy, equipment capability etc.) 1055 o If a PCEP speaker rejects a segment routed path, then it SHOULD 1056 create a log to inform the operator, giving the reason for the 1057 decision (local policy, MSD exceeded etc.) 1059 8.4. Relationship to Existing Management Models 1061 The PCEP YANG module [I-D.ietf-pce-pcep-yang] should include: 1063 o advertised PST capabilities and MSD per PCEP session. 1065 o the PST configured for, and used by, each LSP. 1067 The PCEP MIB [RFC7420] could also be updated to include this 1068 information. 1070 9. Security Considerations 1072 The security considerations described in [RFC5440], [RFC8281] and 1073 [RFC8408] are applicable to this specification. No additional 1074 security measure is required. 1076 Note that this specification enables a network controller to 1077 instantiate a path in the network without the use of a hop-by-hop 1078 signaling protocol (such as RSVP-TE). This creates an additional 1079 vulnerability if the security mechanisms of [RFC5440] and [RFC8281] 1080 are not used, because an attacker could create a path which is not 1081 subjected to the further verification checks that would be performed 1082 by the signaling protocol. 1084 Note that this specification adds the MSD field to the OPEN message 1085 (see Section 5.1.1) which discloses how many MPLS labels the sender 1086 can push onto packets that it forwards into the network. If the 1087 security mechanisms of [RFC5440] and [RFC8281] are not used then an 1088 attacker could use this new field to gain intelligence about the 1089 capabilities of the edge devices in the network. 1091 10. IANA Considerations 1093 10.1. PCEP ERO and RRO subobjects 1095 This document defines a new subobject type for the PCEP explicit 1096 route object (ERO), and a new subobject type for the PCEP record 1097 route object (RRO). The code points for subobject types of these 1098 objects is maintained in the RSVP parameters registry, under the 1099 EXPLICIT_ROUTE and ROUTE_RECORD objects. IANA is requested to 1100 confirm the early allocation of the following code points in the RSVP 1101 Parameters registry for each of the new subobject types defined in 1102 this document. 1104 Object Subobject Subobject Type 1105 --------------------- -------------------------- ------------------ 1106 EXPLICIT_ROUTE SR-ERO (PCEP-specific) 36 1107 ROUTE_RECORD SR-RRO (PCEP-specific) 36 1109 10.2. New NAI Type Registry 1111 IANA is requested to create a new sub-registry within the "Path 1112 Computation Element Protocol (PCEP) Numbers" registry called "PCEP 1113 SR-ERO NAI Types". The allocation policy for this new registry 1114 should be by IETF Review. The new registry should contain the 1115 following values: 1117 Value Description Reference 1119 0 NAI is absent. This document 1120 1 NAI is an IPv4 node ID. This document 1121 2 NAI is an IPv6 node ID. This document 1122 3 NAI is an IPv4 adjacency. This document 1123 4 NAI is an IPv6 adjacency. This document 1124 5 NAI is an unnumbered This document 1125 adjacency with IPv4 node IDs. 1127 10.3. New SR-ERO Flag Registry 1129 IANA is requested to create a new sub-registry, named "SR-ERO Flag 1130 Field", within the "Path Computation Element Protocol (PCEP) Numbers" 1131 registry to manage the Flag field of the SR-ERO subobject. New 1132 values are to be assigned by Standards Action [RFC8126]. Each bit 1133 should be tracked with the following qualities: 1135 o Bit number (counting from bit 0 as the most significant bit) 1137 o Capability description 1138 o Defining RFC 1140 The following values are defined in this document: 1142 Bit Description Reference 1144 0-7 Unassigned 1145 8 NAI is absent (F) This document 1146 9 SID is absent (S) This document 1147 10 SID specifies TC, S This document 1148 and TTL in addition 1149 to an MPLS label (C) 1150 11 SID specifies an MPLS This document 1151 label (M) 1153 10.4. PCEP-Error Object 1155 IANA is requested to confirm the early allocation of the code-points 1156 in the PCEP-ERROR Object Error Types and Values registry for the 1157 following new error-values: 1159 Error-Type Meaning 1160 ---------- ------- 1161 10 Reception of an invalid object. 1163 Error-value = 2: Bad label value 1164 Error-value = 3: Unsupported number 1165 of SR-ERO 1166 subobjects 1167 Error-value = 4: Bad label format 1168 Error-value = 5: ERO mixes SR-ERO 1169 subobjects with 1170 other subobject 1171 types 1172 Error-value = 6: Both SID and NAI 1173 are absent in SR- 1174 ERO subobject 1175 Error-value = 7: Both SID and NAI 1176 are absent in SR- 1177 RRO subobject 1178 Error-value = 9: MSD exceeds the 1179 default for the 1180 PCEP session 1181 Error-value = 10: RRO mixes SR-RRO 1182 subobjects with 1183 other subobject 1184 types 1186 Error-value = TBD1: Missing PCE-SR- 1187 CAPABILITY sub-TLV 1188 Error-value = TBD2: Unsupported NAI 1189 Type in SR-ERO 1190 subobject 1191 Error-value = TBD3: Unknown SID 1192 Error-value = TBD4: NAI cannot be 1193 resolved to a SID 1194 Error-value = TBD5: Could not find SRGB 1195 Error-value = TBD6: SID index exceeds 1196 SRGB size 1197 Error-value = TBD7: Could not find SRLB 1198 Error-value = TBD8: SID index exceeds 1199 SRLB size 1200 Error-value = TBD9: Inconsistent SIDs 1201 in SR-ERO / SR-RRO 1202 subobjects 1204 Note to IANA: this draft originally had an early allocation for 1205 Error-value=11 (Malformed object) in the above list. However, we 1206 have since moved the definition of that code point to RFC8408. 1208 Note to IANA: some Error-values in the above list were defined after 1209 the early allocation took place, and so do not currently have a code 1210 point assigned. Please assign code points from the indicated 1211 registry and replace each instance of "TBD1", "TBD2" etc. in this 1212 document with the respective code points. 1214 Note to IANA: some of the Error-value descriptive strings above have 1215 changed since the early allocation. Please refresh the registry. 1217 10.5. PCEP TLV Type Indicators 1219 IANA is requested to confirm the early allocation of the following 1220 code point in the PCEP TLV Type Indicators registry. 1222 Value Meaning Reference 1223 ------------------------- ---------------------------- -------------- 1224 26 SR-PCE-CAPABILITY This document 1226 10.6. New Path Setup Type 1228 [RFC8408] requests that IANA creates a sub-registry within the "Path 1229 Computation Element Protocol (PCEP) Numbers" registry called "PCEP 1230 Path Setup Types". IANA is requested to allocate a new code point 1231 within this registry, as follows: 1233 Value Description Reference 1234 ------------------------- ---------------------------- -------------- 1235 1 Traffic engineering path is This document 1236 setup using Segment Routing. 1238 10.7. New Metric Type 1240 IANA is requested to confirm the early allocation of the following 1241 code point in the PCEP METRIC object T field registry: 1243 Value Description Reference 1244 ------------------------- ---------------------------- -------------- 1245 11 Segment-ID (SID) Depth. This document 1247 10.8. SR PCE Capability Flags 1249 IANA is requested to create a new sub-registry, named "SR Capability 1250 Flag Field", within the "Path Computation Element Protocol (PCEP) 1251 Numbers" registry to manage the Flag field of the SR-PCE-CAPABILITY 1252 TLV. New values are to be assigned by Standards Action [RFC8126]. 1253 Each bit should be tracked with the following qualities: 1255 o Bit number (counting from bit 0 as the most significant bit) 1256 o Capability description 1257 o Defining RFC 1259 The following values are defined in this document: 1261 Bit Description Reference 1263 0-5 Unassigned 1264 6 Node or Adjacency This document 1265 Identifier (NAI) is 1266 supported (N) 1267 7 Unlimited Maximum SID This document 1268 Depth (L) 1270 11. Contributors 1272 The following people contributed to this document: 1274 - Lakshmi Sharma 1275 - Jan Medved 1276 - Edward Crabbe 1277 - Robert Raszuk 1278 - Victor Lopez 1280 12. Acknowledgements 1282 We thank Ina Minei, George Swallow, Marek Zavodsky, Dhruv Dhody, Ing- 1283 Wher Chen and Tomas Janciga for the valuable comments. 1285 13. References 1287 13.1. Normative References 1289 [I-D.ietf-idr-bgp-ls-segment-routing-msd] 1290 Tantsura, J., Chunduri, U., Mirsky, G., and S. Sivabalan, 1291 "Signaling MSD (Maximum SID Depth) using Border Gateway 1292 Protocol Link-State", draft-ietf-idr-bgp-ls-segment- 1293 routing-msd-02 (work in progress), August 2018. 1295 [I-D.ietf-isis-segment-routing-extensions] 1296 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 1297 Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, 1298 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 1299 segment-routing-extensions-19 (work in progress), July 1300 2018. 1302 [I-D.ietf-isis-segment-routing-msd] 1303 Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 1304 "Signaling MSD (Maximum SID Depth) using IS-IS", draft- 1305 ietf-isis-segment-routing-msd-16 (work in progress), 1306 September 2018. 1308 [I-D.ietf-ospf-segment-routing-extensions] 1309 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1310 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1311 Extensions for Segment Routing", draft-ietf-ospf-segment- 1312 routing-extensions-25 (work in progress), April 2018. 1314 [I-D.ietf-ospf-segment-routing-msd] 1315 Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 1316 "Signaling MSD (Maximum SID Depth) using OSPF", draft- 1317 ietf-ospf-segment-routing-msd-20 (work in progress), 1318 August 2018. 1320 [I-D.ietf-pce-pcep-yang] 1321 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1322 YANG Data Model for Path Computation Element 1323 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1324 yang-08 (work in progress), June 2018. 1326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1327 Requirement Levels", BCP 14, RFC 2119, 1328 DOI 10.17487/RFC2119, March 1997, 1329 . 1331 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1332 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1333 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 1334 . 1336 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1337 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1338 DOI 10.17487/RFC5440, March 2009, 1339 . 1341 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1342 Hardwick, "Path Computation Element Communication Protocol 1343 (PCEP) Management Information Base (MIB) Module", 1344 RFC 7420, DOI 10.17487/RFC7420, December 2014, 1345 . 1347 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1348 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1349 May 2017, . 1351 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1352 Computation Element Communication Protocol (PCEP) 1353 Extensions for Stateful PCE", RFC 8231, 1354 DOI 10.17487/RFC8231, September 2017, 1355 . 1357 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1358 Computation Element Communication Protocol (PCEP) 1359 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1360 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1361 . 1363 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1364 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1365 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1366 July 2018, . 1368 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 1369 Hardwick, "Conveying Path Setup Type in PCE Communication 1370 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 1371 July 2018, . 1373 13.2. Informative References 1375 [I-D.ietf-6man-segment-routing-header] 1376 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 1377 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 1378 (SRH)", draft-ietf-6man-segment-routing-header-14 (work in 1379 progress), June 2018. 1381 [I-D.ietf-spring-segment-routing-mpls] 1382 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 1383 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1384 data plane", draft-ietf-spring-segment-routing-mpls-14 1385 (work in progress), June 2018. 1387 [I-D.ietf-spring-segment-routing-policy] 1388 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 1389 bogdanov@google.com, b., and P. Mattes, "Segment Routing 1390 Policy Architecture", draft-ietf-spring-segment-routing- 1391 policy-01 (work in progress), June 2018. 1393 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1394 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1395 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1396 . 1398 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 1399 Element (PCE) Communication Protocol Generic 1400 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 1401 2006, . 1403 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1404 Writing an IANA Considerations Section in RFCs", BCP 26, 1405 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1406 . 1408 Authors' Addresses 1410 Siva Sivabalan 1411 Cisco Systems, Inc. 1412 2000 Innovation Drive 1413 Kanata, Ontario K2K 3E8 1414 Canada 1416 Email: msiva@cisco.com 1417 Clarence Filsfils 1418 Cisco Systems, Inc. 1419 Pegasus Parc 1420 De kleetlaan 6a, DIEGEM BRABANT 1831 1421 BELGIUM 1423 Email: cfilsfil@cisco.com 1425 Jeff Tantsura 1426 Individual 1427 444 San Antonio Rd, 10A 1428 Palo Alto, CA 94306 1429 USA 1431 Email: jefftant.ietf@gmail.com 1433 Wim Henderickx 1434 Nokia 1435 Copernicuslaan 50 1436 Antwerp 2018, CA 95134 1437 BELGIUM 1439 Email: wim.henderickx@alcatel-lucent.com 1441 Jon Hardwick 1442 Metaswitch Networks 1443 100 Church Street 1444 Enfield, Middlesex 1445 UK 1447 Email: jonathan.hardwick@metaswitch.com