idnits 2.17.1 draft-ietf-pce-segment-routing-ipv6-00.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 == 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 number of SRv6 SIDs that can be imposed on a packet depends on the PCC's IPv6 data plane's capability. If a PCC sets the L flag to 1 then the MSD is not used and MUST not be included. If a PCE receives an SRv6-PCE-CAPABILITY sub-TLV with the L flag set to 1 then it MUST ignore any MSD-Type, MSD-Value fields and MUST assume that the sender can impose any length of SRH. If a PCC sets the L flag to zero, then it sets the SRv6 MSD-Type, MSD-Value fields that it can impose on a packet. If a PCE receives an SRv6-PCE-CAPABILITY sub-TLV with the L flag and SRv6 MSD-Type, MSD-Value fields both set to zero then it is considered as an error and the PCE MUST respond with a PCErr message (Error-Type=1 "PCEP session establishment failure" and Error-Value=1 "reception of an invalid Open message or a non Open message."). In case the MSD-Type in SRv6-PCE-CAPABILITY sub-TLV received by the PCE does not correspond to one of the SRv6 MSD types, the PCE MUST respond with a PCErr message (Error-Type=1 "PCEP session establishment failure" and Error-Value=1 "reception of an invalid Open message or a non Open message."). -- The document date (March 10, 2019) is 1871 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 (-26) exists of draft-ietf-6man-segment-routing-header-16 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-22 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-02 == Outdated reference: A later version (-07) exists of draft-li-ospf-ospfv3-srv6-extensions-03 == Outdated reference: A later version (-06) exists of draft-dawra-idr-bgpls-srv6-ext-05 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group M. Negi 3 Internet-Draft C. Li 4 Intended status: Standards Track Huawei Technologies 5 Expires: September 11, 2019 S. Sivabalan 6 Cisco Systems 7 P. Kaladharan 8 RtBrick Inc 9 March 10, 2019 11 PCEP Extensions for Segment Routing leveraging the IPv6 data plane 12 draft-ietf-pce-segment-routing-ipv6-00 14 Abstract 16 The Source Packet Routing in Networking (SPRING) architecture 17 describes how Segment Routing (SR) can be used to steer packets 18 through an IPv6 or MPLS network using the source routing paradigm. 19 Segment Routing (SR) enables any head-end node to select any path 20 without relying on a hop-by-hop signaling technique (e.g., LDP or 21 RSVP-TE). 23 It depends only on "segments" that are advertised by Link- State 24 IGPs. A Segment Routed Path can be derived from a variety of 25 mechanisms, including an IGP Shortest Path Tree (SPT), explicit 26 configuration, or a Path Computation Element (PCE). 28 Since, Segment Routing can be applied to both MPLS and IPv6 29 forwarding plane, a PCE should be able to compute SR-Path for both 30 MPLS and IPv6 forwarding plane. This draft describes the extensions 31 required for Segment Routing support for IPv6 data plane in Path 32 Computation Element communication Protocol (PCEP). 34 Requirements Language 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 37 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 38 "OPTIONAL" in this document are to be interpreted as described in BCP 39 14 [RFC2119] [RFC8174] when, and only when, they appear in all 40 capitals, as shown here. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on September 11, 2019. 59 Copyright Notice 61 Copyright (c) 2019 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (https://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 3. Overview of PCEP Operation in SRv6 Networks . . . . . . . . . 5 79 3.1. Operation Overview . . . . . . . . . . . . . . . . . . . 6 80 3.2. SRv6-Specific PCEP Message Extensions . . . . . . . . . . 6 81 3.3. Object Formats . . . . . . . . . . . . . . . . . . . . . 6 82 3.3.1. The OPEN Object . . . . . . . . . . . . . . . . . . . 6 83 3.3.1.1. The SRv6 PCE Capability sub-TLV . . . . . . . . . 6 84 3.3.1.2. Exchanging the SRv6 Capability . . . . . . . . . 8 85 3.3.2. The RP/SRP Object . . . . . . . . . . . . . . . . . . 9 86 3.3.3. ERO Object . . . . . . . . . . . . . . . . . . . . . 9 87 3.3.3.1. SR-ERO Subobject . . . . . . . . . . . . . . . . 10 88 3.3.3.2. ERO Processing . . . . . . . . . . . . . . . . . 12 89 3.3.4. RRO Object . . . . . . . . . . . . . . . . . . . . . 13 90 3.3.4.1. SR-RRO Subobject . . . . . . . . . . . . . . . . 13 91 3.4. Security Considerations . . . . . . . . . . . . . . . . . 14 92 3.5. IANA Considerations . . . . . . . . . . . . . . . . . . . 14 93 3.5.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . 14 94 3.5.1.1. ERROR Objects . . . . . . . . . . . . . . . . . . 14 95 3.5.1.2. TLV Type Indicators . . . . . . . . . . . . . . . 14 96 3.5.1.3. New Path Setup Type . . . . . . . . . . . . . . . 15 98 3.6. The NAI Type field . . . . . . . . . . . . . . . . . . . 15 99 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 100 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 101 5.1. Normative References . . . . . . . . . . . . . . . . . . 15 102 5.2. Informative References . . . . . . . . . . . . . . . . . 16 103 Appendix A. Contributor . . . . . . . . . . . . . . . . . . . . 19 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 106 1. Introduction 108 As per [RFC8402], with Segment Routing (SR), a node steers a packet 109 through an ordered list of instructions, called segments. A segment 110 can represent any instruction, topological or service-based. A 111 segment can have a semantic local to an SR node or global within an 112 SR domain. SR allows to enforce a flow through any path and service 113 chain while maintaining per-flow state only at the ingress node of 114 the SR domain. Segments can be derived from different components: 115 IGP, BGP, Services, Contexts, Locater, etc. The list of segment 116 forming the path is called the Segment List and is encoded in the 117 packet header. Segment Routing can be applied to the IPv6 118 architecture with the Segment Routing Header (SRH) 119 [I-D.ietf-6man-segment-routing-header]. A segment is encoded as an 120 IPv6 address. An ordered list of segments is encoded as an ordered 121 list of IPv6 addresses in the routing header. The active segment is 122 indicated by the Destination Address of the packet. Upon completion 123 of a segment, a pointer in the new routing header is incremented and 124 indicates the next segment. 126 Segment Routing use cases are described in [RFC7855] and [RFC8354]. 127 Segment Routing protocol extensions are defined in 128 [I-D.ietf-isis-segment-routing-extensions], and 129 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 131 As per [I-D.ietf-6man-segment-routing-header], an SRv6 Segment is a 132 128-bit value. "SRv6 SID" or simply "SID" are often used as a 133 shorter reference for "SRv6 Segment". Further details are in an 134 illustration provided in 135 [I-D.filsfils-spring-srv6-network-programming]. 137 The SR architecture can be applied to the MPLS forwarding plane 138 without any change, in which case an SR path corresponds to an MPLS 139 Label Switching Path (LSP). The SR is applied to IPV6 forwarding 140 plane using SRH. A SR path can be derived from an IGP Shortest Path 141 Tree (SPT), but SR-TE paths may not follow IGP SPT. Such paths may 142 be chosen by a suitable network planning tool, or a PCE and 143 provisioned on the ingress node. 145 [RFC5440] describes Path Computation Element communication Protocol 146 (PCEP) for communication between a Path Computation Client (PCC) and 147 a Path Computation Element (PCE) or between a pair of PCEs. A PCE or 148 a PCC operating as a PCE (in hierarchical PCE environment) computes 149 paths for MPLS Traffic Engineering LSPs (MPLS-TE LSPs) based on 150 various constraints and optimization criteria. [RFC8231] specifies 151 extensions to PCEP that allow a stateful PCE to compute and recommend 152 network paths in compliance with [RFC4657] and defines objects and 153 TLVs for MPLS-TE LSPs. Stateful PCEP extensions provide 154 synchronization of LSP state between a PCC and a PCE or between a 155 pair of PCEs, delegation of LSP control, reporting of LSP state from 156 a PCC to a PCE, controlling the setup and path routing of an LSP from 157 a PCE to a PCC. Stateful PCEP extensions are intended for an 158 operational model in which LSPs are configured on the PCC, and 159 control over them is delegated to the PCE. 161 A mechanism to dynamically initiate LSPs on a PCC based on the 162 requests from a stateful PCE or a controller using stateful PCE is 163 specified in [RFC8281]. As per [I-D.ietf-pce-segment-routing], it is 164 possible to use a stateful PCE for computing one or more SR-TE paths 165 taking into account various constraints and objective functions. 166 Once a path is chosen, the stateful PCE can initiate an SR-TE path on 167 a PCC using PCEP extensions specified in [RFC8281] using the SR 168 specific PCEP extensions specified in [I-D.ietf-pce-segment-routing]. 169 [I-D.ietf-pce-segment-routing] specifies PCEP extensions for 170 supporting a SR-TE LSP for MPLS data plane. This document extends 171 [I-D.ietf-pce-segment-routing] to support SR for IPv6 data plane. 172 Additionally, using procedures described in this document, a PCC can 173 request an SRv6 path from either stateful or a stateless PCE. This 174 specification relies on the PATH-SETUP-TYPE TLV and procedures 175 specified in [RFC8408]. 177 This specification provides a mechanism for a network controller 178 (acting as a PCE) to instantiate candidate paths for an SR Policy 179 onto a head-end node (acting as a PCC) using PCEP. For more 180 information on the SR Policy Architecture, see 181 [I-D.ietf-spring-segment-routing-policy]. 183 2. Terminology 185 This document uses the following terms defined in [RFC5440]: PCC, 186 PCE, PCEP Peer. 188 This document uses the following terms defined in [RFC8051]: Stateful 189 PCE, Delegation. 191 The message formats in this document are specified using Routing 192 Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. 194 NAI: Node or Adjacency Identifier. 196 PCC: Path Computation Client. 198 PCE: Path Computation Element. 200 PCEP: Path Computation Element Protocol. 202 SR: Segment Routing. 204 SID: Segment Identifier. 206 SRv6: Segment Routing for IPv6 forwarding plane. 208 SRH: IPv6 Segment Routing Header. 210 SR Path: IPv6 Segment (List of IPv6 SID representing a path in IPv6 211 SR domain) 213 3. Overview of PCEP Operation in SRv6 Networks 215 Basic operations for PCEP speakers is as per 216 [I-D.ietf-pce-segment-routing]. SRv6 Paths computed by a PCE can be 217 represented as an ordered list of SRv6 segments of 128-bit value. 218 "SRv6 SID" or simply "SID" are often used as a shorter reference for 219 "SRv6 Segment" in this document. 221 [I-D.ietf-pce-segment-routing] defined a new ERO subobject denoted by 222 "SR-ERO subobject" capable of carrying a SID as well as the identity 223 of the node/adjacency represented by the SID. SR-capable PCEP 224 speakers should be able to generate and/or process such ERO 225 subobject. An ERO containing SR-ERO subobjects can be included in 226 the PCEP Path Computation Reply (PCRep) message defined in [RFC5440], 227 the PCEP LSP Initiate Request message (PCInitiate) defined in 228 [RFC8281], as well as in the PCEP LSP Update Request (PCUpd) and PCEP 229 LSP State Report (PCRpt) messages defined in defined in [RFC8231]. 231 This document extends the "SR-ERO subobject" defined in 232 [I-D.ietf-pce-segment-routing] to carry IPv6 SID(s) (IPv6 Addresses). 233 SRv6-capable PCEP speakers MUST be able to generate and/or process 234 this. 236 When a PCEP session between a PCC and a PCE is established, both PCEP 237 speakers exchange their capabilities to indicate their ability to 238 support SRv6 specific functionality. 240 In summary, this document: 242 o Defines a new PCEP capability for SRv6 244 o Update the SR-ERO and SR-RRO sub-object for SRv6 246 o Defines a new path setup type carried in the PATH-SETUP-TYPE and 247 PATH-SETUP-TYPE-CAPABILITY TLVs. 249 3.1. Operation Overview 251 In SR networks, an ingress node of an SR path appends all outgoing 252 packets with an SR header consisting of a list of SIDs (IPv6 Prefix 253 in case of SRv6). The header has all necessary information to guide 254 the packets from the ingress node to the egress node of the path, and 255 hence there is no need for any signaling protocol. 257 For IPv6 in control plane with MPLS data-plane, mechanism remains 258 same as [I-D.ietf-pce-segment-routing] 260 This document describes extensions to SR path for IPv6 data plane. 261 SRv6 Path (i.e. ERO) consists of an ordered set of SRv6 SIDs(see 262 details in Figure 2). 264 A PCC or PCE indicates its ability to support SRv6 during the PCEP 265 session Initialization Phase via a new SRv6-PCE-CAPABILITY sub-TLV 266 (see details in Section 3.3.1.1). 268 3.2. SRv6-Specific PCEP Message Extensions 270 As defined in [RFC5440], a PCEP message consists of a common header 271 followed by a variable length body made up of mandatory and/or 272 optional objects. This document does not require any changes in the 273 format of PCReq and PCRep messages specified in [RFC5440], PCInitiate 274 message specified in [RFC8281], and PCRpt and PCUpd messages 275 specified in [RFC8231]. However, PCEP messages pertaining to SRv6 276 MUST include PATH-SETUP-TYPE TLV in the RP or SRP object to clearly 277 identify that SRv6 is intended. 279 3.3. Object Formats 281 3.3.1. The OPEN Object 283 3.3.1.1. The SRv6 PCE Capability sub-TLV 285 This document defines a new Path Setup Type (PST) [RFC8408] for SRv6, 286 as follows: 288 o PST = TBD2: Path is setup using SRv6. 290 A PCEP speaker SHOULD indicate its support of the function described 291 in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the 292 OPEN object with this new PST included in the PST list. 294 This document also defines the SRv6-PCE-CAPABILITY sub-TLV. PCEP 295 speakers use this sub-TLV to exchange information about their SRv6 296 capability. If a PCEP speaker includes PST=TBD2 in the PST List of 297 the PATH-SETUP-TYPE-CAPABILITY TLV then it MUST also include the 298 SRv6-PCE- CAPABILITY sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY 299 TLV. 301 The format of the SRv6-PCE-CAPABILITY sub-TLV is shown in the 302 following figure: 304 0 1 2 3 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Type=TBD1 | Length | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Reserved | Flags |L| 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | MSD-Type | MSD-Value | MSD-Type | MSD-Value | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 // ... // 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | MSD-Type | MSD-Value | Padding | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 Figure 1: SRv6-PCE-CAPABILITY sub-TLV format 320 The code point for the TLV type (TBD1) is to be defined by IANA. The 321 TLV length is variable. 323 The value comprise of - 325 Reserved: 2 octet, this field MUST be set to 0 on transmission, 326 and ignored on receipt. 328 Flags: 2 octet, one bit is currently assigned in this document. 330 L bit: A PCC sets this bit to 1 to indicate that it does not 331 impose any limit on MSD (irrespective of the MSD-Type). 333 Unassigned bits MUST be set to 0 and ignored on receipt. 335 A pair of (MSD-Type,MSD-Value): Where MSD-Type (1 octet) is as per 336 the IGP MSD Type registry created by [RFC8491] and populated with 337 SRv6 MSD types as per [I-D.bashandy-isis-srv6-extensions]; MSD- 338 Value (1 octet) is as per [RFC8491]. 340 The TLV format is compliant with the PCEP TLV format defined in 341 [RFC5440]. That is, the TLV is composed of 2 octets for the type, 2 342 octets specifying the TLV length, and a Value field. The Length 343 field defines the length of the value portion in octets. The TLV is 344 padded to 4-octet alignment, and padding is not included in the 345 Length field. The number of (MSD-Type,MSD-Value) pairs can be 346 determined from the Length field of the TLV. 348 3.3.1.2. Exchanging the SRv6 Capability 350 A PCC indicates that it is capable of supporting the head-end 351 functions for SRv6 by including the SRv6-PCE-CAPABILITY sub-TLV in 352 the Open message that it sends to a PCE. A PCE indicates that it is 353 capable of computing SRv6 paths by including the SRv6-PCE-CAPABILITY 354 sub-TLV in the Open message that it sends to a PCC. 356 If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a 357 PST list containing PST=TBD2, but the SRv6-PCE-CAPABILITY sub-TLV is 358 absent, then the PCEP speaker MUST send a PCErr message with Error- 359 Type 10 (Reception of an invalid object) and Error-Value TBD5 (to be 360 assigned by IANA) (Missing PCE-SRv6-CAPABILITY sub-TLV) and MUST then 361 close the PCEP session. If a PCEP speaker receives a PATH-SETUP- 362 TYPE-CAPABILITY TLV with a SRv6-PCE-CAPABILITY sub-TLV, but the PST 363 list does not contain PST=TBD2, then the PCEP speaker MUST ignore the 364 SRv6-PCE-CAPABILITY sub-TLV. 366 The number of SRv6 SIDs that can be imposed on a packet depends on 367 the PCC's IPv6 data plane's capability. If a PCC sets the L flag to 368 1 then the MSD is not used and MUST not be included. If a PCE 369 receives an SRv6-PCE-CAPABILITY sub-TLV with the L flag set to 1 then 370 it MUST ignore any MSD-Type, MSD-Value fields and MUST assume that 371 the sender can impose any length of SRH. If a PCC sets the L flag to 372 zero, then it sets the SRv6 MSD-Type, MSD-Value fields that it can 373 impose on a packet. If a PCE receives an SRv6-PCE-CAPABILITY sub-TLV 374 with the L flag and SRv6 MSD-Type, MSD-Value fields both set to zero 375 then it is considered as an error and the PCE MUST respond with a 376 PCErr message (Error-Type=1 "PCEP session establishment failure" and 377 Error-Value=1 "reception of an invalid Open message or a non Open 378 message."). In case the MSD-Type in SRv6-PCE-CAPABILITY sub-TLV 379 received by the PCE does not correspond to one of the SRv6 MSD types, 380 the PCE MUST respond with a PCErr message (Error-Type=1 "PCEP session 381 establishment failure" and Error-Value=1 "reception of an invalid 382 Open message or a non Open message."). 384 Note that the MSD-Type, MSD-Value exchanged via the SRv6-PCE- 385 CAPABILITY sub-TLV indicates the SRv6 SID imposition limit for the 386 PCC node. However, if a PCE learns these via different means, e.g 387 routing protocols, as specified in: 388 [I-D.li-ospf-ospfv3-srv6-extensions]; 389 [I-D.bashandy-isis-srv6-extensions]; [I-D.dawra-idr-bgpls-srv6-ext], 390 then it ignores the values in the SRv6-PCE-CAPABILITY sub-TLV. 391 Furthermore, whenever a PCE learns the other advanced SRv6 MSD via 392 different means, it MUST use that value regardless of the values 393 exchanged in the SRv6-PCE-CAPABILITY sub-TLV. 395 Once an SRv6-capable PCEP session is established with a non-zero SRv6 396 MSD value, the corresponding PCE MUST NOT send SRv6 paths with a 397 number of SIDs exceeding that SRv6 MSD value (based on the SRv6 MSD 398 Type). If a PCC needs to modify the SRv6 MSD value, it MUST close 399 the PCEP session and re-establish it with the new value. If a PCEP 400 session is established with a non-zero SRv6 MSD value, and the PCC 401 receives an SRv6 path containing more SIDs than specified in the SRv6 402 MSD value (based on the SRv6 MSD type), the PCC MUST send a PCErr 403 message with Error-Type 10 (Reception of an invalid object) and 404 Error-Value 3 (Unsupported number of Segment ERO subobjects). If a 405 PCEP session is established with an SRv6 MSD value of zero, then the 406 PCC MAY specify an SRv6 MSD for each path computation request that it 407 sends to the PCE, by including a "maximum SID depth" metric object on 408 the request similar to [I-D.ietf-pce-segment-routing]. 410 The L flag and (MSD-Type,MSD-Value) pair inside the SRv6-PCE- 411 CAPABILITY sub-TLV are meaningful only in the Open message sent from 412 a PCC to a PCE. As such, a PCE MUST set the L flag and not include 413 (MSD-Type,MSD-Value) in an outbound message to a PCC. Similarly, a 414 PCC MUST ignore any (MSD-Type,MSD-Value) received from a PCE. If a 415 PCE receives multiple SRv6-PCE-CAPABILITY sub-TLVs in an Open 416 message, it processes only the first sub-TLV received. 418 3.3.2. The RP/SRP Object 420 In order to indicate the SRv6 path, RP or SRP object MUST include the 421 PATH-SETUP-TYPE TLV specified in [RFC8408]. This document defines a 422 new Path Setup Type (PST=TBD2) for SRv6. 424 The LSP-IDENTIFIERS TLV MAY be present for the above PST type. 426 3.3.3. ERO Object 428 In order to support SRv6, the SR-ERO subobject is used 429 [I-D.ietf-pce-segment-routing]. This documents extends the SR-ERO 430 subobject. All the processing rules remains the same. 432 3.3.3.1. SR-ERO Subobject 434 For supporting SRv6, a new NAI Type (NT) is defined, the format of 435 SR-ERO sub object remains the same as defined in 436 [I-D.ietf-pce-segment-routing]. 438 When the NAI Type (NT) indicates SRv6, then the SR-ERO subobject 439 represent a SRv6 segment and include a field SRv6I (SRv6 Identifier) 440 in place of NAI (Node or Adjacency Identifier) defined in 441 [I-D.ietf-pce-segment-routing]. The 32 bit SID is not used for SRv6 442 and MUST NOT be included. The format of SR-ERO subobject is 443 reproduced with the SRv6I field as shown below: 445 0 1 2 3 446 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 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 |L| Type | Length | NT | Flags |F|S|C|M| 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | SID (not included) | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 // SRv6I (variable) // 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 Figure 2: SR-ERO Subobject Format 457 The description of all the flags and fields is as per 458 [I-D.ietf-pce-segment-routing]. 460 For SRv6 segments, a new NT (NAI Type) is assigned by IANA as TBD3. 462 For SRv6 segments (when NT is TBD3), M and C flag MUST NOT be set. 463 The S flag MUST be set and SID field MUST NOT be included. The F bit 464 MUST NOT be set. 466 If these flags are not set properly, the subobject MUST be considered 467 malformed and the PCEP speaker react as per the error handling 468 described in Section 3.3.3.2. 470 The SRv6I format is as shown below: 472 0 1 2 3 473 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 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | | 476 | SRv6 Identifier | 477 | (128-bit) | 478 | | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | SRv6NT| Flags | Function Code | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 // NAI (variable) // 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 Figure 3: SR-ERO Subobject's SRv6I Format 487 SRv6 Identifier is the 128 bit IPv6 addresses representing SRv6 488 segment. 490 SRv6NT is the SRv6 NAI Type which indicates the interpretation for 491 NAI (Node or Adjacency Identifier) as per 492 [I-D.ietf-pce-segment-routing]. 494 Flags is the 12 bit field, no flag bits are currently defined in 495 this document. This MUST be set to 0 and ignored on receipt. 497 Function Code is is the 16 bit field representing supported 498 functions associated with SRv6 SIDs. This information is optional 499 and included only for maintainability. Following function codes 500 are currently defined - 502 0: Reserved 504 1: End Function 506 2: End.DX6 Function 508 3: End.DT6 Function 510 4: End.X Function 512 NAI field [I-D.ietf-pce-segment-routing] contains the NAI 513 associated with the SRv6 Identifier. Depending on the value of 514 SRv6NT, the NAI can have different formats. 516 When SRv6NT value is 1, the NAI is as per the 'IPv6 Node ID' 517 format defined in [I-D.ietf-pce-segment-routing], which specify 518 an IPv6 address. This is used to identify the owner of the 519 SRv6 Identifier. This is optional, as the LOC (the locater 520 portion) of the SRv6 SID serves a similar purpose. 522 When SRv6NT value is 2, the NAI is as per the 'IPv6 Adjacency' 523 format defined in [I-D.ietf-pce-segment-routing], which specify 524 a pair of IPv6 addresses. This is used to identify the IPv6 525 Adjacency and used with the SRv6 Adj-SID. 527 Note that when SRv6NT value is 0, NAI is not included and MUST 528 be NULL. 530 [Editor's Note - Add IPv6 unnumbered adjacency, once done by 531 [I-D.ietf-pce-segment-routing]] 533 3.3.3.2. ERO Processing 535 The ERO and SR-ERO subobject processing remains as per [RFC5440] and 536 [I-D.ietf-pce-segment-routing]. 538 The NT MUST only be TDB3, if the PST=TBD3 is set in the PCEP message 539 and SRv6-PCE-CAPABILITY sub-TLV is exchanged with the PCEP peer. In 540 case a PCEP speaker receives the SR-ERO subobject with NT indicating 541 SRv6 segment, when the PST is not set to TBD3 or SRv6-PCE-CAPABILITY 542 sub-TLV was not exchanged, it MUST send a PCErr message with Error- 543 Type = 19 ("Invalid Operation") and Error-Value = TBD4 ("Attempted 544 SRv6 when the capability was not advertised"). A PCEP speaker that 545 does not recognize the NT value, it would behave as per 546 [I-D.ietf-pce-segment-routing]. 548 If a PCC receives a list of SRv6 segments, and the number of SRv6 549 segments exceeds the SRv6 MSD that the PCC can impose on the packet 550 (SRH), it MAY send a PCErr message with Error-Type = 10 ("Reception 551 of an invalid object") and Error-Value = TBD ("Unsupported number of 552 Segment ERO subobjects") as per [I-D.ietf-pce-segment-routing]. 554 When a PCEP speaker detects that all subobjects of ERO are not 555 identical to SRv6, and if it does not handle such ERO, it MUST send a 556 PCErr message with Error-Type = 10 ("Reception of an invalid object") 557 and Error-Value = TBD ("Non-identical ERO subobjects")as per 558 [I-D.ietf-pce-segment-routing]. 560 When a PCEP speaker receives an SR-ERO subobject for SRv6 segment, M, 561 C and F flag MUST NOT be set and S flag MUST be set. Otherwise, it 562 MUST consider the entire ERO object invalid and send a PCErr message 563 with Error-Type = 10 ("Reception of an invalid object") and Error- 564 Value = TBD ("Malformed object") as per 565 [I-D.ietf-pce-segment-routing]. The PCEP speaker MAY include the 566 malformed SR-ERO object in the PCErr message as well. 568 3.3.3.2.1. Interpreting the SR-ERO 570 The SR-ERO contains a sequence of subobjects. According to 571 [I-D.ietf-spring-segment-routing-policy], each SR-ERO subobject in 572 the sequence identifies a segment that the traffic will be directed 573 to, in the order given. That is, the first subobject identifies the 574 first segment the traffic will be directed to, the second SR-ERO 575 subobject represents the second segment, and so on. 577 The PCC interprets the SR-ERO by converting it to an SRv6 SRH plus a 578 next hop. The PCC sends packets along the segment routed path by 579 prepending the SRH onto the packets and sending the resulting, 580 modified packet to the next hop. 582 3.3.4. RRO Object 584 In order to support SRv6, the SR-RRO Subobject is used 585 [I-D.ietf-pce-segment-routing]. All other processing rules remains 586 the same. 588 3.3.4.1. SR-RRO Subobject 590 For SRv6 segments, a new NT (NAI Type) is assigned by IANA as TBD3, 591 the format of SR-RRO sub object remains the same as the SR-ERO 592 subobject, but without the L flag [I-D.ietf-pce-segment-routing]. 594 When the NAI Type (NT) indicates SRv6, then the SR-RRO subobject 595 represent a SRv6 segment and include a field SRv6I (SRv6 Identifier) 596 in place of NAI (Node or Adjacency Identifier) defined in 597 [I-D.ietf-pce-segment-routing]. The 32 bit SID MUST NOT be included. 598 The format of SR-RRO subobject is reproduced with the SRv6I field as 599 shown below: 601 0 1 2 3 602 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 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Type | Length | ST | Flags |F|S|C|M| 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | SID (not included) | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 // SRv6I (variable) // 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 Figure 4: SR-RRO Subobject Format 613 The description of all fields and flags is as per SR-ERO subobject. 615 Processing rules of SR-RRO subobject are identical to those of SR-ERO 616 subobject. 618 If a PCE detects that all subobjects of RRO are not identical, and if 619 it does not handle such RRO, it MUST send a PCErr message with Error- 620 Type = 10 ("Reception of an invalid object") and Error-Value = 10 621 ("Non-identical RRO subobjects"). 623 3.4. Security Considerations 625 The security considerations described in [RFC5440], [RFC8231] and 626 [RFC8281], [I-D.ietf-pce-segment-routing], are applicable to this 627 specification. No additional security measure is required. 629 3.5. IANA Considerations 631 This document requests IANA to include (I) bit in flags registry for 632 SR-ERO and SR-RRO sub-objects. Other changes are defined as: 634 3.5.1. PCEP Objects 636 3.5.1.1. ERROR Objects 638 IANA is requested to allocate code-points in the PCEP-ERROR Object 639 Error Types and Values registry for the following new error-values: 641 Error-Type Meaning 642 ---------- ------- 643 10 Reception of an invalid object 644 Error-value = TBD5 (Missing 645 PCE-SRv6-CAPABILITY sub-TLV) 646 19 Invalid Operation 647 Error-value = TBD4 (Attempted SRv6 when the 648 capability was not advertised) 650 3.5.1.2. TLV Type Indicators 652 IANA is requested to make the assignment of the new code points for 653 the existing "PCEP TLV Type Indicators" registry as follows: 655 Value Meaning Reference 656 ----- ------- --------- 657 TBD1 SRv6-PCE-CAPABILITY This Document 659 3.5.1.3. New Path Setup Type 661 [RFC8408] defines the PATH-SETUP-TYPE TLV and requests that IANA 662 creates a registry to manage the value of the PATH-SETUP-TYPE TLV's 663 PST field. IANA is requested to allocate a new code point in the 664 PCEP PATH_SETUP_TYPE TLV PST field registry, as follows: 666 Value Description Reference 667 ----- ----------- --------- 668 TBD2 SRv6 (SRH) technique This Document 670 3.6. The NAI Type field 672 As per [I-D.ietf-pce-segment-routing], a new subregistery for "PCEP 673 SR-ERO NAI Types" was created. IANA is requested to make the 674 assignment of the new code points in the afore-mentioned registry as 675 follows: 677 Value Description Reference 678 ----- ------- --------- 679 TBD3 NAI is an SRv6 segment This Document 681 4. Acknowledgements 683 The authors would like to thank Jeff Tentsura for suggestions 684 regarding SRv6 MSD Types. 686 5. References 688 5.1. Normative References 690 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 691 Requirement Levels", BCP 14, RFC 2119, 692 DOI 10.17487/RFC2119, March 1997, 693 . 695 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 696 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 697 DOI 10.17487/RFC5440, March 2009, 698 . 700 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 701 Used to Form Encoding Rules in Various Routing Protocol 702 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 703 2009, . 705 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 706 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 707 May 2017, . 709 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 710 Computation Element Communication Protocol (PCEP) 711 Extensions for Stateful PCE", RFC 8231, 712 DOI 10.17487/RFC8231, September 2017, 713 . 715 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 716 Computation Element Communication Protocol (PCEP) 717 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 718 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 719 . 721 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 722 Decraene, B., Litkowski, S., and R. Shakir, "Segment 723 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 724 July 2018, . 726 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 727 Hardwick, "Conveying Path Setup Type in PCE Communication 728 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 729 July 2018, . 731 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 732 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 733 DOI 10.17487/RFC8491, November 2018, 734 . 736 [I-D.ietf-pce-segment-routing] 737 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 738 and J. Hardwick, "PCEP Extensions for Segment Routing", 739 draft-ietf-pce-segment-routing-16 (work in progress), 740 March 2019. 742 5.2. Informative References 744 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 745 Element (PCE) Communication Protocol Generic 746 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 747 2006, . 749 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 750 Litkowski, S., Horneffer, M., and R. Shakir, "Source 751 Packet Routing in Networking (SPRING) Problem Statement 752 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 753 2016, . 755 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 756 Stateful Path Computation Element (PCE)", RFC 8051, 757 DOI 10.17487/RFC8051, January 2017, 758 . 760 [RFC8354] Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R., 761 Ed., and M. Townsley, "Use Cases for IPv6 Source Packet 762 Routing in Networking (SPRING)", RFC 8354, 763 DOI 10.17487/RFC8354, March 2018, 764 . 766 [I-D.ietf-6man-segment-routing-header] 767 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 768 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 769 (SRH)", draft-ietf-6man-segment-routing-header-16 (work in 770 progress), February 2019. 772 [I-D.ietf-isis-segment-routing-extensions] 773 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 774 Gredler, H., and B. Decraene, "IS-IS Extensions for 775 Segment Routing", draft-ietf-isis-segment-routing- 776 extensions-22 (work in progress), December 2018. 778 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 779 Psenak, P. and S. Previdi, "OSPFv3 Extensions for Segment 780 Routing", draft-ietf-ospf-ospfv3-segment-routing- 781 extensions-23 (work in progress), January 2019. 783 [I-D.ietf-spring-segment-routing-policy] 784 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 785 bogdanov@google.com, b., and P. Mattes, "Segment Routing 786 Policy Architecture", draft-ietf-spring-segment-routing- 787 policy-02 (work in progress), October 2018. 789 [I-D.filsfils-spring-srv6-network-programming] 790 Filsfils, C., Camarillo, P., Leddy, J., 791 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 792 Network Programming", draft-filsfils-spring-srv6-network- 793 programming-07 (work in progress), February 2019. 795 [I-D.li-ospf-ospfv3-srv6-extensions] 796 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 797 "OSPFv3 Extensions for SRv6", draft-li-ospf- 798 ospfv3-srv6-extensions-03 (work in progress), March 2019. 800 [I-D.bashandy-isis-srv6-extensions] 801 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 802 Z. Hu, "IS-IS Extensions to Support Routing over IPv6 803 Dataplane", draft-bashandy-isis-srv6-extensions-05 (work 804 in progress), March 2019. 806 [I-D.dawra-idr-bgpls-srv6-ext] 807 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 808 daniel.bernier@bell.ca, d., Uttaro, J., Decraene, B., and 809 H. Elmalky, "BGP Link State Extensions for SRv6", draft- 810 dawra-idr-bgpls-srv6-ext-05 (work in progress), March 811 2019. 813 Appendix A. Contributor 815 The following persons contributed to this document: 817 Dhruv Dhody 818 Huawei Technologies 819 Divyashree Techno Park, Whitefield 820 Bangalore, Karnataka 560066 821 India 823 EMail: dhruv.ietf@gmail.com 825 Huang Wumin 826 Huawei Technologies 827 Huawei Building, No. 156 Beiqing Rd. 828 Beijing 100095 829 China 831 Email: huangwumin@huawei.com 833 Authors' Addresses 835 Mahendra Singh Negi 836 Huawei Technologies 837 Divyashree Techno Park, Whitefield 838 Bangalore, Karnataka 560066 839 India 841 EMail: mahendrasingh@huawei.com 843 Cheng Li 844 Huawei Technologies 845 Huawei Campus, No. 156 Beiqing Rd. 846 Beijing 100095 847 China 849 EMail: chengli13@huawei.com 851 Siva Sivabalan 852 Cisco Systems 854 EMail: msiva@cisco.com 855 Prejeeth Kaladharan 856 RtBrick Inc 857 Bangalore, Karnataka 858 India 860 EMail: prejeeth@rtbrick.com