--- 1/draft-ietf-pce-association-diversity-11.txt 2019-10-28 11:13:28.950669319 -0700 +++ 2/draft-ietf-pce-association-diversity-12.txt 2019-10-28 11:13:29.002670634 -0700 @@ -1,24 +1,23 @@ PCE Working Group S. Litkowski -Internet-Draft Orange -Intended status: Standards Track S. Sivabalan -Expires: April 30, 2020 Cisco Systems, Inc. - C. Barth +Internet-Draft S. Sivabalan +Intended status: Standards Track Cisco Systems, Inc. +Expires: April 30, 2020 C. Barth Juniper Networks M. Negi Huawei Technologies October 28, 2019 Path Computation Element Communication Protocol (PCEP) Extension for LSP Diversity Constraint Signaling - draft-ietf-pce-association-diversity-11 + draft-ietf-pce-association-diversity-12 Abstract This document introduces a simple mechanism to associate a group of Label Switched Paths (LSPs) via an extension to the Path Computation Element (PCE) communication Protocol (PCEP) with the purpose of computing diverse paths for those LSPs. The proposed extension allows a Path Computation Client (PCC) to advertise to a PCE that a particular LSP belongs to a particular disjoint-group, thus the PCE knows that the LSPs in the same group need to be disjoint from each @@ -60,43 +59,44 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Protocol Extension . . . . . . . . . . . . . . . . . . . . . 7 5.1. Association Group . . . . . . . . . . . . . . . . . . . . 7 5.2. Disjoint TLVs . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Disjointness Objective Functions . . . . . . . . . . . . 10 - 5.4. Relationship to SVEC . . . . . . . . . . . . . . . . . . 11 - 5.5. P Flag Considerations . . . . . . . . . . . . . . . . . . 12 - 5.6. Disjointness Computation Issues . . . . . . . . . . . . . 15 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 + 5.4. Relationship to SVEC . . . . . . . . . . . . . . . . . . 12 + 5.4.1. SVEC and OF . . . . . . . . . . . . . . . . . . . . . 12 + 5.5. P Flag Considerations . . . . . . . . . . . . . . . . . . 13 + 5.6. Disjointness Computation Issues . . . . . . . . . . . . . 16 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7.1. Association Type . . . . . . . . . . . . . . . . . . . . 17 - 7.2. PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . . . 17 - 7.3. Objective Functions . . . . . . . . . . . . . . . . . . . 18 - 7.4. NO-PATH-VECTOR Bit Flags . . . . . . . . . . . . . . . . 18 + 7.2. PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . . . 18 + 7.3. Objective Functions . . . . . . . . . . . . . . . . . . . 19 + 7.4. NO-PATH-VECTOR Bit Flags . . . . . . . . . . . . . . . . 19 7.5. PCEP-ERROR Codes . . . . . . . . . . . . . . . . . . . . 19 - 8. Manageability Considerations . . . . . . . . . . . . . . . . 19 - 8.1. Control of Function and Policy . . . . . . . . . . . . . 19 + 8. Manageability Considerations . . . . . . . . . . . . . . . . 20 + 8.1. Control of Function and Policy . . . . . . . . . . . . . 20 8.2. Information and Data Models . . . . . . . . . . . . . . . 20 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 20 8.4. Verification of Correct Operations . . . . . . . . . . . 20 - 8.5. Requirements on Other Protocols . . . . . . . . . . . . . 20 - 8.6. Impact on Network Operations . . . . . . . . . . . . . . 20 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 - 10.2. Informative References . . . . . . . . . . . . . . . . . 21 - Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 23 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 + 8.5. Requirements on Other Protocols . . . . . . . . . . . . . 21 + 8.6. Impact on Network Operations . . . . . . . . . . . . . . 21 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 + 10.2. Informative References . . . . . . . . . . . . . . . . . 22 + Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 24 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction [RFC5440] describes the Path Computation Element communication Protocol (PCEP) which enables the communication between a Path Computation Client (PCC) and a Path Control Element (PCE), or between two PCEs based on the PCE architecture [RFC4655]. PCEP Extensions for Stateful PCE Model [RFC8231] describes a set of extensions to PCEP to enable active control of MPLS-TE and GMPLS @@ -277,75 +277,81 @@ o Status: Used to communicate the status of the computed disjointness. 5. Protocol Extension 5.1. Association Group As per [I-D.ietf-pce-association-group], LSPs are associated with other LSPs with which they interact by adding them to a common association group. As described in [I-D.ietf-pce-association-group] - the association A A group is uniquely identified by the combination - of these fields in the ASSOCIATION object:A Association Type, - Association ID, Association Source, and (if present) Global - Association Source or Extended Association ID. + the association group is uniquely identified by the combination of + these fields in the ASSOCIATION object: Association Type, Association + ID, Association Source, and (if present) Global Association Source or + Extended Association ID. This document defines a new Association type, based on the generic Association object: o Association type = TBD1 Disjoint Association Type (DAT). [I-D.ietf-pce-association-group] specifies the mechanism for the capability advertisement of the association types supported by a PCEP speaker by defining a ASSOC-Type-List TLV to be carried within an OPEN object. This capability exchange for the Disjointness Association Type (TBD1) MUST be done before using the disjointness association. Thus the PCEP speaker MUST include the Disjointness Association Type in the ASSOC-Type-List TLV before using the Disjoint Association Group (DAG) in PCEP messages. This association type is considered to be both dynamic and operator- - configured in nature. The association group could be created by the - operator manually on the PCEP peers and the LSPs belonging to this - associations is conveyed via PCEP messages to the PCEP peer; or the - association group could be created dynamically by the PCEP speaker - and both the association group information and the LSPs belonging to - the association group is conveyed to the PCEP peer. The Operator- - configured Association Range MUST be set for this association-type to - mark a range of association identifiers that are used for operator- - configured associations to avoid any association identifier clash - within the scope of the association source. (Refer to - [I-D.ietf-pce-association-group].) + configured in nature. As per [I-D.ietf-pce-association-group], the + association group could be created by the operator manually on the + PCEP peers and the LSPs belonging to this associations is conveyed + via PCEP messages to the PCEP peer; or the association group could be + created dynamically by the PCEP speaker and both the association + group information and the LSPs belonging to the association group is + conveyed to the PCEP peer. The Operator-configured Association Range + MUST be set for this association-type to mark a range of association + identifiers that are used for operator-configured associations to + avoid any association identifier clash within the scope of the + association source. (Refer to [I-D.ietf-pce-association-group].) A disjoint group can have two or more LSPs, but a PCE may be limited in the number of LSPs it can take into account when computing disjointness. If a PCE receives more LSPs in the group than it can handle in its computation algorithm, it SHOULD apply disjointness computation to only a subset of LSPs in the group. The subset of disjoint LSPs will be decided by PCE as a local policy. Local polices MAY define the computational behavior for the other LSPs in the group. For example, the PCE may provide no path, a shortest path, or a constrained path based on relaxing disjointness, etc. The - disjoint status is informed to the PCC. + disjoint status of the computed path is informed to the PCC via + DISJOINTNESS-STATUS-TLV (see Section 5.2). + There are differet types of disjointness identified by the flags (T, + S, N, L) in the DISJOINTNESS-CONFIGURATION-TLV (see Section 5.2). All LSPs in a particular disjoint group MUST use the same combination - of T, S, N, L flags in the DISJOINTNESS-CONFIGURATION-TLVSection 5.2. - If a PCEP peer receives a PCEP messages for LSPs belonging to the - same disjoint group but having an inconsistent combination of T, S, - N, L flags, the PCEP peer SHOULD NOT try to add the LSPs in disjoint - group and SHOULD reply with a PCErr with Error-type 26 (Association - Error) and Error- Value 6 (Association information mismatch). + of T, S, N, L flags in the DISJOINTNESS-CONFIGURATION-TLV. If a PCEP + peer receives a PCEP messages for LSPs belonging to the same disjoint + group but having an inconsistent combination of T, S, N, L flags, the + PCEP peer MUST NOT try to add the LSPs in disjoint group and MUST + reply with a PCErr with Error-type 26 (Association Error) and Error- + Value 6 (Association information mismatch). - Associating a particular LSP to multiple disjoint groups is - authorized from a protocol perspective, however there is no assurance - that the PCE will be able to compute properly the multi-disjointness - constraint. + A particular LSP MAY be associated to multiple disjoint groups, but + in that case, the PCE SHOULD try to consider all the disjoint groups + during path computation if possible. Otherwise a local policy MAY + define the computational behavior. If a PCE does not support such a + path computation it MUST NOT add the LSP into association group and + return a PCErr with Error-type 26 (Association Error) and Error-Value + 7 (Cannot join the association group). 5.2. Disjoint TLVs The disjoint group MUST carry the following TLV: o DISJOINTNESS-CONFIGURATION-TLV: Used to communicate some disjointness configuration parameters. In addition, the disjoint group MAY carry the following TLV: @@ -384,24 +390,26 @@ in common. * S (SRLG diverse) bit: when set, this indicates that the computed paths within the disjoint group MUST NOT share any SRLG (Shared Risk Link Group). * P (Shortest path) bit: when set, this indicates that the computed path of the LSP SHOULD satisfy all the constraints and objective functions first without considering the diversity constraint, this means that all of the LSPs with P flag set in - the association group are computed first, and then with those - LSPs fixed, the other LSPs with P flag unset in the association - group are computed. The role of P flag is further described - with example inA Section 5.5 + the association group are computed first as if the disjointness + constraint has not been configured, and then with those LSPs + fixed, the other LSPs with P flag unset in the association + group are computed by taking into account the disjointness + constraint. The role of P flag is further described with + examples in Section 5.5. * T (Strict disjointness) bit: when set, if disjoint paths cannot be found, PCE SHOULD return no path for LSPs that could not be be disjoint. When unset, the PCE is allowed to relax disjointness by Section 5.5either applying a requested objective function (cf. Section 5.3 below) or using the local policy if no objective function is requested (e.g. using a lower disjoint type (link instead of node) or fully relaxing disjointness constraint). Further see Section 5.6 for details. @@ -409,31 +417,33 @@ on transmission and MUST be ignored on receipt. If a PCEP speaker receives a disjoint-group without DISJOINTNESS- CONFIGURATION-TLV, it SHOULD reply with a PCErr Error-type=6 (Mandatory Object missing) and Error-value=TBD8 (DISJOINTNESS- CONFIGURATION-TLV missing). The DISJOINTNESS-STATUS-TLV uses the same format as the DISJOINTNESS- CONFIGURATION-TLV with a different type TBD3 (in the TLV). The L, N, and S flags are set if the respective disjointness criterion was - requested and the computed paths meet it. The P flag is set to - indicate that the computed path is the shortest. + requested and the computed paths meet it. The P flag indicates that + the computed path is the shortest path (computed first without taking + disjointness constraints into consideration, but considering other + constraints). The T flag has no meaning in the DISJOINTNESS-STATUS-TLV and MUST NOT be set while sending and MUST be ignored on receipt. Any document defining a new flag for the DISJOINTNESS-CONFIGURATION- - TLV automatically defines a new flag A A with the same name and in - the same location in DISJOINTNESS-STATUS-TLV; the semantics of the - flag in A A DISJOINTNESS-STATUS-TLV MUST be specified in the - document that specifies the flag in DISJOINTNESS-CONFIGURATION-TLV. + TLV automatically defines a new flag with the same name and in the + same location in DISJOINTNESS-STATUS-TLV; the semantics of the flag + in DISJOINTNESS-STATUS-TLV MUST be specified in the document that + specifies the flag in DISJOINTNESS-CONFIGURATION-TLV. 5.3. Disjointness Objective Functions An objective function (OF) MAY be applied to the disjointness computation to drive the PCE computation behavior. In this case, the OF-List TLV (defined in ([RFC5541]) is used as an optional TLV in the Association Group Object. Whereas the PCEP OF-List TLV allows multiple OF-codes inside the TLV, a sender SHOULD include a single OF-code in the OF-List TLV when included in the Association Group, and the receiver MUST consider the first OF-code only and ignore @@ -445,79 +455,118 @@ MSL * Name: Minimize the number of shared (common) Links. * Objective Function Code: TBD4 * Description: Find a set of paths such that it passes through the least number of shared (common) links. + * A network comprises a set of N links {Li, (i=1...N)}. + + * A path P passes through K links {Lpi,(i=1...K)}. + + * A set of paths {P1...Pm} have L links that are common to more + than one path {Lpi,(i=1...L)}. + + * Find a set of paths such that the value of L is minimized. + MSS * Name: Minimize the number of shared (common) SRLGs. * Objective Function Code: TBD5 * Description: Find a set of paths such that it passes through the least number of shared (common) SRLGs. + * A network comprises a set of N links {Li, (i=1...N)}. + + * A path P passes through K links {Lpi,(i=1...K)} belonging to + unique M SRLGs {Spi,(i=1..M)}. + + * A set of paths {P1...Pm} have L SRLGs that are common to more + than one path {Spi,(i=1...L)}. + + * Find a set of paths such that the value of L is minimized. + MSN * Name: Minimize the number of shared (common) Nodes. * Objective Function Code: TBD6 * Description: Find a set of paths such that they pass through the least number of shared (common) nodes. + * A network comprises a set of N nodes {Ni, (i=1...N)}. + + * A path P passes through K nodes {Npi,(i=1...K)}. + + * A set of paths {P1...Pm} have L nodes that are common to more + than one path {Npi,(i=1...L)}. + + * Find a set of paths such that the value of L is minimized. + If the OF-list TLV is included in the Association Object, the OF-code inside the OF Object MUST include one of the disjoint OFs defined in this document. If this condition is not met, the PCEP speaker MUST respond with a PCErr message with Error-Type=10 (Reception of an invalid object) and Error-Value=TBD9 (Incompatible OF code). 5.4. Relationship to SVEC [RFC5440] defines a mechanism for the synchronization of a set of path computation requests by using the SVEC object, that specifies the list of synchronized requests that can either be dependent or - independent. The SVEC object identify the relationship between the + independent. The SVEC object identifies the relationship between the set of path computation requests, identified by 'Request-ID-number' in RP (Request Parameters) object. [RFC6007] further clarified the use of the SVEC list for synchronized path computations when computing dependent requests as well as described a number of usage scenarios for SVEC lists within single-domain and multi-domain environments. The SVEC object includes a Flags field that indicates the potential - dependency between the set of path computation request in a similar + dependency between the set of path computation requests in a similar way as the Flags field in the TLVs defined in this document. The path computation request in the PCReq message MAY use both the SVEC and ASSOCIATION objects to identify the related path computation - request as well as the diversity association group. The PCE MUST try - to find a path that meets both the constraints. It is possible that - the diversity requirement in the association group is different from - the one in the SVEC object. The PCE MUST consider both the objects - as per the processing rules and aim to find a path that meets both of - these constraints. In case no such path is possible, the PCE MUST - send a path computation reply (PCRep) with a NO-PATH object - indicating path computation failure as per [RFC5440]. + request as well as the DAG. The PCE MUST try to find a path that + meets both the constraints. It is possible that the diversity + requirement in the association group is different from the one in the + SVEC object. The PCE MUST consider both the objects as per the + processing rules and aim to find a path that meets both of these + constraints. In case no such path is possible, the PCE MUST send a + path computation reply (PCRep) with a NO-PATH object indicating path + computation failure as per [RFC5440]. It should be noted that the + LSPs in the association group can be fully same or partially + overlapping with the LSPs grouped by the SVEC object in PCReq + message. - [RFC5440] uses SVEC diversity flag for node, link or SRLG to describe - the potential disjointness between the set of path computation - requests used in PCEP protocol. + Some examples of usage are listed below: + + o PCReq with SVEC object with node-diverse bit=1 (LSP1,LSP2) and DAG + with S=1 (LSP1,LSP2) - both node and SRLG diverse path between + LSP1, LSP2. + + o PCReq with SVEC object with link-diverse bit=1 (LSP1,LSP2) and DAG + with L=1 (LSP1,LSP3) - link diverse paths between LSP1, LSP2, + LSP3. But any future change in LSP2 will have no impact. + +5.4.1. SVEC and OF This document defines three new OF-codes Section 5.3 to maximize diversity as much as possible, in other words, new OF-codes allow - specification of minimization of common A A shared resources (Node, - Link or SRLG) among a set of paths during path computation. + specification of minimization of common shared resources (Node, Link + or SRLG) among a set of paths during path computation. It may be interesting to note that the diversity flags in the SVEC object and OF for diversity can be used together. Some examples of usage are listed below: o SVEC object with node-diverse bit=1 - ensure full node-diversity. o SVEC object with node-diverse bit=1 and OF=MSS - full node diverse with as much as SRLG-diversity as possible. @@ -533,30 +582,30 @@ however this specification does not prohibit redundant constraints while using "SVEC object" and "OF" together for diversity. 5.5. P Flag Considerations As mentioned in Section 5.2, the P flag (when set) indicates that the computed path of the LSP SHOULD satisfies all constraints and objective functions first without considering the diversity constraint. - This means that an LSP with P flag set should be placed as if the - disjointness constraint has not been configured, while the other LSPs - in the association with P flag unset should be placed by taking into - account the disjointness constraint. Setting P flag changes the + This means that an LSP with P flag set should be placed first as if + the disjointness constraint has not been configured, while the other + LSPs in the association with P flag unset should be placed by taking + into account the disjointness constraint. Setting P flag changes the relationship between LSPs to a one-sided relationship (LSP 1 with P=0 depends of LSP 2 with P=1, but LSP 2 with P=1 does not depend of LSP 1 with P=0). Multiple LSPs in the same disjoint group may have the P flag set. In such a case, those LSPs may not be disjoint from each - other but will be disjoint from others LSPs in the group that have - the P flag unset. + other but will be disjoint from other LSPs in the group that have the + P flag unset. This could be required in some primary/backup scenarios where the primary path should use the more optimal path available (taking into account the other constraints). When disjointness is computed, it is important for the algorithm to know that it should try to optimize the path of one or more LSPs in the disjoint group (for instance the primary path) while other paths are allowed to be costlier (compared to a similar path without the disjointness constraint). Without such a hint, the disjointness algorithm may set a path for all LSPs that may not completely fulfill the customer's requirement. @@ -726,21 +775,21 @@ Also, as stated in [I-D.ietf-pce-association-group], much of the information carried in the Disjointness Association object, as per this document is not extra sensitive. It often reflects information that can also be derived from the LSP Database, but association provides a much easier grouping of related LSPs and messages. The disjointness association could provide an adversary with the opportunity to eavesdrop on the relationship between the LSPs. Thus securing the PCEP session using Transport Layer Security (TLS) [RFC8253], as per the recommendations and best current practices in - [RFC7525], is RECOMMENDED. + BCP 195 [RFC7525], is RECOMMENDED. 7. IANA Considerations 7.1. Association Type This document defines a new Association type, originally described in [I-D.ietf-pce-association-group]. IANA is requested to make the assignment of a new value for the sub-registry "ASSOCIATION Type Field" (request to be created in [I-D.ietf-pce-association-group]), as follows: @@ -891,20 +940,22 @@ LSPs that can belong to a DAG. 9. Acknowledgments A special thanks to authors of [I-D.ietf-pce-association-group], this document borrow some of the text from it. Authors would also like to thank Adrian Farrel and Julien Meuric for the valuable comments. Thanks to Emmanuel Baccelli for RTGDIR reviews. + Thanks to Dale Worley for a detailed GENART review. + 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for @@ -988,23 +1039,23 @@ Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India EMail: dhruv.ietf@gmail.com Authors' Addresses Stephane Litkowski - Orange + Cisco Systems, Inc. - EMail: stephane.litkowski@orange.com + EMail: slitkows.ietf@gmail.com Siva Sivabalan Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada EMail: msiva@cisco.com Colby Barth