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

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/