idnits 2.17.1 draft-ietf-pce-pcep-flowspec-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 4, 2020) is 1513 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 (-22) exists of draft-ietf-idr-flow-spec-v6-10 == Outdated reference: A later version (-27) exists of draft-ietf-idr-rfc5575bis-19 == Outdated reference: A later version (-23) exists of draft-ietf-idr-flowspec-l2vpn-13 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-13 == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-path-computation-08 Summary: 0 errors (**), 0 flaws (~~), 6 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: September 5, 2020 Old Dog Consulting 6 Z. Li 7 Huawei Technologies 8 March 4, 2020 10 PCEP Extension for Flow Specification 11 draft-ietf-pce-pcep-flowspec-08 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 instructions issued by the PCE to network elements. 19 Both approaches use the PCE Communication Protocol (PCEP) to convey 20 the details of the computed path. 22 Traffic flows may be categorized and described using "Flow 23 Specifications". RFC XXXX defines the Flow Specification and 24 describes how Flow Specification Components are used to describe 25 traffic flows. RFC XXXX 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 RFC Editor Note: Please replace XXXX in the Abstract with the RFC 34 number assigned to draft-ietf-idr-rfc5575bis when it is published. 35 Please remove this note. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on September 5, 2020. 54 Copyright Notice 56 Copyright (c) 2020 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Procedures for PCE Use of Flow Specifications . . . . . . . . 5 74 3.1. Context for PCE Use of Flow Specifications . . . . . . . 5 75 3.2. Elements of Procedure . . . . . . . . . . . . . . . . . . 6 76 3.2.1. Capability Advertisement . . . . . . . . . . . . . . 6 77 3.2.2. Dissemination Procedures . . . . . . . . . . . . . . 7 78 3.2.3. Flow Specification Synchronization . . . . . . . . . 8 79 4. PCE FlowSpec Capability TLV . . . . . . . . . . . . . . . . . 9 80 5. PCEP FLOWSPEC Object . . . . . . . . . . . . . . . . . . . . 9 81 6. Flow Filter TLV . . . . . . . . . . . . . . . . . . . . . . . 11 82 7. Flow Specification TLVs . . . . . . . . . . . . . . . . . . . 12 83 8. Detailed Procedures . . . . . . . . . . . . . . . . . . . . . 15 84 8.1. Default Behavior and Backward Compatibility . . . . . . . 16 85 8.2. Composite Flow Specifications . . . . . . . . . . . . . . 16 86 8.3. Modifying Flow Specifications . . . . . . . . . . . . . . 16 87 8.4. Multiple Flow Specifications . . . . . . . . . . . . . . 16 88 8.5. Adding and Removing Flow Specifications . . . . . . . . . 17 89 8.6. VPN Identifiers . . . . . . . . . . . . . . . . . . . . . 17 90 8.7. Priorities and Overlapping Flow Specifications . . . . . 17 91 9. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 18 92 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 93 10.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 21 94 10.1.1. PCEP FLOWSPEC Object Flag Field . . . . . . . . . . 21 95 10.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 22 96 10.3. Flow Specification TLV Type Indicators . . . . . . . . . 22 97 10.4. PCEP Error Codes . . . . . . . . . . . . . . . . . . . . 23 98 10.5. PCE Capability Flag . . . . . . . . . . . . . . . . . . 24 99 11. Implementation Status . . . . . . . . . . . . . . . . . . . . 24 100 12. Security Considerations . . . . . . . . . . . . . . . . . . . 24 101 13. Manageability Considerations . . . . . . . . . . . . . . . . 25 102 13.1. Management of Multiple Flow Specifications . . . . . . . 25 103 13.2. Control of Function through Configuration and Policy . . 26 104 13.3. Information and Data Models . . . . . . . . . . . . . . 27 105 13.4. Liveness Detection and Monitoring . . . . . . . . . . . 27 106 13.5. Verifying Correct Operation . . . . . . . . . . . . . . 27 107 13.6. Requirements on Other Protocols and Functional 108 Components . . . . . . . . . . . . . . . . . . . . . . . 27 109 13.7. Impact on Network Operation . . . . . . . . . . . . . . 27 110 13.8. Other Considerations . . . . . . . . . . . . . . . . . . 28 111 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 112 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 113 15.1. Normative References . . . . . . . . . . . . . . . . . . 28 114 15.2. Informative References . . . . . . . . . . . . . . . . . 29 115 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 31 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 118 1. Introduction 120 [RFC4655] defines the Path Computation Element (PCE), a functional 121 component capable of computing paths for use in traffic engineering 122 networks. PCE was originally conceived for use in Multiprotocol 123 Label Switching (MPLS) for Traffic Engineering (TE) networks to 124 derive the routes of Label Switched Paths (LSPs). However, the scope 125 of PCE was quickly extended to make it applicable to Generalized MPLS 126 (GMPLS)-controlled networks, and more recent work has brought other 127 traffic engineering technologies and planning applications into scope 128 (for example, Segment Routing (SR) [RFC8664]). 130 [RFC5440] describes the Path Computation Element Communication 131 Protocol (PCEP). PCEP defines the communication between a Path 132 Computation Client (PCC) and a PCE, or between PCE and PCE, enabling 133 computation of path for MPLS-TE LSPs. 135 Stateful PCE [RFC8231] specifies a set of extensions to PCEP to 136 enable control of TE-LSPs by a PCE that retains state about the LSPs 137 provisioned in the network (a stateful PCE). [RFC8281] describes the 138 setup, maintenance, and teardown of LSPs initiated by a stateful PCE 139 without the need for local configuration on the PCC, thus allowing 140 for a dynamic network that is centrally controlled. [RFC8283] 141 introduces the architecture for PCE as a central controller and 142 describes how PCE can be viewed as a component that performs 143 computation to place 'flows' within the network and decide how these 144 flows are routed. 146 The description of traffic flows by the combination of multiple Flow 147 Specification Components and their dissemination as traffic flow 148 specifications (Flow Specifications) is described for BGP in 149 [I-D.ietf-idr-rfc5575bis]. A Flow Specification is comprised of 150 traffic filtering rules and actions. The routers that receive a Flow 151 Specification can classify received packets according to the traffic 152 filtering rules and can direct packets based on the actions. 154 When a PCE is used to initiate tunnels (such as TE-LSPs or SR paths) 155 using PCEP, it is important that the head end of the tunnels 156 understands what traffic to place on each tunnel. The data flows 157 intended for a tunnel can be described using Flow Specification 158 Components. When PCEP is in use for tunnel initiation it makes sense 159 for that same protocol to be used to distribute the Flow 160 Specification Components that describe what data is to flow on those 161 tunnels. 163 This document specifies a set of extensions to PCEP to support 164 dissemination of Flow Specifications Components. For convenience we 165 term the description of a traffic flow using Flow Specification 166 Components as a "Flow Specification" and it must be understood that 167 this is not the same as the same term used in 168 [I-D.ietf-idr-rfc5575bis] since no action is explicitly included in 169 the encoding. 171 The extensions defined in this document include the creation, update, 172 and withdrawal of Flow Specifications via PCEP, and can be applied to 173 tunnels initiated by the PCE or to tunnels where control is delegated 174 to the PCE by the PCC. Furthermore, a PCC requesting a new path can 175 include Flow Specifications in the request to indicate the purpose of 176 the tunnel allowing the PCE to factor this into the path computation. 178 Flow Specifications are carried in TLVs within a new object called 179 the FLOWSPEC object defined in this document. The flow filtering 180 rules indicated by the Flow Specifications are mainly defined by BGP 181 Flow Specifications. 183 2. Terminology 185 This document uses the following terms defined in [RFC5440]: PCC, 186 PCE, PCEP Peer. 188 The following term from [I-D.ietf-idr-rfc5575bis] is used frequently 189 throughout this document: 191 Flow Specification (FlowSpec): A Flow Specification is an n-tuple 192 consisting of several matching criteria that can be applied to IP 193 traffic, including filters and actions. Each FlowSpec consists of 194 a set of filters and a set of actions. 196 However, in the context of this document, no action is specified as 197 part of the FlowSpec since the action "forward all matching traffic 198 onto the associated path" is implicit. How an implementation decides 199 how to filter traffic that matches a Flow Specification does not form 200 part of this specification, but a flag is provided to indicate that 201 the sender of a PCEP message that includes a Flow Specification is 202 intended to be installed as a Longest Prefix Match route, or as a 203 Flow Specification policy. 205 This document uses the terms "stateful PCE" and "active PCE" as 206 advocated in [RFC7399]. 208 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 209 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 210 "OPTIONAL" in this document are to be interpreted as described in BCP 211 14 [RFC2119] [RFC8174] when, and only when, they appear in all 212 capitals, as shown here. 214 3. Procedures for PCE Use of Flow Specifications 216 3.1. Context for PCE Use of Flow Specifications 218 In the PCE architecture there are five steps in the setup and use of 219 LSPs: 221 1. Decide which LSPs to set up. The decision may be made by a user, 222 by a PCC, or by the PCE. There can be a number of triggers for 223 this including user intervention and dynamic response to changes 224 in traffic demands. 226 2. Decide what properties to assign to an LSP. This can include 227 bandwidth reservations, priorities, and DSCP (i.e., MPLS Traffic 228 Class field). This function is also determined by user 229 configuration or response to predicted or observed traffic 230 demands. 232 3. Decide what traffic to put on the LSP. This is effectively 233 determining which traffic flows to assign to which LSPs, and 234 practically, this is closely linked to the first two decisions 235 listed above. 237 4. Cause the LSP to be set up and modified to have the right 238 characteristics. This will usually involve the PCE advising or 239 instructing the PCC which will then signal the LSP across the 240 network. 242 5. Tell the head end what traffic to put on the LSP. This may 243 happen after or at the same time as the LSP is set up. This step 244 is the subject of this document. 246 3.2. Elements of Procedure 248 There are three elements of procedure: 250 o A PCE and a PCC must be able to indicate whether or not they 251 support the use of Flow Specifications. 253 o A PCE or PCC must be able to include Flow Specifications in PCEP 254 messages with clear understanding of the applicability of those 255 Flow Specifications in each case. This includes whether the use 256 of such information is mandatory, constrained, or optional, and 257 how overlapping Flow Specifications will be resolved. 259 o Flow Specification information/state must be synchronized between 260 PCEP peers so that, on recovery, the peers have the same 261 understanding of which Flow Specifications apply. 263 The following subsections describe these points. 265 3.2.1. Capability Advertisement 267 As with most PCEP capability advertisements, the ability to support 268 Flow Specifications can be indicated in the PCEP OPEN message or in 269 IGP PCE capability advertisements. 271 3.2.1.1. PCEP OPEN Message 273 During PCEP session establishment, a PCC or PCE that supports the 274 procedures described in this document announces this fact by 275 including the "PCE FlowSpec Capability" TLV (described in Section 4) 276 in the OPEN Object carried in the PCEP Open message. 278 The presence of the PCE FlowSpec Capability TLV in the OPEN Object in 279 a PCE's OPEN message indicates that the PCE can distribute FlowSpecs 280 to PCCs and can receive FlowSpecs in messages from PCCs. 282 The presence of the PCE FlowSpec Capability TLV in the OPEN Object in 283 a PCC's OPEN message indicates that the PCC supports the FlowSpec 284 functionality described in this document. 286 If either one of a pair of PCEP peers does not indicate support of 287 the functionality described in this document by not including the PCE 288 FlowSpec Capability TLV in the OPEN Object in its OPEN message, then 289 the other peer MUST NOT include a FLOWSPEC object in any PCEP message 290 sent to the peer that does not support the procedures. If a FLOWSPEC 291 object is received when support has not been indicated, the receiver 292 will respond with a PCErr message reporting the objects containing 293 the FlowSpec as described in [RFC5440]: that is, it will use 'Unknown 294 Object' if it does not support this specification, and 'Not supported 295 object' if it supports this specification but has not chosen to 296 support FLOWSPEC objects on this PCEP session. 298 3.2.1.2. IGP PCE Capabilities Advertisement 300 The ability to advertise support for PCEP and PCE features in IGP 301 advertisements is provided for OSPF in [RFC5088] and for IS-IS in 302 [RFC5089]. The mechanism uses the PCE Discovery TLV which has a PCE- 303 CAP-FLAGS sub-TLV containing bit-flags each of which indicates 304 support for a different feature. 306 This document defines a new PCE-CAP-FLAGS sub-TLV bit, the FlowSpec 307 Capable flag (bit number TBD1). Setting the bit indicates that an 308 advertising PCE supports the procedures defined in this document. 310 Note that while PCE FlowSpec Capability may be advertised during 311 discovery, PCEP speakers that wish to use Flow Specification in PCEP 312 MUST negotiate PCE FlowSpec Capability during PCEP session setup, as 313 specified in Section 3.2.1.1. A PCC MAY initiate PCE FlowSpec 314 Capability negotiation at PCEP session setup even if it did not 315 receive any IGP PCE capability advertisement, and a PCEP peer that 316 advertised support for FlowSpec in the IGP is not obliged to support 317 these procedures on any given PCEP session. 319 3.2.2. Dissemination Procedures 321 This section describes the procedures to support Flow Specifications 322 in PCEP messages. 324 The primary purpose of distributing Flow Specification information is 325 to allow a PCE to indicate to a PCC what traffic it should place on a 326 path (such as an LSP or an SR path). This means that the Flow 327 Specification may be included in: 329 o PCInitiate messages so that an active PCE can indicate the traffic 330 to place on a path at the time that the PCE instantiates the path. 332 o PCUpd messages so that an active PCE can indicate or change the 333 traffic to place on a path that has already been set up. 335 o PCRpt messages so that a PCC can report the traffic that the PCC 336 plans to place on the path. 338 o PCReq messages so that a PCC can indicate what traffic it plans to 339 place on a path at the time it requests the PCE to perform a 340 computation in case that information aids the PCE in its work. 342 o PCRep messages so that a PCE that has been asked to compute a path 343 can suggest which traffic could be placed on a path that a PCC may 344 be about to set up. 346 o PCErr messages so that issues related to paths and the traffic 347 they carry can be reported to the PCE by the PCC, and so that 348 problems with other PCEP messages that carry Flow Specifications 349 can be reported. 351 To carry Flow Specifications in PCEP messages, this document defines 352 a new PCEP object called the PCEP FLOWSPEC object. The object is 353 OPTIONAL in the messages described above and MAY appear more than 354 once in each message. 356 The PCEP FLOWSPEC object carries zero or one Flow Filter TLV which 357 describes a traffic flow. 359 The inclusion of multiple PCEP FLOWSPEC objects allows multiple 360 traffic flows to be placed on a single path. 362 Once a PCE and PCC have established that they can both support the 363 use of Flow Specifications in PCEP messages, such information may be 364 exchanged at any time for new or existing paths. 366 The application and prioritization of Flow Specifications is 367 described in Section 8.7. 369 As per [RFC8231], any attributes of the path received from a PCE are 370 subject to PCC's local policy. This holds good for the Flow 371 Specifications as well. 373 3.2.3. Flow Specification Synchronization 375 The Flow Specifications are carried along with the LSP State 376 information as per [RFC8231] making the Flow Specifications part of 377 the LSP database (LSP-DB). Thus, the synchronization of the Flow 378 Specification information is done as part of LSP-DB synchronization. 379 This may be achieved using normal state synchronization procedures as 380 described in [RFC8231] or enhanced state synchronization procedures 381 as defined in [RFC8232]. 383 The approach selected will be implementation and deployment specific 384 and will depend on issues such as how the databases are constructed 385 and what level of synchronization support is needed. 387 4. PCE FlowSpec Capability TLV 389 The PCE-FLOWSPEC-CAPABILITY TLV is an optional TLV that can be 390 carried in the OPEN Object [RFC5440] to exchange PCE FlowSpec 391 capabilities of the PCEP speakers. 393 The format of the PCE-FLOWSPEC-CAPABILITY TLV follows the format of 394 all PCEP TLVs as defined in [RFC5440] and is shown in Figure 1. 396 0 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Type=TBD2 | Length=2 | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Value=0 | Padding | 402 +---------------------------------------------------------------+ 404 Figure 1: PCE-FLOWSPEC-CAPABILITY TLV format 406 The type of the PCE-FLOWSPEC-CAPABILITY TLV is TBD2 and it has a 407 fixed length of 2 octets. The Value field is set to default value 0. 408 The two bytes of padding MUST be set to zero and ignored on receipt. 410 The inclusion of this TLV in an OPEN object indicates that the sender 411 can perform FlowSpec handling as defined in this document. 413 5. PCEP FLOWSPEC Object 415 The PCEP FLOWSPEC object defined in this document is compliant with 416 the PCEP object format defined in [RFC5440]. It is OPTIONAL in the 417 PCReq, PCRep, PCErr, PCInitiate, PCRpt, and PCUpd messages and MAY be 418 present zero, one, or more times. Each instance of the object 419 specifies a traffic flow. 421 The PCEP FLOWSPEC object carries a FlowSpec filter rule encoded in a 422 TLV (as defined in Section 6). 424 The FLOWSPEC Object-Class is TBD3 (to be assigned by IANA). 426 The FLOWSPEC Object-Type is 1. 428 The format of the body of the PCEP FLOWSPEC object is shown in 429 Figure 2 430 0 1 2 3 431 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 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | FS-ID | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | AFI | Reserved | Flags |L|R| 436 0 1 2 3 4 5 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | | 439 // TLVs // 440 | | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 Figure 2: PCEP FLOWSPEC Object Body Format 445 FS-ID (32-bits): A PCEP-specific identifier for the FlowSpec 446 information. A PCE or PCC creates an FS-ID for each FlowSpec that it 447 originates, and the value is unique within the scope of that PCE or 448 PCC and is constant for the lifetime of a PCEP session. All 449 subsequent PCEP messages can identify the FlowSpec using the FS-ID. 450 The values 0 and 0xFFFFFFFF are reserved and MUST NOT be used. 452 AFI (16-bits): Address Family Identifier as used in BGP [RFC4760] 453 (AFI=1 for IPv4 or VPNv4, AFI=2 for IPv6 and VPNv6 as per as per 454 [I-D.ietf-idr-flow-spec-v6]). 456 Reserved (8-bits): MUST be set to zero on transmission and ignored on 457 receipt. 459 Flags (8-bits): Two flags are currently assigned - 461 R bit: The Remove bit is set when a PCEP FLOWSPEC object is 462 included in a PCEP message to indicate removal of the Flow 463 Specification from the associated tunnel. If the bit is clear, 464 the Flow Specification is being added or modified. 466 L bit: The Longest Prefix Match (LPM) bit is set to indicate that 467 the Flow Specification is to be installed as a route subject to 468 longest prefix match forwarding. If the bit is clear, the Flow 469 Specification described by the Flow Filter TLV (see Section 6) is 470 to be installed as a Flow Specification. If the bit is set, only 471 Flow Specifications that describe IPv4 or IPv6 destinations are 472 meaningful in the Flow Filter TLV. If the L is set and the 473 receiver does not support the use of Flow Specifications that are 474 present in the Flow Filter TLV for the installation of a route 475 subject to longest prefix match forwarding, then the PCEP peer 476 MUST respond with a PCErr message with error-type TBD8 (FlowSpec 477 Error) and error-value 5 (Unsupported LPM Route). 479 Unassigned bits MUST be set to zero on transmission and ignored on 480 receipt. 482 If the PCEP speaker receives a message with R bit set in the FLOWSPEC 483 object and the Flow Specification identified with a FS-ID does not 484 exist, it MUST generate a PCErr with Error-type TBD8 (FlowSpec 485 Error), error-value 4 (Unknown FlowSpec). 487 If the PCEP speaker does not understand or support the AFI in the 488 FLOWSPEC message, the PCEP peer MUST respond with a PCErr message 489 with error-type TBD8 (FlowSpec Error), error-value 2 (Malformed 490 FlowSpec). 492 The following TLVs can be used in the FLOWSPEC object: 494 o Speaker Entity Identifier TLV: As specified in [RFC8232], SPEAKER- 495 ENTITY-ID TLV encodes a unique identifier for the node that does 496 not change during the lifetime of the PCEP speaker. This is used 497 to uniquely identify the FlowSpec originator and thus used in 498 conjunction with FS-ID to uniquely identify the FlowSpec 499 information. This TLV MUST be included. If the TLV is missing, 500 the PCEP peer MUST respond with a PCErr message with error-type 501 TBD8 (FlowSpec Error), error-value 2 (Malformed FlowSpec). 503 o Flow Filter TLV (variable): One TLV MAY be included. The Flow 504 Filter TLV is OPTIONAL when the R bit is set. The TLV MUST be 505 present when the R bit is clear. If the TLV is missing when the R 506 bit is clear, the PCEP peer MUST respond with a PCErr message with 507 error-type TBD8 (FlowSpec Error) and error-value 2 (Malformed 508 FlowSpec). 510 6. Flow Filter TLV 512 A new PCEP TLV is defined to convey Flow Specification filtering 513 rules that specify what traffic is carried on a path. The TLV 514 follows the format of all PCEP TLVs as defined in [RFC5440]. The 515 Type field values come from the codepoint space for PCEP TLVs and has 516 the value TBD4. 518 The Value field contains one or more sub-TLVs (the Flow Specification 519 TLVs) as defined in Section 7. Only one Flow Filter TLV can be 520 present and represents the complete definition of a Flow 521 Specification for traffic to be placed on the tunnel. This tunnel is 522 indicated by the PCEP message in which the PCEP FLOWSPEC object is 523 carried. The set of Flow Specification TLVs in a single instance of 524 a Flow Filter TLV are combined to indicate the specific Flow 525 Specification. 527 Further Flow Specifications can be included in a PCEP message by 528 including additional FLOWSPEC objects. 530 7. Flow Specification TLVs 532 The Flow Filter TLV carries one or more Flow Specification TLV. The 533 Flow Specification TLV follows the format of all PCEP TLVs as defined 534 in [RFC5440]. However, the Type values are selected from a separate 535 IANA registry (see Section 10) rather than from the common PCEP TLV 536 registry. 538 Type values are chosen so that there can be commonality with Flow 539 Specifications defined for use with BGP [I-D.ietf-idr-rfc5575bis]. 540 This is possible because the BGP Flow Spec encoding uses a single 541 octet to encode the type where as PCEP uses two octets. Thus the 542 space of values for the Type field is partitioned as shown in 543 Figure 3. 545 Range | 546 ---------------+--------------------------------------------------- 547 0 | Reserved - must not be allocated. 548 | 549 1 .. 255 | Per BGP registry defined by 550 | [I-D.ietf-idr-rfc5575bis] and 551 | [I-D.ietf-idr-flow-spec-v6]. 552 | Not to be allocated in this registry. 553 | 554 256 .. 65535 | New PCEP Flow Specifications allocated according 555 | to the registry defined in this document. 557 Figure 3: Flow Specification TLV Type Ranges 559 [I-D.ietf-idr-rfc5575bis] is the reference for the registry "Flow 560 Spec Component Types" and defines the allocations it contains. 561 [I-D.ietf-idr-flow-spec-v6] requested for another registry "Flow Spec 562 IPv6 Component Types" and requested initial allocations in it. If 563 the AFI (in the FLOWSPEC object) is set to IPv4, the range 1..255 is 564 as per "Flow Spec Component Types" [I-D.ietf-idr-rfc5575bis]; if the 565 AFI is set to IPv6, the range 1..255 is as per "Flow Spec IPv6 566 Component Types" [I-D.ietf-idr-flow-spec-v6]. When future BGP 567 specifications (such as [I-D.ietf-idr-flowspec-l2vpn]) make further 568 allocations to the aforementioned registries, they are also inherited 569 for PCEP usage. 571 The content of the Value field in each TLV is specific to the type/ 572 AFI and describes the parameters of the Flow Specification. The 573 definition of the format of many of these Value fields is inherited 574 from BGP specifications. Specifically, the inheritance is from 575 [I-D.ietf-idr-rfc5575bis] and [I-D.ietf-idr-flow-spec-v6], but may 576 also be inherited from future BGP specifications. 578 When multiple Flow Specification TLVs are present in a single Flow 579 Filter TLV they are combined to produce a more detailed specification 580 of a flow. For examples and rules about how this is achieved, see 581 [I-D.ietf-idr-rfc5575bis]. 583 An implementation that receives a PCEP message carrying a Flow 584 Specification TLV with a type value that it does not recognize or 585 does not support MUST respond with a PCErr message with error-type 586 TBD8 (FlowSpec Error), error-value 1 (Unsupported FlowSpec) and MUST 587 NOT install the Flow Specification. 589 When used in other protocols (such as BGP), these Flow Specifications 590 are also associated with actions to indicate how traffic matching the 591 Flow Specification should be treated. In PCEP, however, the only 592 action is to associate the traffic with a tunnel and to forward 593 matching traffic onto that path, so no encoding of an action is 594 needed. 596 Section 8.7 describes how overlapping Flow Specifications are 597 prioritized and handled. 599 All Flow Specification TLVs with Types in the range 1 to 255 have 600 Values defined for use in BGP (for example, in 601 [I-D.ietf-idr-rfc5575bis], [I-D.ietf-idr-flow-spec-v6], and 602 [I-D.ietf-idr-flowspec-l2vpn]) and are set using the BGP encoding, 603 but without the type octet (the relevant information is in the Type 604 field of the TLV). The Value field is padded with trailing zeros to 605 achieve 4-byte alignment. 607 This document defines following new types - 608 +-------+-------------------------+-----------------------------+ 609 | Type | Description | Value defined in | 610 | | | | 611 +-------+-------------------------+-----------------------------+ 612 | TBD5 | Route Distinguisher | [This.I-D] | 613 +-------+-------------------------+-----------------------------+ 614 | TBD6 | IPv4 Multicast Flow | [This.I-D] | 615 +-------+-------------------------+-----------------------------+ 616 | TBD7 | IPv6 Multicast Flow | [This.I-D] | 617 +-------+-------------------------+-----------------------------+ 619 Figure 4: Table of Flow Specification TLV Types defined in this 620 document 622 To allow identification of a VPN in PCEP via a Route Distinguisher 623 (RD) [RFC4364], a new TLV - ROUTE-DISTINGUISHER TLV is defined in 624 this document. A Flow Specification TLV with Type TBD5 (ROUTE- 625 DISTINGUISHER TLV) carries an RD Value, used to identify that other 626 flow filter information (for example, an IPv4 destination prefix) is 627 associated with a specific VPN identified by the RD. See Section 8.6 628 for further discussion of VPN identification. 630 0 1 2 3 631 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 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | Type=[TBD5] | Length=8 | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Route Distinguisher | 636 | | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 Figure 5: The Format of the ROUTE-DISTINGUISHER TLV 641 The format of RD is as per [RFC4364]. 643 Although it may be possible to describe a multicast Flow 644 Specification from the combination of other Flow Specification TLVs 645 with specific values, it is more convenient to use a dedicated Flow 646 Specification TLV. Flow Specification TLVs with Type values TBD6 and 647 TBD7 are used to identify a multicast flow for IPv4 and IPv6 648 respectively. The Value field is encoded as shown in Figure 6. 650 0 1 2 3 651 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 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | Reserved |S|G| Src Mask Len | Grp Mask Len | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 ~ Source Address ~ 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 ~ Group multicast Address ~ 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 Figure 6: Multicast Flow Specification TLV Encoding 662 The address fields and address mask lengths of the two Multicast Flow 663 Specification TLVs contain source and group prefixes for matching 664 against packet flows noting that the two address fields are 32 bits 665 for an IPv4 Multicast Flow and 128 bits for an IPv6 Multicast Flow. 667 The Reserved field MUST be set to zero and ignored on receipt. 669 Two bit flags (S and G) are defined to describe the multicast 670 wildcarding in use. If the S bit is set, then source wildcarding is 671 in use and the values in the Source Mask Length and Source Address 672 fields MUST be ignored. If the G bit is set, then group wildcarding 673 is in use and the values in the Group Mask Length and Group multicast 674 Address fields MUST be ignored. The G bit MUST NOT be set unless the 675 S bit is also set: if a Multicast Flow Specification TLV is received 676 with S bit = 0 and G bit = 1 the receiver MUST respond with a PCErr 677 with Error-type TBD8 (FlowSpec Error) and error-value 2 (Malformed 678 FlowSpec). 680 The three multicast mappings may be achieved as follows: 682 (S, G) - S bit = 0, G bit = 0, the Source Address and Group 683 multicast Address prefixes are both used to define the multicast 684 flow. 686 (*, G) - S bit = 1, G bit = 0, the Group multicast Address prefix, 687 but the Source Address prefix is ignored. 689 (*, *) = S bit = 1, G bit = 1, the Source Address and Group 690 multicast Address prefixes are both ignored. 692 8. Detailed Procedures 694 This section outlines some specific detailed procedures for using the 695 protocol extensions defined in this document. 697 8.1. Default Behavior and Backward Compatibility 699 The default behavior is that no Flow Specification is applied to a 700 tunnel. That is, the default is that the FLOWSPEC object is not used 701 as is the case in all systems before the implementation of this 702 specification. 704 In this case, it is a local matter (such as through configuration) 705 how tunnel head ends are instructed what traffic to place on a 706 tunnel. 708 [RFC5440] describes how receivers respond when they see unknown PCEP 709 objects. 711 8.2. Composite Flow Specifications 713 Flow Specifications may be represented by a single Flow Specification 714 TLV or may require a more complex description using multiple Flow 715 Specification TLVs. For example, a flow indicated by a source- 716 destination pair of IPv6 addresses would be described by the 717 combination of Destination IPv6 Prefix and Source IPv6 Prefix Flow 718 Specification TLVs. 720 8.3. Modifying Flow Specifications 722 A PCE may want to modify a Flow Specification associated with a 723 tunnel, or a PCC may want to report a change to the Flow 724 Specification it is using with a tunnel. 726 It is important that the specific Flow Specification is identified so 727 that it is clear that this is a modification of an existing flow and 728 not the addition of a new flow as described in Section 8.4. The FS- 729 ID field of the PCEP FLOWSPEC object is used to identify a specific 730 Flow Specification. 732 When modifying a Flow Specification, all Flow Specification TLVs for 733 the intended specification of the flow MUST be included in the PCEP 734 FLOWSPEC object and the FS-ID MUST be retained from the previous 735 description of the flow. 737 8.4. Multiple Flow Specifications 739 It is possible that multiple flows will be place on a single tunnel. 740 In some cases it is possible to to define these within a single PCEP 741 FLOWSPEC object: for example, two Destination IPv4 Prefix TLVs could 742 be included to indicate that packets matching either prefix are 743 acceptable. PCEP would consider this as a single Flow Specification 744 identified by a single FS-ID. 746 In other scenarios the use of multiple Flow Specification TLVs would 747 be confusing. For example, if flows from A to B and from C to D are 748 to be included then using two Source IPv4 Prefix TLVs and two 749 Destination IPv4 Prefix TLVs would be confusing (are flows from A to 750 D included?). In these cases, each Flow Specification is carried in 751 its own PCEP FLOWSPEC object with multiple objects present on a 752 single PCEP message. Use of separate objects also allows easier 753 removal and modification of Flow Specifications. 755 8.5. Adding and Removing Flow Specifications 757 The Remove bit in the PCEP FLOWSPEC object is left clear when a Flow 758 Specification is being added or modified. 760 To remove a Flow Specification, a PCEP FLOWSPEC object is included 761 with the FS-ID matching the one being removed, and the R bit set to 762 indicate removal. In this case it is not necessary to include any 763 Flow Specification TLVs. 765 If the R bit is set and Flow Specification TLVs are present, an 766 implementation MAY ignore them. If the implementation checks the 767 Flow Specification TLVs against those recorded for the FS-ID of the 768 Flow Specification being removed and finds a mismatch, the Flow 769 Specification MUST still be removed and the implementation SHOULD 770 record a local exception or log. 772 8.6. VPN Identifiers 774 VPN instances are identified in BGP using Route Distinguishers (RDs) 775 [RFC4364]. These values are not normally considered to have any 776 meaning outside of the network, and they are not encoded in data 777 packets belonging to the VPNs. However, RDs provide a useful way of 778 identifying VPN instances and are often manually or automatically 779 assigned to VPNs as they are provisioned. 781 Thus the RD provides a useful way to indicate that traffic for a 782 particular VPN should be placed on a given tunnel. The tunnel head 783 end will need to interpret this Flow Specification not as a filter on 784 the fields of data packets, but using the other mechanisms that it 785 already uses to identify VPN traffic. This could be based on the 786 incoming port (for port-based VPNs) or may leverage knowledge of the 787 VRF that is in use for the traffic. 789 8.7. Priorities and Overlapping Flow Specifications 791 Flow specifications can overlap. For example, two different flow 792 specifications may be identical except for the length of the prefix 793 in the destination address. In these cases the PCC must determine 794 how to prioritize the flow specifications so as to know to which path 795 to assign packets that match both flow specifications. That is, the 796 PCC must assign a precedence to the flow specifications so that it 797 checks each incoming packet for a match in a predictable order. 799 The processing of BGP Flow Specifications is described in 800 [I-D.ietf-idr-rfc5575bis]. Section 5.1 of that document explains the 801 order of traffic filtering rules to be executed by an implementation 802 of that specification. 804 PCCs MUST apply the same ordering rules as defined in 805 [I-D.ietf-idr-rfc5575bis]. 807 Furthermore, it is possible that Flow Specifications will be 808 distributed by BGP as well as by PCEP as described in this document. 809 In such cases implementations supporting both approaches MUST apply 810 the prioritization and ordering rules as set out in 811 [I-D.ietf-idr-rfc5575bis] regardless of which protocol distributed 812 the Flow Specifications, however implementations MAY provide a 813 configuration control to allow one protocol to take precedence over 814 the other as this may be particularly useful if the Flow 815 Specification make identical matches on traffic but have different 816 actions. It is RECOMMENDED that when two Flow Specifications 817 distributed by different protocols overlap, and especially when one 818 acts to replace another, that a message be logged for the operator to 819 understand the behaviour. 821 Section 13.1 of this document covers manageability considerations 822 relevant to the prioritized ordering of flow specifications. 824 An implementation that receives a PCEP message carrying a Flow 825 Specification that it cannot resolve against other Flow 826 Specifications already installed MUST respond with a PCErr message 827 with error-type TBD8 (FlowSpec Error), error-value 3 (Unresolvable 828 Conflict) and MUST NOT install the Flow Specification. 830 9. PCEP Messages 832 This section describes the format of messages that contain FLOWSPEC 833 objects. The only difference to previous message formats is the 834 inclusion of that object. 836 The figures in this section use the notation defined in [RFC5511]. 838 The FLOWSPEC object is OPTIONAL and MAY be carried in the PCEP 839 messages. 841 The PCInitiate message is defined in [RFC8281] and updated as below: 843 ::= 844 846 Where: 847 ::= 848 [] 850 ::= 851 ( | 852 ) 854 ::= 855 856 [] 857 858 [] 859 [] 861 Where: 862 ::= [] 864 The PCUpd message is defined in [RFC8231] and updated as below: 866 ::= 867 869 Where: 870 ::= 871 [] 873 ::= 874 875 876 [] 878 Where: 879 ::= 881 ::= [] 883 The PCRpt message is defined in [RFC8231] and updated as below: 885 ::= 886 888 Where: 889 ::= [] 891 ::= [] 892 893 894 [] 896 Where: 897 ::= 898 [] 899 901 ::= [] 903 The PCReq message is defined in [RFC5440] and updated in [RFC8231], 904 it is further updated below for flow specification: 906 ::= 907 [] 908 910 Where: 911 ::= [] 913 ::= [] 915 ::= 916 917 [] 918 [] 919 [] 920 [] 921 [[]] 922 [] 923 [] 924 [] 926 Where: 927 ::= [] 929 The PCRep message is defined in [RFC5440] and updated in [RFC8231], 930 it is further updated below for flow specification: 932 ::= 933 935 Where: 936 ::=[] 938 ::= 939 [] 940 [] 941 [] 942 [] 943 [] 945 Where: 946 ::= [] 948 10. IANA Considerations 950 IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" 951 registry. This document requests IANA actions to allocate code 952 points for the protocol elements defined in this document. 954 10.1. PCEP Objects 956 Each PCEP object has an Object-Class and an Object-Type. IANA 957 maintains a subregistry called "PCEP Objects". IANA is requested to 958 make an assignment from this subregistry as follows: 960 Object-Class | Value Name | Object-Type | Reference 961 -------------+-------------+------------------------+---------------- 962 TBD3 | FLOWSPEC | 0: Reserved | [This.I-D] 963 | | 1: Flow Specification | [This.I-D] 965 10.1.1. PCEP FLOWSPEC Object Flag Field 967 This document requests that a new sub-registry, named "FLOWSPEC 968 Object Flag Field", is created within the "Path Computation Element 969 Protocol (PCEP) Numbers" registry to manage the Flag field of the 970 FLOWSPEC object. New values are to be assigned by Standards Action 971 [RFC8126]. Each bit should be tracked with the following qualities: 973 o Bit number (counting from bit 0 as the most significant bit) 975 o Capability description 977 o Defining RFC 979 The initial population of this registry is as follows: 981 Bit | Description | Reference 982 -----+--------------------+------------- 983 0-5 | Unnassigned | 984 6 | Remove (L bit) | [This.I-D] 985 7 | Remove (R bit) | [This.I-D] 987 10.2. PCEP TLV Type Indicators 989 IANA maintains a subregistry called "PCEP TLV Type Indicators". IANA 990 is requested to make an assignment from this subregistry as follows: 992 Value | Meaning | Reference 993 --------+------------------------------+------------- 994 TBD2 | PCE-FLOWSPEC-CAPABILITY TLV | [This.I-D] 995 TBD4 | FLOW FILTER TLV | [This.I-D] 997 10.3. Flow Specification TLV Type Indicators 999 IANA is requested to create a new subregistry call the "PCEP Flow 1000 Specification TLV Type Indicators" registry. 1002 Allocations from this registry are to be made according to the 1003 following assignment policies [RFC8126]: 1005 Range | Assignment policy 1006 ---------------+--------------------------------------------------- 1007 0 | Reserved - must not be allocated. 1008 | 1009 1 .. 255 | Reserved - must not be allocated. 1010 | Usage mirrors the BGP FlowSpec registry 1011 | [I-D.ietf-idr-rfc5575bis] and 1012 | [I-D.ietf-idr-flow-spec-v6]. 1013 | 1014 256 .. 64506 | Specification Required 1015 | 1016 64507 .. 65531 | First Come First Served 1017 | 1018 65532 .. 65535 | Experimental 1020 IANA is requested to pre-populate this registry with values defined 1021 in this document as follows, taking the new values from the range 256 1022 to 64506: 1024 Value | Meaning 1025 -------+------------------------ 1026 TBD5 | Route Distinguisher 1027 TBD6 | IPv4 Multicast 1028 TBD7 | IPv6 Multicast 1030 10.4. PCEP Error Codes 1032 IANA maintains a subregistry called "PCEP-ERROR Object Error Types 1033 and Values". Entries in this subregistry are described by Error-Type 1034 and Error-value. IANA is requested to make the following assignment 1035 from this subregistry: 1037 Error-| Meaning | Error-value | Reference 1038 Type | | | 1039 -------+--------------------+----------------------------+----------- 1040 TBD8 | FlowSpec error | 0: Unassigned | [This.I-D] 1041 | | 1: Unsupported FlowSpec | [This.I-D] 1042 | | 2: Malformed FlowSpec | [This.I-D] 1043 | | 3: Unresolvable Conflict | [This.I-D] 1044 | | 4: Unknown FlowSpec | [This.I-D] 1045 | | 5: Unsupported LPM Route | [This.I-D] 1046 | | 6-255: Unassigned | [This.I-D] 1048 10.5. PCE Capability Flag 1050 IANA maintains a subregistry called "Open Shortest Path First v2 1051 (OSPFv2) Parameters" with a sub-registry called "Path Computation 1052 Element (PCE) Capability Flags". IANA is requested to assign a new 1053 capability bit from this registry as follows: 1055 Bit | Capability Description | Reference 1056 -------+-------------------------------+------------ 1057 TBD1 | FlowSpec | [This.I-D] 1059 11. Implementation Status 1061 [NOTE TO RFC EDITOR : This whole section and the reference to RFC 1062 7942 is to be removed before publication as an RFC] 1064 This section records the status of known implementations of the 1065 protocol defined by this specification at the time of posting of this 1066 Internet-Draft, and is based on a proposal described in [RFC7942]. 1067 The description of implementations in this section is intended to 1068 assist the IETF in its decision processes in progressing drafts to 1069 RFCs. Please note that the listing of any individual implementation 1070 here does not imply endorsement by the IETF. Furthermore, no effort 1071 has been spent to verify the information presented here that was 1072 supplied by IETF contributors. This is not intended as, and must not 1073 be construed to be, a catalog of available implementations or their 1074 features. Readers are advised to note that other implementations may 1075 exist. 1077 According to [RFC7942], "this will allow reviewers and working groups 1078 to assign due consideration to documents that have the benefit of 1079 running code, which may serve as evidence of valuable experimentation 1080 and feedback that have made the implemented protocols more mature. 1081 It is up to the individual working groups to use this information as 1082 they see fit". 1084 At the time of posting the -04 version of this document, there are no 1085 known implementations of this mechanism. It is believed that two 1086 vendors are considering prototype implementations, but these plans 1087 are too vague to make any further assertions. 1089 12. Security Considerations 1091 We may assume that a system that utilizes a remote PCE is subject to 1092 a number of vulnerabilities that could allow spurious LSPs or SR 1093 paths to be established or that could result in existing paths being 1094 modified or torn down. Such systems, therefore, apply security 1095 considerations as described in [RFC5440], [RFC6952], and [RFC8253]. 1097 The description of Flow Specifications associated with paths set up 1098 or controlled by a PCE add a further detail that could be attacked 1099 without tearing down LSPs or SR paths, but causing traffic to be 1100 misrouted within the network. Therefore, the use of the security 1101 mechanisms for PCEP referenced above is important. 1103 Visibility into the information carried in PCEP does not have direct 1104 privacy concerns for end-users' data, however, knowledge of how data 1105 is routed in a network may make that data more vulnerable. Of 1106 course, the ability to interfere with the way data is routed also 1107 makes the data more vulnerable. Furthermore, knowledge of the 1108 connected end-points (such as multicast receivers or VPN sites) is 1109 usually considered private customer information. Therefore, 1110 implementations or deployments concerned with protecting privacy MUST 1111 apply the mechanisms described in the documents referenced above. 1113 Experience with Flow Specifications in BGP systems indicates that 1114 they can become complex and that the overlap of Flow Specifications 1115 installed in different orders can lead to unexpected results. 1116 Although this is not directly a security issue per se, the confusion 1117 and unexpected forwarding behavior may be engineered or exploited by 1118 an attacker. Therefore, implementers and operators SHOULD pay 1119 careful attention to the Manageability Considerations described in 1120 Section 13. 1122 13. Manageability Considerations 1124 The feature introduced by this document enables operational 1125 manageability of networks operated in conjunction with a PCE and 1126 using PCEP. Without this feature, but in the case of a stateful 1127 active PCE or with PCE-initiated services, additional manual 1128 configuration is needed to tell the head-ends what traffic to place 1129 on the network services (LSPs, SR paths, etc.). 1131 This section follows the advice and guidance of [RFC6123]. 1133 13.1. Management of Multiple Flow Specifications 1135 Experience with flow specification in BGP suggests that there can be 1136 a lot of complexity when two or more flow specifications overlap. 1137 This can arise, for example, with addresses indicated using prefixes, 1138 and could cause confusion about what traffic should be placed on 1139 which path. Unlike the behavior in a distributed routing system, it 1140 is not important that each head-end implementation applies the same 1141 rules to disambiguate overlapping Flow Specifications, but it is 1142 important that: 1144 o A network operator can easily find out what traffic is being 1145 placed on which path and why. This will facilitate analysis of 1146 the network and diagnosis of faults. 1148 o A PCE is able to correctly predict the effect of instructions it 1149 gives to a PCC. 1151 To that end, a PCC MUST enable an operator to view the the Flow 1152 Specifications that it has installed, and these MUST be presented in 1153 order of precedence such that when two Flow Specifications overlap, 1154 the one that will be serviced with higher precedence is presented to 1155 the operator first. 1157 A discussion of precedence ordering for flow specifications is found 1158 in Section 8.7. 1160 13.2. Control of Function through Configuration and Policy 1162 Support for the function described in this document implies that a 1163 functional element that is capable of requesting a PCE to compute and 1164 control a path is also able to configure the specification of what 1165 traffic should be placed on that path. Where there is a human 1166 involved in this action, configuration of the Flow Specification must 1167 be available through an interface (such as a graphical user interface 1168 or a command line interface). Where a distinct software component 1169 (i.e., one not co-implemented with the PCE) is used, a protocol 1170 mechanism will be required that could be PCEP itself or could be a 1171 data model such as extensions to the YANG model for requesting path 1172 computation [I-D.ietf-teas-yang-path-computation]. 1174 Implementations MAY be constructed with a configurable switch to say 1175 whether they support the functions defined in this document. 1176 Otherwise, such implementations MUST indicate that they support the 1177 function as described in Section 4. If an implementation supports 1178 configurable support of this function, that support MAY be 1179 configurable per peer or once for the whole implementation. 1181 As mentioned in Section 13.1, a PCE implementation SHOULD provide a 1182 mechanism to configure variations in the precedence ordering of Flow 1183 Specifications per PCC. 1185 13.3. Information and Data Models 1187 The YANG model in [I-D.ietf-pce-pcep-yang] can be used to model and 1188 monitor PCEP states and messages. To make that YANG model useful for 1189 the extensions described in this document, it will need to be 1190 augmented to cover the new protocol elements. 1192 Similarly, as noted in Section 13.2, the YANG model defined in 1193 [I-D.ietf-teas-yang-path-computation] could be extended to allow 1194 specification of Flow Specifications. 1196 Finally, as mentioned in Section 13.1, a PCC implementation SHOULD 1197 provide a mechanism to allow an operator to read the Flow 1198 Specifications from a PCC and to understand in what order they will 1199 be executed. This could be achieved using a new YANG model. 1201 13.4. Liveness Detection and Monitoring 1203 The extensions defined in this document do not require any additional 1204 liveness detection and monitoring support. See [RFC5440] and 1205 [RFC5886] for more information. 1207 13.5. Verifying Correct Operation 1209 The chief element of operation that needs to be verified (in addition 1210 to the operation of the protocol elements as described in [RFC5440]) 1211 is the installation, precedence, and correct operation of the Flow 1212 Specifications at a PCC. 1214 In addition to the YANG model for reading Flow Specifications 1215 described in Section 13.3, tools may be needed to inject Operations 1216 and Management (OAM) traffic at the PCC that matches specific 1217 criteria so that it can be monitored as traveling along the desired 1218 path. Such tools are outside the scope of this document. 1220 13.6. Requirements on Other Protocols and Functional Components 1222 This document places no requirements on other protocols or 1223 components. 1225 13.7. Impact on Network Operation 1227 The use of the features described in this document clearly have an 1228 important impact on network traffic since they cause traffic to be 1229 routed on specific paths in the network. However, in practice, these 1230 changes make no direct changes to the network operation because 1231 traffic is already placed on those paths using some pre-existing 1232 configuration mechanism. Thus, the significant change is the 1233 reduction in mechanisms that have to be applied, rather than a change 1234 to how the traffic is passed through the network. 1236 13.8. Other Considerations 1238 No other manageability considerations are known at this time. 1240 14. Acknowledgements 1242 Thanks to Julian Lucek, Sudhir Cheruathur, Olivier Dugeon, Jayant 1243 Agarwal, Jeffrey Zhang, Acee Lindem, and Vishnu Payam Beeram for 1244 useful discussions. 1246 15. References 1248 15.1. Normative References 1250 [I-D.ietf-idr-flow-spec-v6] 1251 Loibl, C., Raszuk, R., and S. Hares, "Dissemination of 1252 Flow Specification Rules for IPv6", draft-ietf-idr-flow- 1253 spec-v6-10 (work in progress), November 2019. 1255 [I-D.ietf-idr-rfc5575bis] 1256 Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 1257 Bacher, "Dissemination of Flow Specification Rules", 1258 draft-ietf-idr-rfc5575bis-19 (work in progress), January 1259 2020. 1261 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1262 Requirement Levels", BCP 14, RFC 2119, 1263 DOI 10.17487/RFC2119, March 1997, 1264 . 1266 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1267 "Multiprotocol Extensions for BGP-4", RFC 4760, 1268 DOI 10.17487/RFC4760, January 2007, 1269 . 1271 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1272 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1273 DOI 10.17487/RFC5440, March 2009, 1274 . 1276 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 1277 Used to Form Encoding Rules in Various Routing Protocol 1278 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 1279 2009, . 1281 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1282 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1283 May 2017, . 1285 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1286 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1287 Path Computation Element Communication Protocol (PCEP)", 1288 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1289 . 1291 15.2. Informative References 1293 [I-D.ietf-idr-flowspec-l2vpn] 1294 Weiguo, H., Eastlake, D., Uttaro, J., Litkowski, S., and 1295 S. Zhuang, "BGP Dissemination of L2 Flow Specification 1296 Rules", draft-ietf-idr-flowspec-l2vpn-13 (work in 1297 progress), December 2019. 1299 [I-D.ietf-pce-pcep-yang] 1300 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1301 YANG Data Model for Path Computation Element 1302 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1303 yang-13 (work in progress), October 2019. 1305 [I-D.ietf-teas-yang-path-computation] 1306 Busi, I., Belotti, S., Lopezalvarez, V., Sharma, A., and 1307 Y. Shi, "Yang model for requesting Path Computation", 1308 draft-ietf-teas-yang-path-computation-08 (work in 1309 progress), December 2019. 1311 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1312 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1313 2006, . 1315 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1316 Element (PCE)-Based Architecture", RFC 4655, 1317 DOI 10.17487/RFC4655, August 2006, 1318 . 1320 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1321 Zhang, "OSPF Protocol Extensions for Path Computation 1322 Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, 1323 January 2008, . 1325 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1326 Zhang, "IS-IS Protocol Extensions for Path Computation 1327 Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, 1328 January 2008, . 1330 [RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of 1331 Monitoring Tools for Path Computation Element (PCE)-Based 1332 Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010, 1333 . 1335 [RFC6123] Farrel, A., "Inclusion of Manageability Sections in Path 1336 Computation Element (PCE) Working Group Drafts", RFC 6123, 1337 DOI 10.17487/RFC6123, February 2011, 1338 . 1340 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 1341 BGP, LDP, PCEP, and MSDP Issues According to the Keying 1342 and Authentication for Routing Protocols (KARP) Design 1343 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 1344 . 1346 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 1347 Computation Element Architecture", RFC 7399, 1348 DOI 10.17487/RFC7399, October 2014, 1349 . 1351 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1352 Code: The Implementation Status Section", BCP 205, 1353 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1354 . 1356 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1357 Writing an IANA Considerations Section in RFCs", BCP 26, 1358 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1359 . 1361 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1362 Computation Element Communication Protocol (PCEP) 1363 Extensions for Stateful PCE", RFC 8231, 1364 DOI 10.17487/RFC8231, September 2017, 1365 . 1367 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1368 and D. Dhody, "Optimizations of Label Switched Path State 1369 Synchronization Procedures for a Stateful PCE", RFC 8232, 1370 DOI 10.17487/RFC8232, September 2017, 1371 . 1373 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1374 Computation Element Communication Protocol (PCEP) 1375 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1376 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1377 . 1379 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 1380 Architecture for Use of PCE and the PCE Communication 1381 Protocol (PCEP) in a Network with Central Control", 1382 RFC 8283, DOI 10.17487/RFC8283, December 2017, 1383 . 1385 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1386 and J. Hardwick, "Path Computation Element Communication 1387 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 1388 DOI 10.17487/RFC8664, December 2019, 1389 . 1391 Appendix A. Contributors 1393 Shankara 1394 Huawei Technologies 1395 Divyashree Techno Park, 1396 Whitefield Bangalore, 1397 Karnataka 1398 560066 1399 India 1401 Email: shankara@huawei.com 1403 Qiandeng Liang 1404 Huawei Technologies 1405 101 Software Avenue, 1406 Yuhuatai District 1407 Nanjing 1408 210012 1409 China 1411 Email: liangqiandeng@huawei.com 1413 Cyril Margaria 1414 Juniper Networks 1415 200 Somerset Corporate Boulevard, Suite 4001 1416 Bridgewater, NJ 1417 08807 1418 USA 1420 Email: cmargaria@juniper.net 1422 Colby Barth 1423 Juniper Networks 1424 200 Somerset Corporate Boulevard, Suite 4001 1425 Bridgewater, NJ 1426 08807 1427 USA 1429 Email: cbarth@juniper.net 1431 Xia Chen 1432 Huawei Technologies 1433 Huawei Bld., No.156 Beiqing Rd. 1434 Beijing 1435 100095 1436 China 1438 Email: jescia.chenxia@huawei.com 1440 Shunwan Zhuang 1441 Huawei Technologies 1442 Huawei Bld., No.156 Beiqing Rd. 1443 Beijing 1444 100095 1445 China 1447 Email: zhuangshunwan@huawei.com 1449 Cheng Li 1450 Huawei Technologies 1451 Huawei Campus, No. 156 Beiqing Rd. 1452 Beijing 100095 1453 China 1455 Email: chengli13@huawei.com 1457 Authors' Addresses 1459 Dhruv Dhody 1460 Huawei Technologies 1461 Divyashree Techno Park, Whitefield 1462 Bangalore, Karnataka 560066 1463 India 1465 Email: dhruv.ietf@gmail.com 1467 Adrian Farrel 1468 Old Dog Consulting 1470 Email: adrian@olddog.co.uk 1471 Zhenbin Li 1472 Huawei Technologies 1473 Huawei Bld., No.156 Beiqing Rd. 1474 Beijing 100095 1475 China 1477 Email: lizhenbin@huawei.com