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