draft-ietf-pce-association-diversity-12.txt   draft-ietf-pce-association-diversity-13.txt 
PCE Working Group S. Litkowski PCE Working Group S. Litkowski
Internet-Draft S. Sivabalan Internet-Draft S. Sivabalan
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: April 30, 2020 C. Barth Expires: June 20, 2020 C. Barth
Juniper Networks Juniper Networks
M. Negi M. Negi
Huawei Technologies Huawei Technologies
October 28, 2019 December 18, 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-12 draft-ietf-pce-association-diversity-13
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 (disjointed) paths for those LSPs. The proposed
allows a Path Computation Client (PCC) to advertise to a PCE that a extension allows a Path Computation Client (PCC) to advertise to a
particular LSP belongs to a particular disjoint-group, thus the PCE PCE that a particular LSP belongs to a particular disjoint-group,
knows that the LSPs in the same group need to be disjoint from each thus the PCE knows that the LSPs in the same group need to be
other. disjoint from each other.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 30, 2020. This Internet-Draft will expire on June 20, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . 12 5.4. Relationship to SVEC . . . . . . . . . . . . . . . . . . 12
5.4.1. SVEC and OF . . . . . . . . . . . . . . . . . . . . . 12 5.4.1. SVEC and OF . . . . . . . . . . . . . . . . . . . . . 13
5.5. P Flag Considerations . . . . . . . . . . . . . . . . . . 13 5.5. P Flag Considerations . . . . . . . . . . . . . . . . . . 13
5.6. Disjointness Computation Issues . . . . . . . . . . . . . 16 5.6. Disjointness Computation Issues . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7.1. Association Type . . . . . . . . . . . . . . . . . . . . 17 7.1. Association Type . . . . . . . . . . . . . . . . . . . . 18
7.2. PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . . . 18 7.2. PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . . . 18
7.3. Objective Functions . . . . . . . . . . . . . . . . . . . 19 7.3. Objective Functions . . . . . . . . . . . . . . . . . . . 19
7.4. NO-PATH-VECTOR Bit Flags . . . . . . . . . . . . . . . . 19 7.4. NO-PATH-VECTOR Bit Flags . . . . . . . . . . . . . . . . 19
7.5. PCEP-ERROR Codes . . . . . . . . . . . . . . . . . . . . 19 7.5. PCEP-ERROR Codes . . . . . . . . . . . . . . . . . . . . 20
8. Manageability Considerations . . . . . . . . . . . . . . . . 20 8. Manageability Considerations . . . . . . . . . . . . . . . . 20
8.1. Control of Function and Policy . . . . . . . . . . . . . 20 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 . . . . . . . . . . . 21
8.5. Requirements on Other Protocols . . . . . . . . . . . . . 21 8.5. Requirements on Other Protocols . . . . . . . . . . . . . 21
8.6. Impact on Network Operations . . . . . . . . . . . . . . 21 8.6. Impact on Network Operations . . . . . . . . . . . . . . 21
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . 21 10.1. Normative References . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 24 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
skipping to change at page 3, line 26 skipping to change at page 3, line 26
configuration on the PCC, thus allowing for a dynamic network. configuration on the PCC, thus allowing for a dynamic network.
[I-D.ietf-pce-association-group] introduces a generic mechanism to [I-D.ietf-pce-association-group] introduces a generic mechanism to
create a grouping of LSPs in the context of a PCE which can then be create a grouping of LSPs in the context of a PCE which can then be
used to define associations between a set of LSPs and a set of used to define associations between a set of LSPs and a set of
attributes (such as configuration parameters or behaviors) and is attributes (such as configuration parameters or behaviors) and is
equally applicable to the active and passive modes of a stateful PCE equally applicable to the active and passive modes of a stateful PCE
[RFC8231] or a stateless PCE [RFC5440]. [RFC8231] or a stateless PCE [RFC5440].
This document specifies a PCEP extension to signal that a set of LSPs This document specifies a PCEP extension to signal that a set of LSPs
in a particular group should use diverse paths, including the in a particular group should use diverse (disjointed) paths,
requested type of diversity. A PCC can use this extension to signal including the requested type of diversity. Section 3 and Section 4
to a PCE that a particular LSP belongs to a particular disjoint- describe the property and use of a disjoint-group. A PCC can use
group. When a PCE receives LSP states belonging to the same this extension to signal to a PCE that a particular LSP belongs to a
disjoint-group from some PCCs, the PCE should ensure that the LSPs particular disjoint-group. When a PCE receives LSP states belonging
within the group are disjoint from each other. to the same disjoint-group from some PCCs, the PCE should ensure that
the LSPs within the group are disjoint from each other.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Terminology 2. Terminology
skipping to change at page 6, line 21 skipping to change at page 6, line 21
described in [I-D.ietf-pce-association-group]. When a PCC or PCE described in [I-D.ietf-pce-association-group]. When a PCC or PCE
initiates all the LSPs in a particular disjoint-group, it can set the initiates all the LSPs in a particular disjoint-group, it can set the
IPv4/IPv6 association source as one of its own IP address. When IPv4/IPv6 association source as one of its own IP address. When
disjoint LSPs are initiated from different head-ends, the association disjoint LSPs are initiated from different head-ends, the association
source could be the PCE address or any other unique value to identify source could be the PCE address or any other unique value to identify
the DAG. the DAG.
Initiate Disjoint LSPs Initiate Disjoint LSPs
| |
| PCReq/PCRpt | PCReq/PCRpt
V {Disjoint-group Y} V {DAG Y}
+-----+ ----------------> +-----+ +-----+ ----------------> +-----+
_ _ _ _ _ _| PCE | | | PCE | _ _ _ _ _ _| PCE | | | PCE |
| +-----+ | ----------> +-----+ | +-----+ | ----------> +-----+
| PCInitiate | | PCReq/PCRpt | PCInitiate | | PCReq/PCRpt
|{Disjoint-group X} | | {Disjoint-group Y} |{DAG X} | | {DAG Y}
| | | | | |
| .-----. | | .-----. | .-----. | | .-----.
| ( ) | +-----+ ( ) | ( ) | +-----+ ( )
| .--( )--. | |PCC 2|--.--( )--. | .--( )--. | |PCC 2|--.--( )--.
V ( ) | +-----+ ( ) V ( ) | +-----+ ( )
+---+ ( ) | ( ) +---+ ( ) | ( )
|PCC|----( (G)MPLS network ) +-----+ ( (G)MPLS network ) |PCC|----( (G)MPLS network ) +-----+ ( (G)MPLS network )
+---+ ( ) |PCC 1|-----( ) +---+ ( ) |PCC 1|-----( )
Disjoint-group X ) +-----+ ( ) {DAG X} ( ) +-----+ ( )
'--( )--' '--( )--' '--( )--' ( )--'
( ) ( ) ( ) ( )
'-----' '-----' '-----' '-----'
Case 1: Disjointness initiated by Case 2: Disjointness initiated by Case 1: Disjointness initiated by Case 2: Disjointness initiated by
PCE and enforced by PCC PCC and enforced by PCE PCE and enforced by PCC PCC and enforced by PCE
Figure 2 - Sample use-cases for carrying disjoint-group over PCEP Figure 2 - Sample use-cases for carrying disjoint-group over PCEP
session session
Using the disjoint-group within a PCEP messages is used for: Using the disjoint-group within a PCEP messages is used for:
o Configuration: Used to communicate the configured disjoint o Configuration: Used to communicate the configured disjoint
skipping to change at page 7, line 31 skipping to change at page 7, line 31
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 DAT (TBD1) MUST be
Association Type (TBD1) MUST be done before using the disjointness done before using the disjointness association. Thus the PCEP
association. Thus the PCEP speaker MUST include the Disjointness speaker MUST include the DAT in the ASSOC-Type-List TLV and MUST
Association Type in the ASSOC-Type-List TLV before using the Disjoint receive the same from the PCEP peer 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. As per [I-D.ietf-pce-association-group], the configured in nature. As per [I-D.ietf-pce-association-group], the
association group could be created by the operator manually on the association group could be created by the operator manually on the
PCEP peers and the LSPs belonging to this associations is conveyed PCEP peers and the LSPs belonging to this associations is conveyed
via PCEP messages to the PCEP peer; or the association group could be via PCEP messages to the PCEP peer; or the association group could be
created dynamically by the PCEP speaker and both the association created dynamically by the PCEP speaker and both the association
group information and the LSPs belonging to the association group is group information and the LSPs belonging to the association group is
conveyed to the PCEP peer. The Operator-configured Association Range conveyed to the PCEP peer. The Operator-configured Association Range
skipping to change at page 8, line 19 skipping to change at page 8, line 19
path, or a constrained path based on relaxing disjointness, etc. The path, or a constrained path based on relaxing disjointness, etc. The
disjoint status of the computed path is informed to the PCC via disjoint status of the computed path is informed to the PCC via
DISJOINTNESS-STATUS-TLV (see Section 5.2). DISJOINTNESS-STATUS-TLV (see Section 5.2).
There are differet types of disjointness identified by the flags (T, There are differet types of disjointness identified by the flags (T,
S, N, L) in the DISJOINTNESS-CONFIGURATION-TLV (see Section 5.2). 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-TLV. If a PCEP 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 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 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 PCEP peer MUST NOT add the LSPs to the disjoint group and MUST reply
reply with a PCErr with Error-type 26 (Association Error) and Error- with a PCErr with Error-type 26 (Association Error) and Error-Value 6
Value 6 (Association information mismatch). (Association information mismatch).
A particular LSP MAY be associated to multiple disjoint groups, but A particular LSP MAY be associated to the multiple disjoint groups,
in that case, the PCE SHOULD try to consider all the disjoint groups but in that case, the PCE SHOULD try to consider all the disjoint
during path computation if possible. Otherwise a local policy MAY groups during path computation if possible. Otherwise a local policy
define the computational behavior. If a PCE does not support such a MAY define the computational behavior. If a PCE does not support
path computation it MUST NOT add the LSP into association group and such a path computation it MUST NOT add the LSP into the association
return a PCErr with Error-type 26 (Association Error) and Error-Value group and return a PCErr with Error-type 26 (Association Error) and
7 (Cannot join the association group). 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 (ASSOCIATION object with Association type = TBD1
for DAT) 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. This is applicable for all
PCEP message that includes DAG.
In addition, the disjoint group MAY carry the following TLV: In addition, the disjoint group (ASSOCIATION object with Association
type = TBD1 for DAT) MAY carry the following TLVs:
o DISJOINTNESS-STATUS-TLV: Used to communicate the status of the o DISJOINTNESS-STATUS-TLV: Used to communicate the status of the
computed disjointness. This is applicable for messages from PCE computed disjointness. This is applicable for messages from a PCE
to PCC (PCUpd, PCInitiate or PCRep message). to a PCC only (i.e. 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
skipping to change at page 9, line 43 skipping to change at page 9, line 45
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 as if the disjointness the association group are computed first as if the disjointness
constraint has not been configured, and then with those LSPs constraint has not been configured, and then with those LSPs
fixed, the other LSPs with P flag unset in the association fixed, the other LSPs with P flag unset in the association
group are computed by taking into account the disjointness group are computed by taking into account the disjointness
constraint. The role of P flag is further described with constraint. The role of P flag is further described with
examples in Section 5.5. 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 MUST return no path for LSPs that could not be be
be disjoint. When unset, the PCE is allowed to relax disjoint. When unset, the PCE is allowed to relax disjointness
disjointness by Section 5.5 either applying a requested by Section 5.5 either applying a requested objective function
objective function (cf. Section 5.3 below) or using the local (cf. Section 5.3 below) or using the local policy if no
policy if no objective function is requested (e.g. using a objective function is requested (e.g. using a lower disjoint
lower disjoint type (link instead of node) or fully relaxing type (link instead of node) or fully relaxing disjointness
disjointness constraint). Further see Section 5.6 for details. 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 (ASSOCIATION object with
CONFIGURATION-TLV, it SHOULD reply with a PCErr Error-type=6 Association type = TBD1 for DAT) without DISJOINTNESS-CONFIGURATION-
(Mandatory Object missing) and Error-value=TBD8 (DISJOINTNESS- TLV, it SHOULD reply with a PCErr Error-type=6 (Mandatory Object
CONFIGURATION-TLV missing). missing) and Error-value=TBD10 (DISJOINTNESS-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 indicates that requested and the computed paths meet it. The P flag indicates that
the computed path is the shortest path (computed first without taking the computed path is the shortest path (computed first without taking
disjointness constraints into consideration, but considering other disjointness constraints into consideration, but considering other
constraints). 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
skipping to change at page 10, line 47 skipping to change at page 11, line 4
To minimize the common shared resources (Node, Link or SRLG) between To minimize the common shared resources (Node, Link or SRLG) between
a set of paths during path computation three new OF-codes are a set of paths during path computation three new OF-codes are
proposed: proposed:
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 network comprises a set of N links {Li, (i=1...N)}.
* A path P passes through K links {Lpi,(i=1...K)}. * 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 * A set of paths {P1...Pm} have L links that are common to more
than one path {Lpi,(i=1...L)}. than one path {Lci,(i=1...L)}.
* Find a set of paths such that the value of L is minimized. * 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 network comprises a set of N links {Li, (i=1...N)}.
* A path P passes through K links {Lpi,(i=1...K)} belonging to * A path P passes through K links {Lpi,(i=1...K)} belonging to
unique M SRLGs {Spi,(i=1..M)}. unique M SRLGs {Spi,(i=1..M)}.
* A set of paths {P1...Pm} have L SRLGs that are common to more * A set of paths {P1...Pm} have L SRLGs that are common to more
than one path {Spi,(i=1...L)}. than one path {Sci,(i=1...L)}.
* Find a set of paths such that the value of L is minimized. * 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 network comprises a set of N nodes {Ni, (i=1...N)}.
* A path P passes through K nodes {Npi,(i=1...K)}. * 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 * A set of paths {P1...Pm} have L nodes that are common to more
than one path {Npi,(i=1...L)}. than one path {Nci,(i=1...L)}.
* Find a set of paths such that the value of L is minimized. * 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 first
inside the OF Object MUST include one of the disjoint OFs defined in OF-code inside the OF Object MUST be one of the disjoint OFs defined
this document. If this condition is not met, the PCEP speaker MUST in this document. If this condition is not met, the PCEP speaker
respond with a PCErr message with Error-Type=10 (Reception of an MUST 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 identifies 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
skipping to change at page 12, line 28 skipping to change at page 12, line 32
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 requests 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 DAG. The PCE MUST try to find a path that 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 meets both the constraints. It is possible that the diversity
requirement in the association group is different from the one in the requirement in the association group is different from the one in the
SVEC object. The PCE MUST consider both the objects as per the SVEC object. The PCE MUST consider both the objects (including the
processing rules and aim to find a path that meets both of these flags set inside the objects) as per the processing rules and aim to
constraints. In case no such path is possible, the PCE MUST send a find a path that meets both of these constraints. In case no such
path computation reply (PCRep) with a NO-PATH object indicating path path is possible, the PCE MUST send a path computation reply (PCRep)
computation failure as per [RFC5440]. It should be noted that the with a NO-PATH object indicating path computation failure as per
LSPs in the association group can be fully same or partially [RFC5440]. It should be noted that the LSPs in the association group
overlapping with the LSPs grouped by the SVEC object in PCReq can be fully same or partially overlapping with the LSPs grouped by
message. the SVEC object in PCReq message.
Some examples of usage are listed below: Some examples of usage are listed below:
o PCReq with SVEC object with node-diverse bit=1 (LSP1,LSP2) and DAG 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 with S=1 (LSP1,LSP2) - both node and SRLG diverse path between
LSP1, LSP2. LSP1, LSP2.
o PCReq with SVEC object with link-diverse bit=1 (LSP1,LSP2) and DAG 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, with L=1 (LSP1,LSP3) - link diverse paths between LSP1, LSP2,
LSP3. But any future change in LSP2 will have no impact. LSP3. But any future change in LSP2 will have no impact.
skipping to change at page 13, line 38 skipping to change at page 13, line 43
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 first as if 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 the disjointness constraint has not been configured, while the other
LSPs in the association with P flag unset should be placed by taking LSPs in the association with P flag unset should be placed by taking
into account the disjointness constraint. Setting P flag changes the into account the disjointness constraint. Setting the P flag changes
relationship between LSPs to a one-sided relationship (LSP 1 with P=0 the relationship between LSPs to a one-sided relationship (LSP 1 with
depends of LSP 2 with P=1, but LSP 2 with P=1 does not depend of LSP P=0 depends on LSP 2 with P=1, but LSP 2 with P=1 does not depend of
1 with P=0). Multiple LSPs in the same disjoint group may have the P LSP 1 with P=0). Multiple LSPs in the same disjoint group may have
flag set. In such a case, those LSPs may not be disjoint from each the P flag set. In such a case, those LSPs may not be disjoint from
other but will be disjoint from other LSPs in the group that have the each other but will be disjoint from other LSPs in the group that
P flag unset. have the 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 14, line 32 skipping to change at page 14, line 36
| +------+ \ | / +------+ | | +------+ \ | / +------+ |
| \ | 10 / | | \ | 10 / |
\ +-- R5 --------- R6 / \ +-- R5 --------- R6 /
\_________________________________________/ \_________________________________________/
Cost of all the links is 1, unless explicitly marked otherwise. Cost of all the links is 1, unless explicitly marked otherwise.
Figure 3 Figure 3
In the figure above, a customer has two dual homed sites (CE1/CE3 and In the figure above, a customer has two dual homed sites (CE1/CE3 and
CE2/CE4). Let us consider that this customer wants two disjoint CE2/CE4). Let us consider that this customer wants two link disjoint
paths between the two sites. Due to physical meshing, the customer paths between the two sites. Due to physical meshing, the customer
wants to use CE1 and CE2 as primary (and CE3 and CE4 are hosted in a wants to use CE1 and CE2 as primary (and CE3 and CE4 are hosted in a
remote site for redundancy purpose). remote site for redundancy purpose).
Without any hint (constraint) provided, the PCE may compute the two Without any hint (constraint) provided, the PCE may compute the two
disjoint LSPs together, leading to PE1->PE2 using a path link disjoint LSPs together, leading to PE1->PE2 using a path
PE1->R1->R2->PE2 and PE3->PE4 using PE3->R3->R4->PE4. In this case, PE1->R1->R2->PE2 and PE3->PE4 using PE3->R3->R4->PE4. In this case,
even if the disjointness constraint is fulfilled, the path from PE1 even if the disjointness constraint is fulfilled, the path from PE1
to PE2 does not use the best optimal path available in the network to PE2 does not use the best optimal path available in the network
(path delay may be higher): the customer requirement is thus not (path delay may be higher): the customer requirement is thus not
completely fulfilled. completely fulfilled.
The usage of the P flag allows the PCE to know that a particular LSP The usage of the P flag allows the PCE to know that a particular LSP
should be tied to the best path as if the disjointness constraint was should be tied to the best path as if the disjointness constraint was
not requested. not requested.
In our example, if the P flag is set to the LSP PE1->PE2, the PCE In our example, if the P flag is set to the LSP PE1->PE2, the PCE
should use the path PE1->R1->R3->R4->R2->PE2 for this LSP, while the should use the path PE1->R1->R3->R4->R2->PE2 for this LSP, while the
other LSP should be disjoint from this path. The second LSP will be other LSP should be link disjoint from this path. The second LSP
placed on PE3->R5->R6->PE4 as it is allowed to be costlier. will be placed on PE3->R5->R6->PE4 as it is allowed to be costlier.
Driving the PCE disjointness computation may be done in other ways, Driving the PCE disjointness computation may be done in other ways,
for instance setting a metric boundary reflecting an path delay for instance setting a metric boundary reflecting an path delay
boundary. Other constraints may also be used. boundary. Other constraints may also be used.
The P flag allows to simply express that the disjointness constraint The P flag allows to simply express that the disjointness constraint
should not make the LSP worst. should not make the LSP worst.
Any constraint added to a path disjointness computation may reduce Any constraint added to a path disjointness computation may reduce
the chance to find suitable paths. The usage of the P flag, as any the chance to find suitable paths. The usage of the P flag, as any
other constraint, may prevent to find a disjoint path. In the other constraint, may prevent to find a disjoint path. In the
example above, if we consider that the router R5 is down, if PE1->PE2 example above, if we consider that the router R5 is down, if PE1->PE2
has the P flag set, there is no room available to place PE3->PE4 (the has the P flag set, there is no room available to place PE3->PE4 (the
disjointness constraint cannot be fulfilled). If PE1->PE2 has the P link disjointness constraint cannot be fulfilled). If PE1->PE2 has
flag unset, the algorithm may be able to place PE1->PE2 on R1->R2 the P flag unset, the algorithm may be able to place PE1->PE2 on
link leaving a room for PE3->PE4 using the R3->R4 link. When using P R1->R2 link leaving a room for PE3->PE4 using the R3->R4 link. When
flag or any additional constraint on top of the disjointness using P flag or any additional constraint on top of the disjointness
constraint, the user should be aware that there is less chance to constraint, the user should be aware that there is less chance to
fulfill the disjointness constraint. fulfill the disjointness constraint.
_________________________________________ _________________________________________
/ \ / \
/ +------+ \ / +------+ \
| | PCE | | | | PCE | |
| +------+ | | +------+ |
| | | |
| | | |
skipping to change at page 15, line 51 skipping to change at page 16, line 7
| | | |
\ / \ /
\_________________________________________/ \_________________________________________/
Cost of all the links is 1, unless explicitly marked otherwise. Cost of all the links is 1, unless explicitly marked otherwise.
Figure 4 Figure 4
In the figure above, we still consider the same previous In the figure above, we still consider the same previous
requirements, so PE1->PE2 LSP should be optimized (P flag set) while requirements, so PE1->PE2 LSP should be optimized (P flag set) while
PE3->PE4 should be disjoint and may use a costlier path. PE3->PE4 should be link disjoint and may use a costlier path.
Regarding PE1->PE2, there are two paths that are satisfying the Regarding PE1->PE2, there are two paths that are satisfying the
constraints (ECMP): PE1->R1->R4->R2->PE2 (path 1) and constraints (ECMP): PE1->R1->R4->R2->PE2 (path 1) and
PE1->R1->R3->R4->R2->PE2 (path 2). An implementation may choose one PE1->R1->R3->R4->R2->PE2 (path 2). An implementation may choose one
of the paths. of the paths
.
If the implementation elects only one path, there is a chance that If the implementation elects only one path, there is a chance that
picking up one path may prevent disjointness. In our example, if picking up one path may prevent link disjointness. In our example,
path 2 is used for PE1->PE2, there is no room left for PE3->PE4 while if path 2 is used for PE1->PE2, there is no room left for PE3->PE4
if path 1 is used, PE3->PE4 can be placed on R3->R4 link. while if path 1 is used, PE3->PE4 can be placed on R3->R4 link.
When P flag is set for an LSP and when ECMPs are available, an When P flag is set for an LSP and when ECMPs are available, an
implementation should aim to select a path that allows disjointness. implementation should aim to select a path that allows disjointness.
5.6. Disjointness Computation Issues 5.6. Disjointness Computation Issues
There may be some cases where the PCE is not able to provide a set of There may be some cases where the PCE is not able to provide a set of
disjoint paths for one or more LSPs in the association. disjoint paths for one or more LSPs in the association.
When the T flag is set (Strict disjointness requested), if When the T flag is set (Strict disjointness requested), if
disjointness cannot be ensured for one or more LSPs, the PCE MUST disjointness cannot be ensured for one or more LSPs, the PCE MUST
reply to a Path Computation Request (PCReq) with a Path Computation reply to a Path Computation Request (PCReq) with a Path Computation
Reply (PCRep) message containing a NO-PATH object. In case of PCRpt Reply (PCRep) message containing a NO-PATH object. In case of PCRpt
message, the PCE MUST return a PCErr message with Error-Type 26 message, the PCE MUST return a PCErr message with Error-Type 26
"Association Error" and Error-Value 7 "Cannot join the association "Association Error" and Error-Value 7 "Cannot join the association
group". group".
In case of network event leading to an impossible strict In case of a network event leading to an impossible strict
disjointness, the PCE MUST send a PCUpd message containing an empty disjointness, the PCE MUST send a PCUpd message containing an empty
ERO to the corresponding PCCs. In addition to the empty ERO Object, ERO to the corresponding PCCs. In addition to the empty ERO Object,
the PCE MAY add the NO-PATH-VECTOR TLV ([RFC5440]) in the LSP Object. the PCE MAY add the NO-PATH-VECTOR TLV ([RFC5440]) in the LSP Object.
This document adds new bits in the NO-PATH-VECTOR TLV: This document adds new bits in the NO-PATH-VECTOR TLV:
bit "TBD7": when set, the PCE indicates that it could not find a bit "TBD7": when set, the PCE indicates that it could not find a
disjoint path for this LSP. disjoint path for this LSP.
bit "TBD8": when set, the PCE indicates that it does not support bit "TBD8": when set, the PCE indicates that it does not support
the requested disjointness computation. the requested disjointness computation.
When the T flag is unset, the PCE is allowed to relax disjointness by When the T flag is unset,
applying a requested objective function (Section 5.3) if specified. the PCE is allowed to relax disjointness by applying a requested
Otherwise, if no objective function is specified, the PCE is allowed objective function (Section 5.3) if specified. Otherwise, if no
to reduce the required level of disjointness as it deems fit. The objective function is specified, the PCE is allowed to reduce the
actual level of disjointness of the paths computed by the PCE can be required level of disjointness as it deems fit. The actual level of
reported through the DISJOINTNESS-STATUS-TLV by setting the disjointness of the paths computed by the PCE can be reported through
appropriate flags in the TLV. While the DISJOINTNESS-CONFIGURATION- the DISJOINTNESS-STATUS-TLV by setting the appropriate flags in the
TLV defines the desired level of disjointness required by TLV. While the DISJOINTNESS-CONFIGURATION-TLV defines the desired
configuration, the DISJOINTNESS-STATUS-TLV defines the achieved level level of disjointness required by configuration, the DISJOINTNESS-
of disjointness computed. STATUS-TLV defines the achieved level of disjointness computed.
There are some cases where the PCE may need to completely relax the There are some cases where the PCE may need to completely relax the
disjointness constraint in order to provide a path to all the LSPs disjointness constraint in order to provide a path to all the LSPs
that are part of the association. A mechanism that allows the PCE to that are part of the association. A mechanism that allows the PCE to
fully relax a constraint is considered by the authors as more global fully relax a constraint is considered by the authors as more global
to PCEP rather than linked to the disjointness use case. As a to PCEP rather than linked to the disjointness use case. As a
consequence, it is considered as out of scope of the document. consequence, it is considered as out of scope of the document.
6. Security Considerations 6. Security Considerations
This document defines one new PCEP association type, which on itself This document defines one new PCEP association type, which on itself
does not add any new security concerns beyond those discussed in does not add any new security concerns beyond those discussed in
[RFC5440], [RFC8231] and [I-D.ietf-pce-association-group]. But, [RFC5440], [RFC8231], [RFC7470] and [I-D.ietf-pce-association-group].
adding of a spurious LSP into the disjointness association group But, adding of a spurious LSP into the disjointness association group
could lead to re-computation and set-up of all LSPs in the group, could lead to re-computation and set-up of all LSPs in the group,
that could be used to overwhelm the PCE and the network. that could be used to overwhelm the PCE and the network.
A spurious LSP can have flags that are inconsistent with those of the A spurious LSP can have flags that are inconsistent with those of the
legitimate LSPs of the group and thus cause LSP allocation for the legitimate LSPs of the group and thus cause LSP allocation for the
legitimate LSPs to fail with an error. legitimate LSPs to fail with an error. Also, certain combinations of
flags (notably, the 'T' bit) can result in conflicts that cannot be
resolved.
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 reflects
this document is not extra sensitive. It often reflects information information that can also be derived from the LSP Database, but
that can also be derived from the LSP Database, but association association provides a much easier grouping of related LSPs and
provides a much easier grouping of related LSPs and messages. The messages. The disjointness association could provide an adversary
disjointness association could provide an adversary with the with the opportunity to eavesdrop on the relationship between the
opportunity to eavesdrop on the relationship between the LSPs. LSPs and understand the network topology.
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
BCP 195 [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:
+------------------+-----------------------------+-------------+ +------------------+---------------------------------+--------------+
| Association type | Association Name | Reference | | Association type | Association Name | Reference |
+------------------+-----------------------------+-------------+ +------------------+---------------------------------+--------------+
| TBD1 | Disjoint-group Association | [This.I-D] | | TBD1 | Disjointness Association Type | [This.I-D] |
+------------------+-----------------------------+-------------+ +------------------+---------------------------------+--------------+
7.2. PCEP TLVs 7.2. PCEP TLVs
This document defines the following new PCEP TLVs and the IANA is This document defines the following new PCEP TLVs and the IANA is
requested to make the assignment of new values for the existing "PCEP requested to make the assignment of new values for the existing "PCEP
TLV Type Indicators" registry as follows: TLV Type Indicators" registry as follows:
+----------+---------------------------------+-------------+ +----------+----------------------------------+--------------+
| TLV Type | TLV Name | Reference | | TLV Type | TLV Name | Reference |
+----------+---------------------------------+-------------+ +----------+----------------------------------+--------------+
| TBD2 | Disjointness Configuration TLV | [This.I-D] | | TBD2 | Disjointness Configuration TLV | [This.I-D] |
| TBD3 | Disjointness Status TLV | [This.I-D] | | TBD3 | Disjointness Status TLV | [This.I-D] |
+----------+---------------------------------+-------------+ +----------+----------------------------------+--------------+
This document requests that a new sub-registry, named "Disjointness This document requests that a new sub-registry, named "Disjointness
Configuration TLV Flag Field", is created within the "Path Configuration TLV Flag Field", is created within the "Path
Computation Element Protocol (PCEP) Numbers" registry to manage the Computation Element Protocol (PCEP) Numbers" registry to manage the
Flag field in the Disjointness Configuration TLV. New values are to Flag field in the Disjointness Configuration TLV. New values are to
be assigned by Standards Action [RFC8126]. Each bit should be be assigned by Standards Action [RFC8126]. Each bit should be
tracked with the following qualities: tracked with the following qualities:
o Bit number (count from 0 as the most significant bit) o Bit number (count from 0 as the most significant bit)
o Flag Name o Flag Name
o Reference o Reference
+------------+-------------------------+--------------+
+------------+-------------------------+-------------+ | Bit Number | Name | Reference |
| Bit Number | Name | Reference | +------------+-------------------------+--------------+
+------------+-------------------------+-------------+ | 31 | L - Link Diverse | [This.I-D] |
| 31 | L - Link Diverse | [This.I-D] | | 30 | N - Node Diverse | [This.I-D] |
| 30 | N - Node Diverse | [This.I-D] | | 29 | S - SRLG Diverse | [This.I-D] |
| 29 | S - SRLG Diverse | [This.I-D] | | 28 | P - Shortest Path | [This.I-D] |
| 28 | P - Shortest Path | [This.I-D] | | 27 | T - Strict Disjointness | [This.I-D] |
| 27 | T - Strict Disjointness | [This.I-D] | +------------+-------------------------+--------------+
+------------+-------------------------+-------------+
Table 1: Disjointness Configuration TLV Table 1: Disjointness Configuration TLV
7.3. Objective Functions 7.3. Objective Functions
Three new Objective Functions have been defined in this document. Three new Objective Functions have been defined in this document.
IANA is requested to make the following allocations from the PCEP IANA is requested to make the following allocations from the PCEP
"Objective Function" sub-registry: "Objective Function" sub-registry:
+------------+----------------------------------------+-------------+ +------------+---------------------------------------+--------------+
| Code Point | Name | Reference | | Code Point | Name | Reference |
+------------+----------------------------------------+-------------+ +------------+---------------------------------------+--------------+
| TBD4 | Minimize the number of shared Links | [This.I-D] | | TBD4 | Minimize the number of shared Links | [This.I-D] |
| | (MSL) | | | | (MSL) | |
| TBD5 | Minimize the number of shared SRLGs | [This.I-D] | | TBD5 | Minimize the number of shared SRLGs | [This.I-D] |
| | (MSS) | | | | (MSS) | |
| TBD6 | Minimize the number of shared Nodes | [This.I-D] | | TBD6 | Minimize the number of shared Nodes | [This.I-D] |
| | (MSN) | | | | (MSN) | |
+------------+----------------------------------------+-------------+ +------------+---------------------------------------+--------------+
7.4. NO-PATH-VECTOR Bit Flags 7.4. NO-PATH-VECTOR Bit Flags
This documents defines new bits for the NO-PATH-VECTOR TLV in the This documents defines new bits for the NO-PATH-VECTOR TLV in the
"NO-PATH-VECTOR TLV Flag Field" sub-registry of the "Path Computation "NO-PATH-VECTOR TLV Flag Field" sub-registry of the "Path Computation
Element Protocol (PCEP) Numbers" registry. IANA is requested to make Element Protocol (PCEP) Numbers" registry. IANA is requested to make
the following allocation: the following allocation:
+------------+-----------------------------------------+------------+ +-----------+-----------------------------------------+-------------+
| Bit Number | Name | Reference | | Bit | Name | Reference |
+------------+-----------------------------------------+------------+ | Number | | |
| TBD7 | Disjoint path not found | [This.I-D] | +-----------+-----------------------------------------+-------------+
| TBD8 | Requested disjoint computation not | [This.I-D] | | TBD7 | Disjoint path not found | [This.I-D] |
| | supported | | | TBD8 | Requested disjoint computation not | [This.I-D] |
+------------+-----------------------------------------+------------+ | | supported | |
+-----------+-----------------------------------------+-------------+
Table 2: NO-PATH-VECTOR TLV Table 2: NO-PATH-VECTOR TLV
7.5. PCEP-ERROR Codes 7.5. PCEP-ERROR Codes
This document defines new Error-Value within existing Error-Type This document defines new Error-Value within existing Error-Type
related to path protection association. IANA is requested to related to path protection association. IANA is requested to
allocate new error values within the "PCEP-ERROR Object Error Types allocate new error values within the "PCEP-ERROR Object Error Types
and Values" sub-registry of the PCEP Numbers registry, as follows: and Values" sub-registry of the PCEP Numbers registry, as follows:
+----------+-------------------------+------------------------------+ +----------+-------------------------+------------------------------+
| Error- | Meaning | Reference | | Error- | Meaning | Reference |
| Type | | | | Type | | |
+----------+-------------------------+------------------------------+ +----------+-------------------------+------------------------------+
| 6 | Mandatory Object | [I-D.ietf-pce-association-gr | | 6 | Mandatory Object | [I-D.ietf-pce-association-gr |
| | missing | oup] | | | missing | oup] |
| | Error-value=TBD8: | [This.I-D] | | | Error-value=TBD10: | [This.I-D] |
| | DISJOINTNESS- | | | | DISJOINTNESS- | |
| | CONFIGURATION TLV | | | | CONFIGURATION TLV | |
| | missing | | | | missing | |
| 10 | Reception of an invalid | [RFC5440] | | 10 | Reception of an | [RFC5440] |
| | object | | | | invalid object | |
| | Error-value=TBD9: | [This.I-D] | | | Error-value=TBD9: | [This.I-D] |
| | Incompatible OF code | | | | Incompatible OF code | |
+----------+-------------------------+------------------------------+ +----------+-------------------------+------------------------------+
8. Manageability Considerations 8. Manageability Considerations
8.1. Control of Function and Policy 8.1. Control of Function and Policy
An operator SHOULD be allowed to configure the disjointness An operator SHOULD be allowed to configure the disjointness
association groups and disjoint parameters at the PCEP peers and association groups and disjoint parameters at the PCEP peers and
associate it with the LSPs. The Operator-configured Association associate it with the LSPs. The Operator-configured Association
Range MUST be allowed to be set by the operator. Operator SHOULD be Range MUST be allowed to be set by the operator. The operator SHOULD
allowed to set the local policies to define various disjoint be allowed to set the local policies to define various disjoint
computational behavior at the PCE. computational behavior at the PCE.
8.2. Information and Data Models 8.2. Information and Data Models
An implementation SHOULD allow the operator to view the disjoint An implementation SHOULD allow the operator to view the disjoint
associations configured or created dynamically. Further associations configured or created dynamically. Furthermore,
implementation SHOULD allow to view disjoint associations reported by implementations SHOULD allow to view disjoint associations reported
each peer, and the current set of LSPs in this association. The PCEP by each peer, and the current set of LSPs in this association. The
YANG module [I-D.ietf-pce-pcep-yang] includes association groups PCEP YANG module [I-D.ietf-pce-pcep-yang] includes association groups
information. information.
8.3. Liveness Detection and Monitoring 8.3. Liveness Detection and Monitoring
Mechanisms defined in this document do not imply any new liveness Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already detection and monitoring requirements in addition to those already
listed in [RFC5440]. listed in [RFC5440].
8.4. Verification of Correct Operations 8.4. Verification of Correct Operations
Mechanisms defined in this document do not imply any new operation Apart from the operation verification requirements already listed in
verification requirements in addition to those already listed in [RFC5440], a PCEP implementation SHOULD provide parameters related to
[RFC5440]. disjoint path computation, such as number of DAG, number of disjoint
path computation failures etc. A PCEP implementation SHOULD log
failure events (e.g., incompatible Flags).
8.5. Requirements on Other Protocols 8.5. Requirements on Other Protocols
Mechanisms defined in this document do not imply any new requirements Mechanisms defined in this document do not imply any new requirements
on other protocols. on other protocols.
8.6. Impact on Network Operations 8.6. Impact on Network Operations
Mechanisms defined in [RFC5440], Section 8.6 also apply to PCEP Mechanisms defined in [RFC5440], Section 8.6 also apply to PCEP
extensions defined in this document. Additionally, a PCEP extensions defined in this document. Additionally, a PCEP
implementation SHOULD allow a limit to be placed on the number of implementation SHOULD allow a limit to be placed on the number of
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 review.
Thanks to Dale Worley for a detailed GENART review. Thanks to Dale Worley for a detailed GENART review.
Thanks to Alvaro Retana, Benjamin Kaduk, Suresh Krishnan, Roman
Danyliw, Alissa Cooper and Eric Vyncke for IESG 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 22, line 5 skipping to change at page 22, line 16
Element (PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009, DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>. <https://www.rfc-editor.org/info/rfc5440>.
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
Objective Functions in the Path Computation Element Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC 5541, Communication Protocol (PCEP)", RFC 5541,
DOI 10.17487/RFC5541, June 2009, DOI 10.17487/RFC5541, June 2009,
<https://www.rfc-editor.org/info/rfc5541>. <https://www.rfc-editor.org/info/rfc5541>.
[RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific
Constraints in the Path Computation Element Communication
Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015,
<https://www.rfc-editor.org/info/rfc7470>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231, Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017, DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>. <https://www.rfc-editor.org/info/rfc8231>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>.
[I-D.ietf-pce-association-group] [I-D.ietf-pce-association-group]
Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H.,
Dhody, D., and Y. Tanaka, "Path Computation Element Dhody, D., and Y. Tanaka, "Path Computation Element
Communication Protocol (PCEP) Extensions for Establishing Communication Protocol (PCEP) Extensions for Establishing
Relationships Between Sets of Label Switched Paths Relationships Between Sets of Label Switched Paths
(LSPs)", draft-ietf-pce-association-group-10 (work in (LSPs)", draft-ietf-pce-association-group-10 (work in
progress), August 2019. progress), August 2019.
10.2. Informative References 10.2. Informative References
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006, DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>. <https://www.rfc-editor.org/info/rfc4655>.
[RFC6007] Nishioka, I. and D. King, "Use of the Synchronization [RFC6007] Nishioka, I. and D. King, "Use of the Synchronization
VECtor (SVEC) List for Synchronized Dependent Path VECtor (SVEC) List for Synchronized Dependent Path
Computations", RFC 6007, DOI 10.17487/RFC6007, September Computations", RFC 6007, DOI 10.17487/RFC6007, September
2010, <https://www.rfc-editor.org/info/rfc6007>. 2010, <https://www.rfc-editor.org/info/rfc6007>.
[RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific
Constraints in the Path Computation Element Communication
Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015,
<https://www.rfc-editor.org/info/rfc7470>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>. <https://www.rfc-editor.org/info/rfc8281>.
[I-D.ietf-pce-pcep-yang] [I-D.ietf-pce-pcep-yang]
Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A
YANG Data Model for Path Computation Element YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", draft-ietf-pce-pcep- Communications Protocol (PCEP)", draft-ietf-pce-pcep-
yang-12 (work in progress), July 2019. yang-13 (work in progress), October 2019.
Appendix A. Contributor Addresses Appendix A. Contributor Addresses
Dhruv Dhody Dhruv Dhody
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
 End of changes. 60 change blocks. 
181 lines changed or deleted 194 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/