idnits 2.17.1 draft-negi-pce-segment-routing-ipv6-01.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 (March 3, 2018) is 2243 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-11 == Outdated reference: A later version (-10) exists of draft-ietf-pce-lsp-setup-type-08 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-08 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-15 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-11 == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-03 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 P. Kaladharan 4 Intended status: Standards Track D. Dhody 5 Expires: September 4, 2018 Huawei Technologies 6 S. Sivabalan 7 Cisco Systems 8 March 3, 2018 10 PCEP Extensions for Segment Routing leveraging the IPv6 data plane 11 draft-negi-pce-segment-routing-ipv6-01 13 Abstract 15 The Source Packet Routing in Networking (SPRING) architecture 16 describes how Segment Routing (SR) can be used to steer packets 17 through an IPv6 or MPLS network using the source routing paradigm. 18 Segment Routing (SR) enables any head-end node to select any path 19 without relying on a hop-by-hop signaling technique (e.g., LDP or 20 RSVP-TE). 22 It depends only on "segments" that are advertised by Link- State 23 Interior Gateway Protocols (IGPs). A Segment Routed Path can be 24 derived from a variety of mechanisms, including an IGP Shortest Path 25 Tree (SPT), explicit configuration, or a Path Computation Element 26 (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 PCEP. 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 37 "OPTIONAL" in this document are to be interpreted as described in BCP 38 14 [RFC2119] [RFC8174] when, and only when, they appear in all 39 capitals, as shown here. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on September 4, 2018. 58 Copyright Notice 60 Copyright (c) 2018 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (https://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3. Overview of PCEP Operation in SRv6 Networks . . . . . . . . . 5 78 3.1. Operation Overview . . . . . . . . . . . . . . . . . . . 6 79 3.2. SRv6-Specific PCEP Message Extensions . . . . . . . . . . 6 80 3.3. Object Formats . . . . . . . . . . . . . . . . . . . . . 6 81 3.3.1. The OPEN Object . . . . . . . . . . . . . . . . . . . 6 82 3.3.1.1. The SRv6 PCE Capability sub-TLV . . . . . . . . . 6 83 3.3.1.2. Exchanging the SRv6 Capability . . . . . . . . . 7 84 3.3.2. The RP/SRP Object . . . . . . . . . . . . . . . . . . 9 85 3.3.3. ERO Object . . . . . . . . . . . . . . . . . . . . . 9 86 3.3.3.1. SR-ERO Subobject . . . . . . . . . . . . . . . . 9 87 3.3.3.2. ERO Processing . . . . . . . . . . . . . . . . . 11 88 3.3.4. RRO Object . . . . . . . . . . . . . . . . . . . . . 12 89 3.3.4.1. SR-RRO Subobject . . . . . . . . . . . . . . . . 12 90 3.4. Security Considerations . . . . . . . . . . . . . . . . . 13 91 3.5. IANA Considerations . . . . . . . . . . . . . . . . . . . 13 92 3.5.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . 13 93 3.5.1.1. ERROR Objects . . . . . . . . . . . . . . . . . . 13 94 3.5.1.2. TLV Type Indicators . . . . . . . . . . . . . . . 13 95 3.5.1.3. New Path Setup Type . . . . . . . . . . . . . . . 13 97 3.6. The SID Type field . . . . . . . . . . . . . . . . . . . 14 98 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 99 4.1. Normative References . . . . . . . . . . . . . . . . . . 14 100 4.2. Informative References . . . . . . . . . . . . . . . . . 15 101 Appendix A. Contributor . . . . . . . . . . . . . . . . . . . . 17 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 104 1. Introduction 106 As per [I-D.ietf-spring-segment-routing], with Segment Routing (SR), 107 a node steers a packet through an ordered list of instructions, 108 called segments. A segment can represent any instruction, 109 topological or service-based. A segment can have a semantic local to 110 an SR node or global within an SR domain. SR allows to enforce a 111 flow through any path and service chain while maintaining per-flow 112 state only at the ingress node of the SR domain. Segments can be 113 derived from different components: IGP, BGP, Services, Contexts, 114 Locators, etc. The list of segment forming the path is called the 115 Segment List and is encoded in the packet header. Segment Routing 116 can be applied to the IPv6 architecture with the Segment Routing 117 Header (SRH) [I-D.ietf-6man-segment-routing-header]. A segment is 118 encoded as an IPv6 address. An ordered list of segments is encoded 119 as an ordered list of IPv6 addresses in the routing header. The 120 active segment is indicated by the Destination Address of the packet. 121 Upon completion of a segment, a pointer in the new routing header is 122 incremented and indicates the next segment. 124 Segment Routing use cases are described in [RFC7855] and 125 [I-D.ietf-spring-ipv6-use-cases]. Segment Routing protocol 126 extensions are defined in [I-D.ietf-isis-segment-routing-extensions], 127 and [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 129 As per [I-D.ietf-6man-segment-routing-header], an SRv6 Segment is a 130 128-bit value. "SRv6 SID" or simply "SID" are often used as a 131 shorter reference for "SRv6 Segment". Further details are in an 132 illustration provided in 133 [I-D.filsfils-spring-srv6-network-programming]. 135 The SR architecture can be applied to the MPLS forwarding plane 136 without any change, in which case an SR path corresponds to an MPLS 137 Label Switching Path (LSP). The SR is applied to IPV6 forwarding 138 plane using SRH. A SR path can be derived from an IGP Shortest Path 139 Tree (SPT), but SR-TE paths may not follow IGP SPT. Such paths may 140 be chosen by a suitable network planning tool, or a PCE and 141 provisioned on the ingress node. 143 [RFC5440] describes Path Computation Element Protocol (PCEP) for 144 communication between a Path Computation Client (PCC) and a Path 145 Computation Element (PCE) or between a pair of PCEs. A PCE or a PCC 146 operating as a PCE (in hierarchical PCE environment) computes paths 147 for MPLS Traffic Engineering LSPs (MPLS-TE LSPs) based on various 148 constraints and optimization criteria. [RFC8231] specifies 149 extensions to PCEP that allow a stateful PCE to compute and recommend 150 network paths in compliance with [RFC4657] and defines objects and 151 TLVs for MPLS-TE LSPs. Stateful PCEP extensions provide 152 synchronization of LSP state between a PCC and a PCE or between a 153 pair of PCEs, delegation of LSP control, reporting of LSP state from 154 a PCC to a PCE, controlling the setup and path routing of an LSP from 155 a PCE to a PCC. Stateful PCEP extensions are intended for an 156 operational model in which LSPs are configured on the PCC, and 157 control over them is delegated to the PCE. 159 A mechanism to dynamically initiate LSPs on a PCC based on the 160 requests from a stateful PCE or a controller using stateful PCE is 161 specified in [RFC8281]. As per [I-D.ietf-pce-segment-routing], it is 162 possible to use a stateful PCE for computing one or more SR-TE paths 163 taking into account various constraints and objective functions. 164 Once a path is chosen, the stateful PCE can initiate an SR-TE path on 165 a PCC using PCEP extensions specified in [RFC8281] using the SR 166 specific PCEP extensions specified in [I-D.ietf-pce-segment-routing]. 167 [I-D.ietf-pce-segment-routing] specifies PCEP extensions for 168 supporting a SR-TE LSP for MPLS data plane. This document extends 169 [I-D.ietf-pce-segment-routing] to support SR for IPv6 data plane. 170 Additionally, using procedures described in this document, a PCC can 171 request an SRv6 path from either stateful or a stateless PCE. This 172 specification relies on the PATH-SETUP-TYPE TLV and procedures 173 specified in [I-D.ietf-pce-lsp-setup-type]. 175 2. Terminology 177 This document uses the following terms defined in [RFC5440]: PCC, 178 PCE, PCEP Peer. 180 This document uses the following terms defined in [RFC8051]: Stateful 181 PCE, Delegation. 183 The message formats in this document are specified using Routing 184 Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. 186 PCC: Path Computation Client. 188 PCE: Path Computation Element. 190 PCEP: Path Computation Element Protocol. 192 SR: Segment Routing. 194 SID: Segment Identifier. 196 SRv6: Segment Routing for IPv6 forwarding plane. 198 SRH: IPv6 Segment Routing Header. 200 SR Path: IPv6 Segment (List of IPv6 SID representing a path in IPv6 201 SR domain) 203 3. Overview of PCEP Operation in SRv6 Networks 205 Basic operations for PCEP speakers is as per 206 [I-D.ietf-pce-segment-routing]. SRv6 Paths computed by a PCE can be 207 represented as an ordered list of SRv6 segments of 128-bit value. 208 "SRv6 SID" or simply "SID" are often used as a shorter reference for 209 "SRv6 Segment" in this document. 211 [I-D.ietf-pce-segment-routing] defined a new ERO subobject denoted by 212 "SR-ERO subobject" capable of carrying a SID as well as the identity 213 of the node/adjacency represented by the SID. SR-capable PCEP 214 speakers should be able to generate and/or process such ERO 215 subobject. An ERO containing SR-ERO subobjects can be included in 216 the PCEP Path Computation Reply (PCRep) message defined in [RFC5440], 217 the PCEP LSP Initiate Request message (PCInitiate) defined in 218 [RFC8281], as well as in the PCEP LSP Update Request (PCUpd) and PCEP 219 LSP State Report (PCRpt) messages defined in defined in [RFC8231]. 221 This document extends the "SR-ERO subobject" defined in 222 [I-D.ietf-pce-segment-routing] to carry IPv6 SID(s) (IPv6 Addresses). 223 SRv6-capable PCEP speakers should be able to generate and/or process 224 this. 226 When a PCEP session between a PCC and a PCE is established, both PCEP 227 speakers exchange their capabilities to indicate their ability to 228 support SRv6 specific functionality. 230 In summary, this document defines new path setup type carried in the 231 PATH-SETUP-TYPE TLV for SRv6 path. 233 In summary, this document: 235 o Defines a new PCEP capability for SRv6 237 o Update the SR-ERO and SR-RRO sub-object for SRv6 239 o Defines a new path setup type carried in the PATH-SETUP-TYPE TLV 240 for SR-TE LSP. 242 3.1. Operation Overview 244 In SR networks, an ingress node of an SR path appends all outgoing 245 packets with an SR header consisting of a list of SIDs (IPv6 Prefix 246 in case of SRv6). The header has all necessary information to guide 247 the packets from the ingress node to the egress node of the path, and 248 hence there is no need for any signaling protocol. 250 For IPv6 in control plane with MPLS data-plane, mechanism remains 251 same as [I-D.ietf-pce-segment-routing] 253 This document describes extensions to SR path for IPv6 data plane. 254 SRv6 Path (i.e. ERO) consists of an ordered set of SIDs(see details 255 in Figure 2). 257 A PCC or PCE indicates its ability to support SRv6 during the PCEP 258 session Initialization Phase via a new SRv6-PCE-CAPABILITY sub-TLV 259 (see details in Section 3.3.1.1). 261 3.2. SRv6-Specific PCEP Message Extensions 263 As defined in [RFC5440], a PCEP message consists of a common header 264 followed by a variable length body made up of mandatory and/or 265 optional objects. This document does not require any changes in the 266 format of PCReq and PCRep messages specified in [RFC5440], PCInitiate 267 message specified in [RFC8281], and PCRpt and PCUpd messages 268 specified in [RFC8231]. However, PCEP messages pertaining to SRv6 269 MUST include PATH-SETUP-TYPE TLV in the RP or SRP object to clearly 270 identify that SRv6 is intended. In other words, a PCEP speaker MUST 271 NOT infer whether or not a PCEP message pertains to SRv6 from any 272 other object or TLV. 274 3.3. Object Formats 276 3.3.1. The OPEN Object 278 3.3.1.1. The SRv6 PCE Capability sub-TLV 280 This document defines a new Path Setup Type (PST) 281 [I-D.ietf-pce-lsp-setup-type] for SRv6, as follows: 283 o PST = TBD2: Path is setup using SRv6. 285 A PCEP speaker SHOULD indicate its support of the function described 286 in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the 287 OPEN object with this new PST included in the PST list. 289 This document also defines the SRv6-PCE-CAPABILITY sub-TLV. PCEP 290 speakers use this sub-TLV to exchange information about their SRv6 291 capability. If a PCEP speaker includes PST=TBD2 in the PST List of 292 the PATH-SETUP-TYPE-CAPABILITY TLV then it MUST also include the 293 SRv6-PCE- CAPABILITY sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY 294 TLV. 296 The format of the SRv6-PCE-CAPABILITY sub-TLV is shown in the 297 following figure: 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Type=TBD1 | Length=4 | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | max-SL | Reserved | Flags |L| 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 Figure 1: SRv6-PCE-CAPABILITY sub-TLV format 309 The code point for the TLV type (TBD1) is to be defined by IANA. The 310 TLV length is 4 octets. 312 The 4-octet value comprise of - 314 max-SL: 1 octet, this field specifies the maximum value of the 315 "Segments Left (SL)" in the SRH 316 [I-D.ietf-6man-segment-routing-header]. 318 Reserved: 1 octet, this field MUST be set to 0 on transmission, 319 and ignored on receipt. 321 Flags: 2 octet, one flag is currently defined in this document. 323 L bit: A PCC sets this bit to 1 to indicate that it does not 324 impose any limit on SL. 326 3.3.1.2. Exchanging the SRv6 Capability 328 A PCC indicates that it is capable of supporting the head-end 329 functions for SRv6 by including the SRv6-PCE-CAPABILITY sub-TLV in 330 the Open message that it sends to a PCE. A PCE indicates that it is 331 capable of computing SRv6 paths by including the SRv6-PCE-CAPABILITY 332 sub-TLV in the Open message that it sends to a PCC. 334 If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a 335 PST list containing PST=TBD2, but the SRv6-PCE-CAPABILITY sub-TLV is 336 absent, then the PCEP speaker MUST send a PCErr message with Error- 337 Type 10 (Reception of an invalid object) and Error-Value TBD5 (to be 338 assigned by IANA) (Missing PCE-SRv6-CAPABILITY sub-TLV) and MUST then 339 close the PCEP session. If a PCEP speaker receives a PATH-SETUP- 340 TYPE-CAPABILITY TLV with a SRv6-PCE-CAPABILITY sub-TLV, but the PST 341 list does not contain PST=TBD2, then the PCEP speaker MUST ignore the 342 SRv6-PCE-CAPABILITY sub-TLV. 344 The number of SIDs that can be imposed on a packet depends on the 345 PCC's IPv6 data plane's capability. If a PCC sets the L flag to 1 346 then the max-ML is not used and MUST be set to zero. If a PCE 347 receives an SRv6-PCE-CAPABILITY sub-TLV with the L flag set to 1 then 348 it MUST ignore the max-SL field and MUST assume that the sender can 349 impose a SL of any depth. If a PCC sets the L flag to zero, then it 350 sets the max-SL field to the maximum number of SIDs that it can 351 impose on a packet. If a PCE receives an SRv6-PCE-CAPABILITY sub-TLV 352 with the L flag and max-SL both set to zero then it MUST assume that 353 the PCC is not capable of imposing a SL of any length and hence is 354 not SRv6 capable, unless it learns a non-zero max-SL for the PCC 355 through some other means. 357 Once an SRv6-capable PCEP session is established with a non-zero max- 358 SL value, the corresponding PCE MUST NOT send SRv6 paths with a 359 number of SIDs exceeding that max-SL value. If a PCC needs to modify 360 the max-SL value, it MUST close the PCEP session and re-establish it 361 with the new max-SL value. If a PCEP session is established with a 362 non-zero max-SL value, and the PCC receives an SRv6 path containing 363 more SIDs than specified in the max-SL value, the PCC MUST send a 364 PCErr message with Error-Type 10 (Reception of an invalid object) and 365 Error-Value 3 (Unsupported number of Segment ERO subobjects). If a 366 PCEP session is established with an max-SL value of zero, then the 367 PCC MAY specify an max-SL for each path computation request that it 368 sends to the PCE, by including a "maximum SID depth" metric object on 369 the request similar to [I-D.ietf-pce-segment-routing]. 371 The L flag and Max-SL value inside the SRv6-PCE-CAPABILITY sub-TLV 372 are meaningful only in the Open message sent from a PCC to a PCE. As 373 such, a PCE MUST set the L flag and Max-SL value to zero in an 374 outbound message to a PCC. Similarly, a PCC MUST ignore any max-SL 375 value received from a PCE. If a PCE receives multiple SRv6-PCE- 376 CAPABILITY sub-TLVs in an Open message, it processes only the first 377 sub-TLV received. 379 3.3.2. The RP/SRP Object 381 In order to indicate the SRv6 path, RP or SRP object MUST include the 382 PATH-SETUP-TYPE TLV specified in [I-D.ietf-pce-lsp-setup-type]. This 383 document defines a new Path Setup Type (PST=TBD2) for SRv6. 385 3.3.3. ERO Object 387 In order to support SRv6, the SR-ERO subobject is used 388 [I-D.ietf-pce-segment-routing]. All other processing rules remains 389 the same. 391 3.3.3.1. SR-ERO Subobject 393 For supporting SRv6, a new SID Type (ST) is defined, the format of 394 SR-ERO sub object remains the same as defined in 395 [I-D.ietf-pce-segment-routing]. 397 When the SID Type (ST) indicates SRv6, then the SR-ERO subobject 398 represent a SRv6 segment and include a field SRv6I (SRv6 Identifier) 399 in place of NAI (Node or Adjacency Identifier) defined in 400 [I-D.ietf-pce-segment-routing]. The 32 bit SID MUST be set to zero 401 on transit and ignored on receipt. The format of SR-ERO subobject is 402 reproduced with the SRv6I field as shown below: 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 |L| Type | Length | ST | Flags |F|S|C|M| 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | SID | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 // SRv6I (variable) // 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 Figure 2: SR-ERO Subobject Format 416 The description of all the flags and fields is as per 417 [I-D.ietf-pce-segment-routing]. 419 For SRv6 segments, a new ST (SID Type) is assigned by IANA as TBD3. 421 For SRv6 segments (when ST is TBD3), M and C flag MUST NOT be set. 422 The S flag MUST be set and SID field MUST be set to 0. The F bit 423 MUST NOT be set. The Length is 28. 425 The SRv6I format is as shown below: 427 0 1 2 3 428 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 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | | 431 | SRv6 Identifier | 432 | (128-bit) | 433 | | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | SRv6ST| Flags | Function Code | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 // NAI (variable) // 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 Figure 3: SR-ERO Subobject's SRv6I Format 442 SRv6 Identifier is the 128 bit IPv6 addresses representing SRv6 443 segment. 445 SRv6ST is the SRv6 SID Type which indicates the interpretation for 446 NAI (Node or Adjacency Identifier) as per 447 [I-D.ietf-pce-segment-routing]. 449 Flags is the 12 bit field, no flag bits are currently defined in 450 this document. 452 Function Code is is the 16 bit field representing supported 453 functions. associated with SRv6 SIDs. [Editor's Note - The 454 authors needs to finalize if this functionality be removed for 455 now, with a possibility for addition in another extention as the 456 [I-D.filsfils-spring-srv6-network-programming] progressses]. 457 Following function codes are currently defined - 459 0: Reserved 461 1: End Function 463 2: End.DX6 Function 465 3: End.DT6 Function 467 4: End.X Function 469 NAI field [I-D.ietf-pce-segment-routing] contains the NAI 470 associated with the SRv6 Identifier. Depending on the value of 471 SRv6ST, the NAI can have different formats. 473 When SRv6ST value is 1, the NAI is as per the 'IPv6 Node ID' 474 format defined in [I-D.ietf-pce-segment-routing], which specify 475 an IPv6 address. This is used to identify the owner of the 476 SRv6 Identifier. 478 When SRv6ST value is 2, the NAI is as per the 'IPv6 Adjacency' 479 format defined in [I-D.ietf-pce-segment-routing], which specify 480 a pair of IPv6 addresses. This is used to identify the IPv6 481 Adjacency and used with the SRv6 Adj-SID. 483 Note that when SRv6ST value is 0, NAI is not included and MUST 484 be NULL. 486 3.3.3.2. ERO Processing 488 The ERO and SR-ERO subobject processing remains as per [RFC5440] and 489 [I-D.ietf-pce-segment-routing]. 491 The ST MUST only be TDB3, if the PST=TBD3 is set in the PCEP message 492 and SRv6-PCE-CAPABILITY sub-TLV is exchanged with the PCEP peer. In 493 case a PCEP speaker receives the SR-ERO subobject with ST indicating 494 SRv6 segment, when the PST is not set to TBD3 or SRv6-PCE-CAPABILITY 495 sub-TLV was not exchanged, it MUST send a PCErr message with Error- 496 Type = 19 ("Invalid Operation") and Error-Value = TBD4 ("Attempted 497 SRv6 when the capability was not advertised"). A PCEP speaker that 498 does not recognize the ST value, it would behave as per 499 [I-D.ietf-pce-segment-routing]. 501 [Editor's Note - this is missing from 502 [I-D.ietf-pce-segment-routing].] 504 If a PCC receives a list of SRv6 segments, and the number of SRv6 505 segments exceeds the max-SL that the PCC can impose on the packet 506 (SRH), it MAY send a PCErr message with Error-Type = 10 ("Reception 507 of an invalid object") and Error-Value = TBD ("Unsupported number of 508 Segment ERO subobjects") as per [I-D.ietf-pce-segment-routing]. 510 When a PCEP speaker detects that all subobjects of ERO are not 511 identical to SRv6, and if it does not handle such ERO, it MUST send a 512 PCErr message with Error-Type = 10 ("Reception of an invalid object") 513 and Error-Value = TBD ("Non-identical ERO subobjects")as per 514 [I-D.ietf-pce-segment-routing]. 516 When a PCEP speaker receives an SR-ERO subobject for SRv6 segment, M, 517 C and F flag MUST NOT be set and S flag MUST be set. Otherwise, it 518 MUST consider the entire ERO object invalid and send a PCErr message 519 with Error-Type = 10 ("Reception of an invalid object") and Error- 520 Value = TBD ("Malformed object") as per 521 [I-D.ietf-pce-segment-routing]. The PCEP speaker MAY include the 522 malformed SR-ERO object in the PCErr message as well. 524 3.3.4. RRO Object 526 In order to support SRv6, the SR-ERO Subobject is used 527 [I-D.ietf-pce-segment-routing]. All other processing rules remains 528 the same. 530 3.3.4.1. SR-RRO Subobject 532 For SRv6 segments, a new ST (SID Type) is assigned by IANA as TBD3, 533 the format of SR-ERO sub object remains the same as defined in 534 [I-D.ietf-pce-segment-routing]. 536 When the SID Type (ST) indicates SRv6, then the SR-RRO subobject 537 represent a SRv6 segment and include a field SRv6I (SRv6 Identifier) 538 in place of NAI (Node or Adjacency Identifier) defined in 539 [I-D.ietf-pce-segment-routing]. The 32 bit SID MUST be set to zero 540 on transit and ignored on receipt. The format of SR-RRO subobject is 541 reproduced with the SRv6I field as shown below: 543 0 1 2 3 544 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 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Type | Length | ST | Flags |F|S|C|M| 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | SID | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 // SRv6I (variable) // 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 Figure 4: SR-RRO Subobject Format 555 The description of all fields and flags is as per SR-ERO subobject. 557 Processing rules of SR-RRO subobject are identical to those of SR-ERO 558 subobject. 560 If a PCE detects that all subobjects of RRO are not identical, and if 561 it does not handle such RRO, it MUST send a PCErr message with Error- 562 Type = 10 ("Reception of an invalid object") and Error-Value = 10 563 ("Non-identical RRO subobjects"). 565 3.4. Security Considerations 567 The security considerations described in [RFC5440], [RFC8231] and 568 [RFC8281], [I-D.ietf-pce-segment-routing], are applicable to this 569 specification. No additional security measure is required. 571 3.5. IANA Considerations 573 This document requests IANA to include (I) bit in flags registry for 574 SR-ERO and SR-RRO sub-objects. Other changes are defined as: 576 3.5.1. PCEP Objects 578 3.5.1.1. ERROR Objects 580 IANA is requested to allocate code-points in the PCEP-ERROR Object 581 Error Types and Values registry for the following new error-values: 583 Error-Type Meaning 584 ---------- ------- 585 10 Reception of an invalid object 586 Error-value = TBD5 (Missing 587 PCE-SRv6-CAPABILITY sub-TLV) 588 19 Invalid Operation 589 Error-value = TBD4 (Attempted SRv6 when the 590 capability was not advertised) 592 3.5.1.2. TLV Type Indicators 594 IANA is requested to make the assignment of the new code points for 595 the existing "PCEP TLV Type Indicators" registry as follows: 597 Value Meaning Reference 598 ----- ------- --------- 599 TBD1 SRv6-PCE-CAPABILITY This Document 601 3.5.1.3. New Path Setup Type 603 [I-D.ietf-pce-lsp-setup-type]defines the PATH-SETUP-TYPE TLV and 604 requests that IANA creates a registry to manage the value of the 605 PATH-SETUP-TYPE TLV's PST field. IANA is requested to allocate a new 606 code point in the PCEP PATH_SETUP_TYPE TLV PST field registry, as 607 follows: 609 Value Description Reference 610 ----- ----------- --------- 611 TBD2 SRv6 (SRH) technique This Document 613 3.6. The SID Type field 615 [Editor's Note - an IANA code point sub registry needs to be setup in 616 [I-D.ietf-pce-segment-routing], so that future extensions (like this 617 one) can define new ST types (TBD3).] 619 4. References 621 4.1. Normative References 623 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 624 Requirement Levels", BCP 14, RFC 2119, 625 DOI 10.17487/RFC2119, March 1997, 626 . 628 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 629 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 630 DOI 10.17487/RFC5440, March 2009, 631 . 633 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 634 Used to Form Encoding Rules in Various Routing Protocol 635 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 636 2009, . 638 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 639 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 640 May 2017, . 642 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 643 Computation Element Communication Protocol (PCEP) 644 Extensions for Stateful PCE", RFC 8231, 645 DOI 10.17487/RFC8231, September 2017, 646 . 648 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 649 Computation Element Communication Protocol (PCEP) 650 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 651 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 652 . 654 [I-D.ietf-pce-segment-routing] 655 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 656 and J. Hardwick, "PCEP Extensions for Segment Routing", 657 draft-ietf-pce-segment-routing-11 (work in progress), 658 November 2017. 660 [I-D.ietf-spring-segment-routing] 661 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 662 Litkowski, S., and R. Shakir, "Segment Routing 663 Architecture", draft-ietf-spring-segment-routing-15 (work 664 in progress), January 2018. 666 [I-D.ietf-pce-lsp-setup-type] 667 Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 668 Hardwick, "Conveying path setup type in PCEP messages", 669 draft-ietf-pce-lsp-setup-type-08 (work in progress), 670 January 2018. 672 4.2. Informative References 674 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 675 Element (PCE) Communication Protocol Generic 676 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 677 2006, . 679 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 680 Litkowski, S., Horneffer, M., and R. Shakir, "Source 681 Packet Routing in Networking (SPRING) Problem Statement 682 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 683 2016, . 685 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 686 Stateful Path Computation Element (PCE)", RFC 8051, 687 DOI 10.17487/RFC8051, January 2017, 688 . 690 [I-D.ietf-6man-segment-routing-header] 691 Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J., 692 Field, B., daniel.voyer@bell.ca, d., 693 daniel.bernier@bell.ca, d., Matsushima, S., Leung, I., 694 Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun, 695 D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing 696 Header (SRH)", draft-ietf-6man-segment-routing-header-08 697 (work in progress), January 2018. 699 [I-D.ietf-spring-ipv6-use-cases] 700 Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R., and 701 M. Townsley, "IPv6 SPRING Use Cases", draft-ietf-spring- 702 ipv6-use-cases-12 (work in progress), December 2017. 704 [I-D.ietf-isis-segment-routing-extensions] 705 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 706 Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, 707 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 708 segment-routing-extensions-15 (work in progress), December 709 2017. 711 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 712 Psenak, P., Filsfils, C., Previdi, S., Gredler, H., 713 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 714 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 715 segment-routing-extensions-11 (work in progress), January 716 2018. 718 [I-D.filsfils-spring-srv6-network-programming] 719 Filsfils, C., Leddy, J., daniel.voyer@bell.ca, d., 720 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 721 Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., 722 Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., 723 Sharif, M., Ayyangar, A., Mynam, S., Henderickx, W., 724 Bashandy, A., Raza, K., Dukes, D., Clad, F., and P. 725 Camarillo, "SRv6 Network Programming", draft-filsfils- 726 spring-srv6-network-programming-03 (work in progress), 727 December 2017. 729 Appendix A. Contributor 731 The following persons contributed to this document: 733 Huang Wumin 734 Huawei Technologies 735 Huawei Building, No. 156 Beiqing Rd. 736 Beijing 100095 737 China 739 Email: huangwumin@huawei.com 741 Authors' Addresses 743 Mahendra Singh Negi 744 Huawei Technologies 745 Divyashree Techno Park, Whitefield 746 Bangalore, Karnataka 560066 747 India 749 EMail: mahendrasingh@huawei.com 751 Prejeeth Kaladharan 752 Huawei Technologies 753 Divyashree Techno Park, Whitefield 754 Bangalore, Karnataka 560066 755 India 757 EMail: prejeeth.k@huawei.com 759 Dhruv Dhody 760 Huawei Technologies 761 Divyashree Techno Park, Whitefield 762 Bangalore, Karnataka 560066 763 India 765 EMail: dhruv.ietf@gmail.com 767 Siva Sivabalan 768 Cisco Systems 770 EMail: msiva@cisco.com