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