idnits 2.17.1 draft-ietf-pce-pcep-flowspec-13.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 14, 2021) is 918 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 (-11) exists of draft-gont-numeric-ids-sec-considerations-06 == Outdated reference: A later version (-23) exists of draft-ietf-idr-flowspec-l2vpn-17 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-16 == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-path-computation-16 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Dhody 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track A. Farrel 5 Expires: April 17, 2022 Old Dog Consulting 6 Z. Li 7 Huawei Technologies 8 October 14, 2021 10 PCEP Extension for Flow Specification 11 draft-ietf-pce-pcep-flowspec-13 13 Abstract 15 The Path Computation Element (PCE) is a functional component capable 16 of selecting paths through a traffic engineering network. These 17 paths may be supplied in response to requests for computation, or may 18 be unsolicited requests issued by the PCE to network elements. Both 19 approaches use the PCE Communication Protocol (PCEP) to convey the 20 details of the computed path. 22 Traffic flows may be categorized and described using "Flow 23 Specifications". RFC 8955 defines the Flow Specification and 24 describes how Flow Specification Components are used to describe 25 traffic flows. RFC 8955 also defines how Flow Specifications may be 26 distributed in BGP to allow specific traffic flows to be associated 27 with routes. 29 This document specifies a set of extensions to PCEP to support 30 dissemination of Flow Specifications. This allows a PCE to indicate 31 what traffic should be placed on each path that it is aware of. 33 The extensions defined in this document include the creation, update, 34 and withdrawal of Flow Specifications via PCEP, and can be applied to 35 tunnels initiated by the PCE or to tunnels where control is delegated 36 to the PCE by the PCC. Furthermore, a PCC requesting a new path can 37 include Flow Specifications in the request to indicate the purpose of 38 the tunnel allowing the PCE to factor this into the path computation. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on April 17, 2022. 57 Copyright Notice 59 Copyright (c) 2021 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (https://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 3. Procedures for PCE Use of Flow Specifications . . . . . . . . 6 77 3.1. Context for PCE Use of Flow Specifications . . . . . . . 6 78 3.2. Elements of Procedure . . . . . . . . . . . . . . . . . . 6 79 3.2.1. Capability Advertisement . . . . . . . . . . . . . . 7 80 3.2.2. Dissemination Procedures . . . . . . . . . . . . . . 8 81 3.2.3. Flow Specification Synchronization . . . . . . . . . 9 82 4. PCE FlowSpec Capability TLV . . . . . . . . . . . . . . . . . 9 83 5. PCEP FLOWSPEC Object . . . . . . . . . . . . . . . . . . . . 10 84 6. Flow Filter TLV . . . . . . . . . . . . . . . . . . . . . . . 12 85 7. Flow Specification TLVs . . . . . . . . . . . . . . . . . . . 13 86 8. Detailed Procedures . . . . . . . . . . . . . . . . . . . . . 17 87 8.1. Default Behavior and Backward Compatibility . . . . . . . 17 88 8.2. Composite Flow Specifications . . . . . . . . . . . . . . 17 89 8.3. Modifying Flow Specifications . . . . . . . . . . . . . . 17 90 8.4. Multiple Flow Specifications . . . . . . . . . . . . . . 18 91 8.5. Adding and Removing Flow Specifications . . . . . . . . . 18 92 8.6. VPN Identifiers . . . . . . . . . . . . . . . . . . . . . 18 93 8.7. Priorities and Overlapping Flow Specifications . . . . . 19 94 9. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 19 95 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 96 10.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 23 97 10.1.1. PCEP FLOWSPEC Object Flag Field . . . . . . . . . . 23 99 10.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 23 100 10.3. Flow Specification TLV Type Indicators . . . . . . . . . 24 101 10.4. PCEP Error Codes . . . . . . . . . . . . . . . . . . . . 24 102 10.5. PCE Capability Flag . . . . . . . . . . . . . . . . . . 25 103 11. Implementation Status . . . . . . . . . . . . . . . . . . . . 25 104 12. Security Considerations . . . . . . . . . . . . . . . . . . . 26 105 13. Manageability Considerations . . . . . . . . . . . . . . . . 27 106 13.1. Management of Multiple Flow Specifications . . . . . . . 27 107 13.2. Control of Function through Configuration and Policy . . 28 108 13.3. Information and Data Models . . . . . . . . . . . . . . 28 109 13.4. Liveness Detection and Monitoring . . . . . . . . . . . 28 110 13.5. Verifying Correct Operation . . . . . . . . . . . . . . 29 111 13.6. Requirements on Other Protocols and Functional 112 Components . . . . . . . . . . . . . . . . . . . . . . . 29 113 13.7. Impact on Network Operation . . . . . . . . . . . . . . 29 114 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 115 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 116 15.1. Normative References . . . . . . . . . . . . . . . . . . 29 117 15.2. Informative References . . . . . . . . . . . . . . . . . 31 118 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 33 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 121 1. Introduction 123 [RFC4655] defines the Path Computation Element (PCE), a functional 124 component capable of computing paths for use in traffic engineering 125 networks. PCE was originally conceived for use in Multiprotocol 126 Label Switching (MPLS) for Traffic Engineering (TE) networks to 127 derive the routes of Label Switched Paths (LSPs). However, the scope 128 of PCE was quickly extended to make it applicable to Generalized MPLS 129 (GMPLS)-controlled networks, and more recent work has brought other 130 traffic engineering technologies and planning applications into scope 131 (for example, Segment Routing (SR) [RFC8664]). 133 [RFC5440] describes the Path Computation Element Communication 134 Protocol (PCEP). PCEP defines the communication between a Path 135 Computation Client (PCC) and a PCE, or between PCE and PCE, enabling 136 computation of path for MPLS-TE LSPs. 138 Stateful PCE [RFC8231] specifies a set of extensions to PCEP to 139 enable control of TE-LSPs by a PCE that retains state about the LSPs 140 provisioned in the network (a stateful PCE). [RFC8281] describes the 141 setup, maintenance, and teardown of LSPs initiated by a stateful PCE 142 without the need for local configuration on the PCC, thus allowing 143 for a dynamic network that is centrally controlled. [RFC8283] 144 introduces the architecture for PCE as a central controller and 145 describes how PCE can be viewed as a component that performs 146 computation to place 'flows' within the network and decide how these 147 flows are routed. 149 The description of traffic flows by the combination of multiple Flow 150 Specification Components and their dissemination as traffic flow 151 specifications (Flow Specifications) is described for BGP in 152 [RFC8955]. In BGP, a Flow Specification is comprised of traffic 153 filtering rules and is associated with actions to perform on the 154 packets that match the Flow Specification. The BGP routers that 155 receive a Flow Specification can classify received packets according 156 to the traffic filtering rules and can direct packets based on the 157 associated actions. 159 When a PCE is used to initiate tunnels (such as TE-LSPs or SR paths) 160 using PCEP, it is important that the head end of the tunnels 161 understands what traffic to place on each tunnel. The data flows 162 intended for a tunnel can be described using Flow Specification 163 Components. When PCEP is in use for tunnel initiation it makes sense 164 for that same protocol to be used to distribute the Flow 165 Specification Components that describe what data is to flow on those 166 tunnels. 168 This document specifies a set of extensions to PCEP to support 169 dissemination of Flow Specification Components. We term the 170 description of a traffic flow using Flow Specification Components as 171 a "Flow Specification". This term is conceptually the same as the 172 term used in [RFC8955], however, no mechanism is provided to 173 distribute an action associated with the Flow Specification because 174 there is only one action that is applicable in the PCEP context (that 175 is, directing the matching traffic to the identified LSP). 177 The extensions defined in this document include the creation, update, 178 and withdrawal of Flow Specifications via PCEP, and can be applied to 179 tunnels initiated by the PCE or to tunnels where control is delegated 180 to the PCE by the PCC. Furthermore, a PCC requesting a new path can 181 include Flow Specifications in the request to indicate the purpose of 182 the tunnel allowing the PCE to factor this into the path computation. 184 Flow Specifications are carried in TLVs within a new object called 185 the FLOWSPEC object defined in this document. The flow filtering 186 rules indicated by the Flow Specifications are mainly defined by BGP 187 Flow Specifications. 189 Note that PCEP-installed Flow Specifications are intended to be 190 installed only at the head-end of the LSP to which they direct 191 traffic. It is acceptable (and potentially desirable) that other 192 routers in the network have Flow Specifications installed that match 193 the same traffic, but direct it onto different routes or to different 194 LSPs. Those other Flow Specifications may be installed using the 195 PCEP extensions defined in this document, may be distributed using 196 BGP per [RFC8955], or may be configured using manual operations. 197 Since this document is about PCEP-installed Flow Specifications, 198 those other Flow Specifications at other routers are out of scope. 199 In this context, however, it is worth noting that changes to the 200 wider routing system (such as the distribution and installation of 201 BGP Flow Specifications, or fluctuations in the IGP link state 202 database) might mean that traffic matching the PCEP Flow 203 Specification never reaches the head end of the LSP at which the PCEP 204 Flow Specification has been installed. This may or may not be 205 desirable according to the operator's traffic engineering and routing 206 policies, and is particularly applicable at LSPs that do not have 207 their head ends at the ingress-edge of the network, but it is not an 208 effect that this document seeks to address. 210 2. Terminology 212 This document uses the following terms defined in [RFC5440]: PCC, 213 PCE, PCEP Peer. 215 The following term from [RFC8955] is used frequently throughout this 216 document: 218 A Flow Specification is an n-tuple consisting of several matching 219 criteria that can be applied to IP traffic. A given IP packet is 220 said to match the defined Flow Specification if it matches all the 221 specified criteria. 223 [RFC8955] also states that "A given Flow Specification may be 224 associated with a set of attributes," and that, "...attributes can be 225 used to encode a set of predetermined actions." However, in the 226 context of this document, no action is explicitly specified 227 associated with the Flow Specification since the action "forward all 228 matching traffic onto the associated path" is implicit. 230 How an implementation decides how to filter traffic that matches a 231 Flow Specification does not form part of this specification, but a 232 flag is provided to indicate whether the sender of a PCEP message 233 that includes a Flow Specification intends it to be installed as a 234 Longest Prefix Match route or as a Flow Specification policy. 236 This document uses the terms "stateful PCE" and "active PCE" as 237 advocated in [RFC7399]. 239 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 240 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 241 "OPTIONAL" in this document are to be interpreted as described in BCP 242 14 [RFC2119] [RFC8174] when, and only when, they appear in all 243 capitals, as shown here. 245 3. Procedures for PCE Use of Flow Specifications 247 3.1. Context for PCE Use of Flow Specifications 249 In the PCE architecture there are five steps in the setup and use of 250 LSPs: 252 1. Decide which LSPs to set up. The decision may be made by a user, 253 by a PCC, or by the PCE. There can be a number of triggers for 254 this including user intervention and dynamic response to changes 255 in traffic demands. 257 2. Decide what properties to assign to an LSP. This can include 258 bandwidth reservations, priorities, and DSCP (i.e., MPLS Traffic 259 Class field). This function is also determined by user 260 configuration or in response to predicted or observed traffic 261 demands. 263 3. Decide what traffic to put on the LSP. This is effectively 264 determining which traffic flows to assign to which LSPs, and 265 practically, this is closely linked to the first two decisions 266 listed above. 268 4. Cause the LSP to be set up and modified to have the right 269 characteristics. This will usually involve the PCE advising or 270 instructing the PCC at the head end of the LSP, and the PCC will 271 then signal the LSP across the network. 273 5. Tell the head end of the LSP what traffic to put on the LSP. 274 This may happen after or at the same time as the LSP is set up. 275 This step is the subject of this document. 277 3.2. Elements of Procedure 279 There are three elements of procedure: 281 o A PCE and a PCC must be able to indicate whether or not they 282 support the use of Flow Specifications. 284 o A PCE or PCC must be able to include Flow Specifications in PCEP 285 messages with clear understanding of the applicability of those 286 Flow Specifications in each case. This includes whether the use 287 of such information is mandatory, constrained, or optional, and 288 how overlapping Flow Specifications will be resolved. 290 o Flow Specification information/state must be synchronized between 291 PCEP peers so that, on recovery, the peers have the same 292 understanding of which Flow Specifications apply just as is 293 required in the case of stateful PCE and LSP delegation (see 294 Section 5.6 of [RFC8231]). 296 The following subsections describe these points. 298 3.2.1. Capability Advertisement 300 As with most PCEP capability advertisements, the ability to support 301 Flow Specifications can be indicated in the PCEP OPEN message or in 302 IGP PCE capability advertisements. 304 3.2.1.1. PCEP OPEN Message 306 During PCEP session establishment, a PCC or PCE that supports the 307 procedures described in this document announces this fact by 308 including the "PCE FlowSpec Capability" TLV (described in Section 4) 309 in the OPEN Object carried in the PCEP Open message. 311 The presence of the PCE FlowSpec Capability TLV in the OPEN Object in 312 a PCE's OPEN message indicates that the PCE can distribute FlowSpecs 313 to PCCs and can receive FlowSpecs in messages from PCCs. 315 The presence of the PCE FlowSpec Capability TLV in the OPEN Object in 316 a PCC's OPEN message indicates that the PCC supports the FlowSpec 317 functionality described in this document. 319 If either one of a pair of PCEP peers does not include the PCE 320 FlowSpec Capability TLV in the OPEN Object in its OPEN message, then 321 the other peer MUST NOT include a FLOWSPEC object in any PCEP message 322 sent to the peer. If a FLOWSPEC object is received when support has 323 not been indicated, the receiver will respond with a PCErr message 324 reporting the objects containing the FlowSpec as described in 325 [RFC5440]: that is, it will use 'Unknown Object' if it does not 326 support this specification, and 'Not supported object' if it supports 327 this specification but has not chosen to support FLOWSPEC objects on 328 this PCEP session. 330 3.2.1.2. IGP PCE Capabilities Advertisement 332 The ability to advertise support for PCEP and PCE features in IGP 333 advertisements is provided for OSPF in [RFC5088] and for IS-IS in 334 [RFC5089]. The mechanism uses the PCE Discovery TLV which has a PCE- 335 CAP-FLAGS sub-TLV containing bit-flags each of which indicates 336 support for a different feature. 338 This document defines a new PCE-CAP-FLAGS sub-TLV bit, the FlowSpec 339 Capable flag (bit number TBD1). Setting the bit indicates that an 340 advertising PCE supports the procedures defined in this document. 342 Note that while PCE FlowSpec Capability may be advertised during 343 discovery, PCEP speakers that wish to use Flow Specification in PCEP 344 MUST negotiate PCE FlowSpec Capability during PCEP session setup, as 345 specified in Section 3.2.1.1. A PCC MAY initiate PCE FlowSpec 346 Capability negotiation at PCEP session setup even if it did not 347 receive any IGP PCE capability advertisement, and a PCEP peer that 348 advertised support for FlowSpec in the IGP is not obliged to support 349 these procedures on any given PCEP session. 351 3.2.2. Dissemination Procedures 353 This section describes the procedures to support Flow Specifications 354 in PCEP messages. 356 The primary purpose of distributing Flow Specification information is 357 to allow a PCE to indicate to a PCC what traffic it should place on a 358 path (such as an LSP or an SR path). This means that the Flow 359 Specification may be included in: 361 o PCInitiate messages so that an active PCE can indicate the traffic 362 to place on a path at the time that the PCE instantiates the path. 364 o PCUpd messages so that an active PCE can indicate or change the 365 traffic to place on a path that has already been set up. 367 o PCRpt messages so that a PCC can report the traffic that the PCC 368 will place on the path. 370 o PCReq messages so that a PCC can indicate what traffic it plans to 371 place on a path at the time it requests the PCE to perform a 372 computation in case that information aids the PCE in its work. 374 o PCRep messages so that a PCE that has been asked to compute a path 375 can suggest which traffic could be placed on a path that a PCC may 376 be about to set up. 378 o PCErr messages so that issues related to paths and the traffic 379 they carry can be reported to the PCE by the PCC, and so that 380 problems with other PCEP messages that carry Flow Specifications 381 can be reported. 383 To carry Flow Specifications in PCEP messages, this document defines 384 a new PCEP object called the PCEP FLOWSPEC object. The object is 385 OPTIONAL in the messages described above and MAY appear more than 386 once in each message. 388 To describe a traffic flow, the PCEP FLOWSPEC object carries a Flow 389 Filter TLV. 391 The inclusion of multiple PCEP FLOWSPEC objects allows multiple 392 traffic flows to be placed on a single path. 394 Once a PCE and PCC have established that they can both support the 395 use of Flow Specifications in PCEP messages, such information may be 396 exchanged at any time for new or existing paths. 398 The application and prioritization of Flow Specifications is 399 described in Section 8.7. 401 As per [RFC8231], any attributes of the path received from a PCE are 402 subject to PCC's local policy. This holds good for the Flow 403 Specifications as well. 405 3.2.3. Flow Specification Synchronization 407 The Flow Specifications are carried along with the LSP State 408 information as per [RFC8231] making the Flow Specifications part of 409 the LSP database (LSP-DB). Thus, the synchronization of the Flow 410 Specification information is done as part of LSP-DB synchronization. 411 This may be achieved using normal state synchronization procedures as 412 described in [RFC8231] or enhanced state synchronization procedures 413 as defined in [RFC8232]. 415 The approach selected will be implementation and deployment specific 416 and will depend on issues such as how the databases are constructed 417 and what level of synchronization support is needed. 419 4. PCE FlowSpec Capability TLV 421 The PCE-FLOWSPEC-CAPABILITY TLV is an optional TLV that can be 422 carried in the OPEN Object [RFC5440] to exchange PCE FlowSpec 423 capabilities of the PCEP speakers. 425 The format of the PCE-FLOWSPEC-CAPABILITY TLV follows the format of 426 all PCEP TLVs as defined in [RFC5440] and is shown in Figure 1. 428 0 1 2 3 429 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 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Type=TBD2 | Length=2 | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Value=0 | Padding | 434 +---------------------------------------------------------------+ 436 Figure 1: PCE-FLOWSPEC-CAPABILITY TLV format 438 The type of the PCE-FLOWSPEC-CAPABILITY TLV is TBD2 and it has a 439 fixed length of 2 octets. The Value field MUST be set to 0 and MUST 440 be ignored on receipt. The two bytes of padding MUST be set to zero 441 and ignored on receipt. 443 The inclusion of this TLV in an OPEN object indicates that the sender 444 can perform FlowSpec handling as defined in this document. 446 5. PCEP FLOWSPEC Object 448 The PCEP FLOWSPEC object defined in this document is compliant with 449 the PCEP object format defined in [RFC5440]. It is OPTIONAL in the 450 PCReq, PCRep, PCErr, PCInitiate, PCRpt, and PCUpd messages and MAY be 451 present zero, one, or more times. Each instance of the object 452 specifies a separate traffic flow. 454 The PCEP FLOWSPEC object MAY carry a FlowSpec filter rule encoded in 455 a Flow Filter TLV as defined in Section 6. 457 The FLOWSPEC Object-Class is TBD3 (to be assigned by IANA). 459 The FLOWSPEC Object-Type is 1. 461 The format of the body of the PCEP FLOWSPEC object is shown in 462 Figure 2 463 0 1 2 3 464 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 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | FS-ID | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | AFI | Reserved | Flags |L|R| 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | | 471 // TLVs // 472 | | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 Figure 2: PCEP FLOWSPEC Object Body Format 477 FS-ID (32-bits): A PCEP-specific identifier for the FlowSpec 478 information. A PCE or PCC creates an FS-ID for each FlowSpec that it 479 originates, and the value is unique within the scope of that PCE or 480 PCC and is constant for the lifetime of a PCEP session. All 481 subsequent PCEP messages can identify the FlowSpec using the FS-ID. 482 The values 0 and 0xFFFFFFFF are reserved and MUST NOT be used. Note 483 that [I-D.gont-numeric-ids-sec-considerations] gives advice on 484 assigning transient numeric identifiers such as the FS-ID so as to 485 minimise security risks. 487 AFI (16-bits): Address Family Identifier as used in BGP [RFC4760] 488 (AFI=1 for IPv4 or VPNv4, AFI=2 for IPv6 and VPNv6 as per as per 489 [RFC8956]). 491 Reserved (8-bits): MUST be set to zero on transmission and ignored on 492 receipt. 494 Flags (8-bits): Two flags are currently assigned - 496 R bit: The Remove bit is set when a PCEP FLOWSPEC object is 497 included in a PCEP message to indicate removal of the Flow 498 Specification from the associated tunnel. If the bit is clear, 499 the Flow Specification is being added or modified. 501 L bit: The Longest Prefix Match (LPM) bit is set to indicate that 502 the Flow Specification is to be installed as a route subject to 503 longest prefix match forwarding. If the bit is clear, the Flow 504 Specification described by the Flow Filter TLV (see Section 6) is 505 to be installed as a Flow Specification. If the bit is set, only 506 Flow Specifications that describe IPv4 or IPv6 destinations are 507 meaningful in the Flow Filter TLV and others are ignored. If the 508 L is set and the receiver does not support the use of Flow 509 Specifications that are present in the Flow Filter TLV for the 510 installation of a route subject to longest prefix match 511 forwarding, then the PCEP peer MUST respond with a PCErr message 512 with error-type TBD8 (FlowSpec Error) and error-value 5 513 (Unsupported LPM Route). 515 Unassigned bits MUST be set to zero on transmission and ignored on 516 receipt. 518 If the PCEP speaker receives a message with R bit set in the FLOWSPEC 519 object and the Flow Specification identified with a FS-ID does not 520 exist, it MUST generate a PCErr with Error-type TBD8 (FlowSpec 521 Error), error-value 4 (Unknown FlowSpec). 523 If the PCEP speaker does not understand or support the AFI in the 524 FLOWSPEC message, the PCEP peer MUST respond with a PCErr message 525 with error-type TBD8 (FlowSpec Error), error-value 2 (Malformed 526 FlowSpec). 528 The following TLVs can be used in the FLOWSPEC object: 530 o Speaker Entity Identifier TLV: As specified in [RFC8232], the 531 SPEAKER-ENTITY-ID TLV encodes a unique identifier for the node 532 that does not change during the lifetime of the PCEP speaker. 533 This is used to uniquely identify the FlowSpec originator and thus 534 used in conjunction with FS-ID to uniquely identify the FlowSpec 535 information. This TLV MUST be included. If the TLV is missing, 536 the PCEP peer MUST respond with a PCErr message with error-type 537 TBD8 (FlowSpec Error), error-value 2 (Malformed FlowSpec). If 538 more than one instance of this TLV is present, the first MUST be 539 processed and subsequence instances MUST be ignored. 541 o Flow Filter TLV (variable): One TLV MAY be included. The Flow 542 Filter TLV is OPTIONAL when the R bit is set. 544 The Flow Filter TLV MUST be present when the R bit is clear. If the 545 TLV is missing when the R bit is clear, the PCEP peer MUST respond 546 with a PCErr message with error-type TBD8 (FlowSpec Error) and error- 547 value 2 (Malformed FlowSpec). 549 Filtering based on the L2 fields is out of scope of this document. 551 6. Flow Filter TLV 553 One new PCEP TLV is defined to convey Flow Specification filtering 554 rules that specify what traffic is carried on a path. The TLV 555 follows the format of all PCEP TLVs as defined in [RFC5440]. The 556 Type field values come from the codepoint space for PCEP TLVs and has 557 the value TBD4 for Flow Filter TLV. 559 The Value field of the TLV contain one or more sub-TLVs (the Flow 560 Specification TLVs) as defined in Section 7, and they represent the 561 complete definition of a Flow Specification for traffic to be placed 562 on the tunnel. This tunnel is indicated by the PCEP message in which 563 the PCEP FLOWSPEC object is carried. The set of Flow Specification 564 TLVs in a single instance of a Flow Filter TLV are combined to 565 indicate the specific Flow Specification. Note that the PCEP 566 FLOWSPEC object can include just one Flow Filter TLV. 568 Further Flow Specifications can be included in a PCEP message by 569 including additional FLOWSPEC objects. 571 In future, there may be a desire to add support for L2 Flow 572 Specifications (such as described in [I-D.ietf-idr-flowspec-l2vpn]). 574 7. Flow Specification TLVs 576 The Flow Filter TLV carries one or more Flow Specification TLVs. The 577 Flow Specification TLV follows the format of all PCEP TLVs as defined 578 in [RFC5440]. However, the Type values are selected from a separate 579 IANA registry (see Section 10.3) rather than from the common PCEP TLV 580 registry. 582 Type values are chosen so that there can be commonality with Flow 583 Specifications defined for use with BGP [RFC8955] and [RFC8956]. 584 This is possible because the BGP Flow Spec encoding uses a single 585 octet to encode the type where as PCEP uses two octets. Thus the 586 space of values for the Type field is partitioned as shown in 587 Figure 3. 589 Range | 590 ---------------+--------------------------------------------------- 591 0 .. 255 | Per BGP registry defined by 592 | [RFC8955] and [RFC8956]. 593 | Not to be allocated in this registry. 594 | 595 256 .. 65535 | New PCEP Flow Specifications allocated according 596 | to the registry defined in this document. 598 Figure 3: Flow Specification TLV Type Ranges 600 [RFC8955] is the reference for the registry "Flow Spec Component 601 Types" and defines the allocations it contains. [RFC8956] requested 602 for another registry "Flow Spec IPv6 Component Types" and requested 603 initial allocations in it. If the AFI (in the FLOWSPEC object) is 604 set to IPv4, the range 0..255 is as per "Flow Spec Component Types" 606 [RFC8955]; if the AFI is set to IPv6, the range 0..255 is as per 607 "Flow Spec IPv6 Component Types" [RFC8956]. 609 The content of the Value field in each TLV is specific to the type/ 610 AFI and describes the parameters of the Flow Specification. The 611 definition of the format of many of these Value fields is inherited 612 from BGP specifications. Specifically, the inheritance is from 613 [RFC8955] and [RFC8956], but may also be inherited from future BGP 614 specifications. 616 When multiple Flow Specification TLVs are present in a single Flow 617 Filter TLV they are combined to produce a more detailed specification 618 of a flow. For examples and rules about how this is achieved, see 619 [RFC8955]. As described in [RFC8955] where it says "A given 620 component type MAY (exactly once) be present in the Flow 621 Specification," a Flow Filter TLV MUST NOT contain more than one Flow 622 Specification TLV of the same type: an implementation that receives a 623 PCEP message with a Flow Flter TLV that contains more than one Flow 624 Specification TLV of the same type MUST respond with a PCErr message 625 with error-type TBD8 (FlowSpec Error), error-value 2 (Malformed 626 FlowSpec) and MUST NOT install the Flow Specification. 628 An implementation that receives a PCEP message carrying a Flow 629 Specification TLV with a type value that it does not recognize or 630 does not support MUST respond with a PCErr message with error-type 631 TBD8 (FlowSpec Error), error-value 1 (Unsupported FlowSpec) and MUST 632 NOT install the Flow Specification. 634 When used in other protocols (such as BGP), these Flow Specifications 635 are also associated with actions to indicate how traffic matching the 636 Flow Specification should be treated. In PCEP, however, the only 637 action is to associate the traffic with a tunnel and to forward 638 matching traffic onto that path, so no encoding of an action is 639 needed. 641 Section 8.7 describes how overlapping Flow Specifications are 642 prioritized and handled. 644 All Flow Specification TLVs with Types in the range 0 to 255 have 645 Values defined for use in BGP (for example, in [RFC8955] and 646 [RFC8956]) and are set using the BGP encoding, but without the type 647 octet (the relevant information is in the Type field of the TLV). 648 The Value field is padded with trailing zeros to achieve 4-byte 649 alignment. 651 This document defines the following new types: 653 +-------+-------------------------+-----------------------------+ 654 | Type | Description | Value defined in | 655 | | | | 656 +-------+-------------------------+-----------------------------+ 657 | TBD5 | Route Distinguisher | [This.I-D] | 658 +-------+-------------------------+-----------------------------+ 659 | TBD6 | IPv4 Multicast Flow | [This.I-D] | 660 +-------+-------------------------+-----------------------------+ 661 | TBD7 | IPv6 Multicast Flow | [This.I-D] | 662 +-------+-------------------------+-----------------------------+ 664 Figure 4: Table of Flow Specification TLV Types defined in this 665 document 667 To allow identification of a VPN in PCEP via a Route Distinguisher 668 (RD) [RFC4364], a new TLV - ROUTE-DISTINGUISHER TLV is defined in 669 this document. A Flow Specification TLV with Type TBD5 (ROUTE- 670 DISTINGUISHER TLV) carries an RD Value, used to identify that other 671 flow filter information (for example, an IPv4 destination prefix) is 672 associated with a specific VPN identified by the RD. See Section 8.6 673 for further discussion of VPN identification. 675 0 1 2 3 676 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 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | Type=[TBD5] | Length=8 | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | Route Distinguisher | 681 | | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 Figure 5: The Format of the ROUTE-DISTINGUISHER TLV 686 The format of RD is as per [RFC4364]. 688 Although it may be possible to describe a multicast Flow 689 Specification from the combination of other Flow Specification TLVs 690 with specific values, it is more convenient to use a dedicated Flow 691 Specification TLV. Flow Specification TLVs with Type values TBD6 and 692 TBD7 are used to identify a multicast flow for IPv4 and IPv6 693 respectively. The Value field is encoded as shown in Figure 6. 695 0 1 2 3 696 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 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Reserved |S|G| Src Mask Len | Grp Mask Len | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 ~ Source Address ~ 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 ~ Group multicast Address ~ 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 Figure 6: Multicast Flow Specification TLV Encoding 707 The address fields and address mask lengths of the two Multicast Flow 708 Specification TLVs contain source and group prefixes for matching 709 against packet flows noting that the two address fields are 32 bits 710 for an IPv4 Multicast Flow and 128 bits for an IPv6 Multicast Flow. 712 The Reserved field MUST be set to zero and ignored on receipt. 714 Two bit flags (S and G) are defined to describe the multicast 715 wildcarding in use. If the S bit is set, then source wildcarding is 716 in use and the values in the Source Mask Length and Source Address 717 fields MUST be ignored. If the G bit is set, then group wildcarding 718 is in use and the values in the Group Mask Length and Group multicast 719 Address fields MUST be ignored. The G bit MUST NOT be set unless the 720 S bit is also set: if a Multicast Flow Specification TLV is received 721 with S bit = 0 and G bit = 1 the receiver MUST respond with a PCErr 722 with Error-type TBD8 (FlowSpec Error) and error-value 2 (Malformed 723 FlowSpec). 725 The three multicast mappings may be achieved as follows: 727 (S, G) - S bit = 0, G bit = 0, the Source Address and Group 728 multicast Address prefixes are both used to define the multicast 729 flow. 731 (*, G) - S bit = 1, G bit = 0, the Group multicast Address prefix 732 is used to define the multicast flow, but the Source Address 733 prefix is ignored. 735 (*, *) = S bit = 1, G bit = 1, the Source Address and Group 736 multicast Address prefixes are both ignored. 738 8. Detailed Procedures 740 This section outlines some specific detailed procedures for using the 741 protocol extensions defined in this document. 743 8.1. Default Behavior and Backward Compatibility 745 The default behavior is that no Flow Specification is applied to a 746 tunnel. That is, the default is that the FLOWSPEC object is not used 747 as is the case in all systems before the implementation of this 748 specification. 750 In this case, it is a local matter (such as through configuration) 751 how tunnel head ends are instructed what traffic to place on a 752 tunnel. 754 [RFC5440] describes how receivers respond when they see unknown PCEP 755 objects. 757 8.2. Composite Flow Specifications 759 Flow Specifications may be represented by a single Flow Specification 760 TLV or may require a more complex description using multiple Flow 761 Specification TLVs. For example, a flow indicated by a source- 762 destination pair of IPv6 addresses would be described by the 763 combination of Destination IPv6 Prefix and Source IPv6 Prefix Flow 764 Specification TLVs. 766 8.3. Modifying Flow Specifications 768 A PCE may want to modify a Flow Specification associated with a 769 tunnel, or a PCC may want to report a change to the Flow 770 Specification it is using with a tunnel. 772 It is important that the specific Flow Specification is identified so 773 that it is clear that this is a modification of an existing flow and 774 not the addition of a new flow as described in Section 8.4. The FS- 775 ID field of the PCEP FLOWSPEC object is used to identify a specific 776 Flow Specification in the context of the content of the Speaker 777 Entity Identifier TLV. 779 When modifying a Flow Specification, all Flow Specification TLVs for 780 the intended specification of the flow MUST be included in the PCEP 781 FLOWSPEC object. the FS-ID MUST be retained from the previous 782 description of the flow, and the same Speaker Entity Identity TLV 783 MUST be used. 785 8.4. Multiple Flow Specifications 787 It is possible that traffic from multiple flows will be placed on a 788 single tunnel. In some cases it is possible to define these within a 789 single PCEP FLOWSPEC object by widening the scope of a Flow 790 Specification TLV: for example, traffic to two destination IPv4 791 prefixes might be captured by a single Flow Specification TLV with 792 type 'Destination' with a suitably adjusted prefix. However, this is 793 unlikely to be possible in most scenarios, and it must be recalled 794 that it is not permitted to include two Flow Specification TLVs of 795 the same type within one Flow Filter TLV. 797 The normal procedure, therefore, is to carry each Flow Specification 798 in its own PCEP FLOWSPEC object. Multiple objects may be present on 799 a single PCEP message, or multiple PCEP messages may be used. 801 8.5. Adding and Removing Flow Specifications 803 The Remove bit in the PCEP FLOWSPEC object is left clear when a Flow 804 Specification is being added or modified. 806 To remove a Flow Specification, a PCEP FLOWSPEC object is included 807 with the FS-ID matching the one being removed, and the R bit set to 808 indicate removal. In this case it is not necessary to include any 809 Flow Specification TLVs. 811 If the R bit is set and Flow Specification TLVs are present, an 812 implementation MAY ignore them. If the implementation checks the 813 Flow Specification TLVs against those recorded for the FS-ID and 814 Speaker Entity Identity of the Flow Specification being removed and 815 finds a mismatch, the Flow Specification matching the FS-ID MUST 816 still be removed and the implementation SHOULD record a local 817 exception or log. 819 8.6. VPN Identifiers 821 VPN instances are identified in BGP using Route Distinguishers (RDs) 822 [RFC4364]. These values are not normally considered to have any 823 meaning outside of the network, and they are not encoded in data 824 packets belonging to the VPNs. However, RDs provide a useful way of 825 identifying VPN instances and are often manually or automatically 826 assigned to VPNs as they are provisioned. 828 Thus the RD provides a useful way to indicate that traffic for a 829 particular VPN should be placed on a given tunnel. The tunnel head 830 end will need to interpret this Flow Specification not as a filter on 831 the fields of data packets, but using the other mechanisms that it 832 already uses to identify VPN traffic. This could be based on the 833 incoming port (for port-based VPNs) or may leverage knowledge of the 834 VRF that is in use for the traffic. 836 8.7. Priorities and Overlapping Flow Specifications 838 Flow specifications can overlap. For example, two different flow 839 specifications may be identical except for the length of the prefix 840 in the destination address. In these cases the PCC must determine 841 how to prioritize the flow specifications so as to know to which path 842 to assign packets that match both flow specifications. That is, the 843 PCC must assign a precedence to the flow specifications so that it 844 checks each incoming packet for a match in a predictable order. 846 The processing of BGP Flow Specifications is described in [RFC8955]. 847 Section 5.1 of that document explains the order of traffic filtering 848 rules to be executed by an implementation of that specification. 850 PCCs MUST apply the same ordering rules as defined in [RFC8955]. 852 Furthermore, it is possible that Flow Specifications will be 853 distributed by BGP as well as by PCEP as described in this document. 854 In such cases implementations supporting both approaches MUST apply 855 the prioritization and ordering rules as set out in [RFC8955] 856 regardless of which protocol distributed the Flow Specifications. 857 However, implementations MAY provide a configuration control to allow 858 one protocol to take precedence over the other as this may be 859 particularly useful if the Flow Specifications make identical matches 860 on traffic, but have different actions. It is RECOMMENDED that when 861 two Flow Specifications distributed by different protocols overlap, 862 and especially when one acts to replace another, that a message be 863 logged for the operator to understand the behaviour. 865 Section 13.1 of this document covers manageability considerations 866 relevant to the prioritized ordering of flow specifications. 868 An implementation that receives a PCEP message carrying a Flow 869 Specification that it cannot resolve against other Flow 870 Specifications already installed (for example, because the new Flow 871 Specification has irresolvable conflicts with other Flow 872 Specifications that are already installed) MUST respond with a PCErr 873 message with error-type TBD8 (FlowSpec Error), error-value 3 874 (Unresolvable Conflict) and MUST NOT install the Flow Specification. 876 9. PCEP Messages 878 This section describes the format of messages that contain FLOWSPEC 879 objects. The only difference to previous message formats is the 880 inclusion of that object. 882 The figures in this section use the notation defined in [RFC5511]. 884 The FLOWSPEC object is OPTIONAL and MAY be carried in the PCEP 885 messages. 887 The PCInitiate message is defined in [RFC8281] and updated as below: 889 ::= 890 892 Where: 893 ::= 894 [] 896 ::= 897 ( | 898 ) 900 ::= 901 902 [] 903 904 [] 905 [] 907 Where: 908 ::= [] 910 The PCUpd message is defined in [RFC8231] and updated as below: 912 ::= 913 915 Where: 916 ::= 917 [] 919 ::= 920 921 922 [] 924 Where: 925 ::= 927 ::= [] 929 The PCRpt message is defined in [RFC8231] and updated as below: 931 ::= 932 934 Where: 935 ::= [] 937 ::= [] 938 939 940 [] 942 Where: 943 ::= 944 [] 945 947 ::= [] 949 The PCReq message is defined in [RFC5440] and updated in [RFC8231], 950 it is further updated below for flow specification: 952 ::= 953 [] 954 956 Where: 957 ::= [] 959 ::= [] 961 ::= 962 963 [] 964 [] 965 [] 966 [] 967 [[]] 968 [] 969 [] 970 [] 972 Where: 973 ::= [] 975 The PCRep message is defined in [RFC5440] and updated in [RFC8231], 976 it is further updated below for flow specification: 978 ::= 979 981 Where: 982 ::=[] 984 ::= 985 [] 986 [] 987 [] 988 [] 989 [] 991 Where: 992 ::= [] 994 10. IANA Considerations 996 IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" 997 registry. This document requests IANA actions to allocate code 998 points for the protocol elements defined in this document. 1000 10.1. PCEP Objects 1002 Each PCEP object has an Object-Class and an Object-Type. IANA 1003 maintains a subregistry called "PCEP Objects". IANA is requested to 1004 make an assignment from this subregistry as follows: 1006 Object-Class | Value Name | Object-Type | Reference 1007 -------------+-------------+------------------------+---------------- 1008 TBD3 | FLOWSPEC | 0: Reserved | [This.I-D] 1009 | | 1: Flow Specification | [This.I-D] 1011 10.1.1. PCEP FLOWSPEC Object Flag Field 1013 This document requests that a new sub-registry, named "FLOWSPEC 1014 Object Flag Field", is created within the "Path Computation Element 1015 Protocol (PCEP) Numbers" registry to manage the Flag field of the 1016 FLOWSPEC object. New values are to be assigned by Standards Action 1017 [RFC8126]. Each bit should be tracked with the following qualities: 1019 o Bit number (counting from bit 0 as the most significant bit) 1021 o Capability description 1023 o Defining RFC 1025 The initial population of this registry is as follows: 1027 Bit | Description | Reference 1028 -----+--------------------+------------- 1029 0-5 | Unnassigned | 1030 6 | LPM (L bit) | [This.I-D] 1031 7 | Remove (R bit) | [This.I-D] 1033 10.2. PCEP TLV Type Indicators 1035 IANA maintains a subregistry called "PCEP TLV Type Indicators". IANA 1036 is requested to make an assignment from this subregistry as follows: 1038 Value | Meaning | Reference 1039 --------+------------------------------+------------- 1040 TBD2 | PCE-FLOWSPEC-CAPABILITY TLV | [This.I-D] 1041 TBD4 | FLOW FILTER TLV | [This.I-D] 1043 10.3. Flow Specification TLV Type Indicators 1045 IANA is requested to create a new subregistry call the "PCEP Flow 1046 Specification TLV Type Indicators" registry. 1048 Allocations from this registry are to be made according to the 1049 following assignment policies [RFC8126]: 1051 Range | Assignment policy 1052 ---------------+--------------------------------------------------- 1053 0 .. 255 | Reserved - must not be allocated. 1054 | Usage mirrors the BGP FlowSpec registry 1055 | [RFC8955] and [RFC8956]. 1056 | 1057 256 .. 64506 | Specification Required 1058 | 1059 64507 .. 65531 | First Come First Served 1060 | 1061 65532 .. 65535 | Experimental 1063 IANA is requested to pre-populate this registry with values defined 1064 in this document as follows, taking the new values from the range 256 1065 to 64506: 1067 Value | Meaning 1068 -------+------------------------ 1069 TBD5 | Route Distinguisher 1070 TBD6 | IPv4 Multicast 1071 TBD7 | IPv6 Multicast 1073 10.4. PCEP Error Codes 1075 IANA maintains a subregistry called "PCEP-ERROR Object Error Types 1076 and Values". Entries in this subregistry are described by Error-Type 1077 and Error-value. IANA is requested to make the following assignment 1078 from this subregistry: 1080 Error-| Meaning | Error-value | Reference 1081 Type | | | 1082 -------+--------------------+----------------------------+----------- 1083 TBD8 | FlowSpec error | 0: Unassigned | [This.I-D] 1084 | | 1: Unsupported FlowSpec | [This.I-D] 1085 | | 2: Malformed FlowSpec | [This.I-D] 1086 | | 3: Unresolvable Conflict | [This.I-D] 1087 | | 4: Unknown FlowSpec | [This.I-D] 1088 | | 5: Unsupported LPM Route | [This.I-D] 1089 | | 6-255: Unassigned | [This.I-D] 1091 10.5. PCE Capability Flag 1093 IANA maintains a subregistry called "Open Shortest Path First v2 1094 (OSPFv2) Parameters" with a sub-registry called "Path Computation 1095 Element (PCE) Capability Flags". IANA is requested to assign a new 1096 capability bit from this registry as follows: 1098 Bit | Capability Description | Reference 1099 -------+-------------------------------+------------ 1100 TBD1 | FlowSpec | [This.I-D] 1102 11. Implementation Status 1104 [NOTE TO RFC EDITOR : This whole section and the reference to RFC 1105 7942 is to be removed before publication as an RFC] 1107 This section records the status of known implementations of the 1108 protocol defined by this specification at the time of posting of this 1109 Internet-Draft, and is based on a proposal described in [RFC7942]. 1110 The description of implementations in this section is intended to 1111 assist the IETF in its decision processes in progressing drafts to 1112 RFCs. Please note that the listing of any individual implementation 1113 here does not imply endorsement by the IETF. Furthermore, no effort 1114 has been spent to verify the information presented here that was 1115 supplied by IETF contributors. This is not intended as, and must not 1116 be construed to be, a catalog of available implementations or their 1117 features. Readers are advised to note that other implementations may 1118 exist. 1120 According to [RFC7942], "this will allow reviewers and working groups 1121 to assign due consideration to documents that have the benefit of 1122 running code, which may serve as evidence of valuable experimentation 1123 and feedback that have made the implemented protocols more mature. 1125 It is up to the individual working groups to use this information as 1126 they see fit". 1128 At the time of posting the -12 version of this document, there are no 1129 known implementations of this mechanism. It is believed that two 1130 vendors are considering prototype implementations, but these plans 1131 are too vague to make any further assertions. 1133 12. Security Considerations 1135 We may assume that a system that utilizes a remote PCE is subject to 1136 a number of vulnerabilities that could allow spurious LSPs or SR 1137 paths to be established or that could result in existing paths being 1138 modified or torn down. Such systems, therefore, apply security 1139 considerations as described in [RFC5440], Section 2.5 of [RFC6952], 1140 [RFC8253], and [RFC8955]. 1142 The description of Flow Specifications associated with paths set up 1143 or controlled by a PCE add a further detail that could be attacked 1144 without tearing down LSPs or SR paths, but causing traffic to be 1145 misrouted within the network. Therefore, the use of the security 1146 mechanisms for PCEP referenced above is important. 1148 Visibility into the information carried in PCEP does not have direct 1149 privacy concerns for end-users' data, however, knowledge of how data 1150 is routed in a network may make that data more vulnerable. Of 1151 course, the ability to interfere with the way data is routed also 1152 makes the data more vulnerable. Furthermore, knowledge of the 1153 connected end-points (such as multicast receivers or VPN sites) is 1154 usually considered private customer information. Therefore, 1155 implementations or deployments concerned with protecting privacy MUST 1156 apply the mechanisms described in the documents referenced above: in 1157 particular to secure the PCEP session using IPSec per Sections 10.4 1158 to 10.6 of [RFC5440] or TLS per [RFC8253]. Note that TCP-MD5 1159 security as originally suggested in [RFC5440] does not provide 1160 sufficient security or privacy guarantees, and SHOULD NOT be relied 1161 upon. 1163 Experience with Flow Specifications in BGP systems indicates that 1164 they can become complex and that the overlap of Flow Specifications 1165 installed in different orders can lead to unexpected results. 1166 Although this is not directly a security issue per se, the confusion 1167 and unexpected forwarding behavior may be engineered or exploited by 1168 an attacker. Furthermore, this complexity might give rise to a 1169 situation where the forwarding behaviors might create gaps in the 1170 monitoring and inspection of particular traffic or provide a path 1171 that avoids expected mitigations. Therefore, implementers and 1172 operators SHOULD pay careful attention to the Manageability 1173 Considerations described in Section 13 and familiarize themselves 1174 with the careful explanations in [RFC8955]. 1176 13. Manageability Considerations 1178 The feature introduced by this document enables operational 1179 manageability of networks operated in conjunction with a PCE and 1180 using PCEP. Without this feature, but in the case of a stateful 1181 active PCE or with PCE-initiated services, additional manual 1182 configuration is needed to tell the head-ends what traffic to place 1183 on the network services (LSPs, SR paths, etc.). 1185 This section follows the advice and guidance of [RFC6123]. 1187 13.1. Management of Multiple Flow Specifications 1189 Experience with flow specification in BGP suggests that there can be 1190 a lot of complexity when two or more flow specifications overlap. 1191 This can arise, for example, with addresses indicated using prefixes, 1192 and could cause confusion about what traffic should be placed on 1193 which path. Unlike the behavior in a distributed routing system, it 1194 is not important to the routing stablity and consistency of the 1195 network that each head-end implementation applies the same rules to 1196 disambiguate overlapping Flow Specifications, but it is important 1197 that: 1199 o A network operator can easily find out what traffic is being 1200 placed on which path and why. This will facilitate analysis of 1201 the network and diagnosis of faults. 1203 o A PCE is able to correctly predict the effect of instructions it 1204 gives to a PCC. This will ensure that traffic is correctly placed 1205 on the network without causing congestion or other network 1206 inefficiencies, and that traffic is correctly delivered. 1208 To that end, a PCC MUST enable an operator to view the the Flow 1209 Specifications that it has installed, and these MUST be presented in 1210 order of precedence such that when two Flow Specifications overlap, 1211 the one that will be serviced with higher precedence is presented to 1212 the operator first. 1214 A discussion of precedence ordering for flow specifications is found 1215 in Section 8.7. 1217 13.2. Control of Function through Configuration and Policy 1219 Support for the function described in this document implies that a 1220 functional element that is capable of requesting a PCE to compute and 1221 control a path is also able to configure the specification of what 1222 traffic should be placed on that path. Where there is a human 1223 involved in this action, configuration of the Flow Specification must 1224 be available through an interface (such as a graphical user interface 1225 or a command line interface). Where a distinct software component 1226 (i.e., one not co-implemented with the PCE) is used, a protocol 1227 mechanism will be required that could be PCEP itself or could be a 1228 data model such as extensions to the YANG model for requesting path 1229 computation [I-D.ietf-teas-yang-path-computation]. 1231 Implementations MAY be constructed with a configurable switch to say 1232 whether they support the functions defined in this document. 1233 Otherwise, such implementations MUST indicate that they support the 1234 function as described in Section 4. If an implementation supports 1235 configurable support of this function, that support MAY be 1236 configurable per peer or once for the whole implementation. 1238 As mentioned in Section 13.1, a PCE implementation SHOULD provide a 1239 mechanism to configure variations in the precedence ordering of Flow 1240 Specifications per PCC. 1242 13.3. Information and Data Models 1244 The YANG model in [I-D.ietf-pce-pcep-yang] can be used to model and 1245 monitor PCEP states and messages. To make that YANG model useful for 1246 the extensions described in this document, it would need to be 1247 augmented to cover the new protocol elements. 1249 Similarly, as noted in Section 13.2, the YANG model defined in 1250 [I-D.ietf-teas-yang-path-computation] could be extended to allow 1251 specification of Flow Specifications. 1253 Finally, as mentioned in Section 13.1, a PCC implementation SHOULD 1254 provide a mechanism to allow an operator to read the Flow 1255 Specifications from a PCC and to understand in what order they will 1256 be executed. This could be achieved using a new YANG model. 1258 13.4. Liveness Detection and Monitoring 1260 The extensions defined in this document do not require any additional 1261 liveness detection and monitoring support. See [RFC5440] and 1262 [RFC5886] for more information. 1264 13.5. Verifying Correct Operation 1266 The chief element of operation that needs to be verified (in addition 1267 to the operation of the protocol elements as described in [RFC5440]) 1268 is the installation, precedence, and correct operation of the Flow 1269 Specifications at a PCC. 1271 In addition to the YANG model for reading Flow Specifications 1272 described in Section 13.3, tools may be needed to inject Operations 1273 and Management (OAM) traffic at the PCC that matches specific 1274 criteria so that it can be monitored as traveling along the desired 1275 path. Such tools are outside the scope of this document. 1277 13.6. Requirements on Other Protocols and Functional Components 1279 This document places no requirements on other protocols or 1280 components. 1282 13.7. Impact on Network Operation 1284 The use of the features described in this document clearly have an 1285 important impact on network traffic since they cause traffic to be 1286 routed on specific paths in the network. However, in practice, these 1287 changes make no direct changes to the network operation because 1288 traffic is already placed on those paths using some pre-existing 1289 configuration mechanism. Thus, the significant change is the 1290 reduction in mechanisms that have to be applied, rather than a change 1291 to how the traffic is passed through the network. 1293 14. Acknowledgements 1295 Thanks to Julian Lucek, Sudhir Cheruathur, Olivier Dugeon, Jayant 1296 Agarwal, Jeffrey Zhang, Acee Lindem, Vishnu Pavan Beeram, Julien 1297 Meuric, Deborah Brungard, Eric Vyncke, Erik Kline, Benjamin Kaduk, 1298 Martin Duke, Roman Danyliw, and Alvaro Retana for useful discussions 1299 and comments. 1301 15. References 1303 15.1. Normative References 1305 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1306 Requirement Levels", BCP 14, RFC 2119, 1307 DOI 10.17487/RFC2119, March 1997, 1308 . 1310 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1311 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1312 2006, . 1314 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1315 "Multiprotocol Extensions for BGP-4", RFC 4760, 1316 DOI 10.17487/RFC4760, January 2007, 1317 . 1319 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1320 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1321 DOI 10.17487/RFC5440, March 2009, 1322 . 1324 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 1325 Used to Form Encoding Rules in Various Routing Protocol 1326 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 1327 2009, . 1329 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1330 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1331 May 2017, . 1333 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1334 Computation Element Communication Protocol (PCEP) 1335 Extensions for Stateful PCE", RFC 8231, 1336 DOI 10.17487/RFC8231, September 2017, 1337 . 1339 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1340 and D. Dhody, "Optimizations of Label Switched Path State 1341 Synchronization Procedures for a Stateful PCE", RFC 8232, 1342 DOI 10.17487/RFC8232, September 2017, 1343 . 1345 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1346 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1347 Path Computation Element Communication Protocol (PCEP)", 1348 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1349 . 1351 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1352 Computation Element Communication Protocol (PCEP) 1353 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1354 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1355 . 1357 [RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 1358 Bacher, "Dissemination of Flow Specification Rules", 1359 RFC 8955, DOI 10.17487/RFC8955, December 2020, 1360 . 1362 [RFC8956] Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., 1363 "Dissemination of Flow Specification Rules for IPv6", 1364 RFC 8956, DOI 10.17487/RFC8956, December 2020, 1365 . 1367 15.2. Informative References 1369 [I-D.gont-numeric-ids-sec-considerations] 1370 Gont, F. and I. Arce, "Security Considerations for 1371 Transient Numeric Identifiers Employed in Network 1372 Protocols", draft-gont-numeric-ids-sec-considerations-06 1373 (work in progress), December 2020. 1375 [I-D.ietf-idr-flowspec-l2vpn] 1376 Hao, W., Eastlake, D. E., Litkowski, S., and S. Zhuang, 1377 "BGP Dissemination of L2 Flow Specification Rules", draft- 1378 ietf-idr-flowspec-l2vpn-17 (work in progress), May 2021. 1380 [I-D.ietf-pce-pcep-yang] 1381 Dhody, D., Hardwick, J., Beeram, V. P., and J. Tantsura, 1382 "A YANG Data Model for Path Computation Element 1383 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1384 yang-16 (work in progress), February 2021. 1386 [I-D.ietf-teas-yang-path-computation] 1387 Busi, I., Belotti, S., Lopez, V., Sharma, A., and Y. Shi, 1388 "YANG Data Model for requesting Path Computation", draft- 1389 ietf-teas-yang-path-computation-16 (work in progress), 1390 September 2021. 1392 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1393 Element (PCE)-Based Architecture", RFC 4655, 1394 DOI 10.17487/RFC4655, August 2006, 1395 . 1397 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1398 Zhang, "OSPF Protocol Extensions for Path Computation 1399 Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, 1400 January 2008, . 1402 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1403 Zhang, "IS-IS Protocol Extensions for Path Computation 1404 Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, 1405 January 2008, . 1407 [RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of 1408 Monitoring Tools for Path Computation Element (PCE)-Based 1409 Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010, 1410 . 1412 [RFC6123] Farrel, A., "Inclusion of Manageability Sections in Path 1413 Computation Element (PCE) Working Group Drafts", RFC 6123, 1414 DOI 10.17487/RFC6123, February 2011, 1415 . 1417 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 1418 BGP, LDP, PCEP, and MSDP Issues According to the Keying 1419 and Authentication for Routing Protocols (KARP) Design 1420 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 1421 . 1423 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 1424 Computation Element Architecture", RFC 7399, 1425 DOI 10.17487/RFC7399, October 2014, 1426 . 1428 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1429 Code: The Implementation Status Section", BCP 205, 1430 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1431 . 1433 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1434 Writing an IANA Considerations Section in RFCs", BCP 26, 1435 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1436 . 1438 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 1439 Architecture for Use of PCE and the PCE Communication 1440 Protocol (PCEP) in a Network with Central Control", 1441 RFC 8283, DOI 10.17487/RFC8283, December 2017, 1442 . 1444 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1445 and J. Hardwick, "Path Computation Element Communication 1446 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 1447 DOI 10.17487/RFC8664, December 2019, 1448 . 1450 Appendix A. Contributors 1452 Shankara 1453 Huawei Technologies 1454 Divyashree Techno Park, 1455 Whitefield Bangalore, 1456 Karnataka 1457 560066 1458 India 1460 Email: shankara@huawei.com 1462 Qiandeng Liang 1463 Huawei Technologies 1464 101 Software Avenue, 1465 Yuhuatai District 1466 Nanjing 1467 210012 1468 China 1470 Email: liangqiandeng@huawei.com 1472 Cyril Margaria 1473 Juniper Networks 1474 200 Somerset Corporate Boulevard, Suite 4001 1475 Bridgewater, NJ 1476 08807 1477 USA 1479 Email: cmargaria@juniper.net 1481 Colby Barth 1482 Juniper Networks 1483 200 Somerset Corporate Boulevard, Suite 4001 1484 Bridgewater, NJ 1485 08807 1486 USA 1488 Email: cbarth@juniper.net 1490 Xia Chen 1491 Huawei Technologies 1492 Huawei Bld., No.156 Beiqing Rd. 1493 Beijing 1494 100095 1495 China 1496 Email: jescia.chenxia@huawei.com 1498 Shunwan Zhuang 1499 Huawei Technologies 1500 Huawei Bld., No.156 Beiqing Rd. 1501 Beijing 1502 100095 1503 China 1505 Email: zhuangshunwan@huawei.com 1507 Cheng Li 1508 Huawei Technologies 1509 Huawei Campus, No. 156 Beiqing Rd. 1510 Beijing 100095 1511 China 1513 Email: c.l@huawei.com 1515 Authors' Addresses 1517 Dhruv Dhody 1518 Huawei Technologies 1519 Divyashree Techno Park, Whitefield 1520 Bangalore, Karnataka 560066 1521 India 1523 Email: dhruv.ietf@gmail.com 1525 Adrian Farrel 1526 Old Dog Consulting 1528 Email: adrian@olddog.co.uk 1530 Zhenbin Li 1531 Huawei Technologies 1532 Huawei Bld., No.156 Beiqing Rd. 1533 Beijing 100095 1534 China 1536 Email: lizhenbin@huawei.com