idnits 2.17.1 draft-ietf-pce-segment-routing-10.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 == Line 429 has weird spacing: '...L' Flag indic...' == Line 435 has weird spacing: '... Type is th...' == Line 438 has weird spacing: '... Length conta...' == Line 451 has weird spacing: '... Flags is us...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: As defined in [RFC5440], a PCEP message consists of a common header followed by a variable length body made up of mandatory and/or optional objects. This document does not require any changes in the format of PCReq and PCRep messages specified in [RFC5440], PCInitiate message specified in [I-D.ietf-pce-pce-initiated-lsp], and PCRpt and PCUpd messages specified in [I-D.ietf-pce-stateful-pce]. However, PCEP messages pertaining to SR-TE LSP MUST include PATH-SETUP-TYPE TLV in the RP or SRP object to clearly identify that SR-TE LSP is intended. In other words, a PCEP speaker MUST not infer whether or not a PCEP message pertains to SR-TE LSP from any other object or TLV. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The 'L' Flag indicates whether the subobject represents a loose-hop in the LSP [RFC3209]. If this flag is unset, a PCC MUST not overwrite the SID value present in the SR-ERO subobject. Otherwise, a PCC MAY expand or replace one or more SID value(s) in the received SR-ERO based on its local policy. -- The document date (October 10, 2017) is 2389 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC7420' is defined on line 849, but no explicit reference was found in the text == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-11 == Outdated reference: A later version (-19) exists of draft-ietf-isis-segment-routing-msd-03 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-12 == Outdated reference: A later version (-25) exists of draft-ietf-ospf-segment-routing-msd-04 == Outdated reference: A later version (-10) exists of draft-ietf-pce-lsp-setup-type-03 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-09 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-18 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-11 == Outdated reference: A later version (-05) exists of draft-tantsura-idr-bgp-ls-segment-routing-msd-02 Summary: 0 errors (**), 0 flaws (~~), 17 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 13, 2018 J. Tantsura 6 Individual 7 W. Henderickx 8 Nokia 9 J. Hardwick 10 Metaswitch Networks 11 October 10, 2017 13 PCEP Extensions for Segment Routing 14 draft-ietf-pce-segment-routing-10 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 Protocol (PCEP) that allow a stateful PCE to 26 compute and initiate Traffic Engineering (TE) paths, as well as a PCC 27 to request a path subject to certain constraint(s) and optimization 28 criteria in SR networks. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in [RFC2119]. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on April 13, 2018. 53 Copyright Notice 55 Copyright (c) 2017 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. Overview of PCEP Operation in SR Networks . . . . . . . . . . 5 73 4. SR-Specific PCEP Message Extensions . . . . . . . . . . . . . 6 74 5. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 7 75 5.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 7 76 5.1.1. The SR PCE Capability TLV . . . . . . . . . . . . . . 7 77 5.2. The RP/SRP Object . . . . . . . . . . . . . . . . . . . . 8 78 5.3. ERO Object . . . . . . . . . . . . . . . . . . . . . . . 9 79 5.3.1. SR-ERO Subobject . . . . . . . . . . . . . . . . . . 9 80 5.3.2. NAI Associated with SID . . . . . . . . . . . . . . . 11 81 5.3.3. ERO Processing . . . . . . . . . . . . . . . . . . . 12 82 5.4. RRO Object . . . . . . . . . . . . . . . . . . . . . . . 13 83 5.4.1. RRO Processing . . . . . . . . . . . . . . . . . . . 14 84 5.5. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 14 85 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 15 86 7. Management Considerations . . . . . . . . . . . . . . . . . . 15 87 7.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 7.2. The PCEP Data Model . . . . . . . . . . . . . . . . . . . 15 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 91 9.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 16 92 9.2. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 16 93 9.3. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 17 94 9.4. New Path Setup Type . . . . . . . . . . . . . . . . . . . 17 95 9.5. New Metric Type . . . . . . . . . . . . . . . . . . . . . 17 97 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 98 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 99 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 100 12.1. Normative References . . . . . . . . . . . . . . . . . . 18 101 12.2. Informative References . . . . . . . . . . . . . . . . . 19 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 104 1. Introduction 106 SR technology leverages the source routing and tunneling paradigms. 107 A source node can choose a path without relying on hop-by-hop 108 signaling protocols such as LDP or RSVP-TE. Each path is specified 109 as a set of "segments" advertised by link-state routing protocols 110 (IS-IS or OSPF). [I-D.ietf-spring-segment-routing] provides an 111 introduction to SR architecture. The corresponding IS-IS and OSPF 112 extensions are specified in 113 [I-D.ietf-isis-segment-routing-extensions] and 114 [I-D.ietf-ospf-segment-routing-extensions], respectively. SR 115 architecture defines a "segment" as a piece of information advertised 116 by a link-state routing protocols, e.g. an IGP prefix or an IGP 117 adjacency. Several types of segments are defined. A Node segment 118 represents an ECMP-aware shortest-path computed by IGP to a specific 119 node, and is always global within SR/IGP domain. An Adjacency 120 Segment represents unidirectional adjacency. An Adjacency Segment is 121 local to the node which advertises it. Both Node segments and 122 Adjacency segments can be used for SR Traffic Engineering (SR-TE). 124 The SR architecture can be applied to the MPLS forwarding plane 125 without any change, in which case an SR path corresponds to an MPLS 126 Label Switching Path (LSP). This document is relevant to MPLS 127 forwarding plane only and assumes that a 32-bit Segment Identifier 128 (SID) represents an absolute value of MPLS label entry. In this 129 document, "Node-SID" and "Adjacency-SID" denote Node Segment 130 Identifier and Adjacency Segment Identifier respectively. 132 A Segment Routed path (SR path) can be derived from an IGP Shortest 133 Path Tree (SPT). SR-TE paths may not follow IGP SPT. Such paths may 134 be chosen by a suitable network planning tool and provisioned on the 135 ingress node of the SR-TE path. 137 [RFC5440] describes Path Computation Element Protocol (PCEP) for 138 communication between a Path Computation Client (PCC) and a Path 139 Computation Element (PCE) or between one a pair of PCEs. A PCE or a 140 PCC operating as a PCE (in hierarchical PCE environment) computes 141 paths for MPLS Traffic Engineering LSPs (MPLS-TE LSPs) based on 142 various constraints and optimization criteria. 143 [I-D.ietf-pce-stateful-pce] specifies extensions to PCEP that allow a 144 stateful PCE to compute and recommend network paths in compliance 145 with [RFC4657] and defines objects and TLVs for MPLS-TE LSPs. 146 Stateful PCEP extensions provide synchronization of LSP state between 147 a PCC and a PCE or between a pair of PCEs, delegation of LSP control, 148 reporting of LSP state from a PCC to a PCE, controlling the setup and 149 path routing of an LSP from a PCE to a PCC. Stateful PCEP extensions 150 are intended for an operational model in which LSPs are configured on 151 the PCC, and control over them is delegated to the PCE. 153 A mechanism to dynamically initiate LSPs on a PCC based on the 154 requests from a stateful PCE or a controller using stateful PCE is 155 specified in [I-D.ietf-pce-pce-initiated-lsp]. Such mechanism is 156 useful in Software Driven Networks (SDN) applications, such as on 157 demand engineering, or bandwidth calendaring. 159 It is possible to use a stateful PCE for computing one or more SR-TE 160 paths taking into account various constraints and objective 161 functions. Once a path is chosen, the stateful PCE can initiate an 162 SR-TE path on a PCC using PCEP extensions specified in 163 [I-D.ietf-pce-pce-initiated-lsp] using the SR specific PCEP 164 extensions specified in this document. Additionally, using 165 procedures described in this document, a PCC can request an SR path 166 from either stateful or a stateless PCE. This specification relies 167 on the PATH-SETUP-TYPE TLV and procedures specified in 168 [I-D.ietf-pce-lsp-setup-type]. 170 2. Terminology 172 The following terminologies are used in this document: 174 ERO: Explicit Route Object 176 IGP: Interior Gateway Protocol 178 IS-IS: Intermediate System to Intermediate System 180 LSR: Label Switching Router 182 MSD: Maximum SID Depth 184 NAI: Node or Adjacency Identifier 186 OSPF: Open Shortest Path First 188 PCC: Path Computation Client 190 PCE: Path Computation Element 192 PCEP: Path Computation Element Protocol 193 RRO: Record Route Object 195 SID: Segment Identifier 197 SR: Segment Routing 199 SR-TE: Segment Routed Traffic Engineering 201 TED: Traffic Engineering Database 203 3. Overview of PCEP Operation in SR Networks 205 In SR networks, an ingress node of an SR path appends all outgoing 206 packets with an SR header consisting of a list of SIDs (or MPLS 207 labels in the context of this document). The header has all 208 necessary information to guide the packets from the ingress node to 209 the egress node of the path, and hence there is no need for any 210 signaling protocol. 212 In a PCEP session, LSP information is carried in the Explicit Route 213 Object (ERO), which consists of a sequence of subobjects. Various 214 types of ERO subobjects have been specified in [RFC3209], [RFC3473], 215 and [RFC3477]. In SR networks, an ingress node of an SR path appends 216 all outgoing packets with an SR header consisting of a list of SIDs 217 (or MPLS labels in the context of this document). SR-TE LSPs 218 computed by a PCE can be represented in one of the following forms: 220 o An ordered set of IP address(es) representing network nodes/links: 221 In this case, the PCC needs to convert the IP address(es) into the 222 corresponding MPLS labels by consulting its Traffic Engineering 223 Database (TED). 225 o An ordered set of SID(s). 227 o An ordered set of both MPLS label(s) and IP address(es): In this 228 case, the PCC needs to convert the IP address(es) into the 229 corresponding SID(s) by consulting its TED. 231 This document defines a new ERO subobject denoted by "SR-ERO 232 subobject" capable of carrying a SID as well as the identity of the 233 node/adjacency represented by the SID. SR-capable PCEP speakers 234 should be able to generate and/or process such ERO subobject. An ERO 235 containing SR-ERO subobjects can be included in the PCEP Path 236 Computation Reply (PCRep) message defined in [RFC5440], the PCEP LSP 237 Initiate Request message (PCInitiate) defined in 238 [I-D.ietf-pce-pce-initiated-lsp], as well as in the PCEP LSP Update 239 Request (PCUpd) and PCEP LSP State Report (PCRpt) messages defined in 240 defined in [I-D.ietf-pce-stateful-pce]. 242 When a PCEP session between a PCC and a PCE is established, both PCEP 243 speakers exchange their capabilites to indicate their ability to 244 support SR-specific functionality. Furthermore, an LSP initially 245 established via RSVP-TE signaling can be updated with SR-TE path. 246 This capability is useful when a network is migrated from RSVP-TE to 247 SR-TE technology. Similarly, an LSP initially created with SR-TE 248 signaling can be updated using RSVP-TE if necessary. 250 A PCC MAY include an RRO object containing the recorded LSP in PCReq 251 and PCRpt messages as specified in [RFC5440] and 252 [I-D.ietf-pce-stateful-pce] respectively. This document defines a 253 new RRO subobject for SR networks. Methods used by a PCC to record 254 SR-TE LSP are outside the scope of this document. 256 In summary, this document: 258 o Defines a new PCEP capability, new ERO subobject, new RRO 259 subobject, a new TLV, and new PCEP error codes. 261 o Specifies how two PCEP speakers can establish a PCEP session that 262 can carry information about SR-TE paths. 264 o Specifies processing rules of ERO subobject. 266 o Defines a new path setup type carried in the PATH-SETUP-TYPE TLV 267 for SR-TE LSP. 269 The extensions specified in this document complement the existing 270 PCEP specifications to support SR-TE path. As such, the PCEP 271 messages (e.g., Path Computation Request, Path Computation Reply, 272 Path Computation Report, Path Computation Update, Path Computation 273 Initiate, etc.,) MUST be formatted according to [RFC5440], 274 [I-D.ietf-pce-stateful-pce], [I-D.ietf-pce-pce-initiated-lsp], and 275 any other applicable PCEP specifications. 277 4. SR-Specific PCEP Message Extensions 279 As defined in [RFC5440], a PCEP message consists of a common header 280 followed by a variable length body made up of mandatory and/or 281 optional objects. This document does not require any changes in the 282 format of PCReq and PCRep messages specified in [RFC5440], PCInitiate 283 message specified in [I-D.ietf-pce-pce-initiated-lsp], and PCRpt and 284 PCUpd messages specified in [I-D.ietf-pce-stateful-pce]. However, 285 PCEP messages pertaining to SR-TE LSP MUST include PATH-SETUP-TYPE 286 TLV in the RP or SRP object to clearly identify that SR-TE LSP is 287 intended. In other words, a PCEP speaker MUST not infer whether or 288 not a PCEP message pertains to SR-TE LSP from any other object or 289 TLV. 291 5. Object Formats 293 5.1. The OPEN Object 295 This document defines a new optional TLV for use in the OPEN Object. 297 5.1.1. The SR PCE Capability TLV 299 The SR-PCE-CAPABILITY TLV is an optional TLV associated with the OPEN 300 Object to exchange SR capability of PCEP speakers. The format of the 301 SR-PCE-CAPABILITY TLV is shown in the following figure: 303 0 1 2 3 304 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 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Type=TBD | Length=4 | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Reserved | Flags |L| MSD | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Figure 1: SR-PCE-CAPABILITY TLV format 313 The code point for the TLV type is to be defined by IANA. The TLV 314 length is 4 octets. 316 The 32-bit value is formatted as follows. The "Maximum SID Depth" (1 317 octet) field (MSD) specifies the maximum number of SIDs (MPLS label 318 stack depth in context of this document) that a PCC is capable of 319 imposing on a packet. The "Reserved" (2 octets) field is unused, and 320 MUST be set to zero on transmission and ignored on reception. The 321 "Flags" field is 1 octect long, and this document defines the 322 following flag: 324 o L-flag: A PCC sets this flag to 1 to indicate that it does not 325 impose any limit on MSD. 327 5.1.1.1. Exchanging SR Capability 329 By including the SR-PCE-CAPABILITY TLV in the OPEN message destined 330 to a PCE, a PCC indicates that it is capable of supporting the head- 331 end functions for SR-TE LSP. By including the TLV in the OPEN 332 message destined to a PCC, a PCE indicates that it is capable of 333 computing SR-TE paths. 335 The number of SIDs that can be imposed on a packet depends on PCC's 336 data plane's capability. An MSD value MUST be non-zero otherwise the 337 receiver of the SR-PCE-CAPABILITY TLV MUST assume that the sender is 338 not capable of imposing a MSD of any depth and hence is not SR-TE 339 capable. 341 Note that the MSD value exchanged via SR-PCE-CAPABILITY TLV indicates 342 the SID/label imposition limit for the PCC node. However, if a PCE 343 learns MSD value of a PCC node via different means, e.g routing 344 protocols, as specified in: [I-D.ietf-isis-segment-routing-msd]; 345 [I-D.ietf-ospf-segment-routing-msd]; 346 [I-D.tantsura-idr-bgp-ls-segment-routing-msd], then it ignores the 347 MSD value in the SR-PCE-CAPABILITY TLV. Furthermore, whenever a PCE 348 learns MSD for a link via different means, it MUST use that value for 349 that link regardless of the MSD value exchanged via SR-PCE-CAPABILITY 350 TLV. 352 Once an SR-capable PCEP session is established with a non-zero MSD 353 value, the corresponding PCE MUST NOT send SR-TE paths with number of 354 SIDs exceeding that MSD value. If a PCC needs to modify the MSD 355 value, the PCEP session MUST be closed and re-established with the 356 new MSD value. If a PCEP session is established with a non-zero MSD 357 value, and the PCC receives an SR-TE path containing more SIDs than 358 specified in the MSD value, the PCC MUST send a PCErr message with 359 Error-Type 10 (Reception of an invalid object) and Error-Value 3 360 (Unsupported number of Segment ERO). If a PCEP session is 361 established with an MSD value of zero, then the PCC MAY specify an 362 MSD for each path computation request that it sends to the PCE. 364 The MSD value inside SR Capability TLV is meaningful only in the OPEN 365 message sent from a PCC to a PCE. As such, a PCE does not need to 366 set MSD value in outbound message to a PCC. Similarly, a PCC ignores 367 any MSD value received from a PCE. If a PCE receives multiple SR- 368 PCE-CAPABILITY TLVs in an OPEN message, it processes only the first 369 TLV received. 371 5.2. The RP/SRP Object 373 In order to setup an SR-TE LSP using SR, RP or SRP object MUST 374 include PATH-SETUP-TYPE TLV specified in 375 [I-D.ietf-pce-lsp-setup-type]. This document defines a new Path 376 Setup Type (PST) for SR as follows: 378 o PST = 1: Path is setup using Segment Routing Traffic Engineering 379 technique. 381 LSP-IDENTIFIERS TLV MAY be present for the above PST type. 383 5.3. ERO Object 385 An SR-TE path consists of one or more SID(s) where each SID MAY be 386 associated with the identifier that represents the node or adjacency 387 corresponding to the SID. This identifier is referred to as the 388 'Node or Adjacency Identifier' (NAI). As described later, a NAI can 389 be represented in various formats (e.g., IPv4 address, IPv6 address, 390 etc). Furthermore, a NAI is used for troubleshooting purposes and, 391 if necessary, to derive SID value as described below. 393 The ERO object specified in [RFC5440] is used to carry SR-TE path 394 information. In order to carry SID and/or NAI, this document defines 395 a new ERO subobject referred to as "SR-ERO subobject" whose format is 396 specified in the following section. An ERO object carrying an SR-TE 397 path consists of one or more ERO subobject(s), and MUST carry only 398 SR-ERO subobject(s). Note that an SR-ERO subobject does not need to 399 have both SID and NAI. However, at least one of them MUST be 400 present. 402 When building the MPLS label stack from ERO, a PCC MUST assume that 403 SR-ERO subobjects are organized as a last-in-first-out stack. The 404 first subobject relative to the beginning of ERO contains the 405 information about the topmost label. The last subobject contains 406 information about the bottommost label. 408 5.3.1. SR-ERO Subobject 410 An SR-ERO subobject consists of a 32-bit header followed by the SID 411 and the NAI associated with the SID. The SID is a 32-bit number. 412 The size of the NAI depends on its respective type, as described in 413 the following sections. 415 0 1 2 3 416 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 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 |L| Type | Length | ST | Flags |F|S|C|M| 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | SID | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 // NAI (variable) // 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 Figure 2: SR-ERO Subobject format 427 The fields in the SR-ERO Subobject are as follows: 429 The 'L' Flag indicates whether the subobject represents a loose-hop 430 in the LSP [RFC3209]. If this flag is unset, a PCC MUST not 431 overwrite the SID value present in the SR-ERO subobject. 432 Otherwise, a PCC MAY expand or replace one or more SID value(s) in 433 the received SR-ERO based on its local policy. 435 Type is the type of the SR-ERO subobject. This document defines the 436 SR-ERO subobject type, and requests a new codepoint from IANA. 438 Length contains the total length of the subobject in octets, 439 including the L, Type and Length fields. Length MUST be at least 440 8, and MUST be a multiple of 4. As mentioned earlier, an SR-ERO 441 subobject MUST have at least SID or NAI. The length should take 442 into consideration SID or NAI only if they are not null. The 443 flags described below used to indicate whether SID or NAI field is 444 null. 446 SID Type (ST) indicates the type of information associated with the 447 SID contained in the object body. When ST value is 0, SID MUST 448 NOT be null and NAI MUST be null. Other ST values are described 449 later in this document. 451 Flags is used to carry any additional information pertaining to SID. 452 Currently, the following flag bits are defined: 454 * M: When this bit is set, the SID value represents an MPLS label 455 stack entry as specified in [RFC5462] where only the label 456 value is specified by the PCE. Other fields (TC, S, and TTL) 457 fields MUST be considered invalid, and PCC MUST set these 458 fields according to its local policy and MPLS forwarding rules. 460 * C: When this bit as well as the M bit are set, then the SID 461 value represents an MPLS label stack entry as specified in 462 [RFC5462], where all the entry's fields (Label, TC, S, and TTL) 463 are specified by the PCE. However, a PCC MAY choose to 464 override TC, S, and TTL values according its local policy and 465 MPLS forwarding rules. 467 * S: When this bit is set, the SID value in the subobject body is 468 null. In this case, the PCC is responsible for choosing the 469 SID value, e.g., by looking up its TED using the NAI which, in 470 this case, MUST be present in the subobject. 472 * F: When this bit is set, the NAI value in the subobject body is 473 null. 475 SID is the Segment Identifier. 477 NAI contains the NAI associated with the SID. Depending on the 478 value of ST, the NAI can have different format as described in the 479 following section. 481 5.3.2. NAI Associated with SID 483 This document defines the following NAIs: 485 'IPv4 Node ID' is specified as an IPv4 address. In this case, ST 486 value is 1, and the Length is 8 or 12 depending on either SID or 487 NAI or both are included in the subobject. 489 'IPv6 Node ID' is specified as an IPv6 address. In this case, ST 490 and Length are 2, and Length is 8, 20, or 24 depending on either 491 SID or NAI or both are included in the subobject. 493 'IPv4 Adjacency' is specified as a pair of IPv4 addresses. In this 494 case, ST value is 3. The Length is 8, 12, or 16 depending on 495 either SID or NAI or both are included in the subobject, and the 496 format of the NAI is shown in the following figure: 498 0 1 2 3 499 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 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Local IPv4 address | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Remote IPv4 address | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 Figure 3: NAI for IPv4 Adjacency 508 'IPv6 Adjacency' is specified as a pair of IPv6 addresses. In this 509 case, ST valie is 4. The Length is 8, 36 or 40 depending on 510 whether SID or NAI or both included in the subobject,and the 511 format of the NAI is shown in the following figure: 513 0 1 2 3 514 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 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 // Local IPv6 address (16 bytes) // 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 // Remote IPv6 address (16 bytes) // 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 Figure 4: NAI for IPv6 adjacenc y 523 'Unnumbered Adjacency with IPv4 NodeIDs' is specified as a pair of 524 Node ID / Interface ID tuples. In this case, ST value is 5. The 525 Length is 8, 20, or 24 depending on whether SID or NAI or both 526 included in the subobject, and the format of the NAI is shown in 527 the following figure: 529 0 1 2 3 530 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 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Local Node-ID | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Local Interface ID | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Remote Node-ID | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Remote Interface ID | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 Figure 5: NAI for Unnumbered adjacency with IPv4 Node IDs 543 5.3.3. ERO Processing 545 A PCEP speaker that does not recognize the SR-ERO subobject in PCRep, 546 PCInitiate, PCUpd or PCRpt messages MUST reject the entire PCEP 547 message and MUST send a PCErr message with Error-Type=3 ("Unknown 548 Object") and Error-Value=2 ("Unrecognized object Type") or Error- 549 Type=4 ("Not supported object") and Error-Value=2 ("Not supported 550 object Type"), defined in [RFC5440]. 552 When the SID represents an MPLS label (i.e. the M bit is set), its 553 value (20 most significant bits) MUST be larger than 15, unless it is 554 special purpose label, such as an Entropy Label Indicator (ELI). If 555 a PCEP speaker receives an invalid value, it MUST send a PCErr 556 message with Error-Type = 10 ("Reception of an invalid object") and 557 Error Value = TBD ("Bad label value"). If both M and C bits of an 558 SR-ERO subobject are set, and if a PCEP speaker finds erroneous 559 setting in one or more of TC, S, and TTL fields, it MUST send a PCErr 560 message with Error-Type = 10 ("Reception of an invalid object") and 561 Error-Value = TBD ("Bad label format"). 563 If a PCC receives a stack of SR-ERO subobjects, and the number of 564 stack exceeds the maximum number of SIDs that the PCC can impose on 565 the packet, it MAY send a PCErr message with Error-Type = 10 566 ("Reception of an invalid object") and Error-Value = TBD 567 ("Unsupported number of Segment ERO subobjects"). 569 When a PCEP speaker detects that all subobjects of ERO are not 570 identical, and if it does not handle such ERO, it MUST send a PCErr 571 message with Error-Type = 10 ("Reception of an invalid object") and 572 Error-Value = TBD ("Non-identical ERO subobjects"). 574 If a PCEP speaker receives an SR-ERO subobject in which both SID and 575 NAI are absent, it MUST consider the entire ERO object invalid and 576 send a PCErr message with Error-Type = 10 ("Reception of an invalid 577 object") and Error-Value = TBD ("Both SID and NAI are absent in ERO 578 subobject"). 580 When a PCEP speaker receives an SR-ERO subobject in which ST is 0, 581 SID MUST be present and NAI MUST NOT be present(i.e., S-flag MUST be 582 0, F-flag MUST be 1, and the Length MUST be 8). Otherwise, it MUST 583 consider the entire ERO object invalid and send a PCErr message with 584 Error-Type = 10 ("Reception of an invalid object") and Error-Value = 585 TBD ("Malformed object"). The PCEP speaker MAY include the malformed 586 SR-ERO object in the PCErr message as well. 588 5.4. RRO Object 590 A PCC can record SR-TE LSP and report the LSP to a PCE via RRO. An 591 RRO object contains one or more subobjects called "SR-RRO subobjects" 592 whose format is shown below: 594 0 1 2 3 595 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 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Type | Length | ST | Flags |F|S|C|M| 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | SID | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 // NAI (variable) // 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 Figure 6: SR-RRO Subobject format 606 The format of SR-RRO subobject is the same as that of SR-ERO 607 subobject without L flag. 609 A PCC MUST assume that SR-RRO subobjects are organized such that the 610 first subobject relative to the beginning of RRO contains the 611 information about the topmost label, and the last subobject contains 612 information about the bottommost label of the SR-TE LSP. 614 5.4.1. RRO Processing 616 Processing rules of SR-RRO subobject are identical to those of SR-ERO 617 subobject. 619 If a PCEP speaker receives an SR-RRO subobject in which both SID and 620 NAI are absent, it MUST consider the entire RRO object invalid and 621 send a PCErr message with Error-Type = 10 ("Reception of an invalid 622 object") and Error-Value = TBD ("Both SID and NAI are absent in RRO 623 subobject"). 625 If a PCE detects that all subobjects of RRO are not identical, and if 626 it does not handle such RRO, it MUST send a PCErr message with Error- 627 Type = 10 ("Reception of an invalid object") and Error-Value = TBD 628 ("Non-identical RRO subobjects"). 630 5.5. METRIC Object 632 If a PCEP session is established with an MSD value of zero, then the 633 PCC MAY specify the MSD for an individual path computation request 634 using the METRIC object defined in [RFC5440]. This document defines 635 a new type for the METRIC object to be used for this purpose as 636 follows: 638 o T = TBD (suggested value 11): Maximum SID Depth of the requested 639 path. 641 The PCC sets the metric-value to the MSD for this path. The PCC MUST 642 set the B (bound) bit to 1 in the METRIC object, which specifies that 643 the SID depth for the computed path MUST NOT exceed the metric-value. 645 If a PCEP session is established with a non-zero MSD value, then the 646 PCC MUST NOT send an MSD METRIC object. If the PCE receives a path 647 computation request with an MSD METRIC object on a session with a 648 non-zero MSD value then it MUST consider the request invalid and send 649 a PCErr with Error-Type = 10 ("Reception of an invalid object") and 650 Error-Value TBD ("Default MSD is specified for the PCEP session"). 652 6. Backward Compatibility 654 A PCEP speaker that does not support the SR PCEP capability cannot 655 recognize the SR-ERO or SR-RRO subobjects. As such, it MUST send a 656 PCEP error with Error-Type = 4 (Not supported object) and Error-Value 657 = 2 (Not supported object Type) as per [RFC5440]. 659 7. Management Considerations 661 7.1. Policy 663 PCEP implementation: 665 o Can enable SR PCEP capability either by default or via explicit 666 configuration. 668 o May generate PCEP error due to unsupported number of SR-ERO or SR- 669 RRO subobjects either by default or via explicit configuration. 671 7.2. The PCEP Data Model 673 A PCEP MIB module is defined in [RFC7420]needs be extended to cover 674 additional functionality provided by [RFC5440] and 675 [I-D.ietf-pce-pce-initiated-lsp]. Such extension will cover the new 676 functionality specified in this document. 678 8. Security Considerations 680 The security considerations described in [RFC5440] and 681 [I-D.ietf-pce-pce-initiated-lsp] are applicable to this 682 specification. No additional security measure is required. 684 9. IANA Considerations 685 9.1. PCEP Objects 687 This document defines a new sub-object type for the PCEP explicit 688 route object (ERO), and a new sub-object type for the PCEP record 689 route object (RRO). The code points for sub-object types of these 690 objects is maintained in the RSVP parameters registry, under the 691 EXPLICIT_ROUTE and ROUTE_RECORD objects. IANA is requested to 692 allocate code points in the RSVP Parameters registry for each of the 693 new sub-object types defined in this document, as follows: 695 Object Sub-Object Sub-Object Type 696 --------------------- -------------------------- ------------------ 697 EXPLICIT_ROUTE SR-ERO (PCEP-specific) TBD (recommended 36) 698 ROUTE_RECORD SR-RRO (PCEP-specific) TBD (recommended 36) 700 9.2. PCEP-Error Object 702 IANA is requested to allocate code-points in the PCEP-ERROR Object 703 Error Types and Values registry for the following new error-values: 705 Error-Type Meaning 706 ---------- ------- 707 10 Reception of an invalid object. 709 Error-value = TBD (recommended 2): Bad label value 710 Error-value = TBD (recommended 3): Unsupported number 711 of Segment ERO 712 subobjects 713 Error-value = TBD (recommended 4): Bad label format 714 Error-value = TBD (recommended 5): Non-identical ERO 715 subobjects 716 Error-value = TBD (recommended 6): Both SID and NAI 717 are absent in ERO 718 subobject 719 Error-value = TBD (recommended 7): Both SID and NAI 720 are absent in RRO 721 subobject 722 Error-value = TBD (recommended 9): Default MSD is 723 specified for the 724 PCEP session 725 Error-value = TBD (recommended 10): Non-identical RRO 726 subobjects 727 Error-value = TBD (recommended 11): Malformed object 729 9.3. PCEP TLV Type Indicators 731 IANA is requested to allocate a new code point in the PCEP TLV Type 732 Indicators registry, as follows: 734 Value Meaning Reference 735 ------------------------- ---------------------------- -------------- 736 TBD (recommended 26) SR-PCE-CAPABILITY This document 738 9.4. New Path Setup Type 740 [I-D.ietf-pce-lsp-setup-type] defines the PATH-SETUP-TYPE TLV and 741 requests that IANA creates a registry to manage the value of the 742 PATH_SETUP_TYPE TLV's PST field. IANA is requested to allocate a new 743 code point in the PCEP PATH_SETUP_TYPE TLV PST field registry, as 744 follows: 746 Value Description Reference 747 ------------------------- ---------------------------- -------------- 748 1 Traffic engineering path is This document 749 setup using Segment Routing 750 technique. 752 9.5. New Metric Type 754 IANA is requested to allocate a new code point in the PCEP METRIC 755 object T field registry, as follows: 757 Value Description Reference 758 ------------------------- ---------------------------- -------------- 759 TBD (recommended 11) Segment-ID (SID) Depth. This document 761 10. Contributors 763 The following people contributed to this document: 765 - Lakshmi Sharma 766 - Jan Medved 767 - Edward Crabbe 768 - Robert Raszuk 769 - Victor Lopez 771 11. Acknowledgements 773 We like to thank Ina Minei, George Swallow, Marek Zavodsky, Dhruv 774 Dhody, Ing-Wher Chen and Tomas Janciga for the valuable comments. 776 12. References 778 12.1. Normative References 780 [I-D.ietf-isis-segment-routing-extensions] 781 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 782 Litkowski, S., Decraene, B., and j. jefftant@gmail.com, 783 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 784 segment-routing-extensions-11 (work in progress), March 785 2017. 787 [I-D.ietf-isis-segment-routing-msd] 788 Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 789 "Signaling MSD (Maximum SID Depth) using IS-IS", draft- 790 ietf-isis-segment-routing-msd-03 (work in progress), March 791 2017. 793 [I-D.ietf-ospf-segment-routing-extensions] 794 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 795 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 796 Extensions for Segment Routing", draft-ietf-ospf-segment- 797 routing-extensions-12 (work in progress), March 2017. 799 [I-D.ietf-ospf-segment-routing-msd] 800 Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 801 "Signaling MSD (Maximum SID Depth) using OSPF", draft- 802 ietf-ospf-segment-routing-msd-04 (work in progress), March 803 2017. 805 [I-D.ietf-pce-lsp-setup-type] 806 Sivabalan, S., Medved, J., Minei, I., Crabbe, E., Varga, 807 R., Tantsura, J., and J. Hardwick, "Conveying path setup 808 type in PCEP messages", draft-ietf-pce-lsp-setup-type-03 809 (work in progress), June 2015. 811 [I-D.ietf-pce-pce-initiated-lsp] 812 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 813 Extensions for PCE-initiated LSP Setup in a Stateful PCE 814 Model", draft-ietf-pce-pce-initiated-lsp-09 (work in 815 progress), March 2017. 817 [I-D.ietf-pce-stateful-pce] 818 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 819 Extensions for Stateful PCE", draft-ietf-pce-stateful- 820 pce-18 (work in progress), December 2016. 822 [I-D.ietf-spring-segment-routing] 823 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 824 and R. Shakir, "Segment Routing Architecture", draft-ietf- 825 spring-segment-routing-11 (work in progress), February 826 2017. 828 [I-D.tantsura-idr-bgp-ls-segment-routing-msd] 829 Tantsura, J., Chunduri, U., Mirsky, G., and S. Sivabalan, 830 "Signaling Maximum SID Depth using Border Gateway Protocol 831 Link-State", draft-tantsura-idr-bgp-ls-segment-routing- 832 msd-02 (work in progress), January 2017. 834 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 835 Requirement Levels", BCP 14, RFC 2119, 836 DOI 10.17487/RFC2119, March 1997, 837 . 839 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 840 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 841 DOI 10.17487/RFC5440, March 2009, 842 . 844 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 845 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 846 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 847 2009, . 849 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 850 Hardwick, "Path Computation Element Communication Protocol 851 (PCEP) Management Information Base (MIB) Module", 852 RFC 7420, DOI 10.17487/RFC7420, December 2014, 853 . 855 12.2. Informative References 857 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 858 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 859 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 860 . 862 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 863 Switching (GMPLS) Signaling Resource ReserVation Protocol- 864 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 865 DOI 10.17487/RFC3473, January 2003, 866 . 868 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 869 in Resource ReSerVation Protocol - Traffic Engineering 870 (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, 871 . 873 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 874 Element (PCE) Communication Protocol Generic 875 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 876 2006, . 878 Authors' Addresses 880 Siva Sivabalan 881 Cisco Systems, Inc. 882 2000 Innovation Drive 883 Kanata, Ontario K2K 3E8 884 Canada 886 Email: msiva@cisco.com 888 Clarence Filsfils 889 Cisco Systems, Inc. 890 Pegasus Parc 891 De kleetlaan 6a, DIEGEM BRABANT 1831 892 BELGIUM 894 Email: cfilsfil@cisco.com 896 Jeff Tantsura 897 Individual 898 444 San Antonio Rd, 10A 899 Palo Alto, CA 94306 900 USA 902 Email: jefftant.ietf@gmail.com 904 Wim Henderickx 905 Nokia 906 Copernicuslaan 50 907 Antwerp 2018, CA 95134 908 BELGIUM 910 Email: wim.henderickx@alcatel-lucent.com 911 Jon Hardwick 912 Metaswitch Networks 913 100 Church Street 914 Enfield, Middlesex 915 UK 917 Email: jon.hardwick@metaswitch.com