idnits 2.17.1 draft-ietf-pce-association-diversity-07.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 (June 4, 2019) is 1781 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: December 6, 2019 Cisco Systems, Inc. 6 C. Barth 7 Juniper Networks 8 M. Negi 9 Huawei Technologies 10 June 4, 2019 12 Path Computation Element communication Protocol (PCEP) extension for 13 signaling LSP diversity constraint 14 draft-ietf-pce-association-diversity-07 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 LSPs in the same group needs 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 December 6, 2019. 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 . . . . . . . . . . . . . 14 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . 18 81 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . 19 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, consider that the customer wants to have two 201 disjoint paths between CE1/CE2 and CE3/CE4. From an IP/MPLS network 202 point view, in this example, the CEs are connected to different PEs 203 to maximize their disjointness. When LSPs originate from different 204 head-ends, distributed computation of diverse paths can be difficult. 205 Whereas, computation via a centralized PCE ensures path disjointness 206 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 uses 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 the 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 should allow to overcome this 233 limitation as described in [I-D.ietf-pce-association-group]. When a 234 PCC or PCE initiates all the LSPs in a particular disjoint-group, it 235 can set the IPv4/IPv6 association source as one of its own IP 236 address. When disjoint LSPs are initiated from different head-ends, 237 association source could be the PCE address or any other unique value 238 to identify 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 they 288 are included in combination with mandatory fields to uniquely 289 identifying 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] specify 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 the 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 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 how many 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 391 P-flag set. In such a case, those LSPs may not be disjoint 392 from each other but will be disjoint from others LSPs in the 393 group 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, PCE is allowed to relax disjointness 398 by using either applying a requested objective function or any 399 other behavior if no objective function is requested (e.g.: 400 using a lower disjoint type (link instead of node) or relaxing 401 disjointness constraint fully). 403 * Unassigned bits are considered reserved. They MUST be set to 0 404 on transmission and MUST be ignored on receipt. 406 If a PCEP speaker receives a disjoint-group without DISJOINTNESS- 407 CONFIGURATION-TLV, it SHOULD reply with a PCErr Error-type=6 408 (Mandatory Object missing) and Error-value=TBD8 (DISJOINTNESS- 409 CONFIGURATION-TLV missing). 411 The DISJOINTNESS-STATUS-TLV uses the same format as the DISJOINTNESS- 412 CONFIGURATION-TLV with a different type TBD3 (in the TLV). The flags 413 L, N, and S are set based if the computed path meet the disjointness 414 criteria. The flag P is set to indicate that the computed path is 415 the shortest and the flag T has no meaning in the DISJOINTNESS- 416 STATUS-TLV and MUST NOT be set while sending and ignored on receipt. 418 Any new flag defined for the DISJOINTNESS-CONFIGURATION-TLV is be 419 automatically applicable to the DISJOINTNESS-STATUS-TLV. 421 4.3. Relationship to SVEC 423 [RFC5440] defines a mechanism for the synchronization of a set of 424 path computation requests by using the SVEC object, that specifies 425 the list of synchronized requests that can either be dependent or 426 independent. The SVEC object identify the relationship between the 427 set of path computation requests, identified by 'Request-ID-number' 428 in RP (Request Parameters) object. [RFC6007] further clarified the 429 use of the SVEC list for synchronized path computations when 430 computing dependent requests as well as described a number of usage 431 scenarios for SVEC lists within single-domain and multi-domain 432 environments. 434 The SVEC object includes a Flags field that indicates the potential 435 dependency between the set of path computation request in a similar 436 way as the Flags field in the TLVs defined in this document. The 437 path computation request in the PCReq message MAY use both SVEC and 438 ASSOCIATION object to identify the related path computation request 439 as well as the diversity association group. The PCE MUST try to find 440 a path that meets both the constraints. It is possible that the 441 diversity requirement in the association group is different from the 442 one in SVEC object. The PCE would consider both the objects as per 443 the processing rules and aim to find a path that meets both these 444 constraints. In case no such path is possible (or the constraints 445 are incompatible), the PCE MUST send a path computation reply (PCRep) 446 with NO-PATH object indcating path computation failure as per 447 [RFC5440]. 449 4.4. Disjointness objective functions 451 An objective function (OF) MAY be applied to the disjointness 452 computation to drive the PCE computation behavior. In this case, the 453 OF-List TLV (defined in ([RFC5541]) is used as an optional TLV in the 454 Association Group Object. The PCEP OF-List TLV allow multiple OF- 455 Codes inside the TLV, a sender SHOULD include a single OF-Code in the 456 OF-List TLV when included in the Association Group, and the receiver 457 MUST consider the first OF-code only and ignore others if included. 459 To minimize the common shared resources (Node, Link or SRLG) between 460 a set of paths during path computation three new OF codes are 461 proposed: 463 MSL 465 * Name: Minimize the number of shared (common) Links. 467 * Objective Function Code: TBD4 469 * Description: Find a set of paths such that it passes through the 470 least number of shared (common) links. 472 MSS 474 * Name: Minimize the number of shared (common) SRLGs. 476 * Objective Function Code: TBD5 478 * Description: Find a set of paths such that it passes through the 479 least number of shared (common) SRLGs. 481 MSN 483 * Name: Minimize the number of shared (common) Nodes. 485 * Objective Function Code: TBD6 487 * Description: Find a set of paths such that it passes through the 488 least number of shared (common) nodes. 490 If the OF-list TLV is included in the Association Object, the OF Code 491 inside the OF Object MUST include one of the disjoint OFs defined in 492 this document. If this condition is not met, the PCEP speaker MUST 493 respond with a PCErr message with Error-Type=10 (Reception of an 494 invalid object) and Error-Value=TBD9 (Incompatible OF codes). 496 [RFC5440] uses SVEC diversity flag for node, link or SRLG to describe 497 the potential disjointness between the set of path computation 498 requests used in PCEP protocol. 500 This document defines three new OF codes to maximize diversity as 501 much as possible, in other words, minimize the common shared 502 resources (Node,Link or SRLG) between a set of paths. 504 It may be interesting to note that the diversity flags in the SVEC 505 object and OF for diversity can be used together. Some example of 506 usage are listed below - 508 o SVEC object with node-diverse bit=1 - ensure full node-diversity. 510 o SVEC object with node-diverse bit=1 and OF=MSS - full node diverse 511 with as much as SRLG-diversity as possible. 513 o SVEC object with domain-diverse bit=1;link diverse bit=1 and 514 OF=MSS - full domain and node diverse path with as much as SRLG- 515 diversity as possible. 517 o SVEC object with node-diverse bit=1 and OF=MSN - ensure full node- 518 diversity. 520 4.5. P-flag considerations 522 As mentioned in Section 4.2, the P-flag (when set) indicates that the 523 computed path of the LSP SHOULD satisfies all constraints and 524 objective functions first without considering the diversity 525 constraint. This could be required in some primary/backup scenarios 526 where the primary path should use the more optimal path available 527 (taking into account the other constraints). When disjointness is 528 computed, it is important for the algorithm to know that it should 529 try to optimize the path of one or more LSPs in the disjoint group 530 (for instance the primary path) while other paths are allowed to be 531 costlier (compared to a similar path without the disjointness 532 constraint). Without such a hint, the disjointness algorithm may set 533 a path for all LSPs that may not completely fulfill the customer 534 requirement. 536 _________________________________________ 537 / \ 538 / +------+ \ 539 | | PCE | | 540 | +------+ | 541 | | 542 | | 543 | +------+ 10 +------+ | 544 CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2 545 | +------+ | | +------+ | 546 | | | | 547 | | | | 548 | +------+ | | +------+ | 549 CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4 550 | +------+ \ | / +------+ | 551 | \ | 10 / | 552 \ +-- R5 --------- R6 / 553 \_________________________________________/ 555 Cost of all the links is 1, unless explicitly marked otherwise. 557 Figure 3 559 In the figure above, a customer has two dual homed sites (CE1/CE3 and 560 CE2/CE4). Consider, this customer wants two disjoint paths between 561 the two sites. Due to physical meshing, the customer wants to use 562 CE1 and CE2 as primary ( and CE3 and CE4 are hosted in a remote site 563 for redundancy purpose). 565 Without any hint (constraint) provided, the PCE may compute the two 566 disjoint LSPs together, leading to PE1->PE2 using a path 567 PE1->R1->R2->PE2 and PE3->PE4 using PE3->R3->R4->PE4. In this case, 568 even if the disjointness constraint is fulfilled, the path from PE1 569 to PE2 does not use the best optimal path available in the network 570 (path delay may be higher): the customer requirement is thus not 571 completely fulfilled. 573 The usage of the P-Flag allows the PCE to know that a particular LSP 574 should be tied to the best path as if the disjointness constraint was 575 not requested. 577 In our example, if the P-Flag is set to the LSP PE1->PE2, the PCE 578 should use the path PE1->R1->R3->R4->R2->PE2 for this LSP, while the 579 other LSP should be disjoint from this path. The second LSP will be 580 placed on PE3->R5->R6->PE4 as it is allowed to be costlier. 582 Driving the PCE disjointness computation may be done in other ways, 583 for instance setting a metric boundary reflecting an path delay 584 boundary. Other constraints may also be used. 586 The P-Flag allows a simple expression that the disjointness 587 constraint should not make the LSP worst. 589 Any constraint added to a path disjointness computation may reduce 590 the chance to find suitable paths. The usage of the P-flag, as any 591 other constraint, may prevent to find a disjoint path. In the 592 example above, if we consider that the router R5 is down, if PE1->PE2 593 has the P-flag set, there is no room available to place PE3->PE4 (the 594 disjointness constraint cannot be fulfilled). If PE->PE2 has the 595 P-flag unset, the algorithm may be able to place PE1->PE2 on R1->R2 596 link leaving a room for PE3->PE4 using the R3->R4 link. When using 597 P-flag or any additional constraint on top of the disjointness 598 constraint, the user should be aware that there is less chance to 599 fulfill the disjointness constraint. 601 _________________________________________ 602 / \ 603 / +------+ \ 604 | | PCE | | 605 | +------+ | 606 | | 607 | | 608 | +------+ 10 +------+ | 609 CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2 610 | +------+ | \ | +------+ | 611 | | \2 | | 612 | | \ | | 613 | +------+ | \ | +------+ | 614 CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4 615 | +------+ +------+ | 616 | | 617 \ / 618 \_________________________________________/ 620 Cost of all the links is 1, unless explicitly marked otherwise. 622 Figure 4 624 In the figure above, we still consider the same previous 625 requirements, so PE1->PE2 LSP should be optimized (P-flag set) while 626 PE3->PE4 should be disjoint and may use a costlier path. 628 Regarding PE1->PE2, there are two paths that are satisfying the 629 constraints (ECMP): PE1->R1->R4->R2->PE2 (path 1) and 630 PE1->R1->R3->R4->R2->PE2 (path 2). An implementation may choose one 631 of the paths. 633 If the implementation elects only one path, there is a chance that 634 picking up one path may prevent disjointness. In our example, if 635 path 2 is used for PE1->PE2, there is no room left for PE3->PE4 while 636 if path 1 is used, PE3->PE4 can be placed on R3->R4 link. 638 When P-flag is set for an LSP and when ECMPs are available, an 639 implementation should aim to select a path that allows disjointness. 641 4.6. Disjointness computation issues 643 There may be some cases where the PCE is not able to provide a set of 644 disjoint paths for one or more LSPs in the association. 646 When the T-bit is set (Strict disjointness requested), if 647 disjointness cannot be ensured for one or more LSPs, the PCE SHOULD 648 reply with a PCUpd message containing an empty ERO. In addition to 649 the empty ERO Object, the PCE MAY add the NO-PATH-VECTOR TLV 650 ([RFC5440]) in the LSP Object. 652 This document adds new bits in the NO-PATH-VECTOR TLV: 654 bit "TBD7": when set, the PCE indicates that it could not find a 655 disjoint path for this LSP. 657 bit "TBD8": when set, the PCE indicates that it does not support 658 the requested disjointness computation. 660 When the T-bit is unset, the PCE is allowed to reduce the required 661 level of disjointness. The actual level of disjointness computed by 662 the PCE can be reported through the DISJOINTNESS-STATUS-TLV by 663 setting the appropriate flags in the TLV. While the DISJOINTNESS- 664 CONFIGURATION-TLV defines the expected level of disjointness required 665 by configuration, the DISJOINTNESS-STATUS-TLV defines the actual 666 level of disjointness computed. 668 There are some cases where the PCE may need to completely relax the 669 disjointness constraint in order to provide a path to all the LSPs 670 that are part of the association. A mechanism that allows the PCE to 671 fully relax a constraint is considered by the authors as more global 672 to PCEP rather than linked to the disjointness use case. As a 673 consequence, it is considered as out of scope of the document. 675 All LSPs in a particular disjoint group MUST use the same combination 676 of T,S,N,L flags in the DISJOINTNESS-CONFIGURATION-TLV. If a PCEP 677 peer receives a PCEP messages for LSPs belonging to the same disjoint 678 group but having an inconsistent combination of T,S,N,L flags, the 679 PCEP peer SHOULD NOT try to add the LSPs in disjoint group and SHOULD 680 reply with a PCErr with Error-type 26 (Association Error) and Error- 681 Value 6 (Association information mismatch). 683 5. Security Considerations 685 This document defines one new type for association, which do not add 686 any new security concerns beyond those discussed in [RFC5440], 687 [RFC8231] and [I-D.ietf-pce-association-group] in itself. 689 As stated in [I-D.ietf-pce-association-group], much of the 690 information carried in the Disjointness Association object, as per 691 this document is not extra sensitive. It often reflects information 692 that can also be derived from the LSP Database, but association 693 provides a much easier grouping of related LSPs and messages. The 694 disjointness association could provides an adversary with the 695 opportunity to eavesdrop on the relationship between the LSPs. Thus 696 securing the PCEP session using Transport Layer Security (TLS) 698 [RFC8253], as per the recommendations and best current practices in 699 [RFC7525], is RECOMMENDED. 701 6. IANA Considerations 703 6.1. Association Type 705 This document defines a new Association type, originally described in 706 [I-D.ietf-pce-association-group]. IANA is requested to make the 707 assignment of a new value for the sub-registry "ASSOCIATION Type 708 Field" (request to be created in [I-D.ietf-pce-association-group]), 709 as follows: 711 +------------------+-----------------------------+-------------+ 712 | Association type | Association Name | Reference | 713 +------------------+-----------------------------+-------------+ 714 | TBD1 | Disjoint-group Association | [This.I-D] | 715 +------------------+-----------------------------+-------------+ 717 6.2. PCEP TLVs 719 This document defines following new PCEP TLVs and the IANA is 720 requested to make the assignment of new values for the existing "PCEP 721 TLV Type Indicators" registry as follows: 723 +----------+---------------------------------+-------------+ 724 | TLV Type | TLV Name | Reference | 725 +----------+---------------------------------+-------------+ 726 | TBD2 | Disjointness Configuration TLV | [This.I-D] | 727 | TBD3 | Disjointness Status TLV | [This.I-D] | 728 +----------+---------------------------------+-------------+ 730 This document requests that a new sub-registry, named "Disjointness 731 Configuration TLV Flag Field", is created within the "Path 732 Computation Element Protocol (PCEP) Numbers" registry to manage the 733 Flag field in the Disjointness Configuration TLV. New values are to 734 be assigned by Standards Action [RFC8126]. Each bit should be 735 tracked with the following qualities: 737 o Bit number (count from 0 as the most significant bit) 739 o Flag Name 741 o Reference 742 +------------+-------------------------+-------------+ 743 | Bit Number | Name | Reference | 744 +------------+-------------------------+-------------+ 745 | 31 | L - Link Diverse | [This.I-D] | 746 | 30 | N - Node Diverse | [This.I-D] | 747 | 29 | S - SRLG Diverse | [This.I-D] | 748 | 28 | P - Shortest Path | [This.I-D] | 749 | 27 | T - Strict Disjointness | [This.I-D] | 750 +------------+-------------------------+-------------+ 752 Table 1: Disjointness Configuration TLV 754 6.3. Objective Functions 756 Three new Objective Functions have been defined in this document. 757 IANA is requested to make the following allocations from the PCEP 758 "Objective Function" sub-registry: 760 +------------+----------------------------------------+-------------+ 761 | Code Point | Name | Reference | 762 +------------+----------------------------------------+-------------+ 763 | TBD4 | Minimize the number of shared Links | [This.I-D] | 764 | | (MSL) | | 765 | TBD5 | Minimize the number of shared SRLGs | [This.I-D] | 766 | | (MSS) | | 767 | TBD6 | Minimize the number of shared Nodes | [This.I-D] | 768 | | (MSN) | | 769 +------------+----------------------------------------+-------------+ 771 6.4. NO-PATH-VECTOR Bit Flags 773 This documents defines new bits for the NO-PATH-VECTOR TLV in the 774 "NO-PATH-VECTOR TLV Flag Field" sub-registry of the "Path Computation 775 Element Protocol (PCEP) Numbers" registry. IANA is requested to make 776 the following allocation: 778 +------------+-----------------------------------------+------------+ 779 | Bit Number | Name | Reference | 780 +------------+-----------------------------------------+------------+ 781 | TBD7 | Disjoint path not found | [This.I-D] | 782 | TBD8 | Requested disjoint computation not | [This.I-D] | 783 | | supported | | 784 +------------+-----------------------------------------+------------+ 786 Table 2: NO-PATH-VECTOR TLV 788 6.5. PCEP-ERROR codes 790 This document defines new Error-Type and Error-Value related to path 791 protection association. IANA is requested to allocate new error 792 values within the "PCEP-ERROR Object Error Types and Values" sub- 793 registry of the PCEP Numbers registry, as follows: 795 +----------+-------------------------+------------------------------+ 796 | Error- | Meaning | Reference | 797 | Type | | | 798 +----------+-------------------------+------------------------------+ 799 | 6 | Mandatory Object | [I-D.ietf-pce-association-gr | 800 | | missing | oup] | 801 | | Error-value=TBD8: | [This.I-D] | 802 | | DISJOINTNESS- | | 803 | | CONFIGURATION TLV | | 804 | | missing | | 805 | 10 | Reception of an invalid | [RFC5440] | 806 | | object | | 807 | | Error-value=TBD9: | [This.I-D] | 808 | | Incompatible OF codes | | 809 +----------+-------------------------+------------------------------+ 811 7. Manageability Considerations 813 7.1. Control of Function and Policy 815 An operator SHOULD be allowed to configure the disjointness 816 association groups and disjoint parameters at the PCEP peers and 817 associate it with the LSPs. The Operator-configured Association 818 Range MUST be allowed to be set by the operator. Operator SHOULD be 819 allowed to set the local policies to define various disjoint 820 computational behavior at the PCE. 822 7.2. Information and Data Models 824 An implementation SHOULD allow the operator to view the disjoint 825 associations configured or created dynamically. Further 826 implementation SHOULD allow to view disjoint associations reported by 827 each peer, and the current set of LSPs in this association. The PCEP 828 YANG module [I-D.ietf-pce-pcep-yang] includes association groups 829 information. 831 7.3. Liveness Detection and Monitoring 833 Mechanisms defined in this document do not imply any new liveness 834 detection and monitoring requirements in addition to those already 835 listed in [RFC5440]. 837 7.4. Verify Correct Operations 839 Mechanisms defined in this document do not imply any new operation 840 verification requirements in addition to those already listed in 841 [RFC5440]. 843 7.5. Requirements On Other Protocols 845 Mechanisms defined in this document do not imply any new requirements 846 on other protocols. 848 7.6. Impact On Network Operations 850 Mechanisms defined in [RFC5440], Section 8.6 also apply to PCEP 851 extensions defined in this document. Additionally, a PCEP 852 implementation SHOULD allow a limit to be placed on the number of 853 LSPs that can belong to a disjoint association group. 855 8. Acknowledgments 857 A special thanks to author of [I-D.ietf-pce-association-group], this 858 document borrow some of the text from it. Authors would also like to 859 thank Adrian Farrel for his useful comments. 861 9. References 863 9.1. Normative References 865 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 866 Requirement Levels", BCP 14, RFC 2119, 867 DOI 10.17487/RFC2119, March 1997, 868 . 870 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 871 Writing an IANA Considerations Section in RFCs", BCP 26, 872 RFC 8126, DOI 10.17487/RFC8126, June 2017, 873 . 875 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 876 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 877 DOI 10.17487/RFC5440, March 2009, 878 . 880 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 881 Objective Functions in the Path Computation Element 882 Communication Protocol (PCEP)", RFC 5541, 883 DOI 10.17487/RFC5541, June 2009, 884 . 886 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 887 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 888 May 2017, . 890 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 891 Computation Element Communication Protocol (PCEP) 892 Extensions for Stateful PCE", RFC 8231, 893 DOI 10.17487/RFC8231, September 2017, 894 . 896 [I-D.ietf-pce-association-group] 897 Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 898 Dhody, D., and Y. Tanaka, "PCEP Extensions for 899 Establishing Relationships Between Sets of LSPs", draft- 900 ietf-pce-association-group-09 (work in progress), April 901 2019. 903 9.2. Informative References 905 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 906 Element (PCE)-Based Architecture", RFC 4655, 907 DOI 10.17487/RFC4655, August 2006, 908 . 910 [RFC6007] Nishioka, I. and D. King, "Use of the Synchronization 911 VECtor (SVEC) List for Synchronized Dependent Path 912 Computations", RFC 6007, DOI 10.17487/RFC6007, September 913 2010, . 915 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 916 Constraints in the Path Computation Element Communication 917 Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, 918 . 920 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 921 "Recommendations for Secure Use of Transport Layer 922 Security (TLS) and Datagram Transport Layer Security 923 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 924 2015, . 926 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 927 "PCEPS: Usage of TLS to Provide a Secure Transport for the 928 Path Computation Element Communication Protocol (PCEP)", 929 RFC 8253, DOI 10.17487/RFC8253, October 2017, 930 . 932 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 933 Computation Element Communication Protocol (PCEP) 934 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 935 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 936 . 938 [I-D.ietf-pce-pcep-yang] 939 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 940 YANG Data Model for Path Computation Element 941 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 942 yang-11 (work in progress), March 2019. 944 Appendix A. Contributor Addresses 946 Dhruv Dhody 947 Huawei Technologies 948 Divyashree Techno Park, Whitefield 949 Bangalore, Karnataka 560066 950 India 952 EMail: dhruv.ietf@gmail.com 954 Authors' Addresses 956 Stephane Litkowski 957 Orange 959 EMail: stephane.litkowski@orange.com 961 Siva Sivabalan 962 Cisco Systems, Inc. 963 2000 Innovation Drive 964 Kanata, Ontario K2K 3E8 965 Canada 967 EMail: msiva@cisco.com 969 Colby Barth 970 Juniper Networks 972 EMail: cbarth@juniper.net 974 Mahendra Singh Negi 975 Huawei Technologies 976 Divyashree Techno Park, Whitefield 977 Bangalore, Karnataka 560066 978 India 980 EMail: mahendrasingh@huawei.com