idnits 2.17.1 draft-ietf-pce-association-diversity-01.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 : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 30 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2017) is 2601 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) == Missing Reference: 'TBD2' is mentioned on line 317, but not defined == Missing Reference: 'TBD5' is mentioned on line 536, but not defined ** Downref: Normative reference to an Informational RFC: RFC 4655 == Outdated reference: A later version (-10) exists of draft-ietf-pce-association-group-02 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-18 == Outdated reference: A later version (-07) exists of draft-dhody-pce-of-diverse-06 -- Obsolete informational reference (is this intentional?): RFC 7150 (Obsoleted by RFC 7470) == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-09 Summary: 2 errors (**), 0 flaws (~~), 7 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: September 14, 2017 Cisco Systems, Inc. 6 C. Barth 7 Juniper Networks 8 D. Dhody 9 Huawei 10 March 13, 2017 12 Path Computation Element communication Protocol extension for signaling 13 LSP diversity constraint 14 draft-ietf-pce-association-diversity-01 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 Communication Protocol (PCEP) with the purpose of computing 21 diverse paths for those LSPs. The proposed extension allows a PCC to 22 advertise to a PCE the belonging of a particular LSP to a disjoint- 23 group, thus the PCE knows that LSPs in the same group must 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 http://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 September 14, 2017. 43 Copyright Notice 45 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 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. Mandatory TLV . . . . . . . . . . . . . . . . . . . . . . 7 67 4.3. Optional TLVs . . . . . . . . . . . . . . . . . . . . . . 9 68 4.4. Disjointness objective functions . . . . . . . . . . . . 9 69 4.5. P-flag considerations . . . . . . . . . . . . . . . . . . 9 70 4.6. Disjointness computation issues . . . . . . . . . . . . . 12 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 6.1. Association object Type Indicators . . . . . . . . . . . 13 74 6.2. PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . . . 14 75 6.3. NO-PATH-VECTOR bit Flags . . . . . . . . . . . . . . . . 14 76 6.4. PCEP-ERROR codes . . . . . . . . . . . . . . . . . . . . 14 77 7. Manageability Considerations . . . . . . . . . . . . . . . . 15 78 7.1. Control of Function and Policy . . . . . . . . . . . . . 15 79 7.2. Information and Data Models . . . . . . . . . . . . . . . 15 80 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 15 81 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 15 82 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 15 83 7.6. Impact On Network Operations . . . . . . . . . . . . . . 15 84 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 87 9.2. Informative References . . . . . . . . . . . . . . . . . 16 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 90 1. Introduction 92 [RFC5440] describes the Path Computation Element communication 93 Protocol (PCEP) which enables the communication between a Path 94 Computation Client (PCC) and a Path Control Element (PCE), or between 95 two PCEs based on the PCE architecture [RFC4655]. 97 PCEP Extensions for Stateful PCE Model [I-D.ietf-pce-stateful-pce] 98 describes a set of extensions to PCEP to enable active control of 99 MPLS-TE and GMPLS tunnels. [I-D.ietf-pce-pce-initiated-lsp] 100 describes the setup and teardown of PCE-initiated LSPs under the 101 active stateful PCE model, without the need for local configuration 102 on the PCC, thus allowing for a dynamic network. 104 [I-D.ietf-pce-association-group] introduces a generic mechanism to 105 create a grouping of LSPs which can then be used to define 106 associations between a set of LSPs and a set of attributes (such as 107 configuration parameters or behaviours) and is equally applicable to 108 the active and passive modes of a stateful PCE 109 [I-D.ietf-pce-stateful-pce] or a stateless PCE [RFC5440]. 111 This document specifies a PCEP extension to signal that a particular 112 group of LSPs should use diverse paths including the requested type 113 of diversity. A PCC can use this extension to signal to a PCE the 114 belonging of a particular LSP to a disjoint-group. When a PCE 115 receives LSP states belonging to the same disjoint-group from some 116 PCCs, the PCE should ensure that the LSPs within the group are 117 disjoint from each other. 119 1.1. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 2. Terminology 127 The following terminology is used in this document. 129 LSR: Label Switch Router. 131 MPLS: Multiprotocol Label Switching. 133 PCC: Path Computation Client. Any client application requesting a 134 path computation to be performed by a Path Computation Element. 136 PCE: Path Computation Element. An entity (component, application, 137 or network node) that is capable of computing a network path or 138 route based on a network graph and applying computational 139 constraints. 141 PCEP: Path Computation Element Communication Protocol. 143 SRLG: Shared Risk Link Group. 145 3. Motivation 147 Path diversity is a very common use case today in IP/MPLS networks 148 especially for layer 2 transport over MPLS. A customer may request 149 that the operator provide two end-to-end disjoint paths across the 150 IP/MPLS core. The customer may use those paths as primary/backup or 151 active/active. 153 Different level of disjointness may be offered: 155 o Link disjointness: the paths of the associated LSPs should transit 156 different links (but may use common nodes or different links that 157 may have some shared fate). 159 o Node disjointness: the paths of the associated LSPs should transit 160 different nodes (but may use different links that may have some 161 shared fate). 163 o SRLG disjointness: the paths of the associated LSPs should transit 164 different links that do not share fate (but may use common transit 165 nodes). 167 o Node+SRLG disjointness: the paths of the associated LSPs should 168 transit different links that do not have any common shared fate 169 and should transit different nodes. 171 The associated LSPs may originate from the same or from different 172 head-end(s) and may terminate at the same or different tail-end(s). 174 _________________________________________ 175 / \ 176 / +------+ \ 177 | | PCE | | 178 | +------+ | 179 | | 180 | ***********************> | 181 | +------+ 10 +------+ | 182 CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2 183 | +------+ | | +------+ | 184 | | | | 185 | | | | 186 | +------+ | | +------+ | 187 CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4 188 | +------+ ***********************> +------+ | 189 | | 190 \ / 191 \_________________________________________/ 193 Figure 1 - Disjoint paths with different head-ends and tail-ends 195 In the figure above, the customer wants to have two disjoint paths 196 between CE1/CE2 and CE3/CE4. From an IP/MPLS network point view, in 197 this example, the CEs are connected to different PEs to maximize 198 their disjointness. When LSPs originate from different head-ends, 199 distributed computation of diverse paths can be difficult. Whereas, 200 computation via a centralized PCE ensures path disjointness 201 correctness and simplicity. 203 The SVEC (Synchronization VECtor) object [RFC5440] allows a PCC to 204 request the synchronization of a set of dependent or independent path 205 computation requests. As per [RFC5440], the SVEC object is optional 206 and may be carried within a PCReq message. It uses the Request-ID- 207 number carried within the respective RP (Request Parameters) object 208 to identify the computation request that should be syncronized. 210 The PCEP extension for stateful PCE [I-D.ietf-pce-stateful-pce] 211 defined new PCEP messages - PCRpt, PCUpd and PCInitiate. These 212 messages uses PLSP-ID in the LSP object for identification. Moreover 213 to allow diversity between LSPs originating from different PCCs, the 214 generic mechanism to create a grouping of LSPs as described in 215 [I-D.ietf-pce-association-group] equally applicable to the active and 216 passive modes of a stateful PCE is better suited. 218 Using PCEP, the PCC MUST indicate that disjoint path computation is 219 required, such indication SHOULD include disjointness parameters such 220 as the type of disjointness, the disjoint group-id, and any 221 customization parameters according to the configured local policy. 222 As mentioned previously, the extension described in 223 [I-D.ietf-pce-association-group] is well suited to associated a set 224 of LSPs with a particular disjoint-group. 226 The management of the disjoint group-ids will be a key point for the 227 operator as the Association ID field is limited to 65535. The local 228 configuration of IPv4/IPv6 association source, or Global Association 229 Source/Extended Association ID should allow to overcome this 230 limitation. For example, when a PCC or PCE initiates all the LSPs in 231 a particular disjoint-group, it can set the IPv4/IPv6 association 232 source can be set to one of its IP address. When disjoint LSPs are 233 initiated from different head-ends, a unique association identifier 234 SHOULD be used for those LSPs: this can be achieved by setting the 235 IPv4/IPv6 source address to a common value (zero value can be used) 236 as well as the Association ID. 238 Initiate & Monitor LSP 239 | 240 | PCReq 241 V {Disjoint-group Y} 242 +-----+ ----------------> +-----+ 243 _ _ _ _ _ _| PCE | | | PCE | 244 | +-----+ | ----------> +-----+ 245 | PCInitiate | | PCReq 246 |{Disjoint-group X} | | {Disjoint-group Y} 247 | | | 248 | .-----. | | .-----. 249 | ( ) | +----+ ( ) 250 | .--( )--. | |PE 1|--.--( )--. 251 V ( ) | +----+ ( ) 252 +---+ ( ) | ( ) 253 |PCC|----( (G)MPLS network ) +----+ ( (G)MPLS network ) 254 +---+ ( ) |PE 3|------( ) 255 Disjoint-group X ) +----+ ( ) 256 {Monitor LSP} '--( )--' '--( )--' 257 ( ) ( ) 258 '-----' '-----' 260 Case 1: Disjointness initiated by Case 2: Disjointness initiated by 261 PCE and enforced by PCC PCC and enforced by PCE 263 Figure 2 - Sample use-cases for carrying disjoint-group over PCEP 264 session 266 Using the disjoint-group within a PCUpd or PCInitiate may have two 267 purposes: 269 o Information: in case the PCE is performing the path computation, 270 it may communicate to the PCC the locally used parameters in the 271 attribute-list of the LSP. 273 o Configuration: in case the PCE is updating the diversity 274 parameters. 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 ID will be used to identify the 283 disjoint group a set of LSPs belongs to. This document defines a new 284 Association type, based on the generic Association object - 286 o Association type = TBD1 ("Disjointness Association Type"). 288 A disjoint group can have two or more LSPs. But a PCE may be limited 289 in how many LSPs it can take into account when computing 290 disjointness. If a PCE receives more LSPs in the group than it can 291 handle in its computation algorithm, it SHOULD apply disjointness 292 computation to only a subset of LSPs in the group. The subset of 293 disjoint LSPs will be decided by the implementation. 295 Local polices on the PCC or PCE MAY define the computational behavior 296 for the other LSPs in the group. For example, the PCE may provide no 297 path, a shortest path, or a constrained path based on relaxing 298 disjointness, etc. 300 Associating a particular LSP to multiple disjoint groups is 301 authorized from a protocol perspective, however there is no insurance 302 that the PCE will be able to compute properly the multi-disjointness 303 constraint. 305 4.2. Mandatory TLV 307 The disjoint group MUST carry the following TLV: 309 o DISJOINTNESS-INFORMATION-TLV: Used to communicate some 310 disjointness specific parameters. 312 The DISJOINTNESS-INFORMATION-TLV is shown in the following figure: 314 0 1 2 3 315 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 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Type = [TBD2] | Length | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Flags |T|P|S|N|L| 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 Flags: 324 * L (Link diverse) bit: when set, this indicates that the 325 computed paths within the disjoint group MUST NOT have any link 326 in common. 328 * N (Node diverse) bit: when set, this indicates that the 329 computed paths within the disjoint group MUST NOT have any node 330 in common. 332 * S (SRLG diverse) bit: when set, this indicates that the 333 computed paths within the disjoint group MUST NOT share any 334 SRLG (Shared Risk Link Group). 336 * P (Shortest path) bit: when set, this indicates that the 337 computed path of the LSP SHOULD satisfies all constraints and 338 objective functions first without considering the diversity 339 constraint. This means that an LSP with P flag set should be 340 placed as if the disjointness constraint has not been 341 configured, while the other LSP in the association with P flag 342 unset should be placed by taking into account the disjointness 343 constraint. Setting P flag changes the relationship between 344 LSPs to a unidirectional relationship (LSP 1 with P=0 depends 345 of LSP 2 with P=1, but LSP 2 with P=1 does not depend of LSP 1 346 with P=0). 348 * T (Strict disjointness) bit: when set, if disjoint paths cannot 349 be found, PCE should return no path for LSPs that could not be 350 be disjoint. When unset, PCE is allowed to relax disjointness 351 by using either applying a requested objective function or any 352 other behavior if no objective function is requested (e.g.: 353 using a lower disjoint type (link instead of node) or relaxing 354 disjointness constraint at all). 356 If a PCEP speaker receives a disjoint-group without DISJOINTNESS- 357 INFORMATION-TLV, it SHOULD reply with a PCErr Error-type=6 (Mandatory 358 Object missing) and Error-value=TBD7. 360 4.3. Optional TLVs 362 The disjoint group MAY carry some optional TLVs including but not 363 limited to: 365 o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor 366 specific behavioral information, described in [RFC7150]. 368 4.4. Disjointness objective functions 370 An objective function MAY be applied to the disjointness computation 371 to drive the PCE computation behavior. In this case, the OF-List TLV 372 (defined in ([RFC5541]) is used as an optional TLV in the Association 373 Group Object. The PCEP OF-List TLV allow multiple OF-Codes inside 374 the TLV, a sender SHOULD include a single OF-Code in the OF-List TLV 375 when included in the Association Group, and the receiver MUST 376 consider the first OF-code only and ignore others if included. The 377 OF-Code to maximize diversity are specified in 378 ([I-D.dhody-pce-of-diverse]). 380 4.5. P-flag considerations 382 As mentioned in Section 4.2, the P-flag (when set) indicates that the 383 computed path of the LSP SHOULD satisfies all constraints and 384 objective functions first without considering the diversity 385 constraint. This could be required in some primary/backup scenarios 386 where the primary path should use the more optimal path available 387 (taking into account the other constraints). When disjointness is 388 computed, it is important for the algorithm to know that it should 389 try to optimize the path of one or more LSPs in the disjoint group 390 (for instance the primary path) while other paths are allowed to be 391 longer (compared to a similar path without the disjointness 392 constraint). Without such a hint, the disjointness algorithm may set 393 a path for all LSPs that may not completely fulfil the customer 394 requirement. 396 _________________________________________ 397 / \ 398 / +------+ \ 399 | | PCE | | 400 | +------+ | 401 | | 402 | | 403 | +------+ 10 +------+ | 404 CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2 405 | +------+ | | +------+ | 406 | | | | 407 | | | | 408 | +------+ | | +------+ | 409 CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4 410 | +------+ \ | / +------+ | 411 | \ | 10 / | 412 \ +-- R5 --------- R6 / 413 \_________________________________________/ 415 Figure 3 417 In the figure above, a customer has two dual homed sites (CE1/CE3 and 418 CE2/CE4). This customer wants two disjoint paths between the two 419 sites. Due to physical meshings, the customer wants to use CE1 and 420 CE2 as primary (for instance CE3 and CE4 are hosted in a remote site 421 for redundancy purpose compared the customer hosts). 423 Without any hint (constraint) provided, the PCE may compute the two 424 disjoint LSPs as a batch leading to PE1->PE2 using a path 425 PE1->R1->R2->PE2 and PE3->PE4 using PE3->R3->R4->PE4. In this case, 426 even if the disjointness constraint is fulfilled, the path from PE1 427 to PE2 does not use the best optimal path available in the network 428 (RTD may be higher): the customer requirement is thus not completely 429 fulfilled. 431 The usage of the P-Flag allows the PCE to know that a particular LSP 432 should be tied to the best path as if the disjointness constraint was 433 not requested. 435 In our example, if the P-Flag is set to the LSP PE1->PE2, the PCE 436 should use the path PE1->R1->R3->R4->R2->PE2 for this LSP, while the 437 other LSP should be disjoint from this path. The second LSP will be 438 placed on PE3->R5->R6->PE4 as it is allowed to be longer. 440 Driving the PCE disjointness computation may be done in other ways by 441 for instance setting a metric boundary reflecting an RTD boundary. 442 Other constraints may also be used. 444 The P-Flag allows a simple expression that the disjointness 445 constraint should not make the LSP worst. 447 Any constraint added to a path disjointness computation may reduce 448 the chance to find suitable paths. The usage of the P-flag, as any 449 other constraint, may prevent to find a disjoint path. In the 450 example above, if we consider that the router R5 is down, if PE1->PE2 451 has the P-flag set, there is no room available to place PE3->PE4 (the 452 disjointness constraint cannot be fulfilled). If PE->PE2 has the 453 P-flag unset, the algorithm may be able to place PE1->PE2 on R1->R2 454 link leaving a room for PE3->PE4 using the R3->R4 link. When using 455 P-flag or any additional constraint on top of the disjointness 456 constraint, the user should be aware that there is less chance to 457 fulfill the disjointness constraint. 459 Multiple LSPs in the same disjoint group may have the P-flag set. In 460 such a case, those LSPs may not be disjoint from each other but will 461 be disjoint from others LSPs in the group that have the P-flag unset. 463 _________________________________________ 464 / \ 465 / +------+ \ 466 | | PCE | | 467 | +------+ | 468 | | 469 | | 470 | +------+ 10 +------+ | 471 CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2 472 | +------+ | \ | +------+ | 473 | | \2 | | 474 | | \ | | 475 | +------+ | \ | +------+ | 476 CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4 477 | +------+ +------+ | 478 | | 479 \ / 480 \_________________________________________/ 482 Figure 4 484 In the figure above, we still consider the same previous 485 requirements, so PE1->PE2 LSP should be optimized (P-flag set) while 486 PE3->PE4 should be disjoint and may use a longer path. 488 Regarding PE1->PE2, there are two paths that are satisfying the 489 constraints (ECMP): PE1->R1->R4->R2->PE2 (path 1) and 490 PE1->R1->R3->R4->R2->PE2 (path 2). An implementation may choose one 491 of the paths or even use boths (using both may happen in case Segment 492 Routing TE is used, allowing ECMP). 494 If the implementation elects only one path, there is a chance that 495 picking up one path may prevent disjointness. In our example, if 496 path 2 is used for PE1->PE2, there is no room left for PE3->PE4 while 497 if path 1 is used, PE3->PE4 can be placed on R3->R4 link. 499 When P-flag is set for an LSP and when ECMPs are available, an 500 implementation MAY select a path that allows disjointness. 502 4.6. Disjointness computation issues 504 There may be some cases where the PCE is not able to provide a set of 505 disjoint paths for one or more LSPs in the association. 507 When the T-bit is set (Strict disjointness requested), if 508 disjointness cannot be found for one or more LSPs, the PCE SHOULD 509 reply with a PCUpd message containing an empty ERO. In addition to 510 the empty ERO Object, the PCE MAY add the NO-PATH-VECTOR TLV 511 ([RFC5440]) in the LSP Object. 513 This document adds new bits in the NO-PATH-VECTOR TLV: 515 bit "TBD3": when set, the PCE indicates that it could not find a 516 disjoint path for this LSP. 518 bit "TBD4": when set, the PCE indicates that it does not support 519 the requested disjointness computation. 521 The NO-PATH-VECTOR TLV MAY also be used when T-bit is unset and when 522 the PCE cannot provide a path for an LSP in the disjoint group. 524 When the T-bit is unset, the PCE is allowed to relax the constraint 525 if it cannot be satisfied. This document introduces a new RELAXED- 526 CONSTRAINT-TLV that MAY be used by a PCE to indicate that some 527 constraints have been relaxed. 529 When used, the RELAXED-CONSTRAINT-TLV SHOULD be included in the LSP 530 Object of a PCUpd message. The RELAXED-CONSTRAINT-TLV has the 531 following format: 533 0 1 2 3 534 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 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Type = [TBD5] | Length | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Object-Class#1| OT#1 |Res|P|I| Object Length (bytes) | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | | 541 // (Object body) // 542 | | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 ... 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Object-Class#n| OT#n |Res|P|I| Object Length (bytes) | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | | 549 // (Object body) // 550 | | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 All LSPs in a particular disjoint group MUST use the same combination 554 of T,S,N,L flags in the DISJOINTNESS-INFORMATION-TLV. If a PCE 555 receives PCRpt messages for LSPs belonging to the same disjoint group 556 but having an inconsistent combination of T,S,N,L flags, the PCE 557 SHOULD NOT try to compute disjointness path and SHOULD reply a PCErr 558 with Error-type 5 (Policy Violation) and Error-Value TBD6 559 (Inconsistent parameters in DISJOINTNESS-INFORMATION TLV) to all PCCs 560 involved in the disjoint group. 562 5. Security Considerations 564 This document defines one new type for association, which do not add 565 any new security concerns beyond those discussed in [RFC5440], 566 [I-D.ietf-pce-stateful-pce] and [I-D.ietf-pce-association-group] in 567 itself. 569 6. IANA Considerations 571 6.1. Association object Type Indicators 573 This document defines the following new association type originally 574 defined in [I-D.ietf-pce-association-group]. 576 Value Name Reference 578 TBD1 Disjoint-group 579 Association Type [This I.D.] 581 6.2. PCEP TLVs 583 This document defines the following new PCEP TLVs: 585 Value Name Reference 587 TBD2 DISJOINTNESS-INFORMATION-TLV [This I.D.] 588 TBD5 RELAXED-CONSTRAINT-TLV [This I.D.] 590 IANA is requested to manage the space of flags carried in the 591 DISJOINTNESS-INFORMATION TLV defined in this document, numbering them 592 from 0 as the least significant bit. 594 New bit numbers may be allocated in future. 596 IANA is requested to allocate the following bit numbers in the 597 DISJOINTNESS-INFORMATION-TLV flag space: 599 Bit Number Name Reference 600 0 Link disjointness [This I.D.] 601 1 Node disjointness [This I.D.] 602 2 SRLG disjointness [This I.D.] 603 3 Shortest-path [This I.D.] 604 4 Strict disjointness [This I.D.] 606 6.3. NO-PATH-VECTOR bit Flags 608 This documents defines new bits for the NO-PATH-VECTOR TLV in the 609 "NO-PATH-VECTOR TLV Flag Field" sub-registry of the "Path Computation 610 Element Protocol (PCEP) Numbers" registry: 612 Bit Number Name Reference 613 TBD3 Disjoint path not found [This I.D.] 615 TBD4 Requested disjointness [This I.D.] 616 computation not supported 618 6.4. PCEP-ERROR codes 620 IANA is requested to allocate new Error Types and Error Values within 621 the " PCEP-ERROR Object Error Types and Values" sub-registry of the 622 PCEP Numbers registry, as follows: 624 Error-Type Meaning 625 5 Policy violation 626 Error-value=TBD6: Inconsistent parameters 627 in DISJOINTNESS-INFORMATION TLV 629 6 Mandatory Object missing 630 Error-value=TBD7: DISJOINTNESS-INFORMATION TLV missing 632 7. Manageability Considerations 634 7.1. Control of Function and Policy 636 An operator MUST be allowed to configure the disjointness 637 associations and parameters at PCEP peers and associate it with the 638 LSPs. 640 7.2. Information and Data Models 642 [RFC7420] describes the PCEP MIB, there are no new MIB Objects for 643 this document. 645 7.3. Liveness Detection and Monitoring 647 Mechanisms defined in this document do not imply any new liveness 648 detection and monitoring requirements in addition to those already 649 listed in [RFC5440]. 651 7.4. Verify Correct Operations 653 Mechanisms defined in this document do not imply any new operation 654 verification requirements in addition to those already listed in 655 [RFC5440]. 657 7.5. Requirements On Other Protocols 659 Mechanisms defined in this document do not imply any new requirements 660 on other protocols. 662 7.6. Impact On Network Operations 664 Mechanisms defined in this document do not have any impact on network 665 operations in addition to those already listed in [RFC5440]. 667 8. Acknowledgments 669 A special thanks to author of [I-D.ietf-pce-association-group], this 670 document borrow some of the text from it. Authors would also like to 671 thank Adrian Farrel for his useful comments. 673 9. References 675 9.1. Normative References 677 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 678 Requirement Levels", BCP 14, RFC 2119, 679 DOI 10.17487/RFC2119, March 1997, 680 . 682 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 683 Element (PCE)-Based Architecture", RFC 4655, 684 DOI 10.17487/RFC4655, August 2006, 685 . 687 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 688 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 689 DOI 10.17487/RFC5440, March 2009, 690 . 692 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 693 Objective Functions in the Path Computation Element 694 Communication Protocol (PCEP)", RFC 5541, 695 DOI 10.17487/RFC5541, June 2009, 696 . 698 [I-D.ietf-pce-association-group] 699 Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 700 Zhang, X., and Y. Tanaka, "PCEP Extensions for 701 Establishing Relationships Between Sets of LSPs", draft- 702 ietf-pce-association-group-02 (work in progress), January 703 2017. 705 [I-D.ietf-pce-stateful-pce] 706 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 707 Extensions for Stateful PCE", draft-ietf-pce-stateful- 708 pce-18 (work in progress), December 2016. 710 [I-D.dhody-pce-of-diverse] 711 Dhody, D. and Q. Wu, "PCE support for Maximizing 712 Diversity", draft-dhody-pce-of-diverse-06 (work in 713 progress), October 2016. 715 9.2. Informative References 717 [RFC7150] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 718 Constraints in the Path Computation Element Communication 719 Protocol", RFC 7150, DOI 10.17487/RFC7150, March 2014, 720 . 722 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 723 Hardwick, "Path Computation Element Communication Protocol 724 (PCEP) Management Information Base (MIB) Module", 725 RFC 7420, DOI 10.17487/RFC7420, December 2014, 726 . 728 [I-D.ietf-pce-pce-initiated-lsp] 729 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 730 Extensions for PCE-initiated LSP Setup in a Stateful PCE 731 Model", draft-ietf-pce-pce-initiated-lsp-09 (work in 732 progress), March 2017. 734 Authors' Addresses 736 Stephane Litkowski 737 Orange 739 EMail: stephane.litkowski@orange.com 741 Siva Sivabalan 742 Cisco Systems, Inc. 743 2000 Innovation Drive 744 Kanata, Ontario K2K 3E8 745 Canada 747 EMail: msiva@cisco.com 749 Colby Barth 750 Juniper Networks 752 EMail: cbarth@juniper.net 754 Dhruv Dhody 755 Huawei 757 EMail: dhruv.dhody@huawei.com