idnits 2.17.1 draft-ietf-pce-association-diversity-14.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 (January 26, 2020) is 1524 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-13 == Outdated reference: A later version (-08) exists of draft-dhody-pce-stateful-pce-optional-05 Summary: 0 errors (**), 0 flaws (~~), 3 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 S. Sivabalan 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: July 29, 2020 C. Barth 6 Juniper Networks 7 M. Negi 8 Huawei Technologies 9 January 26, 2020 11 Path Computation Element Communication Protocol (PCEP) Extension for LSP 12 Diversity Constraint Signaling 13 draft-ietf-pce-association-diversity-14 15 Abstract 17 This document introduces a simple mechanism to associate a group of 18 Label Switched Paths (LSPs) via an extension to the Path Computation 19 Element (PCE) communication Protocol (PCEP) with the purpose of 20 computing diverse (disjointed) paths for those LSPs. The proposed 21 extension allows a Path Computation Client (PCC) to advertise to a 22 PCE that a particular LSP belongs to a particular disjoint-group, 23 thus the PCE knows that the LSPs in the same group need to be 24 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 July 29, 2020. 43 Copyright Notice 45 Copyright (c) 2020 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. Disjointness Objective Functions . . . . . . . . . . . . 10 69 5.4. Relationship to SVEC . . . . . . . . . . . . . . . . . . 12 70 5.4.1. SVEC and OF . . . . . . . . . . . . . . . . . . . . . 13 71 5.5. P Flag Considerations . . . . . . . . . . . . . . . . . . 13 72 5.6. Disjointness Computation Issues . . . . . . . . . . . . . 16 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 75 7.1. Association Type . . . . . . . . . . . . . . . . . . . . 18 76 7.2. PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . . . 18 77 7.3. Objective Functions . . . . . . . . . . . . . . . . . . . 19 78 7.4. NO-PATH-VECTOR Bit Flags . . . . . . . . . . . . . . . . 19 79 7.5. PCEP-ERROR Codes . . . . . . . . . . . . . . . . . . . . 20 80 8. Manageability Considerations . . . . . . . . . . . . . . . . 20 81 8.1. Control of Function and Policy . . . . . . . . . . . . . 20 82 8.2. Information and Data Models . . . . . . . . . . . . . . . 21 83 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 21 84 8.4. Verification of Correct Operations . . . . . . . . . . . 21 85 8.5. Requirements on Other Protocols . . . . . . . . . . . . . 21 86 8.6. Impact on Network Operations . . . . . . . . . . . . . . 21 87 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 89 10.1. Normative References . . . . . . . . . . . . . . . . . . 22 90 10.2. Informative References . . . . . . . . . . . . . . . . . 23 91 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 24 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 94 1. Introduction 96 [RFC5440] describes the Path Computation Element communication 97 Protocol (PCEP) which enables the communication between a Path 98 Computation Client (PCC) and a Path Control Element (PCE), or between 99 two PCEs based on the PCE architecture [RFC4655]. 101 PCEP Extensions for Stateful PCE Model [RFC8231] describes a set of 102 extensions to PCEP to enable active control of MPLS-TE and GMPLS 103 tunnels. [RFC8281] describes the setup and teardown of PCE-initiated 104 LSPs under the active stateful PCE model, without the need for local 105 configuration on the PCC, thus allowing for a dynamic network. 107 [I-D.ietf-pce-association-group] introduces a generic mechanism to 108 create a grouping of LSPs in the context of a PCE which can then be 109 used to define associations between a set of LSPs and a set of 110 attributes (such as configuration parameters or behaviors) and is 111 equally applicable to the active and passive modes of a stateful PCE 112 [RFC8231] or a stateless PCE [RFC5440]. 114 This document specifies a PCEP extension to signal that a set of LSPs 115 in a particular group should use diverse (disjointed) paths, 116 including the requested type of diversity. Section 3 and Section 4 117 describe the property and use of a disjoint-group. A PCC can use 118 this extension to signal to a PCE that a particular LSP belongs to a 119 particular disjoint-group. When a PCE receives LSP states belonging 120 to the same disjoint-group from some PCCs, the PCE should ensure that 121 the LSPs within the group are disjoint from each other. 123 1.1. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 127 "OPTIONAL" in this document are to be interpreted as described in BCP 128 14 [RFC2119] [RFC8174] when, and only when, they appear in all 129 capitals, as shown here. 131 2. Terminology 133 The following terminology is used in this document. 135 DAT: Disjoint Association Type. 137 DAG: Disjoint Association Group. 139 MPLS: Multiprotocol Label Switching. 141 OF: Objective Function. 143 PCC: Path Computation Client. Any client application requesting a 144 path computation to be performed by a Path Computation Element. 146 PCE: Path Computation Element. An entity (component, application, 147 or network node) that is capable of computing a network path or 148 route based on a network graph and applying computational 149 constraints. 151 PCEP: Path Computation Element communication Protocol. 153 SRLG: Shared Risk Link Group. 155 3. Motivation 157 Path diversity is a very common use case in today's IP/MPLS networks 158 especially for layer 2 transport over MPLS. A customer may request 159 that the operator provide two end-to-end disjoint paths across the 160 operator's IP/MPLS core. The customer may use these paths as 161 primary/backup or active/active configuration. 163 Different levels of disjointness may be offered: 165 o Link disjointness: the paths of the associated LSPs should transit 166 different links (but may use common nodes or different links that 167 may have some shared fate). 169 o Node disjointness: the paths of the associated LSPs should transit 170 different nodes (but may use different links that may have some 171 shared fate). 173 o SRLG disjointness: the paths of the associated LSPs should transit 174 different links that do not share fate (but may use common transit 175 nodes). 177 o Node+SRLG disjointness: the paths of the associated LSPs should 178 transit different links that do not have any common shared fate 179 and should transit different nodes. 181 The associated LSPs may originate from the same or from different 182 head-end(s) and may terminate at the same or different tail-end(s). 184 4. Applicability 185 _________________________________________ 186 / \ 187 / +------+ \ 188 | | PCE | | 189 | +------+ | 190 | | 191 | ***********************> | 192 | +------+ 10 +------+ | 193 CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2 194 | +------+ | | +------+ | 195 | | | | 196 | | | | 197 | +------+ | | +------+ | 198 CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4 199 | +------+ ***********************> +------+ | 200 | | 201 \ / 202 \_________________________________________/ 204 Figure 1 - Disjoint paths with different head-ends and tail-ends 206 In the figure above, let us consider that the customer wants to have 207 two disjoint paths, one between CE1 and CE2 and one between CE3 and 208 CE4. From an IP/MPLS network point view, in this example, the CEs 209 are connected to different PEs to maximize their disjointness. When 210 LSPs originate from different head-ends, distributed computation of 211 diverse paths can be difficult, whereas, computation via a 212 centralized PCE ensures path disjointness, correctness and 213 simplicity. 215 Section 5.4 describes the relationship between the Disjoint 216 Association Group (DAG) and Synchronization VECtor (SVEC) object. 218 The PCEP extension for stateful PCE [RFC8231] defined new PCEP 219 messages - Path Computation Report (PCRpt), Path Computation Update 220 (PCUpd) and Path Computation Initiate (PCInitiate) [RFC8281]. These 221 messages use PLSP-ID in the LSP object for identification. Moreover 222 to allow diversity between LSPs originating from different PCCs, the 223 generic mechanism to create a grouping of LSPs is described in 224 [I-D.ietf-pce-association-group] (that is equally applicable to the 225 active and passive modes of a stateful PCE). 227 Using the extension to PCEP defined in this document, the PCC uses 228 the [I-D.ietf-pce-association-group] extension to indicate that a 229 group of LSPs are required to be disjoint; such indication should 230 include disjointness parameters such as the type of disjointness, the 231 disjoint group identifiers, and any customization parameters 232 according to the configured local policy. 234 The management of the disjoint group IDs will be a key point for the 235 operator as the Association ID field is limited to 65535. The local 236 configuration of IPv4/IPv6 association source, or Global Association 237 Source/Extended Association ID allows to overcome this limitation as 238 described in [I-D.ietf-pce-association-group]. When a PCC or PCE 239 initiates all the LSPs in a particular disjoint-group, it can set the 240 IPv4/IPv6 association source as one of its own IP address. When 241 disjoint LSPs are initiated from different head-ends, the association 242 source could be the PCE address or any other unique value to identify 243 the DAG. 245 Initiate Disjoint LSPs 246 | 247 | PCReq/PCRpt 248 V {DAG Y} 249 +-----+ ----------------> +-----+ 250 _ _ _ _ _ _| PCE | | | PCE | 251 | +-----+ | ----------> +-----+ 252 | PCInitiate | | PCReq/PCRpt 253 |{DAG X} | | {DAG Y} 254 | | | 255 | .-----. | | .-----. 256 | ( ) | +-----+ ( ) 257 | .--( )--. | |PCC 2|--.--( )--. 258 V ( ) | +-----+ ( ) 259 +---+ ( ) | ( ) 260 |PCC|----( (G)MPLS network ) +-----+ ( (G)MPLS network ) 261 +---+ ( ) |PCC 1|-----( ) 262 {DAG X} ( ) +-----+ ( ) 263 '--( )--' ( )--' 264 ( ) ( ) 265 '-----' '-----' 267 Case 1: Disjointness initiated by Case 2: Disjointness initiated by 268 PCE and enforced by PCC PCC and enforced by PCE 270 Figure 2 - Sample use-cases for carrying disjoint-group over PCEP 271 session 273 Using the disjoint-group within a PCEP messages is used for: 275 o Configuration: Used to communicate the configured disjoint 276 requirement to a PCEP peer. 278 o Status: Used to communicate the status of the computed 279 disjointness. 281 5. Protocol Extension 283 5.1. Association Group 285 As per [I-D.ietf-pce-association-group], LSPs are associated with 286 other LSPs with which they interact by adding them to a common 287 association group. As described in [I-D.ietf-pce-association-group] 288 the association group is uniquely identified by the combination of 289 these fields in the ASSOCIATION object: Association Type, Association 290 ID, Association Source, and (if present) Global Association Source or 291 Extended Association ID. 293 This document defines a new Association type, based on the generic 294 Association object: 296 o Association type = TBD1 Disjoint Association Type (DAT). 298 [I-D.ietf-pce-association-group] specifies the mechanism for the 299 capability advertisement of the association types supported by a PCEP 300 speaker by defining a ASSOC-Type-List TLV to be carried within an 301 OPEN object. This capability exchange for the DAT (TBD1) MUST be 302 done before using the disjointness association. Thus the PCEP 303 speaker MUST include the DAT in the ASSOC-Type-List TLV and MUST 304 receive the same from the PCEP peer before using the Disjoint 305 Association Group (DAG) in PCEP messages. 307 This association type is considered to be both dynamic and operator- 308 configured in nature. As per [I-D.ietf-pce-association-group], the 309 association group could be created by the operator manually on the 310 PCEP peers and the LSPs belonging to this associations is conveyed 311 via PCEP messages to the PCEP peer; or the association group could be 312 created dynamically by the PCEP speaker and both the association 313 group information and the LSPs belonging to the association group is 314 conveyed to the PCEP peer. The Operator-configured Association Range 315 MUST be set for this association-type to mark a range of association 316 identifiers that are used for operator-configured associations to 317 avoid any association identifier clash within the scope of the 318 association source. (Refer to [I-D.ietf-pce-association-group].) 320 A disjoint group can have two or more LSPs, but a PCE may be limited 321 in the number of LSPs it can take into account when computing 322 disjointness. If a PCE receives more LSPs in the group than it can 323 handle in its computation algorithm, it SHOULD apply disjointness 324 computation to only a subset of LSPs in the group. The subset of 325 disjoint LSPs will be decided by PCE as a local policy. Local 326 polices MAY define the computational behavior for the other LSPs in 327 the group. For example, the PCE may provide no path, a shortest 328 path, or a constrained path based on relaxing disjointness, etc. The 329 disjoint status of the computed path is informed to the PCC via 330 DISJOINTNESS-STATUS-TLV (see Section 5.2). 332 There are differet types of disjointness identified by the flags (T, 333 S, N, L) in the DISJOINTNESS-CONFIGURATION-TLV (see Section 5.2). 334 All LSPs in a particular disjoint group MUST use the same combination 335 of T, S, N, L flags in the DISJOINTNESS-CONFIGURATION-TLV. If a PCEP 336 peer receives a PCEP messages for LSPs belonging to the same disjoint 337 group but having an inconsistent combination of T, S, N, L flags, the 338 PCEP peer MUST NOT add the LSPs to the disjoint group and MUST reply 339 with a PCErr with Error-type 26 (Association Error) and Error-Value 6 340 (Association information mismatch). 342 A particular LSP MAY be associated to the multiple disjoint groups, 343 but in that case, the PCE SHOULD try to consider all the disjoint 344 groups during path computation if possible. Otherwise a local policy 345 MAY define the computational behavior. If a PCE does not support 346 such a path computation it MUST NOT add the LSP into the association 347 group and return a PCErr with Error-type 26 (Association Error) and 348 Error-Value 7 (Cannot join the association group). 350 5.2. Disjoint TLVs 352 The disjoint group (ASSOCIATION object with Association type = TBD1 353 for DAT) MUST carry the following TLV: 355 o DISJOINTNESS-CONFIGURATION-TLV: Used to communicate some 356 disjointness configuration parameters. This is applicable for all 357 PCEP message that includes DAG. 359 In addition, the disjoint group (ASSOCIATION object with Association 360 type = TBD1 for DAT) MAY carry the following TLVs: 362 o DISJOINTNESS-STATUS-TLV: Used to communicate the status of the 363 computed disjointness. This is applicable for messages from a PCE 364 to a PCC only (i.e. PCUpd, PCInitiate or PCRep message). 366 o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor- 367 specific behavioral information, described in [RFC7470]. 369 o OF-List TLV: Used to communicate the disjointness objective 370 function. See Section 5.3. 372 The DISJOINTNESS-CONFIGURATION-TLV is shown in the following figure: 374 0 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Type = TBD2 | Length | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Flags |T|P|S|N|L| 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 Type: TBD2. 384 Length: Fixed value of 4 bytes. 386 Flags: 388 * L (Link diverse) bit: when set, this indicates that the 389 computed paths within the disjoint group MUST NOT have any link 390 in common. 392 * N (Node diverse) bit: when set, this indicates that the 393 computed paths within the disjoint group MUST NOT have any node 394 in common. 396 * S (SRLG diverse) bit: when set, this indicates that the 397 computed paths within the disjoint group MUST NOT share any 398 SRLG (Shared Risk Link Group). 400 * P (Shortest path) bit: when set, this indicates that the 401 computed path of the LSP SHOULD satisfy all the constraints and 402 objective functions first without considering the diversity 403 constraint, this means that all of the LSPs with P flag set in 404 the association group are computed first as if the disjointness 405 constraint has not been configured, and then with those LSPs 406 fixed, the other LSPs with P flag unset in the association 407 group are computed by taking into account the disjointness 408 constraint. The role of P flag is further described with 409 examples in Section 5.5. 411 * T (Strict disjointness) bit: when set, if disjoint paths cannot 412 be found, PCE MUST return no path for LSPs that could not be be 413 disjoint. When unset, the PCE is allowed to relax disjointness 414 by Section 5.5 either applying a requested objective function 415 (cf. Section 5.3 below) or using the local policy if no 416 objective function is requested (e.g. using a lower disjoint 417 type (link instead of node) or fully relaxing disjointness 418 constraint). Further see Section 5.6 for details. 420 * Unassigned bits are considered reserved. They MUST be set to 0 421 on transmission and MUST be ignored on receipt. 423 If a PCEP speaker receives a disjoint-group (ASSOCIATION object with 424 Association type = TBD1 for DAT) without DISJOINTNESS-CONFIGURATION- 425 TLV, it SHOULD reply with a PCErr Error-type=6 (Mandatory Object 426 missing) and Error-value=TBD10 (DISJOINTNESS-CONFIGURATION-TLV 427 missing). 429 The DISJOINTNESS-STATUS-TLV uses the same format as the DISJOINTNESS- 430 CONFIGURATION-TLV with a different type TBD3 (in the TLV). The L, N, 431 and S flags are set if the respective disjointness criterion was 432 requested and the computed paths meet it. The P flag indicates that 433 the computed path is the shortest path (computed first without taking 434 disjointness constraints into consideration, but considering other 435 constraints). 437 The T flag has no meaning in the DISJOINTNESS-STATUS-TLV and MUST NOT 438 be set while sending and MUST be ignored on receipt. 440 Any document defining a new flag for the DISJOINTNESS-CONFIGURATION- 441 TLV automatically defines a new flag with the same name and in the 442 same location in DISJOINTNESS-STATUS-TLV; the semantics of the flag 443 in DISJOINTNESS-STATUS-TLV MUST be specified in the document that 444 specifies the flag in DISJOINTNESS-CONFIGURATION-TLV. 446 5.3. Disjointness Objective Functions 448 An objective function (OF) MAY be applied to the disjointness 449 computation to drive the PCE computation behavior. In this case, the 450 OF-List TLV (defined in ([RFC5541]) is used as an optional TLV in the 451 Association Group Object. Whereas the PCEP OF-List TLV allows 452 multiple OF-codes inside the TLV, a sender SHOULD include a single 453 OF-code in the OF-List TLV when included in the Association Group, 454 and the receiver MUST consider the first OF-code only and ignore 455 others if included. 457 To minimize the common shared resources (Node, Link or SRLG) between 458 a set of paths during path computation three new OF-codes are 459 proposed: 461 MSL 463 * Name: Minimize the number of shared (common) Links. 465 * Objective Function Code: TBD4 466 * Description: Find a set of paths such that it passes through the 467 least number of shared (common) links. 469 * A network comprises a set of N links {Li, (i=1...N)}. 471 * A path P passes through K links {Lpi,(i=1...K)}. 473 * A set of paths {P1...Pm} have L links that are common to more 474 than one path {Lci,(i=1...L)}. 476 * Find a set of paths such that the value of L is minimized. 478 MSS 480 * Name: Minimize the number of shared (common) SRLGs. 482 * Objective Function Code: TBD5 484 * Description: Find a set of paths such that it passes through the 485 least number of shared (common) SRLGs. 487 * A network comprises a set of N links {Li, (i=1...N)}. 489 * A path P passes through K links {Lpi,(i=1...K)} belonging to 490 unique M SRLGs {Spi,(i=1..M)}. 492 * A set of paths {P1...Pm} have L SRLGs that are common to more 493 than one path {Sci,(i=1...L)}. 495 * Find a set of paths such that the value of L is minimized. 497 MSN 499 * Name: Minimize the number of shared (common) Nodes. 501 * Objective Function Code: TBD6 503 * Description: Find a set of paths such that they pass through the 504 least number of shared (common) nodes. 506 * A network comprises a set of N nodes {Ni, (i=1...N)}. 508 * A path P passes through K nodes {Npi,(i=1...K)}. 510 * A set of paths {P1...Pm} have L nodes that are common to more 511 than one path {Nci,(i=1...L)}. 513 * Find a set of paths such that the value of L is minimized. 515 If the OF-list TLV is included in the Association Object, the first 516 OF-code inside the OF Object MUST be one of the disjoint OFs defined 517 in this document. If this condition is not met, the PCEP speaker 518 MUST respond with a PCErr message with Error-Type=10 (Reception of an 519 invalid object) and Error-Value=TBD9 (Incompatible OF code). 521 5.4. Relationship to SVEC 523 [RFC5440] defines a mechanism for the synchronization of a set of 524 path computation requests by using the SVEC object, that specifies 525 the list of synchronized requests that can either be dependent or 526 independent. The SVEC object identifies the relationship between the 527 set of path computation requests, identified by 'Request-ID-number' 528 in RP (Request Parameters) object. [RFC6007] further clarified the 529 use of the SVEC list for synchronized path computations when 530 computing dependent requests as well as described a number of usage 531 scenarios for SVEC lists within single-domain and multi-domain 532 environments. 534 The SVEC object includes a Flags field that indicates the potential 535 dependency between the set of path computation requests in a similar 536 way as the Flags field in the TLVs defined in this document. The 537 path computation request in the PCReq message MAY use both the SVEC 538 and ASSOCIATION objects to identify the related path computation 539 request as well as the DAG. The PCE MUST try to find a path that 540 meets both the constraints. It is possible that the diversity 541 requirement in the association group is different from the one in the 542 SVEC object. The PCE MUST consider both the objects (including the 543 flags set inside the objects) as per the processing rules and aim to 544 find a path that meets both of these constraints. In case no such 545 path is possible, the PCE MUST send a path computation reply (PCRep) 546 with a NO-PATH object indicating path computation failure as per 547 [RFC5440]. It should be noted that the LSPs in the association group 548 can be fully same or partially overlapping with the LSPs grouped by 549 the SVEC object in PCReq message. 551 Some examples of usage are listed below: 553 o PCReq with SVEC object with node-diverse bit=1 (LSP1,LSP2) and DAG 554 with S=1 (LSP1,LSP2) - both node and SRLG diverse path between 555 LSP1, LSP2. 557 o PCReq with SVEC object with link-diverse bit=1 (LSP1,LSP2) and DAG 558 with L=1 (LSP1,LSP3) - link diverse paths between LSP1 & LSP2, and 559 LSP1 & LSP3. If the DAG is part of the stateful database, any 560 future change in LSP3 will have an impact on LSP1. But any future 561 change in LSP2 will have no impact on LSP1, as LSP2 is part of 562 SVEC object (which is considered once on receipt of the PCReq 563 message only). 565 5.4.1. SVEC and OF 567 This document defines three new OF-codes Section 5.3 to maximize 568 diversity as much as possible, in other words, new OF-codes allow 569 specification of minimization of common shared resources (Node, Link 570 or SRLG) among a set of paths during path computation. 572 It may be interesting to note that the diversity flags in the SVEC 573 object and OF for diversity can be used together. Some examples of 574 usage are listed below: 576 o SVEC object with node-diverse bit=1 - ensure full node-diversity. 578 o SVEC object with node-diverse bit=1 and OF=MSS - full node diverse 579 with as much as SRLG-diversity as possible. 581 o SVEC object with domain-diverse bit=1;link diverse bit=1 and 582 OF=MSS - full domain and node diverse path with as much as SRLG- 583 diversity as possible. 585 o SVEC object with node-diverse bit=1 and OF=MSN - ensure full node- 586 diversity. 588 In the last example above, it is interesting to note that "OF" 589 becomes redundant as "SVEC object" ensures full node-diversity, 590 however this specification does not prohibit redundant constraints 591 while using "SVEC object" and "OF" together for diversity. 593 5.5. P Flag Considerations 595 As mentioned in Section 5.2, the P flag (when set) indicates that the 596 computed path of the LSP SHOULD satisfies all constraints and 597 objective functions first without considering the diversity 598 constraint. 600 This means that an LSP with P flag set should be placed first as if 601 the disjointness constraint has not been configured, while the other 602 LSPs in the association with P flag unset should be placed by taking 603 into account the disjointness constraint. Setting the P flag changes 604 the relationship between LSPs to a one-sided relationship (LSP 1 with 605 P=0 depends on LSP 2 with P=1, but LSP 2 with P=1 does not depend of 606 LSP 1 with P=0). Multiple LSPs in the same disjoint group may have 607 the P flag set. In such a case, those LSPs may not be disjoint from 608 each other but will be disjoint from other LSPs in the group that 609 have the P flag unset. 611 This could be required in some primary/backup scenarios where the 612 primary path should use the more optimal path available (taking into 613 account the other constraints). When disjointness is computed, it is 614 important for the algorithm to know that it should try to optimize 615 the path of one or more LSPs in the disjoint group (for instance the 616 primary path) while other paths are allowed to be costlier (compared 617 to a similar path without the disjointness constraint). Without such 618 a hint, the disjointness algorithm may set a path for all LSPs that 619 may not completely fulfill the customer's requirement. 621 _________________________________________ 622 / \ 623 / +------+ \ 624 | | PCE | | 625 | +------+ | 626 | | 627 | | 628 | +------+ 10 +------+ | 629 CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2 630 | +------+ | | +------+ | 631 | | | | 632 | | | | 633 | +------+ | | +------+ | 634 CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4 635 | +------+ \ | / +------+ | 636 | \ | 10 / | 637 \ +-- R5 --------- R6 / 638 \_________________________________________/ 640 Cost of all the links is 1, unless explicitly marked otherwise. 642 Figure 3 644 In the figure above, a customer has two dual homed sites (CE1/CE3 and 645 CE2/CE4). Let us consider that this customer wants two link disjoint 646 paths between the two sites. Due to physical meshing, the customer 647 wants to use CE1 and CE2 as primary (and CE3 and CE4 are hosted in a 648 remote site for redundancy purpose). 650 Without any hint (constraint) provided, the PCE may compute the two 651 link disjoint LSPs together, leading to PE1->PE2 using a path 652 PE1->R1->R2->PE2 and PE3->PE4 using PE3->R3->R4->PE4. In this case, 653 even if the disjointness constraint is fulfilled, the path from PE1 654 to PE2 does not use the best optimal path available in the network 655 (path delay may be higher): the customer requirement is thus not 656 completely fulfilled. 658 The usage of the P flag allows the PCE to know that a particular LSP 659 should be tied to the best path as if the disjointness constraint was 660 not requested. 662 In our example, if the P flag is set to the LSP PE1->PE2, the PCE 663 should use the path PE1->R1->R3->R4->R2->PE2 for this LSP, while the 664 other LSP should be link disjoint from this path. The second LSP 665 will be placed on PE3->R5->R6->PE4 as it is allowed to be costlier. 667 Driving the PCE disjointness computation may be done in other ways, 668 for instance setting a metric boundary reflecting an path delay 669 boundary. Other constraints may also be used. 671 The P flag allows to simply express that the disjointness constraint 672 should not make the LSP worst. 674 Any constraint added to a path disjointness computation may reduce 675 the chance to find suitable paths. The usage of the P flag, as any 676 other constraint, may prevent to find a disjoint path. In the 677 example above, if we consider that the router R5 is down, if PE1->PE2 678 has the P flag set, there is no room available to place PE3->PE4 (the 679 link disjointness constraint cannot be fulfilled). If PE1->PE2 has 680 the P flag unset, the algorithm may be able to place PE1->PE2 on 681 R1->R2 link leaving a room for PE3->PE4 using the R3->R4 link. When 682 using P flag or any additional constraint on top of the disjointness 683 constraint, the user should be aware that there is less chance to 684 fulfill the disjointness constraint. 686 _________________________________________ 687 / \ 688 / +------+ \ 689 | | PCE | | 690 | +------+ | 691 | | 692 | | 693 | +------+ 10 +------+ | 694 CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2 695 | +------+ | \ | +------+ | 696 | | \2 | | 697 | | \ | | 698 | +------+ | \ | +------+ | 699 CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4 700 | +------+ +------+ | 701 | | 702 \ / 703 \_________________________________________/ 705 Cost of all the links is 1, unless explicitly marked otherwise. 707 Figure 4 709 In the figure above, we still consider the same previous 710 requirements, so PE1->PE2 LSP should be optimized (P flag set) while 711 PE3->PE4 should be link disjoint and may use a costlier path. 713 Regarding PE1->PE2, there are two paths that are satisfying the 714 constraints (ECMP): PE1->R1->R4->R2->PE2 (path 1) and 715 PE1->R1->R3->R4->R2->PE2 (path 2). An implementation may choose one 716 of the paths. 718 If the implementation elects only one path, there is a chance that 719 picking up one path may prevent link disjointness. In our example, 720 if path 2 is used for PE1->PE2, there is no room left for PE3->PE4 721 while if path 1 is used, PE3->PE4 can be placed on R3->R4 link. 723 When P flag is set for an LSP and when ECMPs are available, an 724 implementation should aim to select a path that allows disjointness. 726 5.6. Disjointness Computation Issues 728 There may be some cases where the PCE is not able to provide a set of 729 disjoint paths for one or more LSPs in the association. 731 When the T flag is set (Strict disjointness requested), if 732 disjointness cannot be ensured for one or more LSPs, the PCE MUST 733 reply to a Path Computation Request (PCReq) with a Path Computation 734 Reply (PCRep) message containing a NO-PATH object. In case of PCRpt 735 message, the PCE MUST return a PCErr message with Error-Type 26 736 "Association Error" and Error-Value 7 "Cannot join the association 737 group". 739 In case of a network event leading to an impossible strict 740 disjointness, the PCE MUST send a PCUpd message containing an empty 741 ERO to the corresponding PCCs. In addition to the empty ERO Object, 742 the PCE MAY add the NO-PATH-VECTOR TLV ([RFC5440]) in the LSP Object. 744 This document adds new bits in the NO-PATH-VECTOR TLV: 746 bit "TBD7": when set, the PCE indicates that it could not find a 747 disjoint path for this LSP. 749 bit "TBD8": when set, the PCE indicates that it does not support 750 the requested disjointness computation. 752 When the T flag is unset, the PCE is allowed to relax disjointness by 753 applying a requested objective function (Section 5.3) if specified. 754 Otherwise, if no objective function is specified, the PCE is allowed 755 to reduce the required level of disjointness as it deems fit. The 756 actual level of disjointness of the paths computed by the PCE can be 757 reported through the DISJOINTNESS-STATUS-TLV by setting the 758 appropriate flags in the TLV. While the DISJOINTNESS-CONFIGURATION- 759 TLV defines the desired level of disjointness required by 760 configuration, the DISJOINTNESS-STATUS-TLV defines the achieved level 761 of disjointness computed. 763 There are some cases where the PCE may need to completely relax the 764 disjointness constraint in order to provide a path to all the LSPs 765 that are part of the association. A mechanism that allows the PCE to 766 fully relax a constraint is considered by the authors as more global 767 to PCEP rather than linked to the disjointness use case. As a 768 consequence, it is considered as out of scope of the document. See 769 [I-D.dhody-pce-stateful-pce-optional] for a proposed mechanism. 771 6. Security Considerations 773 This document defines one new PCEP association type, which on itself 774 does not add any new security concerns beyond those discussed in 775 [RFC5440], [RFC8231], [RFC7470] and [I-D.ietf-pce-association-group]. 776 But, adding of a spurious LSP into the disjointness association group 777 could lead to re-computation and set-up of all LSPs in the group, 778 that could be used to overwhelm the PCE and the network. 780 A spurious LSP can have flags that are inconsistent with those of the 781 legitimate LSPs of the group and thus cause LSP allocation for the 782 legitimate LSPs to fail with an error. Also, certain combinations of 783 flags (notably, the 'T' bit) can result in conflicts that cannot be 784 resolved. 786 Also, as stated in [I-D.ietf-pce-association-group], much of the 787 information carried in the Disjointness Association object reflects 788 information that can also be derived from the LSP Database, but 789 association provides a much easier grouping of related LSPs and 790 messages. The disjointness association could provide an adversary 791 with the opportunity to eavesdrop on the relationship between the 792 LSPs and understand the network topology. 794 Thus securing the PCEP session using Transport Layer Security (TLS) 795 [RFC8253], as per the recommendations and best current practices in 796 BCP 195 [RFC7525], is RECOMMENDED. 798 7. IANA Considerations 800 7.1. Association Type 802 This document defines a new Association type, originally described in 803 [I-D.ietf-pce-association-group]. IANA is requested to make the 804 assignment of a new value for the sub-registry "ASSOCIATION Type 805 Field" (request to be created in [I-D.ietf-pce-association-group]), 806 as follows: 808 +------------------+--------------------------------+-------------+ 809 | Association type | Association Name | Reference | 810 +------------------+--------------------------------+-------------+ 811 | TBD1 | Disjointness Association Type | [This.I-D] | 812 +------------------+--------------------------------+-------------+ 814 7.2. PCEP TLVs 816 This document defines the following new PCEP TLVs and the IANA is 817 requested to make the assignment of new values for the existing "PCEP 818 TLV Type Indicators" registry as follows: 820 +----------+---------------------------------+-------------+ 821 | TLV Type | TLV Name | Reference | 822 +----------+---------------------------------+-------------+ 823 | TBD2 | Disjointness Configuration TLV | [This.I-D] | 824 | TBD3 | Disjointness Status TLV | [This.I-D] | 825 +----------+---------------------------------+-------------+ 827 This document requests that a new sub-registry, named "Disjointness 828 Configuration TLV Flag Field", is created within the "Path 829 Computation Element Protocol (PCEP) Numbers" registry to manage the 830 Flag field in the Disjointness Configuration TLV. New values are to 831 be assigned by Standards Action [RFC8126]. Each bit should be 832 tracked with the following qualities: 834 o Bit number (count from 0 as the most significant bit) 836 o Flag Name 838 o Reference 840 +------------+-------------------------+-------------+ 841 | Bit Number | Name | Reference | 842 +------------+-------------------------+-------------+ 843 | 31 | L - Link Diverse | [This.I-D] | 844 | 30 | N - Node Diverse | [This.I-D] | 845 | 29 | S - SRLG Diverse | [This.I-D] | 846 | 28 | P - Shortest Path | [This.I-D] | 847 | 27 | T - Strict Disjointness | [This.I-D] | 848 +------------+-------------------------+-------------+ 850 Table 1: Disjointness Configuration TLV 852 7.3. Objective Functions 854 Three new Objective Functions have been defined in this document. 855 IANA is requested to make the following allocations from the PCEP 856 "Objective Function" sub-registry: 858 +------------+----------------------------------------+-------------+ 859 | Code Point | Name | Reference | 860 +------------+----------------------------------------+-------------+ 861 | TBD4 | Minimize the number of shared Links | [This.I-D] | 862 | | (MSL) | | 863 | TBD5 | Minimize the number of shared SRLGs | [This.I-D] | 864 | | (MSS) | | 865 | TBD6 | Minimize the number of shared Nodes | [This.I-D] | 866 | | (MSN) | | 867 +------------+----------------------------------------+-------------+ 869 7.4. NO-PATH-VECTOR Bit Flags 871 This documents defines new bits for the NO-PATH-VECTOR TLV in the 872 "NO-PATH-VECTOR TLV Flag Field" sub-registry of the "Path Computation 873 Element Protocol (PCEP) Numbers" registry. IANA is requested to make 874 the following allocation: 876 +------------+-----------------------------------------+------------+ 877 | Bit Number | Name | Reference | 878 +------------+-----------------------------------------+------------+ 879 | TBD7 | Disjoint path not found | [This.I-D] | 880 | TBD8 | Requested disjoint computation not | [This.I-D] | 881 | | supported | | 882 +------------+-----------------------------------------+------------+ 884 Table 2: NO-PATH-VECTOR TLV 886 7.5. PCEP-ERROR Codes 888 This document defines new Error-Value within existing Error-Type 889 related to path protection association. IANA is requested to 890 allocate new error values within the "PCEP-ERROR Object Error Types 891 and Values" sub-registry of the PCEP Numbers registry, as follows: 893 +----------+-------------------------+------------------------------+ 894 | Error- | Meaning | Reference | 895 | Type | | | 896 +----------+-------------------------+------------------------------+ 897 | 6 | Mandatory Object | [I-D.ietf-pce-association-gr | 898 | | missing | oup] | 899 | | Error-value=TBD10: | [This.I-D] | 900 | | DISJOINTNESS- | | 901 | | CONFIGURATION TLV | | 902 | | missing | | 903 | 10 | Reception of an invalid | [RFC5440] | 904 | | object | | 905 | | Error-value=TBD9: | [This.I-D] | 906 | | Incompatible OF code | | 907 +----------+-------------------------+------------------------------+ 909 8. Manageability Considerations 911 8.1. Control of Function and Policy 913 An operator SHOULD be allowed to configure the disjointness 914 association groups and disjoint parameters at the PCEP peers and 915 associate it with the LSPs. The Operator-configured Association 916 Range MUST be allowed to be set by the operator. The operator SHOULD 917 be allowed to set the local policies to define various disjoint 918 computational behavior at the PCE. 920 8.2. Information and Data Models 922 An implementation SHOULD allow the operator to view the disjoint 923 associations configured or created dynamically. Furthermore, 924 implementations SHOULD allow to view disjoint associations reported 925 by each peer, and the current set of LSPs in this association. The 926 PCEP YANG module [I-D.ietf-pce-pcep-yang] includes association groups 927 information. 929 8.3. Liveness Detection and Monitoring 931 Mechanisms defined in this document do not imply any new liveness 932 detection and monitoring requirements in addition to those already 933 listed in [RFC5440]. 935 8.4. Verification of Correct Operations 937 Apart from the operation verification requirements already listed in 938 [RFC5440], a PCEP implementation SHOULD provide parameters related to 939 disjoint path computation, such as number of DAG, number of disjoint 940 path computation failures etc. A PCEP implementation SHOULD log 941 failure events (e.g., incompatible Flags). 943 8.5. Requirements on Other Protocols 945 Mechanisms defined in this document do not imply any new requirements 946 on other protocols. 948 8.6. Impact on Network Operations 950 Mechanisms defined in [RFC5440], Section 8.6 also apply to PCEP 951 extensions defined in this document. Additionally, a PCEP 952 implementation SHOULD allow a limit to be placed on the number of 953 LSPs that can belong to a DAG. 955 9. Acknowledgments 957 A special thanks to authors of [I-D.ietf-pce-association-group], this 958 document borrow some of the text from it. Authors would also like to 959 thank Adrian Farrel and Julien Meuric for the valuable comments. 961 Thanks to Emmanuel Baccelli for RTGDIR review. 963 Thanks to Dale Worley for a detailed GENART review. 965 Thanks to Alvaro Retana, Benjamin Kaduk, Suresh Krishnan, Roman 966 Danyliw, Alissa Cooper and Eric Vyncke for IESG review. 968 10. References 970 10.1. Normative References 972 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 973 Requirement Levels", BCP 14, RFC 2119, 974 DOI 10.17487/RFC2119, March 1997, 975 . 977 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 978 Writing an IANA Considerations Section in RFCs", BCP 26, 979 RFC 8126, DOI 10.17487/RFC8126, June 2017, 980 . 982 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 983 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 984 DOI 10.17487/RFC5440, March 2009, 985 . 987 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 988 Objective Functions in the Path Computation Element 989 Communication Protocol (PCEP)", RFC 5541, 990 DOI 10.17487/RFC5541, June 2009, 991 . 993 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 994 Constraints in the Path Computation Element Communication 995 Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, 996 . 998 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 999 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1000 May 2017, . 1002 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1003 Computation Element Communication Protocol (PCEP) 1004 Extensions for Stateful PCE", RFC 8231, 1005 DOI 10.17487/RFC8231, September 2017, 1006 . 1008 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1009 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1010 Path Computation Element Communication Protocol (PCEP)", 1011 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1012 . 1014 [I-D.ietf-pce-association-group] 1015 Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 1016 Dhody, D., and Y. Tanaka, "Path Computation Element 1017 Communication Protocol (PCEP) Extensions for Establishing 1018 Relationships Between Sets of Label Switched Paths 1019 (LSPs)", draft-ietf-pce-association-group-10 (work in 1020 progress), August 2019. 1022 10.2. Informative References 1024 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1025 Element (PCE)-Based Architecture", RFC 4655, 1026 DOI 10.17487/RFC4655, August 2006, 1027 . 1029 [RFC6007] Nishioka, I. and D. King, "Use of the Synchronization 1030 VECtor (SVEC) List for Synchronized Dependent Path 1031 Computations", RFC 6007, DOI 10.17487/RFC6007, September 1032 2010, . 1034 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1035 "Recommendations for Secure Use of Transport Layer 1036 Security (TLS) and Datagram Transport Layer Security 1037 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1038 2015, . 1040 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1041 Computation Element Communication Protocol (PCEP) 1042 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1043 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1044 . 1046 [I-D.ietf-pce-pcep-yang] 1047 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1048 YANG Data Model for Path Computation Element 1049 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1050 yang-13 (work in progress), October 2019. 1052 [I-D.dhody-pce-stateful-pce-optional] 1053 Li, C., Zheng, H., and S. Litkowski, "Extension for 1054 Stateful PCE to allow Optional Processing of PCEP 1055 Objects", draft-dhody-pce-stateful-pce-optional-05 (work 1056 in progress), January 2020. 1058 Appendix A. Contributor Addresses 1060 Dhruv Dhody 1061 Huawei Technologies 1062 Divyashree Techno Park, Whitefield 1063 Bangalore, Karnataka 560066 1064 India 1066 EMail: dhruv.ietf@gmail.com 1068 Authors' Addresses 1070 Stephane Litkowski 1071 Cisco Systems, Inc. 1073 EMail: slitkows.ietf@gmail.com 1075 Siva Sivabalan 1076 Cisco Systems, Inc. 1077 2000 Innovation Drive 1078 Kanata, Ontario K2K 3E8 1079 Canada 1081 EMail: msiva@cisco.com 1083 Colby Barth 1084 Juniper Networks 1086 EMail: cbarth@juniper.net 1088 Mahendra Singh Negi 1089 Huawei Technologies 1090 Divyashree Techno Park, Whitefield 1091 Bangalore, Karnataka 560066 1092 India 1094 EMail: mahend.ietf@gmail.com