idnits 2.17.1 draft-ietf-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-pce-segment-routing]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (April 7, 2019) is 1839 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4657' is defined on line 862, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-18 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-23 == 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 Summary: 1 error (**), 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: October 9, 2019 S. Sivabalan 6 Cisco Systems 7 P. Kaladharan 8 RtBrick Inc 9 Z. Yongqing 10 China Telecom 11 April 7, 2019 13 PCEP Extensions for Segment Routing leveraging the IPv6 data plane 14 draft-ietf-pce-segment-routing-ipv6-01 16 Abstract 18 The Source Packet Routing in Networking (SPRING) architecture 19 describes how Segment Routing (SR) can be used to steer packets 20 through an IPv6 or MPLS network using the source routing paradigm. 21 SR enables any head-end node to select any path without relying on a 22 hop-by-hop signaling technique (e.g., LDP or RSVP-TE). 24 It depends only on "segments" that are advertised by Link- State 25 IGPs. A Segment Routed Path can be derived from a variety of 26 mechanisms, including an IGP Shortest Path Tree (SPT), explicit 27 configuration, or a Path Computation Element (PCE). 29 Since SR can be applied to both MPLS and IPv6 forwarding plane, a PCE 30 should be able to compute SR-Path for both MPLS and IPv6 forwarding 31 plane. This document describes the extensions required for SR 32 support for IPv6 data plane in Path Computation Element communication 33 Protocol (PCEP). The PCEP extension and mechanism to support SR-MPLS 34 is described in [I-D.ietf-pce-segment-routing]. This document 35 extends it to support SRv6 (SR over IPv6). 37 Requirements Language 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 41 "OPTIONAL" in this document are to be interpreted as described in BCP 42 14 [RFC2119] [RFC8174]when, and only when, they appear in all 43 capitals, as shown here. 45 Status of This Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at https://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 This Internet-Draft will expire on October 9, 2019. 62 Copyright Notice 64 Copyright (c) 2019 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (https://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the Simplified BSD License. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 80 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 3. Overview of PCEP Operation in SRv6 Networks . . . . . . . . . 5 82 3.1. Operation Overview . . . . . . . . . . . . . . . . . . . 6 83 3.2. SRv6-Specific PCEP Message Extensions . . . . . . . . . . 6 84 4. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 7 85 4.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 7 86 4.1.1. The SRv6 PCE Capability sub-TLV . . . . . . . . . . . 7 87 4.2. The RP/SRP Object . . . . . . . . . . . . . . . . . . . . 8 88 4.3. ERO . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 89 4.3.1. SRv6-ERO Subobject . . . . . . . . . . . . . . . . . 8 90 4.4. RRO . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 4.4.1. SRv6-RRO Subobject . . . . . . . . . . . . . . . . . 11 92 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 11 93 5.1. Exchanging the SRv6 Capability . . . . . . . . . . . . . 11 94 5.2. ERO Processing . . . . . . . . . . . . . . . . . . . . . 13 95 5.2.1. SRv6 ERO Validation . . . . . . . . . . . . . . . . . 13 96 5.2.2. Interpreting the SRv6-ERO . . . . . . . . . . . . . . 14 97 5.3. RRO Processing . . . . . . . . . . . . . . . . . . . . . 14 98 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 99 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 100 7.1. PCEP ERO and RRO subobjects . . . . . . . . . . . . . . . 15 101 7.2. New SRv6-ERO Flag Registry . . . . . . . . . . . . . . . 15 102 7.3. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators . . . 16 103 7.4. SRv6 PCE Capability Flags . . . . . . . . . . . . . . . . 16 104 7.5. New Path Setup Type . . . . . . . . . . . . . . . . . . . 17 105 7.6. ERROR Objects . . . . . . . . . . . . . . . . . . . . . . 17 106 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 107 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 108 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 109 9.2. Informative References . . . . . . . . . . . . . . . . . 19 110 Appendix A. Contributor . . . . . . . . . . . . . . . . . . . . 21 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 113 1. Introduction 115 As per [RFC8402], with Segment Routing (SR), a node steers a packet 116 through an ordered list of instructions, called segments. A segment 117 can represent any instruction, topological or service-based. A 118 segment can have a semantic local to an SR node or global within an 119 SR domain. SR allows to enforce a flow through any path and service 120 chain while maintaining per-flow state only at the ingress node of 121 the SR domain. Segments can be derived from different components: 122 IGP, BGP, Services, Contexts, Locater, etc. The list of segment 123 forming the path is called the Segment List and is encoded in the 124 packet header. Segment Routing can be applied to the IPv6 125 architecture with the Segment Routing Header (SRH) 126 [I-D.ietf-6man-segment-routing-header]. A segment is encoded as an 127 IPv6 address. An ordered list of segments is encoded as an ordered 128 list of IPv6 addresses in the routing header. The active segment is 129 indicated by the Destination Address of the packet. Upon completion 130 of a segment, a pointer in the new routing header is incremented and 131 indicates the next segment. 133 Segment Routing use cases are described in [RFC7855]and [RFC8354]. 134 Segment Routing protocol extensions are defined in 135 [I-D.ietf-isis-segment-routing-extensions], and 136 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 138 As per [I-D.ietf-6man-segment-routing-header], an SRv6 Segment is a 139 128-bit value. "SRv6 SID" or simply "SID" are often used as a 140 shorter reference for "SRv6 Segment". Further details are in an 141 illustration provided in 142 [I-D.filsfils-spring-srv6-network-programming]. 144 The SR architecture can be applied to the MPLS forwarding plane 145 without any change, in which case an SR path corresponds to an MPLS 146 Label Switching Path (LSP). The SR is applied to IPV6 forwarding 147 plane using SRH. A SR path can be derived from an IGP Shortest Path 148 Tree (SPT), but SR-TE paths may not follow IGP SPT. Such paths may 149 be chosen by a suitable network planning tool, or a PCE and 150 provisioned on the ingress node. 152 [RFC5440]describes Path Computation Element communication Protocol 153 (PCEP) for communication between a Path Computation Client (PCC) and 154 a Path Computation Element (PCE) or between a pair of PCEs. A PCE or 155 a PCC operating as a PCE (in hierarchical PCE environment) computes 156 paths for MPLS Traffic Engineering LSPs (MPLS-TE LSPs) based on 157 various constraints and optimization criteria. [RFC8231]specifies 158 extensions to PCEP that allow a stateful PCE to compute and recommend 159 network paths in compliance with [RFC4657]and defines objects and 160 TLVs for MPLS-TE LSPs. Stateful PCEP extensions provide 161 synchronization of LSP state between a PCC and a PCE or between a 162 pair of PCEs, delegation of LSP control, reporting of LSP state from 163 a PCC to a PCE, controlling the setup and path routing of an LSP from 164 a PCE to a PCC. Stateful PCEP extensions are intended for an 165 operational model in which LSPs are configured on the PCC, and 166 control over them is delegated to the PCE. 168 A mechanism to dynamically initiate LSPs on a PCC based on the 169 requests from a stateful PCE or a controller using stateful PCE is 170 specified in [RFC8281]. As per [I-D.ietf-pce-segment-routing], it is 171 possible to use a stateful PCE for computing one or more SR-TE paths 172 taking into account various constraints and objective functions. 173 Once a path is chosen, the stateful PCE can initiate an SR-TE path on 174 a PCC using PCEP extensions specified in [RFC8281]using the SR 175 specific PCEP extensions specified in [I-D.ietf-pce-segment-routing]. 176 [I-D.ietf-pce-segment-routing]specifies PCEP extensions for 177 supporting a SR-TE LSP for MPLS data plane. This document extends 178 [I-D.ietf-pce-segment-routing]to support SR for IPv6 data plane. 179 Additionally, using procedures described in this document, a PCC can 180 request an SRv6 path from either stateful or a stateless PCE. This 181 specification relies on the PATH-SETUP-TYPE TLV and procedures 182 specified in [RFC8408]. 184 This specification provides a mechanism for a network controller 185 (acting as a PCE) to instantiate candidate paths for an SR Policy 186 onto a head-end node (acting as a PCC) using PCEP. For more 187 information on the SR Policy Architecture, see 188 [I-D.ietf-spring-segment-routing-policy]. 190 2. Terminology 192 This document uses the following terms defined in [RFC5440]: PCC, 193 PCE, PCEP Peer. 195 This document uses the following terms defined in [RFC8051]: Stateful 196 PCE, Delegation. 198 The message formats in this document are specified using Routing 199 Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. 201 NAI: Node or Adjacency Identifier. 203 PCC: Path Computation Client. 205 PCE: Path Computation Element. 207 PCEP: Path Computation Element Protocol. 209 SR: Segment Routing. 211 SID: Segment Identifier. 213 SRv6: Segment Routing for IPv6 forwarding plane. 215 SRH: IPv6 Segment Routing Header. 217 SR Path: IPv6 Segment (List of IPv6 SID representing a path in IPv6 218 SR domain) 220 3. Overview of PCEP Operation in SRv6 Networks 222 Basic operations for PCEP speakers is as per 223 [I-D.ietf-pce-segment-routing]. SRv6 Paths computed by a PCE can be 224 represented as an ordered list of SRv6 segments of 128-bit value. 225 "SRv6 SID" or simply "SID" are often used as a shorter reference for 226 "SRv6 Segment" in this document. 228 [I-D.ietf-pce-segment-routing]defined a new Explicit Route Object 229 (ERO) subobject denoted by "SR-ERO subobject" capable of carrying a 230 SID as well as the identity of the node/adjacency represented by the 231 SID. SR-capable PCEP speakers should be able to generate and/or 232 process such ERO subobject. An ERO containing SR-ERO subobjects can 233 be included in the PCEP Path Computation Reply (PCRep) message 234 defined in [RFC5440], the PCEP LSP Initiate Request message 235 (PCInitiate) defined in [RFC8281], as well as in the PCEP LSP Update 236 Request (PCUpd) and PCEP LSP State Report (PCRpt) messages defined in 237 defined in [RFC8231]. 239 This document define new subobjects "SRv6-ERO" and "SRv6-RRO" in ERO 240 and RRO respectively to carry SRv6 SID (IPv6 Address). SRv6-capable 241 PCEP speakers MUST be able to generate and/or process this. 243 When a PCEP session between a PCC and a PCE is established, both PCEP 244 speakers exchange their capabilities to indicate their ability to 245 support SRv6 specific functionality. 247 In summary, this document: 249 o Defines a new PCEP capability for SRv6. 251 o Defines a new subobject SRv6-ERO in ERO. 253 o Defines a new subobject SRv6-RRO in RRO. 255 o Defines a new path setup type carried in the PATH-SETUP-TYPE and 256 PATH-SETUP-TYPE-CAPABILITY TLVs. 258 3.1. Operation Overview 260 In SR networks, an ingress node of an SR path appends all outgoing 261 packets with an SR header consisting of a list of SIDs (IPv6 Prefix 262 in case of SRv6). The header has all necessary information to guide 263 the packets from the ingress node to the egress node of the path, and 264 hence there is no need for any signaling protocol. 266 For IPv6 in control plane with MPLS data-plane, mechanism remains 267 same as [I-D.ietf-pce-segment-routing] 269 This document describes extensions to SR path for IPv6 data plane. 270 SRv6 Path (i.e. ERO) consists of an ordered set of SRv6 SIDs(see 271 details in Figure 2). 273 A PCC or PCE indicates its ability to support SRv6 during the PCEP 274 session Initialization Phase via a new SRv6-PCE-CAPABILITY sub-TLV 275 (see details in Section 4.1.1). 277 3.2. SRv6-Specific PCEP Message Extensions 279 As defined in [RFC5440], a PCEP message consists of a common header 280 followed by a variable length body made up of mandatory and/or 281 optional objects. This document does not require any changes in the 282 format of PCReq and PCRep messages specified in [RFC5440], PCInitiate 283 message specified in [RFC8281], and PCRpt and PCUpd messages 284 specified in [RFC8231]. However, PCEP messages pertaining to SRv6 285 MUST include PATH-SETUP-TYPE TLV in the RP or SRP object to clearly 286 identify that SRv6 is intended. 288 4. Object Formats 290 4.1. The OPEN Object 292 4.1.1. The SRv6 PCE Capability sub-TLV 294 This document defines a new Path Setup Type (PST) [RFC8408]for SRv6, 295 as follows: 297 o PST = TBD2: Path is setup using SRv6. 299 A PCEP speaker SHOULD indicate its support of the function described 300 in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the 301 OPEN object with this new PST included in the PST list. 303 This document also defines the SRv6-PCE-CAPABILITY sub-TLV. PCEP 304 speakers use this sub-TLV to exchange information about their SRv6 305 capability. If a PCEP speaker includes PST=TBD2 in the PST List of 306 the PATH-SETUP-TYPE-CAPABILITY TLV then it MUST also include the 307 SRv6-PCE- CAPABILITY sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY 308 TLV. 310 The format of the SRv6-PCE-CAPABILITY sub-TLV is shown in the 311 following figure: 313 0 1 2 3 314 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Type=TBD1 | Length | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Reserved | Flags |N|X| 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | MSD-Type | MSD-Value | MSD-Type | MSD-Value | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 // ... // 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | MSD-Type | MSD-Value | Padding | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Figure 1: SRv6-PCE-CAPABILITY sub-TLV format 329 The code point for the TLV type (TBD1) is to be defined by IANA. The 330 TLV length is variable. 332 The value comprise of - 333 Reserved: 2 octet, this field MUST be set to 0 on transmission, 334 and ignored on receipt. 336 Flags: 2 octet, two bits are currently assigned in this document. 338 N bit: A PCC sets this flag bit to 1 to indicate that it is 339 capable of resolving a Node or Adjacency Identifier (NAI) to a 340 SRv6-SID. 342 X bit: A PCC sets this bit to 1 to indicate that it does not 343 impose any limit on MSD (irrespective of the MSD-Type). 345 Unassigned bits MUST be set to 0 and ignored on receipt. 347 A pair of (MSD-Type,MSD-Value): Where MSD-Type (1 octet) is as per 348 the IGP MSD Type registry created by [RFC8491]and populated with 349 SRv6 MSD types as per [I-D.bashandy-isis-srv6-extensions]; MSD- 350 Value (1 octet) is as per [RFC8491]. 352 The TLV format is compliant with the PCEP TLV format defined in 353 [RFC5440]. That is, the TLV is composed of 2 octets for the type, 2 354 octets specifying the TLV length, and a Value field. The Length 355 field defines the length of the value portion in octets. The TLV is 356 padded to 4-octet alignment, and padding is not included in the 357 Length field. The number of (MSD-Type,MSD-Value) pairs can be 358 determined from the Length field of the TLV. 360 4.2. The RP/SRP Object 362 In order to indicate the SRv6 path, RP or SRP object MUST include the 363 PATH-SETUP-TYPE TLV specified in [RFC8408]. This document defines a 364 new Path Setup Type (PST=TBD2) for SRv6. 366 The LSP-IDENTIFIERS TLV MAY be present for the above PST type. 368 4.3. ERO 370 In order to support SRv6, new subobjects "SRv6-ERO" and "SRv6-RRO" 371 are defined in ERO and RRO respectively. 373 4.3.1. SRv6-ERO Subobject 375 An SRv6-ERO subobject is formatted as shown in the following diagram. 377 0 1 2 3 378 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 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 |L| Type=TBD3 | Length | NT | Flags |F|S| 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | reserved | Function Code | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | | 385 | SRv6 SID (optional) | 386 | (128-bit) | 387 | | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 // NAI (variable, optional) // 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 Figure 2: SRv6-ERO Subobject Format 394 The fields in the SRv6-ERO Subobject are as follows: 396 The 'L' Flag: Indicates whether the subobject represents a loose-hop 397 (see [RFC3209]). If this flag is set to zero, a PCC MUST NOT 398 overwrite the SID value present in the SRv6-ERO subobject. 399 Otherwise, a PCC MAY expand or replace one or more SID values in the 400 received SRv6-ERO based on its local policy. 402 Type: Set to TBD3. 404 Length: Contains the total length of the subobject in octets. The 405 Length MUST be at least 24, and MUST be a multiple of 4. An SRv6-ERO 406 subobject MUST contain at least one of a SRv6-SID or an NAI. The 407 flags described below indicate whether the SRv6-SID or NAI fields are 408 absent. 410 NAI Type (NT): Indicates the type and format of the NAI contained in 411 the object body, if any is present. If the F bit is set to zero (see 412 below) then the NT field has no meaning and MUST be ignored by the 413 receiver. This document reuses NT types defined in 414 [I-D.ietf-pce-segment-routing]: 416 If NT value is 0, the NAI MUST NOT be included. 418 When NT value is 2, the NAI is as per the 'IPv6 Node ID' format 419 defined in [I-D.ietf-pce-segment-routing], which specifies an IPv6 420 address. This is used to identify the owner of the SRv6 421 Identifier. This is optional, as the LOC (the locater portion) of 422 the SRv6 SID serves a similar purpose (when present). 424 When NT value is 3, the NAI is as per the 'IPv6 Adjacency' format 425 defined in [I-D.ietf-pce-segment-routing], which specify a pair of 426 IPv6 addresses. This is used to identify the IPv6 Adjacency and 427 used with the SRv6 Adj-SID. 429 When NT value is 6, the NAI is as per the 'link-local IPv6 430 addresses' format defined in [I-D.ietf-pce-segment-routing], which 431 specify a pair of (global IPv6 address, interface ID) tuples. It 432 is used to identify the IPv6 Adjacency and used with the SRv6 Adj- 433 SID. 435 SR-MPLS specific NT types are not valid in SRv6-ERO. 437 Flags: Used to carry additional information pertaining to the 438 SRv6-SID. This document defines the following flag bits. The other 439 bits MUST be set to zero by the sender and MUST be ignored by the 440 receiver. 442 o S: When this bit is set to 1, the SRv6-SID value in the subobject 443 body is absent. In this case, the PCC is responsible for choosing 444 the SRv6-SID value, e.g., by looking up in the SR-DB using the NAI 445 which, in this case, MUST be present in the subobject. If the S 446 bit is set to 1 then F bit MUST be set to zero. 448 o F: When this bit is set to 1, the NAI value in the subobject body 449 is absent. The F bit MUST be set to 1 if NT=0, and otherwise MUST 450 be set to zero. The S and F bits MUST NOT both be set to 1. 452 Function Code: A 16 bit field representing supported functions 453 associated with SRv6 SIDs. This information is optional and plays no 454 role in the SRH imposed on the packet. It could be included for 455 maintainability and diagnostic purpose. If function code is not 456 defined 0 is used. Functions codes are defined in 457 [I-D.filsfils-spring-srv6-network-programming]. 459 SRv6 SID: SRv6 Identifier is the 128 bit IPv6 addresses representing 460 the SRv6 segment. 462 NAI: The NAI associated with the SRv6-SID. The NAI's format depends 463 on the value in the NT field, and is described in 464 [I-D.ietf-pce-segment-routing]. 466 At least one of the SRv6-SID and the NAI MUST be included in the 467 SRv6-ERO subobject, and both MAY be included. 469 4.4. RRO 471 4.4.1. SRv6-RRO Subobject 473 A PCC reports an SRv6 path to a PCE by sending a PCRpt message, per 474 [RFC8231]. The RRO on this message represents the SID list that was 475 applied by the PCC, that is, the actual path taken. The procedures 476 of [I-D.ietf-pce-segment-routing]with respect to the RRO apply 477 equally to this specification without change. 479 An RRO contains one or more subobjects called "SRv6-RRO subobjects" 480 whose format is shown below: 482 0 1 2 3 483 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 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Type=TBD4 | Length | NT | Flags |F|S| 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | reserved | Function Code | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | | 490 | SRv6 SID | 491 | (128-bit) | 492 | | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 // NAI (variable) // 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 Figure 3: SRv6-RRO Subobject Format 499 The format of the SRv6-RRO subobject is the same as that of the 500 SRv6-ERO subobject, but without the L flag. 502 Ordering of SRv6-RRO subobjects by PCC in PCRpt message remains as 503 per [I-D.ietf-pce-segment-routing]. 505 5. Procedures 507 5.1. Exchanging the SRv6 Capability 509 A PCC indicates that it is capable of supporting the head-end 510 functions for SRv6 by including the SRv6-PCE-CAPABILITY sub-TLV in 511 the Open message that it sends to a PCE. A PCE indicates that it is 512 capable of computing SRv6 paths by including the SRv6-PCE-CAPABILITY 513 sub-TLV in the Open message that it sends to a PCC. 515 If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a 516 PST list containing PST=TBD2, but the SRv6-PCE-CAPABILITY sub-TLV is 517 absent, then the PCEP speaker MUST send a PCErr message with Error- 518 Type 10 (Reception of an invalid object) and Error-Value TBD5 (to be 519 assigned by IANA) (Missing PCE-SRv6-CAPABILITY sub-TLV) and MUST then 520 close the PCEP session. If a PCEP speaker receives a PATH-SETUP- 521 TYPE-CAPABILITY TLV with a SRv6-PCE-CAPABILITY sub-TLV, but the PST 522 list does not contain PST=TBD2, then the PCEP speaker MUST ignore the 523 SRv6-PCE-CAPABILITY sub-TLV. 525 The number of SRv6 SIDs that can be imposed on a packet depends on 526 the PCC's IPv6 data plane's capability. If a PCC sets the X flag to 527 1 then the MSD is not used and MUST NOT be included. If a PCE 528 receives an SRv6-PCE-CAPABILITY sub-TLV with the X flag set to 1 then 529 it MUST ignore any MSD-Type, MSD-Value fields and MUST assume that 530 the sender can impose any length of SRH. If a PCC sets the X flag to 531 zero, then it sets the SRv6 MSD-Type, MSD-Value fields that it can 532 impose on a packet. If a PCE receives an SRv6-PCE-CAPABILITY sub-TLV 533 with the X flag and SRv6 MSD-Type, MSD-Value fields both set to zero 534 then it is considered as an error and the PCE MUST respond with a 535 PCErr message (Error-Type=1 "PCEP session establishment failure" and 536 Error-Value=1 "reception of an invalid Open message or a non Open 537 message."). In case the MSD-Type in SRv6-PCE-CAPABILITY sub-TLV 538 received by the PCE does not correspond to one of the SRv6 MSD types, 539 the PCE MUST respond with a PCErr message (Error-Type=1 "PCEP session 540 establishment failure" and Error-Value=1 "reception of an invalid 541 Open message or a non Open message."). 543 Note that the MSD-Type, MSD-Value exchanged via the SRv6-PCE- 544 CAPABILITY sub-TLV indicates the SRv6 SID imposition limit for the 545 PCC node. However, if a PCE learns these via different means, e.g 546 routing protocols, as specified in: 547 [I-D.li-ospf-ospfv3-srv6-extensions]; 548 [I-D.bashandy-isis-srv6-extensions]; [I-D.dawra-idr-bgpls-srv6-ext], 549 then it ignores the values in the SRv6-PCE-CAPABILITY sub-TLV. 550 Furthermore, whenever a PCE learns the other advanced SRv6 MSD via 551 different means, it MUST use that value regardless of the values 552 exchanged in the SRv6-PCE-CAPABILITY sub-TLV. 554 Once an SRv6-capable PCEP session is established with a non-zero SRv6 555 MSD value, the corresponding PCE MUST NOT send SRv6 paths with a 556 number of SIDs exceeding that SRv6 MSD value (based on the SRv6 MSD 557 Type). If a PCC needs to modify the SRv6 MSD value, it MUST close 558 the PCEP session and re-establish it with the new value. If a PCEP 559 session is established with a non-zero SRv6 MSD value, and the PCC 560 receives an SRv6 path containing more SIDs than specified in the SRv6 561 MSD value (based on the SRv6 MSD type), the PCC MUST send a PCErr 562 message with Error-Type 10 (Reception of an invalid object) and 563 Error-Value 3 (Unsupported number of Segment ERO subobjects). If a 564 PCEP session is established with an SRv6 MSD value of zero, then the 565 PCC MAY specify an SRv6 MSD for each path computation request that it 566 sends to the PCE, by including a "maximum SID depth" metric object on 567 the request similar to [I-D.ietf-pce-segment-routing]. 569 The N flag, X flag and (MSD-Type,MSD-Value) pair inside the SRv6-PCE- 570 CAPABILITY sub-TLV are meaningful only in the Open message sent from 571 a PCC to a PCE. As such, a PCE MUST set the flags to zero and not 572 include any (MSD-Type, MSD-Value) pair in the SRv6-PCE-CAPABILITY 573 sub-TLV in an outbound message to a PCC. Similarly, a PCC MUST 574 ignore N, X flag and any (MSD-Type,MSD-Value) pair received from a 575 PCE. If a PCE receives multiple SRv6-PCE-CAPABILITY sub-TLVs in an 576 Open message, it processes only the first sub-TLV received. 578 5.2. ERO Processing 580 The ERO processing remains as per [RFC5440]and 581 [I-D.ietf-pce-segment-routing]. 583 5.2.1. SRv6 ERO Validation 585 If a PCC does not support the SRv6 PCE Capability and thus cannot 586 recognize the SRv6-ERO or SRv6-RRO subobjects, it will respond 587 according to the rules for a malformed object per [RFC5440]. 589 On receiving an SRv6-ERO, a PCC MUST validate that the Length field, 590 the S bit, the F bit and the NT field are consistent, as follows. 592 o If NT=0, the F bit MUST be 1, the S bit MUST be zero and the 593 Length MUST be 24. 595 o If NT=2, the F bit MUST be zero. If the S bit is 1, the Length 596 MUST be 24, otherwise the Length MUST be 40. 598 o If NT=4, the F bit MUST be zero. If the S bit is 1, the Length 599 MUST be 40, otherwise the Length MUST be 56. 601 o If NT=6, the F bit MUST be zero. If the S bit is 1, the Length 602 MUST be 48, otherwise the Length MUST be 64. 604 o NT types (1, 3, and 5) are not valid for SRv6. 606 If a PCC finds that the NT field, Length field, S bit and F bit are 607 not consistent, it MUST consider the entire ERO invalid and MUST send 608 a PCErr message with Error-Type = 10 ("Reception of an invalid 609 object") and Error-Value = 11 ("Malformed object"). 611 If a PCEP speaker that does not recognize the NT value received in 612 SRv6-ERO subobject, it would behave as per 613 [I-D.ietf-pce-segment-routing]. 615 In case a PCEP speaker receives the SRv6-ERO subobject, when the PST 616 is not set to TBD2 or SRv6-PCE-CAPABILITY sub-TLV was not exchanged, 617 it MUST send a PCErr message with Error-Type = 19 ("Invalid 618 Operation") and Error-Value = TBD5 ("Attempted SRv6 when the 619 capability was not advertised"). 621 If a PCC receives a list of SRv6 segments, and the number of SRv6 622 segments exceeds the SRv6 MSD that the PCC can impose on the packet 623 (SRH), it MUST send a PCErr message with Error-Type = 10 ("Reception 624 of an invalid object") and Error-Value = TBD ("Unsupported number of 625 Segment ERO subobjects") as per [I-D.ietf-pce-segment-routing]. 627 When a PCEP speaker detects that all subobjects of ERO are not of 628 type TBD3, and if it does not handle such ERO, it MUST send a PCErr 629 message with Error-Type = 10 ("Reception of an invalid object") and 630 Error-Value = TBD ("Non-identical ERO subobjects")as per 631 [I-D.ietf-pce-segment-routing]. 633 5.2.2. Interpreting the SRv6-ERO 635 The SR-ERO contains a sequence of subobjects. According to 636 [I-D.ietf-spring-segment-routing-policy], each SRv6-ERO subobject in 637 the sequence identifies a segment that the traffic will be directed 638 to, in the order given. That is, the first subobject identifies the 639 first segment the traffic will be directed to, the second SR-ERO 640 subobject represents the second segment, and so on. 642 The PCC interprets the SRv6-ERO by converting it to an SRv6 SRH plus 643 a next hop. The PCC sends packets along the segment routed path by 644 prepending the SRH onto the packets and sending the resulting, 645 modified packet to the next hop. 647 5.3. RRO Processing 649 The syntax checking rules that apply to the SRv6-RRO subobject are 650 identical to those of the SRv6-ERO subobject, except as noted below. 652 If a PCEP speaker receives an SRv6-RRO subobject in which both SRv6 653 SID and NAI are absent, it MUST consider the entire RRO invalid and 654 send a PCErr message with Error-Type = 10 ("Reception of an invalid 655 object") and Error-Value = TBD6 ("Both SID and NAI are absent in 656 SRv6-RRO subobject"). 658 If a PCE detects that the subobjects of an RRO are a mixture of 659 SRv6-RRO subobjects and subobjects of other types, then it MUST send 660 a PCErr message with Error-Type = 10 ("Reception of an invalid 661 object") and Error-Value = TBD7 ("RRO mixes SRv6-RRO subobjects with 662 other subobject types"). 664 6. Security Considerations 666 The security considerations described in [RFC5440], [RFC8231]and 667 [RFC8281], [I-D.ietf-pce-segment-routing], are applicable to this 668 specification. No additional security measure is required. 670 7. IANA Considerations 672 7.1. PCEP ERO and RRO subobjects 674 This document defines a new subobject type for the PCEP explicit 675 route object (ERO), and a new subobject type for the PCEP record 676 route object (RRO). The code points for subobject types of these 677 objects is maintained in the RSVP parameters registry, under the 678 EXPLICIT_ROUTE and ROUTE_RECORD objects. IANA is requested to 679 allocate code-points in the RSVP Parameters registry for each of the 680 new subobject types defined in this document. 682 Object Subobject Subobject Type 683 --------------------- -------------------------- ------------------ 684 EXPLICIT_ROUTE SRv6-ERO (PCEP-specific) TBD3 685 ROUTE_RECORD SRv6-RRO (PCEP-specific) TBD4 687 7.2. New SRv6-ERO Flag Registry 689 IANA is requested to create a new sub-registry, named "SRv6-ERO Flag 690 Field", within the "Path Computation Element Protocol (PCEP) Numbers" 691 registry to manage the Flag field of the SRv6-ERO subobject. New 692 values are to be assigned by Standards Action [RFC8126]. Each bit 693 should be tracked with the following qualities: 695 o Bit number (counting from bit 0 as the most significant bit) 697 o Capability description 699 o Defining RFC 701 The following values are defined in this document: 703 Bit Description Reference 704 ----- ------------------ -------------- 705 0-9 Unassigned 706 10 NAI is absent (F) This document 707 11 SID is absent (S) This document 709 7.3. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators 711 IANA maintains a sub-registry, named "PATH-SETUP- TYPE-CAPABILITY 712 Sub-TLV Type Indicators", within the "Path Computation Element 713 Protocol (PCEP) Numbers" registry to manage the type indicator space 714 for sub-TLVs of the PATH-SETUP-TYPE-CAPABILITY TLV. IANA is 715 requested to make the following assignment: 717 Value Meaning Reference 718 ----- ------- --------- 719 TBD1 SRv6-PCE-CAPABILITY This Document 721 7.4. SRv6 PCE Capability Flags 723 IANA is requested to create a new sub-registry, named "SRv6 724 Capability Flag Field", within the "Path Computation Element Protocol 725 (PCEP) Numbers" registry to manage the Flag field of the SRv6-PCE- 726 CAPABILITY sub-TLV. New values are to be assigned by Standards 727 Action [RFC8126]. Each bit should be tracked with the following 728 qualities: 730 o Bit number (counting from bit 0 as the most significant bit) 732 o Capability description 734 o Defining RFC 736 The following values are defined in this document: 738 Bit Description Reference 740 0-13 Unassigned 741 14 Node or Adjacency This document 742 Identifier (NAI) is 743 supported (N) 744 15 Unlimited Maximum SID This document 745 Depth (X) 747 7.5. New Path Setup Type 749 [RFC8408]created a sub-registry within the "Path Computation Element 750 Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". 751 IANA is requested to allocate a new code point within this registry, 752 as follows: 754 Value Description Reference 755 ----- ----------- --------- 756 TBD2 Traffic engineering path is This Document 757 setup using SRv6. 759 7.6. ERROR Objects 761 IANA is requested to allocate code-points in the PCEP-ERROR Object 762 Error Types and Values registry for the following new error-values: 764 Error-Type Meaning 765 ---------- ------- 766 10 Reception of an invalid object 767 Error-value = TBD5 (Missing 768 PCE-SRv6-CAPABILITY sub-TLV) 769 Error-value = TBD6 (Both SID and NAI are absent 770 in SRv6-RRO subobject) 771 Error-value = TBD7 (RRO mixes SRv6-RRO subobjects 772 with other subobject types) 773 19 Invalid Operation 774 Error-value = TBD5 (Attempted SRv6 when the 775 capability was not advertised) 777 8. Acknowledgements 779 The authors would like to thank Jeff Tentsura, Adrian Farrel and 780 Khasanov Boris for valuable suggestions. 782 9. References 784 9.1. Normative References 786 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 787 Requirement Levels", BCP 14, RFC 2119, 788 DOI 10.17487/RFC2119, March 1997, 789 . 791 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 792 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 793 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 794 . 796 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 797 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 798 DOI 10.17487/RFC5440, March 2009, 799 . 801 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 802 Used to Form Encoding Rules in Various Routing Protocol 803 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 804 2009, . 806 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 807 Writing an IANA Considerations Section in RFCs", BCP 26, 808 RFC 8126, DOI 10.17487/RFC8126, June 2017, 809 . 811 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 812 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 813 May 2017, . 815 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 816 Computation Element Communication Protocol (PCEP) 817 Extensions for Stateful PCE", RFC 8231, 818 DOI 10.17487/RFC8231, September 2017, 819 . 821 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 822 Computation Element Communication Protocol (PCEP) 823 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 824 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 825 . 827 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 828 Decraene, B., Litkowski, S., and R. Shakir, "Segment 829 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 830 July 2018, . 832 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 833 Hardwick, "Conveying Path Setup Type in PCE Communication 834 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 835 July 2018, . 837 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 838 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 839 DOI 10.17487/RFC8491, November 2018, 840 . 842 [I-D.ietf-pce-segment-routing] 843 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 844 and J. Hardwick, "PCEP Extensions for Segment Routing", 845 draft-ietf-pce-segment-routing-16 (work in progress), 846 March 2019. 848 [I-D.bashandy-isis-srv6-extensions] 849 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 850 Z. Hu, "IS-IS Extensions to Support Routing over IPv6 851 Dataplane", draft-bashandy-isis-srv6-extensions-05 (work 852 in progress), March 2019. 854 [I-D.filsfils-spring-srv6-network-programming] 855 Filsfils, C., Camarillo, P., Leddy, J., 856 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 857 Network Programming", draft-filsfils-spring-srv6-network- 858 programming-07 (work in progress), February 2019. 860 9.2. Informative References 862 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 863 Element (PCE) Communication Protocol Generic 864 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 865 2006, . 867 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 868 Litkowski, S., Horneffer, M., and R. Shakir, "Source 869 Packet Routing in Networking (SPRING) Problem Statement 870 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 871 2016, . 873 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 874 Stateful Path Computation Element (PCE)", RFC 8051, 875 DOI 10.17487/RFC8051, January 2017, 876 . 878 [RFC8354] Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R., 879 Ed., and M. Townsley, "Use Cases for IPv6 Source Packet 880 Routing in Networking (SPRING)", RFC 8354, 881 DOI 10.17487/RFC8354, March 2018, 882 . 884 [I-D.ietf-6man-segment-routing-header] 885 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 886 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 887 (SRH)", draft-ietf-6man-segment-routing-header-18 (work in 888 progress), April 2019. 890 [I-D.ietf-isis-segment-routing-extensions] 891 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 892 Gredler, H., and B. Decraene, "IS-IS Extensions for 893 Segment Routing", draft-ietf-isis-segment-routing- 894 extensions-23 (work in progress), March 2019. 896 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 897 Psenak, P. and S. Previdi, "OSPFv3 Extensions for Segment 898 Routing", draft-ietf-ospf-ospfv3-segment-routing- 899 extensions-23 (work in progress), January 2019. 901 [I-D.ietf-spring-segment-routing-policy] 902 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 903 bogdanov@google.com, b., and P. Mattes, "Segment Routing 904 Policy Architecture", draft-ietf-spring-segment-routing- 905 policy-02 (work in progress), October 2018. 907 [I-D.li-ospf-ospfv3-srv6-extensions] 908 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 909 "OSPFv3 Extensions for SRv6", draft-li-ospf- 910 ospfv3-srv6-extensions-03 (work in progress), March 2019. 912 [I-D.dawra-idr-bgpls-srv6-ext] 913 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 914 daniel.bernier@bell.ca, d., Uttaro, J., Decraene, B., and 915 H. Elmalky, "BGP Link State Extensions for SRv6", draft- 916 dawra-idr-bgpls-srv6-ext-06 (work in progress), March 917 2019. 919 Appendix A. Contributor 921 The following persons contributed to this document: 923 Dhruv Dhody Huawei Technologies Divyashree Techno 924 Park, Whitefield Bangalore, Karnataka 560066 India EMail: 925 dhruv.ietf@gmail.com Huang Wumin Huawei Technologies Huawei 926 Building, No. 156 Beiqing Rd. Beijing 100095 China Email: 927 huangwumin@huawei.com 929 Authors' Addresses 931 Mahendra Singh Negi 932 Huawei Technologies 933 Divyashree Techno Park, Whitefield 934 Bangalore, Karnataka 560066 935 India 937 EMail: mahendrasingh@huawei.com 939 Cheng Li 940 Huawei Technologies 941 Huawei Campus, No. 156 Beiqing Rd. 942 Beijing 100095 943 China 945 EMail: chengli13@huawei.com 947 Siva Sivabalan 948 Cisco Systems 950 EMail: msiva@cisco.com 952 Prejeeth Kaladharan 953 RtBrick Inc 954 Bangalore, Karnataka 955 India 957 EMail: prejeeth@rtbrick.com 958 Yongqing Zhu 959 China Telecom 960 109 West Zhongshan Ave, Tianhe District 961 Bangalore, Guangzhou 962 P.R. China 964 EMail: zhuyq.gd@chinatelecom.cn