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