idnits 2.17.1 draft-negi-pce-segment-routing-ipv6-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2018) is 2015 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 (-16) exists of draft-ietf-pce-segment-routing-14 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-14 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-19 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-15 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-01 == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-05 == Outdated reference: A later version (-07) exists of draft-li-ospf-ospfv3-srv6-extensions-02 == Outdated reference: A later version (-05) exists of draft-bashandy-isis-srv6-extensions-04 == Outdated reference: A later version (-06) exists of draft-dawra-idr-bgpls-srv6-ext-04 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group M. Negi 3 Internet-Draft D. Dhody 4 Intended status: Standards Track Huawei Technologies 5 Expires: April 22, 2019 S. Sivabalan 6 Cisco Systems 7 P. Kaladharan 8 RtBrick Inc 9 October 19, 2018 11 PCEP Extensions for Segment Routing leveraging the IPv6 data plane 12 draft-negi-pce-segment-routing-ipv6-03 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 April 22, 2019. 59 Copyright Notice 61 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . 9 88 3.3.3.2. ERO Processing . . . . . . . . . . . . . . . . . 11 89 3.3.4. RRO Object . . . . . . . . . . . . . . . . . . . . . 12 90 3.3.4.1. SR-RRO Subobject . . . . . . . . . . . . . . . . 13 91 3.4. Security Considerations . . . . . . . . . . . . . . . . . 13 92 3.5. IANA Considerations . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . 14 98 3.6. The NAI Type field . . . . . . . . . . . . . . . . . . . 14 99 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 100 4.1. Normative References . . . . . . . . . . . . . . . . . . 15 101 4.2. Informative References . . . . . . . . . . . . . . . . . 16 102 Appendix A. Contributor . . . . . . . . . . . . . . . . . . . . 18 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 105 1. Introduction 107 As per [RFC8402], with Segment Routing (SR), a node steers a packet 108 through an ordered list of instructions, called segments. A segment 109 can represent any instruction, topological or service-based. A 110 segment can have a semantic local to an SR node or global within an 111 SR domain. SR allows to enforce a flow through any path and service 112 chain while maintaining per-flow state only at the ingress node of 113 the SR domain. Segments can be derived from different components: 114 IGP, BGP, Services, Contexts, Locater, etc. The list of segment 115 forming the path is called the Segment List and is encoded in the 116 packet header. Segment Routing can be applied to the IPv6 117 architecture with the Segment Routing Header (SRH) 118 [I-D.ietf-6man-segment-routing-header]. A segment is encoded as an 119 IPv6 address. An ordered list of segments is encoded as an ordered 120 list of IPv6 addresses in the routing header. The active segment is 121 indicated by the Destination Address of the packet. Upon completion 122 of a segment, a pointer in the new routing header is incremented and 123 indicates the next segment. 125 Segment Routing use cases are described in [RFC7855] and [RFC8354]. 126 Segment Routing protocol extensions are defined in 127 [I-D.ietf-isis-segment-routing-extensions], and 128 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 130 As per [I-D.ietf-6man-segment-routing-header], an SRv6 Segment is a 131 128-bit value. "SRv6 SID" or simply "SID" are often used as a 132 shorter reference for "SRv6 Segment". Further details are in an 133 illustration provided in 134 [I-D.filsfils-spring-srv6-network-programming]. 136 The SR architecture can be applied to the MPLS forwarding plane 137 without any change, in which case an SR path corresponds to an MPLS 138 Label Switching Path (LSP). The SR is applied to IPV6 forwarding 139 plane using SRH. A SR path can be derived from an IGP Shortest Path 140 Tree (SPT), but SR-TE paths may not follow IGP SPT. Such paths may 141 be chosen by a suitable network planning tool, or a PCE and 142 provisioned on the ingress node. 144 [RFC5440] describes Path Computation Element communication Protocol 145 (PCEP) for communication between a Path Computation Client (PCC) and 146 a Path Computation Element (PCE) or between a pair of PCEs. A PCE or 147 a PCC operating as a PCE (in hierarchical PCE environment) computes 148 paths for MPLS Traffic Engineering LSPs (MPLS-TE LSPs) based on 149 various constraints and optimization criteria. [RFC8231] specifies 150 extensions to PCEP that allow a stateful PCE to compute and recommend 151 network paths in compliance with [RFC4657] and defines objects and 152 TLVs for MPLS-TE LSPs. Stateful PCEP extensions provide 153 synchronization of LSP state between a PCC and a PCE or between a 154 pair of PCEs, delegation of LSP control, reporting of LSP state from 155 a PCC to a PCE, controlling the setup and path routing of an LSP from 156 a PCE to a PCC. Stateful PCEP extensions are intended for an 157 operational model in which LSPs are configured on the PCC, and 158 control over them is delegated to the PCE. 160 A mechanism to dynamically initiate LSPs on a PCC based on the 161 requests from a stateful PCE or a controller using stateful PCE is 162 specified in [RFC8281]. As per [I-D.ietf-pce-segment-routing], it is 163 possible to use a stateful PCE for computing one or more SR-TE paths 164 taking into account various constraints and objective functions. 165 Once a path is chosen, the stateful PCE can initiate an SR-TE path on 166 a PCC using PCEP extensions specified in [RFC8281] using the SR 167 specific PCEP extensions specified in [I-D.ietf-pce-segment-routing]. 168 [I-D.ietf-pce-segment-routing] specifies PCEP extensions for 169 supporting a SR-TE LSP for MPLS data plane. This document extends 170 [I-D.ietf-pce-segment-routing] to support SR for IPv6 data plane. 171 Additionally, using procedures described in this document, a PCC can 172 request an SRv6 path from either stateful or a stateless PCE. This 173 specification relies on the PATH-SETUP-TYPE TLV and procedures 174 specified in [RFC8408]. 176 This specification provides a mechanism for a network controller 177 (acting as a PCE) to instantiate candidate paths for an SR Policy 178 onto a head-end node (acting as a PCC) using PCEP. For more 179 information on the SR Policy Architecture, see 180 [I-D.ietf-spring-segment-routing-policy]. 182 2. Terminology 184 This document uses the following terms defined in [RFC5440]: PCC, 185 PCE, PCEP Peer. 187 This document uses the following terms defined in [RFC8051]: Stateful 188 PCE, Delegation. 190 The message formats in this document are specified using Routing 191 Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. 193 NAI: Node or Adjacency Identifier. 195 PCC: Path Computation Client. 197 PCE: Path Computation Element. 199 PCEP: Path Computation Element Protocol. 201 SR: Segment Routing. 203 SID: Segment Identifier. 205 SRv6: Segment Routing for IPv6 forwarding plane. 207 SRH: IPv6 Segment Routing Header. 209 SR Path: IPv6 Segment (List of IPv6 SID representing a path in IPv6 210 SR domain) 212 3. Overview of PCEP Operation in SRv6 Networks 214 Basic operations for PCEP speakers is as per 215 [I-D.ietf-pce-segment-routing]. SRv6 Paths computed by a PCE can be 216 represented as an ordered list of SRv6 segments of 128-bit value. 217 "SRv6 SID" or simply "SID" are often used as a shorter reference for 218 "SRv6 Segment" in this document. 220 [I-D.ietf-pce-segment-routing] defined a new ERO subobject denoted by 221 "SR-ERO subobject" capable of carrying a SID as well as the identity 222 of the node/adjacency represented by the SID. SR-capable PCEP 223 speakers should be able to generate and/or process such ERO 224 subobject. An ERO containing SR-ERO subobjects can be included in 225 the PCEP Path Computation Reply (PCRep) message defined in [RFC5440], 226 the PCEP LSP Initiate Request message (PCInitiate) defined in 227 [RFC8281], as well as in the PCEP LSP Update Request (PCUpd) and PCEP 228 LSP State Report (PCRpt) messages defined in defined in [RFC8231]. 230 This document extends the "SR-ERO subobject" defined in 231 [I-D.ietf-pce-segment-routing] to carry IPv6 SID(s) (IPv6 Addresses). 232 SRv6-capable PCEP speakers MUST be able to generate and/or process 233 this. 235 When a PCEP session between a PCC and a PCE is established, both PCEP 236 speakers exchange their capabilities to indicate their ability to 237 support SRv6 specific functionality. 239 In summary, this document: 241 o Defines a new PCEP capability for SRv6 242 o Update the SR-ERO and SR-RRO sub-object for SRv6 244 o Defines a new path setup type carried in the PATH-SETUP-TYPE and 245 PATH-SETUP-TYPE-CAPABILITY TLVs. 247 3.1. Operation Overview 249 In SR networks, an ingress node of an SR path appends all outgoing 250 packets with an SR header consisting of a list of SIDs (IPv6 Prefix 251 in case of SRv6). The header has all necessary information to guide 252 the packets from the ingress node to the egress node of the path, and 253 hence there is no need for any signaling protocol. 255 For IPv6 in control plane with MPLS data-plane, mechanism remains 256 same as [I-D.ietf-pce-segment-routing] 258 This document describes extensions to SR path for IPv6 data plane. 259 SRv6 Path (i.e. ERO) consists of an ordered set of SRv6 SIDs(see 260 details in Figure 2). 262 A PCC or PCE indicates its ability to support SRv6 during the PCEP 263 session Initialization Phase via a new SRv6-PCE-CAPABILITY sub-TLV 264 (see details in Section 3.3.1.1). 266 3.2. SRv6-Specific PCEP Message Extensions 268 As defined in [RFC5440], a PCEP message consists of a common header 269 followed by a variable length body made up of mandatory and/or 270 optional objects. This document does not require any changes in the 271 format of PCReq and PCRep messages specified in [RFC5440], PCInitiate 272 message specified in [RFC8281], and PCRpt and PCUpd messages 273 specified in [RFC8231]. However, PCEP messages pertaining to SRv6 274 MUST include PATH-SETUP-TYPE TLV in the RP or SRP object to clearly 275 identify that SRv6 is intended. 277 3.3. Object Formats 279 3.3.1. The OPEN Object 281 3.3.1.1. The SRv6 PCE Capability sub-TLV 283 This document defines a new Path Setup Type (PST) [RFC8408] for SRv6, 284 as follows: 286 o PST = TBD2: Path is setup using SRv6. 288 A PCEP speaker SHOULD indicate its support of the function described 289 in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the 290 OPEN object with this new PST included in the PST list. 292 This document also defines the SRv6-PCE-CAPABILITY sub-TLV. PCEP 293 speakers use this sub-TLV to exchange information about their SRv6 294 capability. If a PCEP speaker includes PST=TBD2 in the PST List of 295 the PATH-SETUP-TYPE-CAPABILITY TLV then it MUST also include the 296 SRv6-PCE- CAPABILITY sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY 297 TLV. 299 The format of the SRv6-PCE-CAPABILITY sub-TLV is shown in the 300 following figure: 302 0 1 2 3 303 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 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Type=TBD1 | Length=4 | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | max-SL | Reserved | Flags |L| 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 Figure 1: SRv6-PCE-CAPABILITY sub-TLV format 312 The code point for the TLV type (TBD1) is to be defined by IANA. The 313 TLV length is 4 octets. 315 The 4-octet value comprise of - 317 max-SL: 1 octet, this field specifies the maximum value of the 318 "Segments Left (SL)" in the SRH 319 [I-D.ietf-6man-segment-routing-header]. 321 Reserved: 1 octet, this field MUST be set to 0 on transmission, 322 and ignored on receipt. 324 Flags: 2 octet, one bit is currently assigned in this document. 326 L bit: A PCC sets this bit to 1 to indicate that it does not 327 impose any limit on SL. 329 Unassigned bits MUST be set to 0 and ignored on receipt. 331 3.3.1.2. Exchanging the SRv6 Capability 333 A PCC indicates that it is capable of supporting the head-end 334 functions for SRv6 by including the SRv6-PCE-CAPABILITY sub-TLV in 335 the Open message that it sends to a PCE. A PCE indicates that it is 336 capable of computing SRv6 paths by including the SRv6-PCE-CAPABILITY 337 sub-TLV in the Open message that it sends to a PCC. 339 If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a 340 PST list containing PST=TBD2, but the SRv6-PCE-CAPABILITY sub-TLV is 341 absent, then the PCEP speaker MUST send a PCErr message with Error- 342 Type 10 (Reception of an invalid object) and Error-Value TBD5 (to be 343 assigned by IANA) (Missing PCE-SRv6-CAPABILITY sub-TLV) and MUST then 344 close the PCEP session. If a PCEP speaker receives a PATH-SETUP- 345 TYPE-CAPABILITY TLV with a SRv6-PCE-CAPABILITY sub-TLV, but the PST 346 list does not contain PST=TBD2, then the PCEP speaker MUST ignore the 347 SRv6-PCE-CAPABILITY sub-TLV. 349 The number of SRv6 SIDs that can be imposed on a packet depends on 350 the PCC's IPv6 data plane's capability. If a PCC sets the L flag to 351 1 then the max-SL is not used and MUST be set to zero. If a PCE 352 receives an SRv6-PCE-CAPABILITY sub-TLV with the L flag set to 1 then 353 it MUST ignore the max-SL field and MUST assume that the sender can 354 impose a SL of any length. If a PCC sets the L flag to zero, then it 355 sets the max-SL field to the maximum number of SIDs that it can 356 impose on a packet. If a PCE receives an SRv6-PCE-CAPABILITY sub-TLV 357 with the L flag and max-SL both set to zero then it MUST assume that 358 the PCC is not capable of imposing a SL of any length and hence is 359 not SRv6 capable, unless it learns a non-zero max-SL for the PCC 360 through some other means. 362 Note that the max-SL value exchanged via the SRv6-PCE-CAPABILITY sub- 363 TLV indicates the SRv6 SID imposition limit for the PCC node. 364 However, if a PCE learns the max-SL value of a PCC node via different 365 means, e.g routing protocols, as specified in: 366 [I-D.li-ospf-ospfv3-srv6-extensions]; 367 [I-D.bashandy-isis-srv6-extensions]; [I-D.dawra-idr-bgpls-srv6-ext], 368 then it ignores the max-SL value in the SRv6-PCE-CAPABILITY sub-TLV. 369 Furthermore, whenever a PCE learns the other advanced max-SL via 370 different means, it MUST use that value regardless of the max-SL 371 value exchanged in the SRv6-PCE-CAPABILITY sub-TLV. 373 Once an SRv6-capable PCEP session is established with a non-zero max- 374 SL value, the corresponding PCE MUST NOT send SRv6 paths with a 375 number of SIDs exceeding that max-SL value. If a PCC needs to modify 376 the max-SL value, it MUST close the PCEP session and re-establish it 377 with the new max-SL value. If a PCEP session is established with a 378 non-zero max-SL value, and the PCC receives an SRv6 path containing 379 more SIDs than specified in the max-SL value, the PCC MUST send a 380 PCErr message with Error-Type 10 (Reception of an invalid object) and 381 Error-Value 3 (Unsupported number of Segment ERO subobjects). If a 382 PCEP session is established with an max-SL value of zero, then the 383 PCC MAY specify an max-SL for each path computation request that it 384 sends to the PCE, by including a "maximum SID depth" metric object on 385 the request similar to [I-D.ietf-pce-segment-routing]. 387 The L flag and Max-SL value inside the SRv6-PCE-CAPABILITY sub-TLV 388 are meaningful only in the Open message sent from a PCC to a PCE. As 389 such, a PCE MUST set the L flag and Max-SL value to zero in an 390 outbound message to a PCC. Similarly, a PCC MUST ignore any max-SL 391 value received from a PCE. If a PCE receives multiple SRv6-PCE- 392 CAPABILITY sub-TLVs in an Open message, it processes only the first 393 sub-TLV received. 395 3.3.2. The RP/SRP Object 397 In order to indicate the SRv6 path, RP or SRP object MUST include the 398 PATH-SETUP-TYPE TLV specified in [RFC8408]. This document defines a 399 new Path Setup Type (PST=TBD2) for SRv6. 401 The LSP-IDENTIFIERS TLV MAY be present for the above PST type. 403 3.3.3. ERO Object 405 In order to support SRv6, the SR-ERO subobject is used 406 [I-D.ietf-pce-segment-routing]. This documents extends the SR-ERO 407 subobject. All the processing rules remains the same. 409 3.3.3.1. SR-ERO Subobject 411 For supporting SRv6, a new NAI Type (NT) is defined, the format of 412 SR-ERO sub object remains the same as defined in 413 [I-D.ietf-pce-segment-routing]. 415 When the NAI Type (NT) indicates SRv6, then the SR-ERO subobject 416 represent a SRv6 segment and include a field SRv6I (SRv6 Identifier) 417 in place of NAI (Node or Adjacency Identifier) defined in 418 [I-D.ietf-pce-segment-routing]. The 32 bit SID is not used for SRv6 419 and MUST NOT be included. The format of SR-ERO subobject is 420 reproduced with the SRv6I field as shown below: 422 0 1 2 3 423 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 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 |L| Type | Length | NT | Flags |F|S|C|M| 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | SID (not included) | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 // SRv6I (variable) // 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 Figure 2: SR-ERO Subobject Format 434 The description of all the flags and fields is as per 435 [I-D.ietf-pce-segment-routing]. 437 For SRv6 segments, a new NT (NAI Type) is assigned by IANA as TBD3. 439 For SRv6 segments (when NT is TBD3), M and C flag MUST NOT be set. 440 The S flag MUST be set and SID field MUST NOT be included. The F bit 441 MUST NOT be set. 443 If these flags are not set properly, the subobject MUST be considered 444 malformed and the PCEP speaker react as per the error handling 445 described in Section 3.3.3.2. 447 The SRv6I format is as shown below: 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | | 453 | SRv6 Identifier | 454 | (128-bit) | 455 | | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | SRv6NT| Flags | Function Code | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 // NAI (variable) // 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 Figure 3: SR-ERO Subobject's SRv6I Format 464 SRv6 Identifier is the 128 bit IPv6 addresses representing SRv6 465 segment. 467 SRv6NT is the SRv6 NAI Type which indicates the interpretation for 468 NAI (Node or Adjacency Identifier) as per 469 [I-D.ietf-pce-segment-routing]. 471 Flags is the 12 bit field, no flag bits are currently defined in 472 this document. This MUST be set to 0 and ignored on receipt. 474 Function Code is is the 16 bit field representing supported 475 functions associated with SRv6 SIDs. This information is optional 476 and included only for maintainability. Following function codes 477 are currently defined - 479 0: Reserved 481 1: End Function 483 2: End.DX6 Function 485 3: End.DT6 Function 487 4: End.X Function 489 NAI field [I-D.ietf-pce-segment-routing] contains the NAI 490 associated with the SRv6 Identifier. Depending on the value of 491 SRv6NT, the NAI can have different formats. 493 When SRv6NT value is 1, the NAI is as per the 'IPv6 Node ID' 494 format defined in [I-D.ietf-pce-segment-routing], which specify 495 an IPv6 address. This is used to identify the owner of the 496 SRv6 Identifier. This is optional, as the LOC (the locater 497 portion) of the SRv6 SID serves a similar purpose. 499 When SRv6NT value is 2, the NAI is as per the 'IPv6 Adjacency' 500 format defined in [I-D.ietf-pce-segment-routing], which specify 501 a pair of IPv6 addresses. This is used to identify the IPv6 502 Adjacency and used with the SRv6 Adj-SID. 504 Note that when SRv6NT value is 0, NAI is not included and MUST 505 be NULL. 507 3.3.3.2. ERO Processing 509 The ERO and SR-ERO subobject processing remains as per [RFC5440] and 510 [I-D.ietf-pce-segment-routing]. 512 The NT MUST only be TDB3, if the PST=TBD3 is set in the PCEP message 513 and SRv6-PCE-CAPABILITY sub-TLV is exchanged with the PCEP peer. In 514 case a PCEP speaker receives the SR-ERO subobject with NT indicating 515 SRv6 segment, when the PST is not set to TBD3 or SRv6-PCE-CAPABILITY 516 sub-TLV was not exchanged, it MUST send a PCErr message with Error- 517 Type = 19 ("Invalid Operation") and Error-Value = TBD4 ("Attempted 518 SRv6 when the capability was not advertised"). A PCEP speaker that 519 does not recognize the NT value, it would behave as per 520 [I-D.ietf-pce-segment-routing]. 522 If a PCC receives a list of SRv6 segments, and the number of SRv6 523 segments exceeds the max-SL that the PCC can impose on the packet 524 (SRH), it MAY send a PCErr message with Error-Type = 10 ("Reception 525 of an invalid object") and Error-Value = TBD ("Unsupported number of 526 Segment ERO subobjects") as per [I-D.ietf-pce-segment-routing]. 528 When a PCEP speaker detects that all subobjects of ERO are not 529 identical to SRv6, and if it does not handle such ERO, it MUST send a 530 PCErr message with Error-Type = 10 ("Reception of an invalid object") 531 and Error-Value = TBD ("Non-identical ERO subobjects")as per 532 [I-D.ietf-pce-segment-routing]. 534 When a PCEP speaker receives an SR-ERO subobject for SRv6 segment, M, 535 C and F flag MUST NOT be set and S flag MUST be set. Otherwise, it 536 MUST consider the entire ERO object invalid and send a PCErr message 537 with Error-Type = 10 ("Reception of an invalid object") and Error- 538 Value = TBD ("Malformed object") as per 539 [I-D.ietf-pce-segment-routing]. The PCEP speaker MAY include the 540 malformed SR-ERO object in the PCErr message as well. 542 3.3.3.2.1. Interpreting the SR-ERO 544 The SR-ERO contains a sequence of subobjects. According to 545 [I-D.ietf-spring-segment-routing-policy], each SR-ERO subobject in 546 the sequence identifies a segment that the traffic will be directed 547 to, in the order given. That is, the first subobject identifies the 548 first segment the traffic will be directed to, the second SR-ERO 549 subobject represents the second segment, and so on. 551 The PCC interprets the SR-ERO by converting it to an SRv6 SRH plus a 552 next hop. The PCC sends packets along the segment routed path by 553 prepending the SRH onto the packets and sending the resulting, 554 modified packet to the next hop. 556 3.3.4. RRO Object 558 In order to support SRv6, the SR-RRO Subobject is used 559 [I-D.ietf-pce-segment-routing]. All other processing rules remains 560 the same. 562 3.3.4.1. SR-RRO Subobject 564 For SRv6 segments, a new NT (NAI Type) is assigned by IANA as TBD3, 565 the format of SR-RRO sub object remains the same as the SR-ERO 566 subobject, but without the L flag [I-D.ietf-pce-segment-routing]. 568 When the NAI Type (NT) indicates SRv6, then the SR-RRO subobject 569 represent a SRv6 segment and include a field SRv6I (SRv6 Identifier) 570 in place of NAI (Node or Adjacency Identifier) defined in 571 [I-D.ietf-pce-segment-routing]. The 32 bit SID MUST NOT be included. 572 The format of SR-RRO subobject is reproduced with the SRv6I field as 573 shown below: 575 0 1 2 3 576 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 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Type | Length | ST | Flags |F|S|C|M| 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | SID (not included) | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 // SRv6I (variable) // 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 Figure 4: SR-RRO Subobject Format 587 The description of all fields and flags is as per SR-ERO subobject. 589 Processing rules of SR-RRO subobject are identical to those of SR-ERO 590 subobject. 592 If a PCE detects that all subobjects of RRO are not identical, and if 593 it does not handle such RRO, it MUST send a PCErr message with Error- 594 Type = 10 ("Reception of an invalid object") and Error-Value = 10 595 ("Non-identical RRO subobjects"). 597 3.4. Security Considerations 599 The security considerations described in [RFC5440], [RFC8231] and 600 [RFC8281], [I-D.ietf-pce-segment-routing], are applicable to this 601 specification. No additional security measure is required. 603 3.5. IANA Considerations 605 This document requests IANA to include (I) bit in flags registry for 606 SR-ERO and SR-RRO sub-objects. Other changes are defined as: 608 3.5.1. PCEP Objects 610 3.5.1.1. ERROR Objects 612 IANA is requested to allocate code-points in the PCEP-ERROR Object 613 Error Types and Values registry for the following new error-values: 615 Error-Type Meaning 616 ---------- ------- 617 10 Reception of an invalid object 618 Error-value = TBD5 (Missing 619 PCE-SRv6-CAPABILITY sub-TLV) 620 19 Invalid Operation 621 Error-value = TBD4 (Attempted SRv6 when the 622 capability was not advertised) 624 3.5.1.2. TLV Type Indicators 626 IANA is requested to make the assignment of the new code points for 627 the existing "PCEP TLV Type Indicators" registry as follows: 629 Value Meaning Reference 630 ----- ------- --------- 631 TBD1 SRv6-PCE-CAPABILITY This Document 633 3.5.1.3. New Path Setup Type 635 [RFC8408] defines the PATH-SETUP-TYPE TLV and requests that IANA 636 creates a registry to manage the value of the PATH-SETUP-TYPE TLV's 637 PST field. IANA is requested to allocate a new code point in the 638 PCEP PATH_SETUP_TYPE TLV PST field registry, as follows: 640 Value Description Reference 641 ----- ----------- --------- 642 TBD2 SRv6 (SRH) technique This Document 644 3.6. The NAI Type field 646 As per [I-D.ietf-pce-segment-routing], a new subregistery for "PCEP 647 SR-ERO NAI Types" was created. IANA is requested to make the 648 assignment of the new code points in the afore-mentioned registry as 649 follows: 651 Value Description Reference 652 ----- ------- --------- 653 TBD3 NAI is an SRv6 segment This Document 655 4. References 657 4.1. Normative References 659 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 660 Requirement Levels", BCP 14, RFC 2119, 661 DOI 10.17487/RFC2119, March 1997, 662 . 664 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 665 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 666 DOI 10.17487/RFC5440, March 2009, 667 . 669 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 670 Used to Form Encoding Rules in Various Routing Protocol 671 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 672 2009, . 674 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 675 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 676 May 2017, . 678 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 679 Computation Element Communication Protocol (PCEP) 680 Extensions for Stateful PCE", RFC 8231, 681 DOI 10.17487/RFC8231, September 2017, 682 . 684 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 685 Computation Element Communication Protocol (PCEP) 686 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 687 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 688 . 690 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 691 Decraene, B., Litkowski, S., and R. Shakir, "Segment 692 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 693 July 2018, . 695 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 696 Hardwick, "Conveying Path Setup Type in PCE Communication 697 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 698 July 2018, . 700 [I-D.ietf-pce-segment-routing] 701 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 702 and J. Hardwick, "PCEP Extensions for Segment Routing", 703 draft-ietf-pce-segment-routing-14 (work in progress), 704 October 2018. 706 4.2. Informative References 708 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 709 Element (PCE) Communication Protocol Generic 710 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 711 2006, . 713 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 714 Litkowski, S., Horneffer, M., and R. Shakir, "Source 715 Packet Routing in Networking (SPRING) Problem Statement 716 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 717 2016, . 719 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 720 Stateful Path Computation Element (PCE)", RFC 8051, 721 DOI 10.17487/RFC8051, January 2017, 722 . 724 [RFC8354] Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R., 725 Ed., and M. Townsley, "Use Cases for IPv6 Source Packet 726 Routing in Networking (SPRING)", RFC 8354, 727 DOI 10.17487/RFC8354, March 2018, 728 . 730 [I-D.ietf-6man-segment-routing-header] 731 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 732 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 733 (SRH)", draft-ietf-6man-segment-routing-header-14 (work in 734 progress), June 2018. 736 [I-D.ietf-isis-segment-routing-extensions] 737 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 738 Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, 739 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 740 segment-routing-extensions-19 (work in progress), July 741 2018. 743 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 744 Psenak, P., Filsfils, C., Previdi, S., Gredler, H., 745 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 746 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 747 segment-routing-extensions-15 (work in progress), August 748 2018. 750 [I-D.ietf-spring-segment-routing-policy] 751 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 752 bogdanov@google.com, b., and P. Mattes, "Segment Routing 753 Policy Architecture", draft-ietf-spring-segment-routing- 754 policy-01 (work in progress), June 2018. 756 [I-D.filsfils-spring-srv6-network-programming] 757 Filsfils, C., Camarillo, P., Leddy, J., 758 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 759 Network Programming", draft-filsfils-spring-srv6-network- 760 programming-05 (work in progress), July 2018. 762 [I-D.li-ospf-ospfv3-srv6-extensions] 763 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 764 "OSPFv3 Extensions for SRv6", draft-li-ospf- 765 ospfv3-srv6-extensions-02 (work in progress), September 766 2018. 768 [I-D.bashandy-isis-srv6-extensions] 769 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 770 Z. Hu, "IS-IS Extensions to Support Routing over IPv6 771 Dataplane", draft-bashandy-isis-srv6-extensions-04 (work 772 in progress), October 2018. 774 [I-D.dawra-idr-bgpls-srv6-ext] 775 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 776 daniel.bernier@bell.ca, d., Uttaro, J., Decraene, B., and 777 H. Elmalky, "BGP Link State extensions for IPv6 Segment 778 Routing(SRv6)", draft-dawra-idr-bgpls-srv6-ext-04 (work in 779 progress), September 2018. 781 Appendix A. Contributor 783 The following persons contributed to this document: 785 Huang Wumin 786 Huawei Technologies 787 Huawei Building, No. 156 Beiqing Rd. 788 Beijing 100095 789 China 791 Email: huangwumin@huawei.com 793 Authors' Addresses 795 Mahendra Singh Negi 796 Huawei Technologies 797 Divyashree Techno Park, Whitefield 798 Bangalore, Karnataka 560066 799 India 801 EMail: mahendrasingh@huawei.com 803 Dhruv Dhody 804 Huawei Technologies 805 Divyashree Techno Park, Whitefield 806 Bangalore, Karnataka 560066 807 India 809 EMail: dhruv.ietf@gmail.com 811 Siva Sivabalan 812 Cisco Systems 814 EMail: msiva@cisco.com 816 Prejeeth Kaladharan 817 RtBrick Inc 818 Bangalore, Karnataka 819 India 821 EMail: prejeeth@rtbrick.com