idnits 2.17.1 draft-ietf-pce-association-diversity-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 4, 2019) is 1729 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-10) exists of draft-ietf-pce-association-group-09 -- 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-11 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 Orange 4 Intended status: Standards Track S. Sivabalan 5 Expires: January 5, 2020 Cisco Systems, Inc. 6 C. Barth 7 Juniper Networks 8 M. Negi 9 Huawei Technologies 10 July 4, 2019 12 Path Computation Element Communication Protocol (PCEP) Extension for LSP 13 Diversity Constraint Signaling 14 draft-ietf-pce-association-diversity-08 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 January 5, 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. Protocol Extension . . . . . . . . . . . . . . . . . . . . . 7 65 4.1. Association Group . . . . . . . . . . . . . . . . . . . . 7 66 4.2. Disjoint TLVs . . . . . . . . . . . . . . . . . . . . . . 8 67 4.3. Relationship to SVEC . . . . . . . . . . . . . . . . . . 10 68 4.4. Disjointness Objective functions . . . . . . . . . . . . 10 69 4.5. P Flag Considerations . . . . . . . . . . . . . . . . . . 12 70 4.6. Disjointness Computation Issues . . . . . . . . . . . . . 15 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 73 6.1. Association Type . . . . . . . . . . . . . . . . . . . . 16 74 6.2. PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . . . 16 75 6.3. Objective Functions . . . . . . . . . . . . . . . . . . . 17 76 6.4. NO-PATH-VECTOR Bit Flags . . . . . . . . . . . . . . . . 18 77 6.5. PCEP-ERROR Codes . . . . . . . . . . . . . . . . . . . . 18 78 7. Manageability Considerations . . . . . . . . . . . . . . . . 18 79 7.1. Control of Function and Policy . . . . . . . . . . . . . 18 80 7.2. Information and Data Models . . . . . . . . . . . . . . . 19 81 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 19 82 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 19 83 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 19 84 7.6. Impact On Network Operations . . . . . . . . . . . . . . 19 85 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 88 9.2. Informative References . . . . . . . . . . . . . . . . . 20 89 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 22 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 92 1. Introduction 94 [RFC5440] describes the Path Computation Element communication 95 Protocol (PCEP) which enables the communication between a Path 96 Computation Client (PCC) and a Path Control Element (PCE), or between 97 two PCEs based on the PCE architecture [RFC4655]. 99 PCEP Extensions for Stateful PCE Model [RFC8231] describes a set of 100 extensions to PCEP to enable active control of MPLS-TE and GMPLS 101 tunnels. [RFC8281] describes the setup and teardown of PCE-initiated 102 LSPs under the active stateful PCE model, without the need for local 103 configuration on the PCC, thus allowing for a dynamic network. 105 [I-D.ietf-pce-association-group] introduces a generic mechanism to 106 create a grouping of LSPs in the context of a PCE which can then be 107 used to define associations between a set of LSPs and a set of 108 attributes (such as configuration parameters or behaviors) and is 109 equally applicable to the active and passive modes of a stateful PCE 110 [RFC8231] or a stateless PCE [RFC5440]. 112 This document specifies a PCEP extension to signal that a particular 113 group of LSPs should use diverse paths including the requested type 114 of diversity. A PCC can use this extension to signal to a PCE that a 115 particular LSP belongs to a disjoint-group. When a PCE receives LSP 116 states belonging to the same disjoint-group from some PCCs, the PCE 117 should ensure that the LSPs within the group are disjoint from each 118 other. 120 1.1. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in BCP 125 14 [RFC2119] [RFC8174] when, and only when, they appear in all 126 capitals, as shown here. 128 2. Terminology 130 The following terminology is used in this document. 132 DAG: Disjoint Association Group. 134 MPLS: Multiprotocol Label Switching. 136 OF: Objective Function. 138 PCC: Path Computation Client. Any client application requesting a 139 path computation to be performed by a Path Computation Element. 141 PCE: Path Computation Element. An entity (component, application, 142 or network node) that is capable of computing a network path or 143 route based on a network graph and applying computational 144 constraints. 146 PCEP: Path Computation Element communication Protocol. 148 SRLG: Shared Risk Link Group. 150 3. Motivation 152 Path diversity is a very common use case in today's IP/MPLS networks 153 especially for layer 2 transport over MPLS. A customer may request 154 that the operator provide two end-to-end disjoint paths across the 155 IP/MPLS core. The customer may use those paths as primary/backup or 156 active/active. 158 Different level of disjointness may be offered: 160 o Link disjointness: the paths of the associated LSPs should transit 161 different links (but may use common nodes or different links that 162 may have some shared fate). 164 o Node disjointness: the paths of the associated LSPs should transit 165 different nodes (but may use different links that may have some 166 shared fate). 168 o SRLG disjointness: the paths of the associated LSPs should transit 169 different links that do not share fate (but may use common transit 170 nodes). 172 o Node+SRLG disjointness: the paths of the associated LSPs should 173 transit different links that do not have any common shared fate 174 and should transit different nodes. 176 The associated LSPs may originate from the same or from different 177 head-end(s) and may terminate at the same or different tail-end(s). 179 _________________________________________ 180 / \ 181 / +------+ \ 182 | | PCE | | 183 | +------+ | 184 | | 185 | ***********************> | 186 | +------+ 10 +------+ | 187 CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2 188 | +------+ | | +------+ | 189 | | | | 190 | | | | 191 | +------+ | | +------+ | 192 CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4 193 | +------+ ***********************> +------+ | 194 | | 195 \ / 196 \_________________________________________/ 198 Figure 1 - Disjoint paths with different head-ends and tail-ends 200 In the figure above, let us consider that the customer wants to have 201 two disjoint paths between CE1/CE2 and CE3/CE4. From an IP/MPLS 202 network point view, in this example, the CEs are connected to 203 different PEs to maximize their disjointness. When LSPs originate 204 from different head-ends, distributed computation of diverse paths 205 can be difficult, whereas, computation via a centralized PCE ensures 206 path disjointness, correctness and simplicity. 208 Section 4.3 describes the relationship between the disjoint 209 association group and Synchronization VECtor (SVEC) object. 211 The PCEP extension for stateful PCE [RFC8231] defined new PCEP 212 messages - Path Computation Report (PCRpt), Path Computation Update 213 (PCUpd) and Path Computation Initiate (PCInitiate) [RFC8281]. These 214 messages use PLSP-ID in the LSP object for identification. Moreover 215 to allow diversity between LSPs originating from different PCCs, the 216 generic mechanism to create a grouping of LSPs is described in 217 [I-D.ietf-pce-association-group] (that is equally applicable to the 218 active and passive modes of a stateful PCE). 220 Using PCEP, the PCC could indicate that a disjoint path computation 221 is required, such indication should include disjointness parameters 222 such as the type of disjointness, the disjoint group identifiers, and 223 any customization parameters according to the configured local 224 policy. As mentioned previously, the extension described in 226 [I-D.ietf-pce-association-group] is well suited to associate a set of 227 LSPs with a particular disjoint-group. 229 The management of the disjoint group IDs will be a key point for the 230 operator as the Association ID field is limited to 65535. The local 231 configuration of IPv4/IPv6 association source, or Global Association 232 Source/Extended Association ID allows to overcome this limitation as 233 described in [I-D.ietf-pce-association-group]. When a PCC or PCE 234 initiates all the LSPs in a particular disjoint-group, it can set the 235 IPv4/IPv6 association source as one of its own IP address. When 236 disjoint LSPs are initiated from different head-ends, the association 237 source could be the PCE address or any other unique value to identify 238 the disjoint association group. 240 Initiate Disjoint LSPs 241 | 242 | PCReq/PCRpt 243 V {Disjoint-group Y} 244 +-----+ ----------------> +-----+ 245 _ _ _ _ _ _| PCE | | | PCE | 246 | +-----+ | ----------> +-----+ 247 | PCInitiate | | PCReq/PCRpt 248 |{Disjoint-group X} | | {Disjoint-group Y} 249 | | | 250 | .-----. | | .-----. 251 | ( ) | +----+ ( ) 252 | .--( )--. | |PE 1|--.--( )--. 253 V ( ) | +----+ ( ) 254 +---+ ( ) | ( ) 255 |PCC|----( (G)MPLS network ) +----+ ( (G)MPLS network ) 256 +---+ ( ) |PE 3|-----( ) 257 Disjoint-group X ) +----+ ( ) 258 '--( )--' '--( )--' 259 ( ) ( ) 260 '-----' '-----' 262 Case 1: Disjointness initiated by Case 2: Disjointness initiated by 263 PCE and enforced by PCC PCC and enforced by PCE 265 Figure 2 - Sample use-cases for carrying disjoint-group over PCEP 266 session 268 Using the disjoint-group within a PCEP messages may have two purpose: 270 o Configuration: Used to communicate the configured disjoint 271 requirement to a PCEP peer. 273 o Status: Used to communicate the status of the computed 274 disjointness. 276 4. Protocol Extension 278 4.1. Association Group 280 As per [I-D.ietf-pce-association-group], LSPs are associated with 281 other LSPs with which they interact by adding them to a common 282 association group. The Association parameters, as described in 283 [I-D.ietf-pce-association-group] as the combination of the mandatory 284 fields Association type, Association ID and Association Source in the 285 ASSOCIATION object, that uniquely identify the association group 286 belonging to this association. If the optional TLVs - Global 287 Association Source or Extended Association ID - are included, then 288 they are included in combination with mandatory fields to uniquely 289 identify the association group. This document defines a new 290 Association type, based on the generic Association object: 292 o Association type = TBD1 ("Disjointness Association Type") for 293 Disjoint Association Group (DAG). 295 [I-D.ietf-pce-association-group] specifies the mechanism for the 296 capability advertisement of the association types supported by a PCEP 297 speaker by defining a ASSOC-Type-List TLV to be carried within an 298 OPEN object. This capability exchange for the association type 299 described in this document (i.e. Disjointness Association Type) MUST 300 be done before using the disjointness association. Thus the PCEP 301 speaker MUST include the Disjointness Association Type (TBD1) in the 302 ASSOC-Type-List TLV before using the disjoint association group (DAG) 303 in PCEP messages. 305 This association type is considered to be both dynamic and operator- 306 configured in nature. The association group could be created by the 307 operator manually on the PCEP peers and the LSPs belonging to this 308 associations is conveyed via PCEP messages to the PCEP peer; or the 309 association group could be created dynamically by the PCEP speaker 310 and both the association group information and the LSPs belonging to 311 the association group is conveyed to the PCEP peer. The Operator- 312 configured Association Range MUST be set for this association-type to 313 mark a range of association identifiers that are used for operator- 314 configured associations to avoid any association identifier clash 315 within the scope of the association source. (Refer to 316 [I-D.ietf-pce-association-group].) 317 A disjoint group can have two or more LSPs, but a PCE may be limited 318 in the number of LSPs it can take into account when computing 319 disjointness. If a PCE receives more LSPs in the group than it can 320 handle in its computation algorithm, it SHOULD apply disjointness 321 computation to only a subset of LSPs in the group. The subset of 322 disjoint LSPs will be decided by PCE as a local policy. Local 323 polices MAY define the computational behavior for the other LSPs in 324 the group. For example, the PCE may provide no path, a shortest 325 path, or a constrained path based on relaxing disjointness, etc. The 326 disjoint status is informed to the PCC. 328 Associating a particular LSP to multiple disjoint groups is 329 authorized from a protocol perspective, however there is no assurance 330 that the PCE will be able to compute properly the multi-disjointness 331 constraint. 333 4.2. Disjoint TLVs 335 The disjoint group MUST carry the following TLV: 337 o DISJOINTNESS-CONFIGURATION-TLV: Used to communicate some 338 disjointness configuration parameters. 340 In addition, the disjoint group MAY carry the following TLV: 342 o DISJOINTNESS-STATUS-TLV: Used to communicate the status of the 343 computed disjointness. This is applicable for messages from PCE 344 to PCC (PCUpd, PCInitiate or PCRep message). 346 o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor- 347 specific behavioral information, described in [RFC7470]. 349 o OF-List TLV: Used to communicate the disjointness objective 350 function. See Section 4.4. 352 The DISJOINTNESS-CONFIGURATION-TLV is shown in the following figure: 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Type = TBD2 | Length | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Flags |T|P|S|N|L| 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 Type: TBD2. 364 Length: Fixed value of 4 bytes. 366 Flags: 368 * L (Link diverse) bit: when set, this indicates that the 369 computed paths within the disjoint group MUST NOT have any link 370 in common. 372 * N (Node diverse) bit: when set, this indicates that the 373 computed paths within the disjoint group MUST NOT have any node 374 in common. 376 * S (SRLG diverse) bit: when set, this indicates that the 377 computed paths within the disjoint group MUST NOT share any 378 SRLG (Shared Risk Link Group). 380 * P (Shortest path) bit: when set, this indicates that the 381 computed path of the LSP SHOULD satisfy all the constraints and 382 objective functions first without considering the diversity 383 constraint. This means that an LSP with P flag set should be 384 placed as if the disjointness constraint has not been 385 configured, while the other LSP in the association with P flag 386 unset should be placed by taking into account the disjointness 387 constraint. Setting P flag changes the relationship between 388 LSPs to a one-sided relationship (LSP 1 with P=0 depends of LSP 389 2 with P=1, but LSP 2 with P=1 does not depend of LSP 1 with 390 P=0). Multiple LSPs in the same disjoint group may have the P 391 flag set. In such a case, those LSPs may not be disjoint from 392 each other but will be disjoint from others LSPs in the group 393 that have the P flag unset. 395 * T (Strict disjointness) bit: when set, if disjoint paths cannot 396 be found, PCE SHOULD return no path for LSPs that could not be 397 be disjoint. When unset, the PCE is allowed to relax 398 disjointness by either applying a requested objective function 399 (cf. Section 4.4 below) or using any other behavior if no 400 objective function is requested (e.g. using a lower disjoint 401 type (link instead of node) or fully relaxing disjointness 402 constraint). 404 * Unassigned bits are considered reserved. They MUST be set to 0 405 on transmission and MUST be ignored on receipt. 407 If a PCEP speaker receives a disjoint-group without DISJOINTNESS- 408 CONFIGURATION-TLV, it SHOULD reply with a PCErr Error-type=6 409 (Mandatory Object missing) and Error-value=TBD8 (DISJOINTNESS- 410 CONFIGURATION-TLV missing). 412 The DISJOINTNESS-STATUS-TLV uses the same format as the DISJOINTNESS- 413 CONFIGURATION-TLV with a different type TBD3 (in the TLV). The L, N, 414 and S flags are set based if the computed path meet the disjointness 415 criteria. The P flag is set to indicate that the computed path is 416 the shortest and the T flag has no meaning in the DISJOINTNESS- 417 STATUS-TLV and MUST NOT be set while sending and ignored on receipt. 419 Any new flag defined for the DISJOINTNESS-CONFIGURATION-TLV is be 420 automatically applicable to the DISJOINTNESS-STATUS-TLV. 422 4.3. Relationship to SVEC 424 [RFC5440] defines a mechanism for the synchronization of a set of 425 path computation requests by using the SVEC object, that specifies 426 the list of synchronized requests that can either be dependent or 427 independent. The SVEC object identify the relationship between the 428 set of path computation requests, identified by 'Request-ID-number' 429 in RP (Request Parameters) object. [RFC6007] further clarified the 430 use of the SVEC list for synchronized path computations when 431 computing dependent requests as well as described a number of usage 432 scenarios for SVEC lists within single-domain and multi-domain 433 environments. 435 The SVEC object includes a Flags field that indicates the potential 436 dependency between the set of path computation request in a similar 437 way as the Flags field in the TLVs defined in this document. The 438 path computation request in the PCReq message MAY use both the SVEC 439 and ASSOCIATION objects to identify the related path computation 440 request as well as the diversity association group. The PCE MUST try 441 to find a path that meets both the constraints. It is possible that 442 the diversity requirement in the association group is different from 443 the one in the SVEC object. The PCE would consider both the objects 444 as per the processing rules and aim to find a path that meets both of 445 these constraints. In case no such path is possible (or the 446 constraints are incompatible), the PCE MUST send a path computation 447 reply (PCRep) with a NO-PATH object indicating path computation 448 failure as per [RFC5440]. 450 4.4. Disjointness Objective functions 452 An objective function (OF) MAY be applied to the disjointness 453 computation to drive the PCE computation behavior. In this case, the 454 OF-List TLV (defined in ([RFC5541]) is used as an optional TLV in the 455 Association Group Object. Whereas the PCEP OF-List TLV allows 456 multiple OF-codes inside the TLV, a sender SHOULD include a single 457 OF-code in the OF-List TLV when included in the Association Group, 458 and the receiver MUST consider the first OF-code only and ignore 459 others if included. 461 To minimize the common shared resources (Node, Link or SRLG) between 462 a set of paths during path computation three new OF-codes are 463 proposed: 465 MSL 467 * Name: Minimize the number of shared (common) Links. 469 * Objective Function Code: TBD4 471 * Description: Find a set of paths such that it passes through the 472 least number of shared (common) links. 474 MSS 476 * Name: Minimize the number of shared (common) SRLGs. 478 * Objective Function Code: TBD5 480 * Description: Find a set of paths such that it passes through the 481 least number of shared (common) SRLGs. 483 MSN 485 * Name: Minimize the number of shared (common) Nodes. 487 * Objective Function Code: TBD6 489 * Description: Find a set of paths such that it passes through the 490 least number of shared (common) nodes. 492 If the OF-list TLV is included in the Association Object, the OF-code 493 inside the OF Object MUST include one of the disjoint OFs defined in 494 this document. If this condition is not met, the PCEP speaker MUST 495 respond with a PCErr message with Error-Type=10 (Reception of an 496 invalid object) and Error-Value=TBD9 (Incompatible OF code). 498 [RFC5440] uses SVEC diversity flag for node, link or SRLG to describe 499 the potential disjointness between the set of path computation 500 requests used in PCEP protocol. 502 This document defines three new OF-codes to maximize diversity as 503 much as possible, in other words, minimize the common shared 504 resources (Node, Link or SRLG) between a set of paths. 506 It may be interesting to note that the diversity flags in the SVEC 507 object and OF for diversity can be used together. Some examples of 508 usage are listed below: 510 o SVEC object with node-diverse bit=1 - ensure full node-diversity. 512 o SVEC object with node-diverse bit=1 and OF=MSS - full node diverse 513 with as much as SRLG-diversity as possible. 515 o SVEC object with domain-diverse bit=1;link diverse bit=1 and 516 OF=MSS - full domain and node diverse path with as much as SRLG- 517 diversity as possible. 519 o SVEC object with node-diverse bit=1 and OF=MSN - ensure full node- 520 diversity. 522 In the last example above, it is interesting to note that "OF" 523 becomes redundant as "SVEC object" ensures full node-diversity, 524 however this specification does not prohibit redundant constraints 525 while using "SVEC object" and "OF" together for diversity. 527 4.5. P Flag Considerations 529 As mentioned in Section 4.2, the P flag (when set) indicates that the 530 computed path of the LSP SHOULD satisfies all constraints and 531 objective functions first without considering the diversity 532 constraint. This could be required in some primary/backup scenarios 533 where the primary path should use the more optimal path available 534 (taking into account the other constraints). When disjointness is 535 computed, it is important for the algorithm to know that it should 536 try to optimize the path of one or more LSPs in the disjoint group 537 (for instance the primary path) while other paths are allowed to be 538 costlier (compared to a similar path without the disjointness 539 constraint). Without such a hint, the disjointness algorithm may set 540 a path for all LSPs that may not completely fulfill the customer's 541 requirement. 543 _________________________________________ 544 / \ 545 / +------+ \ 546 | | PCE | | 547 | +------+ | 548 | | 549 | | 550 | +------+ 10 +------+ | 551 CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2 552 | +------+ | | +------+ | 553 | | | | 554 | | | | 555 | +------+ | | +------+ | 556 CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4 557 | +------+ \ | / +------+ | 558 | \ | 10 / | 559 \ +-- R5 --------- R6 / 560 \_________________________________________/ 562 Cost of all the links is 1, unless explicitly marked otherwise. 564 Figure 3 566 In the figure above, a customer has two dual homed sites (CE1/CE3 and 567 CE2/CE4). Let us consider that this customer wants two disjoint 568 paths between the two sites. Due to physical meshing, the customer 569 wants to use CE1 and CE2 as primary (and CE3 and CE4 are hosted in a 570 remote site for redundancy purpose). 572 Without any hint (constraint) provided, the PCE may compute the two 573 disjoint LSPs together, leading to PE1->PE2 using a path 574 PE1->R1->R2->PE2 and PE3->PE4 using PE3->R3->R4->PE4. In this case, 575 even if the disjointness constraint is fulfilled, the path from PE1 576 to PE2 does not use the best optimal path available in the network 577 (path delay may be higher): the customer requirement is thus not 578 completely fulfilled. 580 The usage of the P flag allows the PCE to know that a particular LSP 581 should be tied to the best path as if the disjointness constraint was 582 not requested. 584 In our example, if the P flag is set to the LSP PE1->PE2, the PCE 585 should use the path PE1->R1->R3->R4->R2->PE2 for this LSP, while the 586 other LSP should be disjoint from this path. The second LSP will be 587 placed on PE3->R5->R6->PE4 as it is allowed to be costlier. 589 Driving the PCE disjointness computation may be done in other ways, 590 for instance setting a metric boundary reflecting an path delay 591 boundary. Other constraints may also be used. 593 The P flag allows to simply express that the disjointness constraint 594 should not make the LSP worst. 596 Any constraint added to a path disjointness computation may reduce 597 the chance to find suitable paths. The usage of the P flag, as any 598 other constraint, may prevent to find a disjoint path. In the 599 example above, if we consider that the router R5 is down, if PE1->PE2 600 has the P flag set, there is no room available to place PE3->PE4 (the 601 disjointness constraint cannot be fulfilled). If PE1->PE2 has the P 602 flag unset, the algorithm may be able to place PE1->PE2 on R1->R2 603 link leaving a room for PE3->PE4 using the R3->R4 link. When using P 604 flag or any additional constraint on top of the disjointness 605 constraint, the user should be aware that there is less chance to 606 fulfill the disjointness constraint. 608 _________________________________________ 609 / \ 610 / +------+ \ 611 | | PCE | | 612 | +------+ | 613 | | 614 | | 615 | +------+ 10 +------+ | 616 CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2 617 | +------+ | \ | +------+ | 618 | | \2 | | 619 | | \ | | 620 | +------+ | \ | +------+ | 621 CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4 622 | +------+ +------+ | 623 | | 624 \ / 625 \_________________________________________/ 627 Cost of all the links is 1, unless explicitly marked otherwise. 629 Figure 4 631 In the figure above, we still consider the same previous 632 requirements, so PE1->PE2 LSP should be optimized (P flag set) while 633 PE3->PE4 should be disjoint and may use a costlier path. 635 Regarding PE1->PE2, there are two paths that are satisfying the 636 constraints (ECMP): PE1->R1->R4->R2->PE2 (path 1) and 637 PE1->R1->R3->R4->R2->PE2 (path 2). An implementation may choose one 638 of the paths. 640 If the implementation elects only one path, there is a chance that 641 picking up one path may prevent disjointness. In our example, if 642 path 2 is used for PE1->PE2, there is no room left for PE3->PE4 while 643 if path 1 is used, PE3->PE4 can be placed on R3->R4 link. 645 When P flag is set for an LSP and when ECMPs are available, an 646 implementation should aim to select a path that allows disjointness. 648 4.6. Disjointness Computation Issues 650 There may be some cases where the PCE is not able to provide a set of 651 disjoint paths for one or more LSPs in the association. 653 When the T flag is set (Strict disjointness requested), if 654 disjointness cannot be ensured for one or more LSPs, the PCE MUST 655 reply to a Path Computation Request (PCReq) with a Path Computation 656 Reply (PCRep) message containing a NO-PATH object. In case of 657 network event leading to an impossible strict disjointness, the PCE 658 MUST send a PCUpd message containing an empty ERO to the 659 corresponding PCCs. In addition to the empty ERO Object, the PCE MAY 660 add the NO-PATH-VECTOR TLV ([RFC5440]) in the LSP Object. 662 This document adds new bits in the NO-PATH-VECTOR TLV: 664 bit "TBD7": when set, the PCE indicates that it could not find a 665 disjoint path for this LSP. 667 bit "TBD8": when set, the PCE indicates that it does not support 668 the requested disjointness computation. 670 When the T flag is unset, the PCE is allowed to reduce the required 671 level of disjointness. The actual level of disjointness computed by 672 the PCE can be reported through the DISJOINTNESS-STATUS-TLV by 673 setting the appropriate flags in the TLV. While the DISJOINTNESS- 674 CONFIGURATION-TLV defines the expected level of disjointness required 675 by configuration, the DISJOINTNESS-STATUS-TLV defines the actual 676 level of disjointness computed. 678 There are some cases where the PCE may need to completely relax the 679 disjointness constraint in order to provide a path to all the LSPs 680 that are part of the association. A mechanism that allows the PCE to 681 fully relax a constraint is considered by the authors as more global 682 to PCEP rather than linked to the disjointness use case. As a 683 consequence, it is considered as out of scope of the document. 685 All LSPs in a particular disjoint group MUST use the same combination 686 of T, S, N, L flags in the DISJOINTNESS-CONFIGURATION-TLV. If a PCEP 687 peer receives a PCEP messages for LSPs belonging to the same disjoint 688 group but having an inconsistent combination of T, S, N, L flags, the 689 PCEP peer SHOULD NOT try to add the LSPs in disjoint group and SHOULD 690 reply with a PCErr with Error-type 26 (Association Error) and Error- 691 Value 6 (Association information mismatch). 693 5. Security Considerations 695 This document defines one new type for association, which does not 696 add any new security concerns beyond those discussed in [RFC5440], 697 [RFC8231] and [I-D.ietf-pce-association-group] in itself. 699 As stated in [I-D.ietf-pce-association-group], much of the 700 information carried in the Disjointness Association object, as per 701 this document is not extra sensitive. It often reflects information 702 that can also be derived from the LSP Database, but association 703 provides a much easier grouping of related LSPs and messages. The 704 disjointness association could provide an adversary with the 705 opportunity to eavesdrop on the relationship between the LSPs. Thus 706 securing the PCEP session using Transport Layer Security (TLS) 707 [RFC8253], as per the recommendations and best current practices in 708 [RFC7525], is RECOMMENDED. 710 6. IANA Considerations 712 6.1. Association Type 714 This document defines a new Association type, originally described in 715 [I-D.ietf-pce-association-group]. IANA is requested to make the 716 assignment of a new value for the sub-registry "ASSOCIATION Type 717 Field" (request to be created in [I-D.ietf-pce-association-group]), 718 as follows: 720 +------------------+-----------------------------+-------------+ 721 | Association type | Association Name | Reference | 722 +------------------+-----------------------------+-------------+ 723 | TBD1 | Disjoint-group Association | [This.I-D] | 724 +------------------+-----------------------------+-------------+ 726 6.2. PCEP TLVs 728 This document defines the following new PCEP TLVs and the IANA is 729 requested to make the assignment of new values for the existing "PCEP 730 TLV Type Indicators" registry as follows: 732 +----------+---------------------------------+-------------+ 733 | TLV Type | TLV Name | Reference | 734 +----------+---------------------------------+-------------+ 735 | TBD2 | Disjointness Configuration TLV | [This.I-D] | 736 | TBD3 | Disjointness Status TLV | [This.I-D] | 737 +----------+---------------------------------+-------------+ 739 This document requests that a new sub-registry, named "Disjointness 740 Configuration TLV Flag Field", is created within the "Path 741 Computation Element Protocol (PCEP) Numbers" registry to manage the 742 Flag field in the Disjointness Configuration TLV. New values are to 743 be assigned by Standards Action [RFC8126]. Each bit should be 744 tracked with the following qualities: 746 o Bit number (count from 0 as the most significant bit) 748 o Flag Name 750 o Reference 752 +------------+-------------------------+-------------+ 753 | Bit Number | Name | Reference | 754 +------------+-------------------------+-------------+ 755 | 31 | L - Link Diverse | [This.I-D] | 756 | 30 | N - Node Diverse | [This.I-D] | 757 | 29 | S - SRLG Diverse | [This.I-D] | 758 | 28 | P - Shortest Path | [This.I-D] | 759 | 27 | T - Strict Disjointness | [This.I-D] | 760 +------------+-------------------------+-------------+ 762 Table 1: Disjointness Configuration TLV 764 6.3. Objective Functions 766 Three new Objective Functions have been defined in this document. 767 IANA is requested to make the following allocations from the PCEP 768 "Objective Function" sub-registry: 770 +------------+----------------------------------------+-------------+ 771 | Code Point | Name | Reference | 772 +------------+----------------------------------------+-------------+ 773 | TBD4 | Minimize the number of shared Links | [This.I-D] | 774 | | (MSL) | | 775 | TBD5 | Minimize the number of shared SRLGs | [This.I-D] | 776 | | (MSS) | | 777 | TBD6 | Minimize the number of shared Nodes | [This.I-D] | 778 | | (MSN) | | 779 +------------+----------------------------------------+-------------+ 781 6.4. NO-PATH-VECTOR Bit Flags 783 This documents defines new bits for the NO-PATH-VECTOR TLV in the 784 "NO-PATH-VECTOR TLV Flag Field" sub-registry of the "Path Computation 785 Element Protocol (PCEP) Numbers" registry. IANA is requested to make 786 the following allocation: 788 +------------+-----------------------------------------+------------+ 789 | Bit Number | Name | Reference | 790 +------------+-----------------------------------------+------------+ 791 | TBD7 | Disjoint path not found | [This.I-D] | 792 | TBD8 | Requested disjoint computation not | [This.I-D] | 793 | | supported | | 794 +------------+-----------------------------------------+------------+ 796 Table 2: NO-PATH-VECTOR TLV 798 6.5. PCEP-ERROR Codes 800 This document defines new Error-Value within existing Error-Type 801 related to path protection association. IANA is requested to 802 allocate new error values within the "PCEP-ERROR Object Error Types 803 and Values" sub-registry of the PCEP Numbers registry, as follows: 805 +----------+-------------------------+------------------------------+ 806 | Error- | Meaning | Reference | 807 | Type | | | 808 +----------+-------------------------+------------------------------+ 809 | 6 | Mandatory Object | [I-D.ietf-pce-association-gr | 810 | | missing | oup] | 811 | | Error-value=TBD8: | [This.I-D] | 812 | | DISJOINTNESS- | | 813 | | CONFIGURATION TLV | | 814 | | missing | | 815 | 10 | Reception of an invalid | [RFC5440] | 816 | | object | | 817 | | Error-value=TBD9: | [This.I-D] | 818 | | Incompatible OF code | | 819 +----------+-------------------------+------------------------------+ 821 7. Manageability Considerations 823 7.1. Control of Function and Policy 825 An operator SHOULD be allowed to configure the disjointness 826 association groups and disjoint parameters at the PCEP peers and 827 associate it with the LSPs. The Operator-configured Association 828 Range MUST be allowed to be set by the operator. Operator SHOULD be 829 allowed to set the local policies to define various disjoint 830 computational behavior at the PCE. 832 7.2. Information and Data Models 834 An implementation SHOULD allow the operator to view the disjoint 835 associations configured or created dynamically. Further 836 implementation SHOULD allow to view disjoint associations reported by 837 each peer, and the current set of LSPs in this association. The PCEP 838 YANG module [I-D.ietf-pce-pcep-yang] includes association groups 839 information. 841 7.3. Liveness Detection and Monitoring 843 Mechanisms defined in this document do not imply any new liveness 844 detection and monitoring requirements in addition to those already 845 listed in [RFC5440]. 847 7.4. Verify Correct Operations 849 Mechanisms defined in this document do not imply any new operation 850 verification requirements in addition to those already listed in 851 [RFC5440]. 853 7.5. Requirements On Other Protocols 855 Mechanisms defined in this document do not imply any new requirements 856 on other protocols. 858 7.6. Impact On Network Operations 860 Mechanisms defined in [RFC5440], Section 8.6 also apply to PCEP 861 extensions defined in this document. Additionally, a PCEP 862 implementation SHOULD allow a limit to be placed on the number of 863 LSPs that can belong to a disjoint association group. 865 8. Acknowledgments 867 A special thanks to authors of [I-D.ietf-pce-association-group], this 868 document borrow some of the text from it. Authors would also like to 869 thank Adrian Farrel and Julien Meuric for the valuable comments. 871 9. References 872 9.1. Normative References 874 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 875 Requirement Levels", BCP 14, RFC 2119, 876 DOI 10.17487/RFC2119, March 1997, 877 . 879 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 880 Writing an IANA Considerations Section in RFCs", BCP 26, 881 RFC 8126, DOI 10.17487/RFC8126, June 2017, 882 . 884 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 885 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 886 DOI 10.17487/RFC5440, March 2009, 887 . 889 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 890 Objective Functions in the Path Computation Element 891 Communication Protocol (PCEP)", RFC 5541, 892 DOI 10.17487/RFC5541, June 2009, 893 . 895 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 896 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 897 May 2017, . 899 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 900 Computation Element Communication Protocol (PCEP) 901 Extensions for Stateful PCE", RFC 8231, 902 DOI 10.17487/RFC8231, September 2017, 903 . 905 [I-D.ietf-pce-association-group] 906 Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 907 Dhody, D., and Y. Tanaka, "PCEP Extensions for 908 Establishing Relationships Between Sets of LSPs", draft- 909 ietf-pce-association-group-09 (work in progress), April 910 2019. 912 9.2. Informative References 914 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 915 Element (PCE)-Based Architecture", RFC 4655, 916 DOI 10.17487/RFC4655, August 2006, 917 . 919 [RFC6007] Nishioka, I. and D. King, "Use of the Synchronization 920 VECtor (SVEC) List for Synchronized Dependent Path 921 Computations", RFC 6007, DOI 10.17487/RFC6007, September 922 2010, . 924 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 925 Constraints in the Path Computation Element Communication 926 Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, 927 . 929 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 930 "Recommendations for Secure Use of Transport Layer 931 Security (TLS) and Datagram Transport Layer Security 932 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 933 2015, . 935 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 936 "PCEPS: Usage of TLS to Provide a Secure Transport for the 937 Path Computation Element Communication Protocol (PCEP)", 938 RFC 8253, DOI 10.17487/RFC8253, October 2017, 939 . 941 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 942 Computation Element Communication Protocol (PCEP) 943 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 944 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 945 . 947 [I-D.ietf-pce-pcep-yang] 948 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 949 YANG Data Model for Path Computation Element 950 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 951 yang-11 (work in progress), March 2019. 953 Appendix A. Contributor Addresses 955 Dhruv Dhody 956 Huawei Technologies 957 Divyashree Techno Park, Whitefield 958 Bangalore, Karnataka 560066 959 India 961 EMail: dhruv.ietf@gmail.com 963 Authors' Addresses 965 Stephane Litkowski 966 Orange 968 EMail: stephane.litkowski@orange.com 970 Siva Sivabalan 971 Cisco Systems, Inc. 972 2000 Innovation Drive 973 Kanata, Ontario K2K 3E8 974 Canada 976 EMail: msiva@cisco.com 978 Colby Barth 979 Juniper Networks 981 EMail: cbarth@juniper.net 983 Mahendra Singh Negi 984 Huawei Technologies 985 Divyashree Techno Park, Whitefield 986 Bangalore, Karnataka 560066 987 India 989 EMail: mahendrasingh@huawei.com