idnits 2.17.1 draft-ietf-pce-association-diversity-09.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 (August 16, 2019) is 1715 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) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-12 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group S. Litkowski 3 Internet-Draft Orange 4 Intended status: Standards Track S. Sivabalan 5 Expires: February 17, 2020 Cisco Systems, Inc. 6 C. Barth 7 Juniper Networks 8 M. Negi 9 Huawei Technologies 10 August 16, 2019 12 Path Computation Element Communication Protocol (PCEP) Extension for LSP 13 Diversity Constraint Signaling 14 draft-ietf-pce-association-diversity-09 16 Abstract 18 This document introduces a simple mechanism to associate a group of 19 Label Switched Paths (LSPs) via an extension to the Path Computation 20 Element (PCE) communication Protocol (PCEP) with the purpose of 21 computing diverse paths for those LSPs. The proposed extension 22 allows a Path Computation Client (PCC) to advertise to a PCE that a 23 particular LSP belongs to a disjoint-group, thus the PCE knows that 24 the LSPs in the same group need to be disjoint from each other. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on February 17, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 65 5. Protocol Extension . . . . . . . . . . . . . . . . . . . . . 7 66 5.1. Association Group . . . . . . . . . . . . . . . . . . . . 7 67 5.2. Disjoint TLVs . . . . . . . . . . . . . . . . . . . . . . 8 68 5.3. Relationship to SVEC . . . . . . . . . . . . . . . . . . 10 69 5.4. Disjointness Objective functions . . . . . . . . . . . . 10 70 5.5. P Flag Considerations . . . . . . . . . . . . . . . . . . 12 71 5.6. Disjointness Computation Issues . . . . . . . . . . . . . 15 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 74 7.1. Association Type . . . . . . . . . . . . . . . . . . . . 16 75 7.2. PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . . . 17 76 7.3. Objective Functions . . . . . . . . . . . . . . . . . . . 18 77 7.4. NO-PATH-VECTOR Bit Flags . . . . . . . . . . . . . . . . 18 78 7.5. PCEP-ERROR Codes . . . . . . . . . . . . . . . . . . . . 18 79 8. Manageability Considerations . . . . . . . . . . . . . . . . 19 80 8.1. Control of Function and Policy . . . . . . . . . . . . . 19 81 8.2. Information and Data Models . . . . . . . . . . . . . . . 19 82 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 19 83 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 19 84 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 20 85 8.6. Impact On Network Operations . . . . . . . . . . . . . . 20 86 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 88 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 89 10.2. Informative References . . . . . . . . . . . . . . . . . 21 90 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 23 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 93 1. Introduction 95 [RFC5440] describes the Path Computation Element communication 96 Protocol (PCEP) which enables the communication between a Path 97 Computation Client (PCC) and a Path Control Element (PCE), or between 98 two PCEs based on the PCE architecture [RFC4655]. 100 PCEP Extensions for Stateful PCE Model [RFC8231] describes a set of 101 extensions to PCEP to enable active control of MPLS-TE and GMPLS 102 tunnels. [RFC8281] describes the setup and teardown of PCE-initiated 103 LSPs under the active stateful PCE model, without the need for local 104 configuration on the PCC, thus allowing for a dynamic network. 106 [I-D.ietf-pce-association-group] introduces a generic mechanism to 107 create a grouping of LSPs in the context of a PCE which can then be 108 used to define associations between a set of LSPs and a set of 109 attributes (such as configuration parameters or behaviors) and is 110 equally applicable to the active and passive modes of a stateful PCE 111 [RFC8231] or a stateless PCE [RFC5440]. 113 This document specifies a PCEP extension to signal that a particular 114 group of LSPs should use diverse paths including the requested type 115 of diversity. A PCC can use this extension to signal to a PCE that a 116 particular LSP belongs to a disjoint-group. When a PCE receives LSP 117 states belonging to the same disjoint-group from some PCCs, the PCE 118 should ensure that the LSPs within the group are disjoint from each 119 other. 121 1.1. Requirements Language 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 2. Terminology 131 The following terminology is used in this document. 133 DAG: Disjoint Association Group. 135 MPLS: Multiprotocol Label Switching. 137 OF: Objective Function. 139 PCC: Path Computation Client. Any client application requesting a 140 path computation to be performed by a Path Computation Element. 142 PCE: Path Computation Element. An entity (component, application, 143 or network node) that is capable of computing a network path or 144 route based on a network graph and applying computational 145 constraints. 147 PCEP: Path Computation Element communication Protocol. 149 SRLG: Shared Risk Link Group. 151 3. Motivation 153 Path diversity is a very common use case in today's IP/MPLS networks 154 especially for layer 2 transport over MPLS. A customer may request 155 that the operator provide two end-to-end disjoint paths across the 156 IP/MPLS core. The customer may use those paths as primary/backup or 157 active/active. 159 Different level of disjointness may be offered: 161 o Link disjointness: the paths of the associated LSPs should transit 162 different links (but may use common nodes or different links that 163 may have some shared fate). 165 o Node disjointness: the paths of the associated LSPs should transit 166 different nodes (but may use different links that may have some 167 shared fate). 169 o SRLG disjointness: the paths of the associated LSPs should transit 170 different links that do not share fate (but may use common transit 171 nodes). 173 o Node+SRLG disjointness: the paths of the associated LSPs should 174 transit different links that do not have any common shared fate 175 and should transit different nodes. 177 The associated LSPs may originate from the same or from different 178 head-end(s) and may terminate at the same or different tail-end(s). 180 4. Applicability 181 _________________________________________ 182 / \ 183 / +------+ \ 184 | | PCE | | 185 | +------+ | 186 | | 187 | ***********************> | 188 | +------+ 10 +------+ | 189 CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2 190 | +------+ | | +------+ | 191 | | | | 192 | | | | 193 | +------+ | | +------+ | 194 CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4 195 | +------+ ***********************> +------+ | 196 | | 197 \ / 198 \_________________________________________/ 200 Figure 1 - Disjoint paths with different head-ends and tail-ends 202 In the figure above, let us consider that the customer wants to have 203 two disjoint paths between CE1/CE2 and CE3/CE4. From an IP/MPLS 204 network point view, in this example, the CEs are connected to 205 different PEs to maximize their disjointness. When LSPs originate 206 from different head-ends, distributed computation of diverse paths 207 can be difficult, whereas, computation via a centralized PCE ensures 208 path disjointness, correctness and simplicity. 210 Section 5.3 describes the relationship between the disjoint 211 association group and Synchronization VECtor (SVEC) object. 213 The PCEP extension for stateful PCE [RFC8231] defined new PCEP 214 messages - Path Computation Report (PCRpt), Path Computation Update 215 (PCUpd) and Path Computation Initiate (PCInitiate) [RFC8281]. These 216 messages use PLSP-ID in the LSP object for identification. Moreover 217 to allow diversity between LSPs originating from different PCCs, the 218 generic mechanism to create a grouping of LSPs is described in 219 [I-D.ietf-pce-association-group] (that is equally applicable to the 220 active and passive modes of a stateful PCE). 222 Using PCEP, the PCC could indicate that a disjoint path computation 223 is required, such indication should include disjointness parameters 224 such as the type of disjointness, the disjoint group identifiers, and 225 any customization parameters according to the configured local 226 policy. As mentioned previously, the extension described in 228 [I-D.ietf-pce-association-group] is well suited to associate a set of 229 LSPs with a particular disjoint-group. 231 The management of the disjoint group IDs will be a key point for the 232 operator as the Association ID field is limited to 65535. The local 233 configuration of IPv4/IPv6 association source, or Global Association 234 Source/Extended Association ID allows to overcome this limitation as 235 described in [I-D.ietf-pce-association-group]. When a PCC or PCE 236 initiates all the LSPs in a particular disjoint-group, it can set the 237 IPv4/IPv6 association source as one of its own IP address. When 238 disjoint LSPs are initiated from different head-ends, the association 239 source could be the PCE address or any other unique value to identify 240 the disjoint association group. 242 Initiate Disjoint LSPs 243 | 244 | PCReq/PCRpt 245 V {Disjoint-group Y} 246 +-----+ ----------------> +-----+ 247 _ _ _ _ _ _| PCE | | | PCE | 248 | +-----+ | ----------> +-----+ 249 | PCInitiate | | PCReq/PCRpt 250 |{Disjoint-group X} | | {Disjoint-group Y} 251 | | | 252 | .-----. | | .-----. 253 | ( ) | +----+ ( ) 254 | .--( )--. | |PE 1|--.--( )--. 255 V ( ) | +----+ ( ) 256 +---+ ( ) | ( ) 257 |PCC|----( (G)MPLS network ) +----+ ( (G)MPLS network ) 258 +---+ ( ) |PE 3|-----( ) 259 Disjoint-group X ) +----+ ( ) 260 '--( )--' '--( )--' 261 ( ) ( ) 262 '-----' '-----' 264 Case 1: Disjointness initiated by Case 2: Disjointness initiated by 265 PCE and enforced by PCC PCC and enforced by PCE 267 Figure 2 - Sample use-cases for carrying disjoint-group over PCEP 268 session 270 Using the disjoint-group within a PCEP messages may have two purpose: 272 o Configuration: Used to communicate the configured disjoint 273 requirement to a PCEP peer. 275 o Status: Used to communicate the status of the computed 276 disjointness. 278 5. Protocol Extension 280 5.1. Association Group 282 As per [I-D.ietf-pce-association-group], LSPs are associated with 283 other LSPs with which they interact by adding them to a common 284 association group. The Association parameters, as described in 285 [I-D.ietf-pce-association-group] as the combination of the mandatory 286 fields Association type, Association ID and Association Source in the 287 ASSOCIATION object, that uniquely identify the association group 288 belonging to this association. If the optional TLVs - Global 289 Association Source or Extended Association ID - are included, then 290 they are included in combination with mandatory fields to uniquely 291 identify the association group. This document defines a new 292 Association type, based on the generic Association object: 294 o Association type = TBD1 ("Disjointness Association Type") for 295 Disjoint Association Group (DAG). 297 [I-D.ietf-pce-association-group] specifies the mechanism for the 298 capability advertisement of the association types supported by a PCEP 299 speaker by defining a ASSOC-Type-List TLV to be carried within an 300 OPEN object. This capability exchange for the association type 301 described in this document (i.e. Disjointness Association Type) MUST 302 be done before using the disjointness association. Thus the PCEP 303 speaker MUST include the Disjointness Association Type (TBD1) in the 304 ASSOC-Type-List TLV before using the disjoint association group (DAG) 305 in PCEP messages. 307 This association type is considered to be both dynamic and operator- 308 configured in nature. The association group could be created by the 309 operator manually on the PCEP peers and the LSPs belonging to this 310 associations is conveyed via PCEP messages to the PCEP peer; or the 311 association group could be created dynamically by the PCEP speaker 312 and both the association group information and the LSPs belonging to 313 the association group is conveyed to the PCEP peer. The Operator- 314 configured Association Range MUST be set for this association-type to 315 mark a range of association identifiers that are used for operator- 316 configured associations to avoid any association identifier clash 317 within the scope of the association source. (Refer to 318 [I-D.ietf-pce-association-group].) 319 A disjoint group can have two or more LSPs, but a PCE may be limited 320 in the number of LSPs it can take into account when computing 321 disjointness. If a PCE receives more LSPs in the group than it can 322 handle in its computation algorithm, it SHOULD apply disjointness 323 computation to only a subset of LSPs in the group. The subset of 324 disjoint LSPs will be decided by PCE as a local policy. Local 325 polices MAY define the computational behavior for the other LSPs in 326 the group. For example, the PCE may provide no path, a shortest 327 path, or a constrained path based on relaxing disjointness, etc. The 328 disjoint status is informed to the PCC. 330 Associating a particular LSP to multiple disjoint groups is 331 authorized from a protocol perspective, however there is no assurance 332 that the PCE will be able to compute properly the multi-disjointness 333 constraint. 335 5.2. Disjoint TLVs 337 The disjoint group MUST carry the following TLV: 339 o DISJOINTNESS-CONFIGURATION-TLV: Used to communicate some 340 disjointness configuration parameters. 342 In addition, the disjoint group MAY carry the following TLV: 344 o DISJOINTNESS-STATUS-TLV: Used to communicate the status of the 345 computed disjointness. This is applicable for messages from PCE 346 to PCC (PCUpd, PCInitiate or PCRep message). 348 o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor- 349 specific behavioral information, described in [RFC7470]. 351 o OF-List TLV: Used to communicate the disjointness objective 352 function. See Section 5.4. 354 The DISJOINTNESS-CONFIGURATION-TLV is shown in the following figure: 356 0 1 2 3 357 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 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Type = TBD2 | Length | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Flags |T|P|S|N|L| 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Type: TBD2. 366 Length: Fixed value of 4 bytes. 368 Flags: 370 * L (Link diverse) bit: when set, this indicates that the 371 computed paths within the disjoint group MUST NOT have any link 372 in common. 374 * N (Node diverse) bit: when set, this indicates that the 375 computed paths within the disjoint group MUST NOT have any node 376 in common. 378 * S (SRLG diverse) bit: when set, this indicates that the 379 computed paths within the disjoint group MUST NOT share any 380 SRLG (Shared Risk Link Group). 382 * P (Shortest path) bit: when set, this indicates that the 383 computed path of the LSP SHOULD satisfy all the constraints and 384 objective functions first without considering the diversity 385 constraint. This means that an LSP with P flag set should be 386 placed as if the disjointness constraint has not been 387 configured, while the other LSP in the association with P flag 388 unset should be placed by taking into account the disjointness 389 constraint. Setting P flag changes the relationship between 390 LSPs to a one-sided relationship (LSP 1 with P=0 depends of LSP 391 2 with P=1, but LSP 2 with P=1 does not depend of LSP 1 with 392 P=0). Multiple LSPs in the same disjoint group may have the P 393 flag set. In such a case, those LSPs may not be disjoint from 394 each other but will be disjoint from others LSPs in the group 395 that have the P flag unset. 397 * T (Strict disjointness) bit: when set, if disjoint paths cannot 398 be found, PCE SHOULD return no path for LSPs that could not be 399 be disjoint. When unset, the PCE is allowed to relax 400 disjointness by either applying a requested objective function 401 (cf. Section 5.4 below) or using any other behavior if no 402 objective function is requested (e.g. using a lower disjoint 403 type (link instead of node) or fully relaxing disjointness 404 constraint). Further see Section 5.6 for details. 406 * Unassigned bits are considered reserved. They MUST be set to 0 407 on transmission and MUST be ignored on receipt. 409 If a PCEP speaker receives a disjoint-group without DISJOINTNESS- 410 CONFIGURATION-TLV, it SHOULD reply with a PCErr Error-type=6 411 (Mandatory Object missing) and Error-value=TBD8 (DISJOINTNESS- 412 CONFIGURATION-TLV missing). 414 The DISJOINTNESS-STATUS-TLV uses the same format as the DISJOINTNESS- 415 CONFIGURATION-TLV with a different type TBD3 (in the TLV). The L, N, 416 and S flags are set based if the computed path meet the disjointness 417 criteria. The P flag is set to indicate that the computed path is 418 the shortest and the T flag has no meaning in the DISJOINTNESS- 419 STATUS-TLV and MUST NOT be set while sending and ignored on receipt. 421 Any new flag defined for the DISJOINTNESS-CONFIGURATION-TLV is be 422 automatically applicable to the DISJOINTNESS-STATUS-TLV. 424 5.3. Relationship to SVEC 426 [RFC5440] defines a mechanism for the synchronization of a set of 427 path computation requests by using the SVEC object, that specifies 428 the list of synchronized requests that can either be dependent or 429 independent. The SVEC object identify the relationship between the 430 set of path computation requests, identified by 'Request-ID-number' 431 in RP (Request Parameters) object. [RFC6007] further clarified the 432 use of the SVEC list for synchronized path computations when 433 computing dependent requests as well as described a number of usage 434 scenarios for SVEC lists within single-domain and multi-domain 435 environments. 437 The SVEC object includes a Flags field that indicates the potential 438 dependency between the set of path computation request in a similar 439 way as the Flags field in the TLVs defined in this document. The 440 path computation request in the PCReq message MAY use both the SVEC 441 and ASSOCIATION objects to identify the related path computation 442 request as well as the diversity association group. The PCE MUST try 443 to find a path that meets both the constraints. It is possible that 444 the diversity requirement in the association group is different from 445 the one in the SVEC object. The PCE would consider both the objects 446 as per the processing rules and aim to find a path that meets both of 447 these constraints. In case no such path is possible (or the 448 constraints are incompatible), the PCE MUST send a path computation 449 reply (PCRep) with a NO-PATH object indicating path computation 450 failure as per [RFC5440]. 452 5.4. Disjointness Objective functions 454 An objective function (OF) MAY be applied to the disjointness 455 computation to drive the PCE computation behavior. In this case, the 456 OF-List TLV (defined in ([RFC5541]) is used as an optional TLV in the 457 Association Group Object. Whereas the PCEP OF-List TLV allows 458 multiple OF-codes inside the TLV, a sender SHOULD include a single 459 OF-code in the OF-List TLV when included in the Association Group, 460 and the receiver MUST consider the first OF-code only and ignore 461 others if included. 463 To minimize the common shared resources (Node, Link or SRLG) between 464 a set of paths during path computation three new OF-codes are 465 proposed: 467 MSL 469 * Name: Minimize the number of shared (common) Links. 471 * Objective Function Code: TBD4 473 * Description: Find a set of paths such that it passes through the 474 least number of shared (common) links. 476 MSS 478 * Name: Minimize the number of shared (common) SRLGs. 480 * Objective Function Code: TBD5 482 * Description: Find a set of paths such that it passes through the 483 least number of shared (common) SRLGs. 485 MSN 487 * Name: Minimize the number of shared (common) Nodes. 489 * Objective Function Code: TBD6 491 * Description: Find a set of paths such that it passes through the 492 least number of shared (common) nodes. 494 If the OF-list TLV is included in the Association Object, the OF-code 495 inside the OF Object MUST include one of the disjoint OFs defined in 496 this document. If this condition is not met, the PCEP speaker MUST 497 respond with a PCErr message with Error-Type=10 (Reception of an 498 invalid object) and Error-Value=TBD9 (Incompatible OF code). 500 [RFC5440] uses SVEC diversity flag for node, link or SRLG to describe 501 the potential disjointness between the set of path computation 502 requests used in PCEP protocol. 504 This document defines three new OF-codes to maximize diversity as 505 much as possible, in other words, minimize the common shared 506 resources (Node, Link or SRLG) between a set of paths. 508 It may be interesting to note that the diversity flags in the SVEC 509 object and OF for diversity can be used together. Some examples of 510 usage are listed below: 512 o SVEC object with node-diverse bit=1 - ensure full node-diversity. 514 o SVEC object with node-diverse bit=1 and OF=MSS - full node diverse 515 with as much as SRLG-diversity as possible. 517 o SVEC object with domain-diverse bit=1;link diverse bit=1 and 518 OF=MSS - full domain and node diverse path with as much as SRLG- 519 diversity as possible. 521 o SVEC object with node-diverse bit=1 and OF=MSN - ensure full node- 522 diversity. 524 In the last example above, it is interesting to note that "OF" 525 becomes redundant as "SVEC object" ensures full node-diversity, 526 however this specification does not prohibit redundant constraints 527 while using "SVEC object" and "OF" together for diversity. 529 5.5. P Flag Considerations 531 As mentioned in Section 5.2, the P flag (when set) indicates that the 532 computed path of the LSP SHOULD satisfies all constraints and 533 objective functions first without considering the diversity 534 constraint. This could be required in some primary/backup scenarios 535 where the primary path should use the more optimal path available 536 (taking into account the other constraints). When disjointness is 537 computed, it is important for the algorithm to know that it should 538 try to optimize the path of one or more LSPs in the disjoint group 539 (for instance the primary path) while other paths are allowed to be 540 costlier (compared to a similar path without the disjointness 541 constraint). Without such a hint, the disjointness algorithm may set 542 a path for all LSPs that may not completely fulfill the customer's 543 requirement. 545 _________________________________________ 546 / \ 547 / +------+ \ 548 | | PCE | | 549 | +------+ | 550 | | 551 | | 552 | +------+ 10 +------+ | 553 CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2 554 | +------+ | | +------+ | 555 | | | | 556 | | | | 557 | +------+ | | +------+ | 558 CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4 559 | +------+ \ | / +------+ | 560 | \ | 10 / | 561 \ +-- R5 --------- R6 / 562 \_________________________________________/ 564 Cost of all the links is 1, unless explicitly marked otherwise. 566 Figure 3 568 In the figure above, a customer has two dual homed sites (CE1/CE3 and 569 CE2/CE4). Let us consider that this customer wants two disjoint 570 paths between the two sites. Due to physical meshing, the customer 571 wants to use CE1 and CE2 as primary (and CE3 and CE4 are hosted in a 572 remote site for redundancy purpose). 574 Without any hint (constraint) provided, the PCE may compute the two 575 disjoint LSPs together, leading to PE1->PE2 using a path 576 PE1->R1->R2->PE2 and PE3->PE4 using PE3->R3->R4->PE4. In this case, 577 even if the disjointness constraint is fulfilled, the path from PE1 578 to PE2 does not use the best optimal path available in the network 579 (path delay may be higher): the customer requirement is thus not 580 completely fulfilled. 582 The usage of the P flag allows the PCE to know that a particular LSP 583 should be tied to the best path as if the disjointness constraint was 584 not requested. 586 In our example, if the P flag is set to the LSP PE1->PE2, the PCE 587 should use the path PE1->R1->R3->R4->R2->PE2 for this LSP, while the 588 other LSP should be disjoint from this path. The second LSP will be 589 placed on PE3->R5->R6->PE4 as it is allowed to be costlier. 591 Driving the PCE disjointness computation may be done in other ways, 592 for instance setting a metric boundary reflecting an path delay 593 boundary. Other constraints may also be used. 595 The P flag allows to simply express that the disjointness constraint 596 should not make the LSP worst. 598 Any constraint added to a path disjointness computation may reduce 599 the chance to find suitable paths. The usage of the P flag, as any 600 other constraint, may prevent to find a disjoint path. In the 601 example above, if we consider that the router R5 is down, if PE1->PE2 602 has the P flag set, there is no room available to place PE3->PE4 (the 603 disjointness constraint cannot be fulfilled). If PE1->PE2 has the P 604 flag unset, the algorithm may be able to place PE1->PE2 on R1->R2 605 link leaving a room for PE3->PE4 using the R3->R4 link. When using P 606 flag or any additional constraint on top of the disjointness 607 constraint, the user should be aware that there is less chance to 608 fulfill the disjointness constraint. 610 _________________________________________ 611 / \ 612 / +------+ \ 613 | | PCE | | 614 | +------+ | 615 | | 616 | | 617 | +------+ 10 +------+ | 618 CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2 619 | +------+ | \ | +------+ | 620 | | \2 | | 621 | | \ | | 622 | +------+ | \ | +------+ | 623 CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4 624 | +------+ +------+ | 625 | | 626 \ / 627 \_________________________________________/ 629 Cost of all the links is 1, unless explicitly marked otherwise. 631 Figure 4 633 In the figure above, we still consider the same previous 634 requirements, so PE1->PE2 LSP should be optimized (P flag set) while 635 PE3->PE4 should be disjoint and may use a costlier path. 637 Regarding PE1->PE2, there are two paths that are satisfying the 638 constraints (ECMP): PE1->R1->R4->R2->PE2 (path 1) and 639 PE1->R1->R3->R4->R2->PE2 (path 2). An implementation may choose one 640 of the paths. 642 If the implementation elects only one path, there is a chance that 643 picking up one path may prevent disjointness. In our example, if 644 path 2 is used for PE1->PE2, there is no room left for PE3->PE4 while 645 if path 1 is used, PE3->PE4 can be placed on R3->R4 link. 647 When P flag is set for an LSP and when ECMPs are available, an 648 implementation should aim to select a path that allows disjointness. 650 5.6. Disjointness Computation Issues 652 There may be some cases where the PCE is not able to provide a set of 653 disjoint paths for one or more LSPs in the association. 655 When the T flag is set (Strict disjointness requested), if 656 disjointness cannot be ensured for one or more LSPs, the PCE MUST 657 reply to a Path Computation Request (PCReq) with a Path Computation 658 Reply (PCRep) message containing a NO-PATH object. In case of other 659 PCEP message, the PCE MUST return a PCErr message with Error-Type 26 660 "Association Error" and Error-Value 7 "Cannot join the association 661 group". Also, in case of network event leading to an impossible 662 strict disjointness, the PCE MUST send a PCUpd message containing an 663 empty ERO to the corresponding PCCs. In addition to the empty ERO 664 Object, the PCE MAY add the NO-PATH-VECTOR TLV ([RFC5440]) in the LSP 665 Object. 667 This document adds new bits in the NO-PATH-VECTOR TLV: 669 bit "TBD7": when set, the PCE indicates that it could not find a 670 disjoint path for this LSP. 672 bit "TBD8": when set, the PCE indicates that it does not support 673 the requested disjointness computation. 675 When the T flag is unset, the PCE is allowed to relax disjointness by 676 either applying a requested objective function (Section 5.4) if 677 specified. Otherwise the PCE is allowed to reduce the required level 678 of disjointness (as it deems fit). The actual level of disjointness 679 computed by the PCE can be reported through the DISJOINTNESS-STATUS- 680 TLV by setting the appropriate flags in the TLV. While the 681 DISJOINTNESS-CONFIGURATION-TLV defines the expected level of 682 disjointness required by configuration, the DISJOINTNESS-STATUS-TLV 683 defines the actual level of disjointness computed. 685 There are some cases where the PCE may need to completely relax the 686 disjointness constraint in order to provide a path to all the LSPs 687 that are part of the association. A mechanism that allows the PCE to 688 fully relax a constraint is considered by the authors as more global 689 to PCEP rather than linked to the disjointness use case. As a 690 consequence, it is considered as out of scope of the document. 692 All LSPs in a particular disjoint group MUST use the same combination 693 of T, S, N, L flags in the DISJOINTNESS-CONFIGURATION-TLV. If a PCEP 694 peer receives a PCEP messages for LSPs belonging to the same disjoint 695 group but having an inconsistent combination of T, S, N, L flags, the 696 PCEP peer SHOULD NOT try to add the LSPs in disjoint group and SHOULD 697 reply with a PCErr with Error-type 26 (Association Error) and Error- 698 Value 6 (Association information mismatch). 700 6. Security Considerations 702 This document defines one new type for association, which on itself 703 does not add any new security concerns beyond those discussed in 704 [RFC5440], [RFC8231] and [I-D.ietf-pce-association-group]. But, 705 adding of a spurious LSP into the disjointness association group 706 could lead to re-computation and set-up of all LSPs in the group, 707 that could be used to overwhelm the PCE and the network. 709 Also, as stated in [I-D.ietf-pce-association-group], much of the 710 information carried in the Disjointness Association object, as per 711 this document is not extra sensitive. It often reflects information 712 that can also be derived from the LSP Database, but association 713 provides a much easier grouping of related LSPs and messages. The 714 disjointness association could provide an adversary with the 715 opportunity to eavesdrop on the relationship between the LSPs. 717 Thus securing the PCEP session using Transport Layer Security (TLS) 718 [RFC8253], as per the recommendations and best current practices in 719 [RFC7525], is RECOMMENDED. 721 7. IANA Considerations 723 7.1. Association Type 725 This document defines a new Association type, originally described in 726 [I-D.ietf-pce-association-group]. IANA is requested to make the 727 assignment of a new value for the sub-registry "ASSOCIATION Type 728 Field" (request to be created in [I-D.ietf-pce-association-group]), 729 as follows: 731 +------------------+-----------------------------+-------------+ 732 | Association type | Association Name | Reference | 733 +------------------+-----------------------------+-------------+ 734 | TBD1 | Disjoint-group Association | [This.I-D] | 735 +------------------+-----------------------------+-------------+ 737 7.2. PCEP TLVs 739 This document defines the following new PCEP TLVs and the IANA is 740 requested to make the assignment of new values for the existing "PCEP 741 TLV Type Indicators" registry as follows: 743 +----------+---------------------------------+-------------+ 744 | TLV Type | TLV Name | Reference | 745 +----------+---------------------------------+-------------+ 746 | TBD2 | Disjointness Configuration TLV | [This.I-D] | 747 | TBD3 | Disjointness Status TLV | [This.I-D] | 748 +----------+---------------------------------+-------------+ 750 This document requests that a new sub-registry, named "Disjointness 751 Configuration TLV Flag Field", is created within the "Path 752 Computation Element Protocol (PCEP) Numbers" registry to manage the 753 Flag field in the Disjointness Configuration TLV. New values are to 754 be assigned by Standards Action [RFC8126]. Each bit should be 755 tracked with the following qualities: 757 o Bit number (count from 0 as the most significant bit) 759 o Flag Name 761 o Reference 763 +------------+-------------------------+-------------+ 764 | Bit Number | Name | Reference | 765 +------------+-------------------------+-------------+ 766 | 31 | L - Link Diverse | [This.I-D] | 767 | 30 | N - Node Diverse | [This.I-D] | 768 | 29 | S - SRLG Diverse | [This.I-D] | 769 | 28 | P - Shortest Path | [This.I-D] | 770 | 27 | T - Strict Disjointness | [This.I-D] | 771 +------------+-------------------------+-------------+ 773 Table 1: Disjointness Configuration TLV 775 7.3. Objective Functions 777 Three new Objective Functions have been defined in this document. 778 IANA is requested to make the following allocations from the PCEP 779 "Objective Function" sub-registry: 781 +------------+----------------------------------------+-------------+ 782 | Code Point | Name | Reference | 783 +------------+----------------------------------------+-------------+ 784 | TBD4 | Minimize the number of shared Links | [This.I-D] | 785 | | (MSL) | | 786 | TBD5 | Minimize the number of shared SRLGs | [This.I-D] | 787 | | (MSS) | | 788 | TBD6 | Minimize the number of shared Nodes | [This.I-D] | 789 | | (MSN) | | 790 +------------+----------------------------------------+-------------+ 792 7.4. NO-PATH-VECTOR Bit Flags 794 This documents defines new bits for the NO-PATH-VECTOR TLV in the 795 "NO-PATH-VECTOR TLV Flag Field" sub-registry of the "Path Computation 796 Element Protocol (PCEP) Numbers" registry. IANA is requested to make 797 the following allocation: 799 +------------+-----------------------------------------+------------+ 800 | Bit Number | Name | Reference | 801 +------------+-----------------------------------------+------------+ 802 | TBD7 | Disjoint path not found | [This.I-D] | 803 | TBD8 | Requested disjoint computation not | [This.I-D] | 804 | | supported | | 805 +------------+-----------------------------------------+------------+ 807 Table 2: NO-PATH-VECTOR TLV 809 7.5. PCEP-ERROR Codes 811 This document defines new Error-Value within existing Error-Type 812 related to path protection association. IANA is requested to 813 allocate new error values within the "PCEP-ERROR Object Error Types 814 and Values" sub-registry of the PCEP Numbers registry, as follows: 816 +----------+-------------------------+------------------------------+ 817 | Error- | Meaning | Reference | 818 | Type | | | 819 +----------+-------------------------+------------------------------+ 820 | 6 | Mandatory Object | [I-D.ietf-pce-association-gr | 821 | | missing | oup] | 822 | | Error-value=TBD8: | [This.I-D] | 823 | | DISJOINTNESS- | | 824 | | CONFIGURATION TLV | | 825 | | missing | | 826 | 10 | Reception of an invalid | [RFC5440] | 827 | | object | | 828 | | Error-value=TBD9: | [This.I-D] | 829 | | Incompatible OF code | | 830 +----------+-------------------------+------------------------------+ 832 8. Manageability Considerations 834 8.1. Control of Function and Policy 836 An operator SHOULD be allowed to configure the disjointness 837 association groups and disjoint parameters at the PCEP peers and 838 associate it with the LSPs. The Operator-configured Association 839 Range MUST be allowed to be set by the operator. Operator SHOULD be 840 allowed to set the local policies to define various disjoint 841 computational behavior at the PCE. 843 8.2. Information and Data Models 845 An implementation SHOULD allow the operator to view the disjoint 846 associations configured or created dynamically. Further 847 implementation SHOULD allow to view disjoint associations reported by 848 each peer, and the current set of LSPs in this association. The PCEP 849 YANG module [I-D.ietf-pce-pcep-yang] includes association groups 850 information. 852 8.3. Liveness Detection and Monitoring 854 Mechanisms defined in this document do not imply any new liveness 855 detection and monitoring requirements in addition to those already 856 listed in [RFC5440]. 858 8.4. Verify Correct Operations 860 Mechanisms defined in this document do not imply any new operation 861 verification requirements in addition to those already listed in 862 [RFC5440]. 864 8.5. Requirements On Other Protocols 866 Mechanisms defined in this document do not imply any new requirements 867 on other protocols. 869 8.6. Impact On Network Operations 871 Mechanisms defined in [RFC5440], Section 8.6 also apply to PCEP 872 extensions defined in this document. Additionally, a PCEP 873 implementation SHOULD allow a limit to be placed on the number of 874 LSPs that can belong to a disjoint association group. 876 9. Acknowledgments 878 A special thanks to authors of [I-D.ietf-pce-association-group], this 879 document borrow some of the text from it. Authors would also like to 880 thank Adrian Farrel and Julien Meuric for the valuable comments. 882 Thanks to Emmanuel Baccelli for RTGDIR reviews. 884 10. References 886 10.1. Normative References 888 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 889 Requirement Levels", BCP 14, RFC 2119, 890 DOI 10.17487/RFC2119, March 1997, 891 . 893 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 894 Writing an IANA Considerations Section in RFCs", BCP 26, 895 RFC 8126, DOI 10.17487/RFC8126, June 2017, 896 . 898 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 899 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 900 DOI 10.17487/RFC5440, March 2009, 901 . 903 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 904 Objective Functions in the Path Computation Element 905 Communication Protocol (PCEP)", RFC 5541, 906 DOI 10.17487/RFC5541, June 2009, 907 . 909 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 910 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 911 May 2017, . 913 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 914 Computation Element Communication Protocol (PCEP) 915 Extensions for Stateful PCE", RFC 8231, 916 DOI 10.17487/RFC8231, September 2017, 917 . 919 [I-D.ietf-pce-association-group] 920 Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 921 Dhody, D., and Y. Tanaka, "Path Computation Element 922 Communication Protocol (PCEP) Extensions for Establishing 923 Relationships Between Sets of Label Switched Paths 924 (LSPs)", draft-ietf-pce-association-group-10 (work in 925 progress), August 2019. 927 10.2. Informative References 929 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 930 Element (PCE)-Based Architecture", RFC 4655, 931 DOI 10.17487/RFC4655, August 2006, 932 . 934 [RFC6007] Nishioka, I. and D. King, "Use of the Synchronization 935 VECtor (SVEC) List for Synchronized Dependent Path 936 Computations", RFC 6007, DOI 10.17487/RFC6007, September 937 2010, . 939 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 940 Constraints in the Path Computation Element Communication 941 Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, 942 . 944 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 945 "Recommendations for Secure Use of Transport Layer 946 Security (TLS) and Datagram Transport Layer Security 947 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 948 2015, . 950 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 951 "PCEPS: Usage of TLS to Provide a Secure Transport for the 952 Path Computation Element Communication Protocol (PCEP)", 953 RFC 8253, DOI 10.17487/RFC8253, October 2017, 954 . 956 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 957 Computation Element Communication Protocol (PCEP) 958 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 959 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 960 . 962 [I-D.ietf-pce-pcep-yang] 963 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 964 YANG Data Model for Path Computation Element 965 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 966 yang-12 (work in progress), July 2019. 968 Appendix A. Contributor Addresses 970 Dhruv Dhody 971 Huawei Technologies 972 Divyashree Techno Park, Whitefield 973 Bangalore, Karnataka 560066 974 India 976 EMail: dhruv.ietf@gmail.com 978 Authors' Addresses 980 Stephane Litkowski 981 Orange 983 EMail: stephane.litkowski@orange.com 985 Siva Sivabalan 986 Cisco Systems, Inc. 987 2000 Innovation Drive 988 Kanata, Ontario K2K 3E8 989 Canada 991 EMail: msiva@cisco.com 993 Colby Barth 994 Juniper Networks 996 EMail: cbarth@juniper.net 998 Mahendra Singh Negi 999 Huawei Technologies 1000 Divyashree Techno Park, Whitefield 1001 Bangalore, Karnataka 560066 1002 India 1004 EMail: mahend.ietf@gmail.com