draft-ietf-pce-association-diversity-15.txt   rfc8800.txt 
PCE Working Group S. Litkowski Internet Engineering Task Force (IETF) S. Litkowski
Internet-Draft S. Sivabalan Request for Comments: 8800 Cisco Systems, Inc.
Intended status: Standards Track Cisco Systems, Inc. Category: Standards Track S. Sivabalan
Expires: December 23, 2020 C. Barth ISSN: 2070-1721 Ciena Corporation
C. Barth
Juniper Networks Juniper Networks
M. Negi M. Negi
RtBrick India RtBrick India
June 21, 2020 July 2020
Path Computation Element Communication Protocol (PCEP) Extension for LSP Path Computation Element Communication Protocol (PCEP) Extension for
Diversity Constraint Signaling Label Switched Path (LSP) Diversity Constraint Signaling
draft-ietf-pce-association-diversity-15
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 Communication Protocol (PCEP) with the purpose of computing
computing diverse (disjointed) paths for those LSPs. The proposed diverse (disjointed) paths for those LSPs. The proposed extension
extension allows a Path Computation Client (PCC) to advertise to a allows a Path Computation Client (PCC) to advertise to a Path
PCE that a particular LSP belongs to a particular disjoint-group, Computation Element (PCE) that a particular LSP belongs to a
thus the PCE knows that the LSPs in the same group need to be particular Disjoint Association Group; thus, the PCE knows that the
disjoint from each other. LSPs in the same group need to be disjoint from each other.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on December 23, 2020. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8800.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivation
4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Applicability
5. Protocol Extension . . . . . . . . . . . . . . . . . . . . . 7 5. Protocol Extension
5.1. Association Group . . . . . . . . . . . . . . . . . . . . 7 5.1. Association Group
5.2. Disjoint TLVs . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Disjoint TLVs
5.3. Disjointness Objective Functions . . . . . . . . . . . . 10 5.3. Disjointness Objective Functions
5.4. Relationship to SVEC . . . . . . . . . . . . . . . . . . 12 5.4. Relationship to SVEC
5.4.1. SVEC and OF . . . . . . . . . . . . . . . . . . . . . 13 5.4.1. SVEC and OF
5.5. P Flag Considerations . . . . . . . . . . . . . . . . . . 13 5.5. P Flag Considerations
5.6. Disjointness Computation Issues . . . . . . . . . . . . . 16 5.6. Disjointness Computation Issues
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations
7.1. Association Type . . . . . . . . . . . . . . . . . . . . 18 7.1. Association Type
7.2. PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . . . 18 7.2. PCEP TLVs
7.3. Objective Functions . . . . . . . . . . . . . . . . . . . 19 7.3. Objective Functions
7.4. NO-PATH-VECTOR Bit Flags . . . . . . . . . . . . . . . . 19 7.4. NO-PATH-VECTOR Bit Flags
7.5. PCEP-ERROR Codes . . . . . . . . . . . . . . . . . . . . 20 7.5. PCEP-ERROR Codes
8. Manageability Considerations . . . . . . . . . . . . . . . . 20 8. Manageability Considerations
8.1. Control of Function and Policy . . . . . . . . . . . . . 20 8.1. Control of Function and Policy
8.2. Information and Data Models . . . . . . . . . . . . . . . 21 8.2. Information and Data Models
8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 21 8.3. Liveness Detection and Monitoring
8.4. Verification of Correct Operations . . . . . . . . . . . 21 8.4. Verification of Correct Operations
8.5. Requirements on Other Protocols . . . . . . . . . . . . . 21 8.5. Requirements on Other Protocols
8.6. Impact on Network Operations . . . . . . . . . . . . . . 21 8.6. Impact on Network Operations
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 9. References
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1. Normative References
10.1. Normative References . . . . . . . . . . . . . . . . . . 22 9.2. Informative References
10.2. Informative References . . . . . . . . . . . . . . . . . 23 Acknowledgments
Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 24 Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses
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 The PCEP Extensions for Stateful PCE Model [RFC8231] describes a set
extensions to PCEP to enable active control of MPLS-TE and GMPLS of extensions to PCEP to enable active control of MPLS-TE and GMPLS
tunnels. [RFC8281] describes the setup and teardown of PCE-initiated tunnels. [RFC8281] describes the setup and teardown of PCE-initiated
LSPs under the active stateful PCE model, without the need for local LSPs under the active stateful PCE model, without the need for local
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 [RFC8697] introduces a generic mechanism to create a grouping of LSPs
create a grouping of LSPs in the context of a PCE which can then be in the context of a PCE that can then be used to define associations
used to define associations between a set of LSPs and a set of between a set of LSPs and a set of attributes (such as configuration
attributes (such as configuration parameters or behaviors) and is parameters or behaviors) and is equally applicable to the active and
equally applicable to the active and passive modes of a stateful PCE passive modes of a stateful PCE [RFC8231] or a stateless PCE
[RFC8231] or a stateless PCE [RFC5440]. [RFC4655].
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 (disjointed) paths, in a particular group should use diverse (disjointed) paths,
including the requested type of diversity. Section 3 and Section 4 including the requested type of diversity. Sections 3 and 4 describe
describe the property and use of a disjoint-group. A PCC can use the property and use of a Disjoint Association Group. A PCC can use
this extension to signal to a PCE that a particular LSP belongs to a this extension to signal to a PCE that a particular LSP belongs to a
particular disjoint-group. When a PCE receives LSP states belonging particular Disjoint Association Group. When a PCE receives LSP
to the same disjoint-group from some PCCs, the PCE should ensure that states belonging to the same Disjoint Association Group from some
the LSPs within the group are disjoint from each other. 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
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Terminology 2. Terminology
The following terminology is used in this document. The following terminology is used in this document.
DAT: Disjoint Association Type. DAT: Disjoint Association Type
DAG: Disjoint Association Group. DAG: Disjoint Association Group
MPLS: Multiprotocol Label Switching. MPLS: Multiprotocol Label Switching
OF: Objective Function. OF: Objective Function
PCC: Path Computation Client. Any client application requesting a PCC: Path Computation Client. Any client application requesting
path computation to be performed by a Path Computation Element. a path computation to be performed by a Path Computation
Element.
PCE: Path Computation Element. An entity (component, application, PCE: Path Computation Element. An entity (component,
or network node) that is capable of computing a network path or application, or network node) that is capable of computing
route based on a network graph and applying computational a network path or route based on a network graph and
constraints. applying computational constraints.
PCEP: Path Computation Element communication Protocol. PCEP: Path Computation Element Communication Protocol
SRLG: Shared Risk Link Group. PLSP-ID: PCEP-specific identifier for the LSP
SRLG: Shared Risk Link Group
3. Motivation 3. Motivation
Path diversity is a very common use case in today's IP/MPLS networks Path diversity is a very common use case in today's IP/MPLS networks,
especially for layer 2 transport over MPLS. A customer may request especially for layer 2 transport over MPLS. A customer may request
that the operator provide two end-to-end disjoint paths across the that the operator provide two end-to-end disjoint paths across the
operator's IP/MPLS core. The customer may use these paths as operator's IP/MPLS core. The customer may use these paths as
primary/backup or active/active configuration. primary/backup or active/active configuration.
Different levels of disjointness may be offered: Different levels of disjointness may be offered:
o Link disjointness: the paths of the associated LSPs should transit * Link disjointness: the paths of the associated LSPs should transit
different links (but may use common nodes or different links that different links (but may use common nodes or different links that
may have some shared fate). may have some shared fate).
o Node disjointness: the paths of the associated LSPs should transit * Node disjointness: the paths of the associated LSPs should transit
different nodes (but may use different links that may have some different nodes (but may use different links that may have some
shared fate). shared fate).
o SRLG disjointness: the paths of the associated LSPs should transit * SRLG disjointness: the paths of the associated LSPs should transit
different links that do not share fate (but may use common transit different links that do not share fate (but may use common transit
nodes). nodes).
o Node+SRLG disjointness: the paths of the associated LSPs should * Node+SRLG disjointness: the paths of the associated LSPs should
transit different links that do not have any common shared fate transit different links that do not have any common shared fate
and should transit different nodes. and should transit different nodes.
The associated LSPs may originate from the same or from different The associated LSPs may originate from the same or different head
head-end(s) and may terminate at the same or different tail-end(s). end(s) and may terminate at the same or different tail end(s).
4. Applicability 4. Applicability
_________________________________________ _________________________________________
/ \ / \
/ +------+ \ / +------+ \
| | PCE | | | | PCE | |
| +------+ | | +------+ |
| | | |
| ***********************> | | ***********************> |
| +------+ 10 +------+ | | +------+ 10 +------+ |
CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2 CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2
| +------+ | | +------+ | | +------+ | | +------+ |
skipping to change at page 5, line 23 skipping to change at line 206
| +------+ | | +------+ | | +------+ | | +------+ |
| | | | | | | |
| | | | | | | |
| +------+ | | +------+ | | +------+ | | +------+ |
CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4 CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4
| +------+ ***********************> +------+ | | +------+ ***********************> +------+ |
| | | |
\ / \ /
\_________________________________________/ \_________________________________________/
Figure 1 - Disjoint paths with different head-ends and tail-ends Figure 1: Disjoint Paths with Different Head Ends and Tail Ends
In the figure above, let us consider that the customer wants to have In the figure above, let us consider that the customer wants to have
two disjoint paths, one between CE1 and CE2 and one between CE3 and two disjoint paths, one between CE1 and CE2 and one between CE3 and
CE4. From an IP/MPLS network point view, in this example, the CEs CE4. From an IP/MPLS network point view, in this example, the CEs
are connected to different PEs to maximize their disjointness. When are connected to different PEs to maximize their disjointness. When
LSPs originate from different head-ends, distributed computation of LSPs originate from different head ends, distributed computation of
diverse paths can be difficult, whereas, computation via a diverse paths can be difficult, whereas computation via a centralized
centralized PCE ensures path disjointness, correctness and PCE ensures path disjointness, correctness, and simplicity.
simplicity.
Section 5.4 describes the relationship between the Disjoint Section 5.4 describes the relationship between the Disjoint
Association Group (DAG) and Synchronization VECtor (SVEC) object. Association Group (DAG) and Synchronization VECtor (SVEC) object.
The PCEP extension for stateful PCE [RFC8231] defined new PCEP The PCEP extension for stateful PCE [RFC8231] defined new PCEP
messages - Path Computation Report (PCRpt), Path Computation Update messages -- Path Computation Report (PCRpt), Path Computation Update
(PCUpd) and Path Computation Initiate (PCInitiate) [RFC8281]. These (PCUpd), and Path Computation Initiate (PCInitiate) [RFC8281]. These
messages use PLSP-ID in the LSP object for identification. Moreover messages use a PLSP-ID in the LSP object for identification.
to allow diversity between LSPs originating from different PCCs, the Moreover, to allow diversity between LSPs originating from different
generic mechanism to create a grouping of LSPs is described in PCCs, the generic mechanism to create a grouping of LSPs that is
[I-D.ietf-pce-association-group] (that is equally applicable to the equally applicable to the active and passive modes of a stateful PCE
active and passive modes of a stateful PCE). is described in [RFC8697].
Using the extension to PCEP defined in this document, the PCC uses Using the extension to PCEP defined in this document, the PCC uses
the [I-D.ietf-pce-association-group] extension to indicate that a the extension defined in [RFC8697] to indicate that a group of LSPs
group of LSPs are required to be disjoint; such indication should are required to be disjoint; such indication should include
include disjointness parameters such as the type of disjointness, the disjointness parameters like the type of disjointness, the Disjoint
disjoint group identifiers, and any customization parameters Association Group identifiers, and any customization parameters
according to the configured local policy. according to the configured local policy.
The management of the disjoint group IDs will be a key point for the The management of the Disjoint Association Group IDs will be a key
operator as the Association ID field is limited to 65535. The local point for the operator as the Association ID field is limited to
configuration of IPv4/IPv6 association source, or Global Association 65535. The local configuration of the IPv4/IPv6 Association Source,
Source/Extended Association ID allows to overcome this limitation as or Global Association Source/Extended Association ID, can overcome
described in [I-D.ietf-pce-association-group]. When a PCC or PCE this limitation, as described in [RFC8697]. 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 Association Group, it
IPv4/IPv6 association source as one of its own IP address. When can set the IPv4/IPv6 Association Source as one of its own IP
disjoint LSPs are initiated from different head-ends, the association address. When disjoint LSPs are initiated from different head ends,
source could be the PCE address or any other unique value to identify the Association Source could be the PCE address or any other unique
the DAG. value to identify the DAG.
Initiate Disjoint LSPs Initiate Disjoint LSPs
| |
| PCReq/PCRpt | PCReq/PCRpt
V {DAG Y} V {DAG Y}
+-----+ ----------------> +-----+ +-----+ ----------------> +-----+
_ _ _ _ _ _| PCE | | | PCE | _ _ _ _ _ _| PCE | | | PCE |
| +-----+ | ----------> +-----+ | +-----+ | ----------> +-----+
| PCInitiate | | PCReq/PCRpt | PCInitiate | | PCReq/PCRpt
|{DAG X} | | {DAG 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|-----( )
{DAG 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 Association
session Group over PCEP Session
Using the disjoint-group within a PCEP messages is used for: The Disjoint Association Group within a PCEP messages is used for:
o Configuration: Used to communicate the configured disjoint * Configuration: Used to communicate the configured disjoint
requirement to a PCEP peer. requirement to a PCEP peer.
o Status: Used to communicate the status of the computed * 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 [RFC8697], LSPs are associated with other LSPs with which they
other LSPs with which they interact by adding them to a common interact by adding them to a common association group. As described
association group. As described in [I-D.ietf-pce-association-group] in [RFC8697], the association group is uniquely identified by the
the association group is uniquely identified by the combination of combination of the following fields in the ASSOCIATION object:
these fields in the ASSOCIATION object: Association Type, Association Association Type, Association ID, Association Source, and (if
ID, Association Source, and (if present) Global Association Source or present) Global Association Source or Extended Association ID.
Extended Association ID.
This document defines a new Association type, based on the generic
Association object:
o Association type = TBD1 Disjoint Association Type (DAT). This document defines a new Association type, called "Disjoint
Association" (2), based on the generic ASSOCIATION object. This new
Association type is also called "DAT", for "Disjoint Association
Type".
[I-D.ietf-pce-association-group] specifies the mechanism for the [RFC8697] specifies the mechanism for the capability advertisement of
capability advertisement of the association types supported by a PCEP the Association types supported by a PCEP speaker by defining an
speaker by defining a ASSOC-Type-List TLV to be carried within an ASSOC-Type-List TLV to be carried within an OPEN object. This
OPEN object. This capability exchange for the DAT (TBD1) MUST be capability exchange for the DAT (2) MUST be done before using the
done before using the disjointness association. Thus the PCEP disjoint association. Thus, the PCEP speaker MUST include the DAT in
speaker MUST include the DAT in the ASSOC-Type-List TLV and MUST the ASSOC-Type-List TLV and MUST receive the same from the PCEP peer
receive the same from the PCEP peer before using the Disjoint 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 [RFC8697], the association group could
association group could be created by the operator manually on the be manually created by the operator on the PCEP peers, and the LSPs
PCEP peers and the LSPs belonging to this associations is conveyed belonging to this association are conveyed via PCEP messages to the
via PCEP messages to the PCEP peer; or the association group could be PCEP peer; alternately, the association group could be created
created dynamically by the PCEP speaker and both the association dynamically by the PCEP speaker, and both the association group
group information and the LSPs belonging to the association group is information and the LSPs belonging to the association group are
conveyed to the PCEP peer. The Operator-configured Association Range conveyed to the PCEP peer. The Operator-configured Association Range
MUST be set for this association-type to mark a range of association MUST be set for this association-type to mark a range of Association
identifiers that are used for operator-configured associations to Identifiers that are used for operator-configured associations to
avoid any association identifier clash within the scope of the avoid any Association Identifier clash within the scope of the
association source. (Refer to [I-D.ietf-pce-association-group].) Association Source. (Refer to [RFC8697].)
A disjoint group can have two or more LSPs, but a PCE may be limited A Disjoint Association Group can have two or more LSPs, but a PCE may
in the number of LSPs it can take into account when computing be limited in the number of LSPs it can take into account when
disjointness. If a PCE receives more LSPs in the group than it can computing disjointness. If a PCE receives more LSPs in the group
handle in its computation algorithm, it SHOULD apply disjointness than it can handle in its computation algorithm, it SHOULD apply
computation to only a subset of LSPs in the group. The subset of disjointness computation to only a subset of LSPs in the group. The
disjoint LSPs will be decided by PCE as a local policy. Local subset of disjoint LSPs will be decided by PCE as a local policy.
polices MAY define the computational behavior for the other LSPs in Local polices MAY define the computational behavior for the other
the group. For example, the PCE may provide no path, a shortest LSPs in the group. For example, the PCE may provide no path, a
path, or a constrained path based on relaxing disjointness, etc. The shortest path, or a constrained path based on relaxing disjointness,
disjoint status of the computed path is informed to the PCC via etc. The disjoint status of the computed path is informed to the PCC
DISJOINTNESS-STATUS-TLV (see Section 5.2). via the DISJOINTNESS-STATUS TLV (see Section 5.2).
There are differet types of disjointness identified by the flags (T, There are different types of disjointness identified by the flags (T,
S, N, L) in the DISJOINTNESS-CONFIGURATION-TLV (see Section 5.2). S, N, and 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 Association Group MUST use the same
of T, S, N, L flags in the DISJOINTNESS-CONFIGURATION-TLV. If a PCEP combination of T, S, N, and L flags in the DISJOINTNESS-CONFIGURATION
peer receives a PCEP messages for LSPs belonging to the same disjoint TLV. If a PCEP peer receives a PCEP message for LSPs belonging to
group but having an inconsistent combination of T, S, N, L flags, the the same Disjoint Association Group but having an inconsistent
PCEP peer MUST NOT add the LSPs to the disjoint group and MUST reply combination of T, S, N, and L flags, the PCEP peer MUST NOT add the
with a PCErr with Error-type 26 (Association Error) and Error-Value 6 LSPs to the Disjoint Association Group and MUST reply with a PCErr
(Association information mismatch). with Error-Type 26 (Association Error) and Error-value 6 (Association
information mismatch).
A particular LSP MAY be associated to the multiple disjoint groups, A particular LSP MAY be associated to multiple Disjoint Association
but 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
groups during path computation if possible. Otherwise a local policy Disjoint Association Groups during path computation, if possible.
MAY define the computational behavior. If a PCE does not support Otherwise, a local policy MAY define the computational behavior. If
such a path computation it MUST NOT add the LSP into the association a PCE does not support such a path computation, it MUST NOT add the
group and return a PCErr with Error-type 26 (Association Error) and LSP into the association group and MUST return a PCErr with Error-
Error-Value 7 (Cannot join the association group). Type 26 (Association Error) and Error-value 7 (Cannot join the
association group).
5.2. Disjoint TLVs 5.2. Disjoint TLVs
The disjoint group (ASSOCIATION object with Association type = TBD1 The Disjoint Association Group (ASSOCIATION object with Association
for DAT) MUST carry the following TLV: type = 2 for DAT) MUST carry the following TLV:
o DISJOINTNESS-CONFIGURATION-TLV: Used to communicate some * DISJOINTNESS-CONFIGURATION TLV: Used to communicate some
disjointness configuration parameters. This is applicable for all disjointness configuration parameters. This is applicable for all
PCEP message that includes DAG. PCEP messages that include DAG.
In addition, the disjoint group (ASSOCIATION object with Association In addition, the Disjoint Association Group (ASSOCIATION object with
type = TBD1 for DAT) MAY carry the following TLVs: Association type = 2 for DAT) MAY carry the following TLVs:
o DISJOINTNESS-STATUS-TLV: Used to communicate the status of the * DISJOINTNESS-STATUS TLV: Used to communicate the status of the
computed disjointness. This is applicable for messages from a PCE computed disjointness. This is applicable for messages from a PCE
to a PCC only (i.e. PCUpd, PCInitiate or PCRep message). to a PCC only (i.e., PCUpd, PCInitiate, or PCRep messages).
o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor- * 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 * 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 = 46 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |T|P|S|N|L| | Flags |T|P|S|N|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD2. Figure 3: DISJOINTNESS-CONFIGURATION TLV
Length: Fixed value of 4 bytes. Type: 46
Flags: Length: Fixed value of 4 bytes.
* L (Link diverse) bit: when set, this indicates that the Flags:
computed paths within the disjoint group MUST NOT have any link
in common.
* N (Node diverse) bit: when set, this indicates that the L (Link Diverse) bit: When set, this indicates that the computed
computed paths within the disjoint group MUST NOT have any node paths within the Disjoint Association Group MUST NOT have any
in common. link in common.
* S (SRLG diverse) bit: when set, this indicates that the N (Node Diverse) bit: When set, this indicates that the computed
computed paths within the disjoint group MUST NOT share any paths within the Disjoint Association Group MUST NOT have any
node in common.
S (SRLG Diverse) bit: When set, this indicates that the computed
paths within the Disjoint Association 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
computed path of the LSP SHOULD satisfy all the constraints and 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 as if the disjointness the association group are computed first, as if the
constraint has not been configured, and then with those LSPs disjointness constraint has not been configured; then, with
fixed, the other LSPs with P flag unset in the association those LSPs fixed, the other LSPs with P flag unset in the
group are computed by taking into account the disjointness association group are computed by taking into account the
constraint. The role of P flag is further described with disjointness constraint. The role of P flag is further
examples in Section 5.5. 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 MUST return no path for LSPs that could not be be be found, the PCE MUST return no path for LSPs that could not
disjoint. When unset, the PCE is allowed to relax disjointness be disjoint. When unset, the PCE is allowed to relax
by Section 5.5 either applying a requested objective function disjointness by either applying a requested objective function
(cf. Section 5.3 below) or using the local policy if no (cf. Section 5.3) or using the local policy if no objective
objective function is requested (e.g. using a lower disjoint function is requested (e.g., using a lower disjoint type (link
type (link instead of node) or fully relaxing disjointness instead of node) or fully relaxing disjointness constraint).
constraint). Further see Section 5.6 for details. See Section 5.6 for further details.
* Unassigned bits are considered reserved. They MUST be set to 0 Unassigned bits: Unassigned bits are considered reserved. They
on transmission and MUST be ignored on receipt. MUST be set to 0 on transmission and MUST be ignored on
receipt.
If a PCEP speaker receives a disjoint-group (ASSOCIATION object with If a PCEP speaker receives a Disjoint Association Group (ASSOCIATION
Association type = TBD1 for DAT) without DISJOINTNESS-CONFIGURATION- object with Association type = 2 for DAT) without the DISJOINTNESS-
TLV, it SHOULD reply with a PCErr Error-type=6 (Mandatory Object CONFIGURATION TLV, it SHOULD reply with a PCErr Error-Type 6
missing) and Error-value=TBD10 (DISJOINTNESS-CONFIGURATION-TLV (Mandatory Object missing) and Error-value 15 (DISJOINTNESS-
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 47 (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
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 with the same name and in the TLV automatically defines a new flag with the same name and in the
same location in DISJOINTNESS-STATUS-TLV; the semantics of the flag same location in DISJOINTNESS-STATUS TLV; the semantics of the flag
in DISJOINTNESS-STATUS-TLV MUST be specified in the document that in the DISJOINTNESS-STATUS TLV MUST be specified in the document that
specifies the flag in DISJOINTNESS-CONFIGURATION-TLV. specifies the flag in the 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 object. Whereas the PCEP OF-List TLV allows multiple OF-
multiple OF-codes inside the TLV, a sender SHOULD include a single codes inside the TLV, a sender SHOULD include a single OF-code in the
OF-code in the OF-List TLV when included in the Association Group, OF-List TLV when included in the Association Group, and the receiver
and the receiver MUST consider the first OF-code only and ignore MUST consider the first OF-code only and ignore others if included.
others if included.
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: defined:
MSL MSL
* Name: Minimize the number of shared (common) Links. Name: Minimize the number of Shared (common) Links.
Objective Function Code: 15
* 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 network comprises a set of N links {Li, (i=1...N)}. - A set of paths {P1...Pm} have L links that are common to
more than one path {Lci,(i=1...L)}.
* A path P passes through K links {Lpi,(i=1...K)}. - Find a set of paths such that the value of L is minimized.
* A set of paths {P1...Pm} have L links that are common to more
than one path {Lci,(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: 16
* Objective Function Code: TBD5 Description: Find a set of paths such that it passes through the
least number of shared (common) SRLGs.
* Description: Find a set of paths such that it passes through the - A network comprises a set of N links {Li, (i=1...N)}.
least number of shared (common) SRLGs. - A path P passes through K links {Lpi,(i=1...K)} belonging to
unique M SRLGs {Spi,(i=1..M)}.
* A network comprises a set of N links {Li, (i=1...N)}. - A set of paths {P1...Pm} have L SRLGs that are common to
more than one path {Sci,(i=1...L)}.
* A path P passes through K links {Lpi,(i=1...K)} belonging to - Find a set of paths such that the value of L is minimized.
unique M SRLGs {Spi,(i=1..M)}.
* A set of paths {P1...Pm} have L SRLGs that are common to more
than one path {Sci,(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: 17
* Objective Function Code: TBD6 Description: Find a set of paths such that they pass through the
least number of shared (common) nodes.
* Description: Find a set of paths such that they pass through the - A network comprises a set of N nodes {Ni, (i=1...N)}.
least number of shared (common) nodes. - A path P passes through K nodes {Npi,(i=1...K)}.
- A set of paths {P1...Pm} have L nodes that are common to
* A network comprises a set of N nodes {Ni, (i=1...N)}. more than one path {Nci,(i=1...L)}.
- Find a set of paths such that the value of L is minimized.
* 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 {Nci,(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 first If the OF-List TLV is included in the ASSOCIATION object, the first
OF-code inside the OF Object MUST be one of the disjoint OFs defined OF-code inside the OF object MUST be one of the disjoint OFs defined
in this document. If this condition is not met, the PCEP speaker in this document. If this condition is not met, the PCEP speaker
MUST respond with a PCErr message with Error-Type=10 (Reception of an 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 32 (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, which specifies
the list of synchronized requests that can either be dependent or the list of synchronized requests that can be either 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 the RP (Request Parameters) object. [RFC6007] further clarifies
use of the SVEC list for synchronized path computations when the use of the SVEC list for synchronized path computations when
computing dependent requests as well as described a number of usage computing dependent requests and describes 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 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 Path Computation Request (PCReq)
and ASSOCIATION objects to identify the related path computation message MAY use both the SVEC and ASSOCIATION objects to identify the
request as well as the DAG. The PCE MUST try to find a path that related path computation request, as well as the DAG. The PCE MUST
meets both the constraints. It is possible that the diversity try to find a path that meets both the constraints. It is possible
requirement in the association group is different from the one in the that the diversity requirement in the association group is different
SVEC object. The PCE MUST consider both the objects (including the from the one in the SVEC object. The PCE MUST consider both the
flags set inside the objects) as per the processing rules and aim to objects (including the flags set inside the objects) as per the
find a path that meets both of these constraints. In case no such processing rules and aim to find a path that meets both of these
path is possible, the PCE MUST send a path computation reply (PCRep) constraints. In case no such path is possible, the PCE MUST send a
with a NO-PATH object indicating path computation failure as per Path Computation Reply (PCRep) with a NO-PATH object indicating path
[RFC5440]. It should be noted that the LSPs in the association group computation failure, as per [RFC5440]. It should be noted that the
can be fully same or partially overlapping with the LSPs grouped by LSPs in the association group can be fully same or partially
the SVEC object in PCReq message. overlapping with the LSPs grouped by 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 * 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 and LSP2.
o PCReq with SVEC object with link-diverse bit=1 (LSP1,LSP2) and DAG * PCReq with SVEC object with link-diverse bit=1 (LSP1,LSP2) and DAG
with L=1 (LSP1,LSP3) - link diverse paths between LSP1 & LSP2, and with L=1 (LSP1,LSP3) - link-diverse paths between LSP1 and LSP2
LSP1 & LSP3. If the DAG is part of the stateful database, any and between LSP1 and LSP3. If the DAG is part of the stateful
future change in LSP3 will have an impact on LSP1. But any future database, any future change in LSP3 will have an impact on LSP1.
change in LSP2 will have no impact on LSP1, as LSP2 is part of But any future change in LSP2 will have no impact on LSP1, as LSP2
SVEC object (which is considered once on receipt of the PCReq is part of SVEC object (which is considered once on receipt of the
message only). PCReq message only).
5.4.1. SVEC and OF 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 in 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 shared resources (Node, Link specification of minimization of common shared resources (Node, 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. * 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 * SVEC object with node-diverse bit=1 and OF=MSS - full node
with as much as SRLG-diversity as possible. diversity with as much SRLG diversity as possible.
o SVEC object with domain-diverse bit=1;link diverse bit=1 and * SVEC object with domain-diverse bit=1 [RFC8685]; node-diverse
OF=MSS - full domain and node diverse path with as much as SRLG- bit=1, and OF=MSS - full domain and node diversity with as much
diversity as possible. SRLG diversity as possible.
o SVEC object with node-diverse bit=1 and OF=MSN - ensure full node- * SVEC object with node-diverse bit=1 and OF=MSN - ensure full node
diversity. diversity.
In the last example above, it is interesting to note that "OF" In the last example above, it is interesting to note that "OF"
becomes redundant as "SVEC object" ensures full node-diversity, becomes redundant as "SVEC object" ensures full node diversity;
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 satisfy all constraints and objective
objective functions first without considering the diversity 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 the P flag set should be placed first, as
the disjointness constraint has not been configured, while the other if the disjointness constraint has not been configured, while the
LSPs in the association with P flag unset should be placed by taking other LSPs in the association with the P flag unset should be placed
into account the disjointness constraint. Setting the P flag changes by taking into account the disjointness constraint. Setting the P
the relationship between LSPs to a one-sided relationship (LSP 1 with flag changes the relationship between LSPs to a one-sided
P=0 depends on LSP 2 with P=1, but LSP 2 with P=1 does not depend of relationship (LSP 1 with P=0 depends on LSP 2 with P=1, but LSP 2
LSP 1 with P=0). Multiple LSPs in the same disjoint group may have with P=1 does not depend on LSP 1 with P=0). Multiple LSPs in the
the P flag set. In such a case, those LSPs may not be disjoint from same Disjoint Association Group may have the P flag set. In such a
each other but will be disjoint from other LSPs in the group that case, those LSPs may not be disjoint from each other but will be
have the P flag unset. disjoint from other LSPs in the group that 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 Association Group (for
primary path) while other paths are allowed to be costlier (compared instance, the primary path), while other paths are allowed to be
to a similar path without the disjointness constraint). Without such costlier (compared to a similar path without the disjointness
a hint, the disjointness algorithm may set a path for all LSPs that constraint). Without such a hint, the disjointness algorithm may set
may not completely fulfill the customer's requirement. a path for all LSPs that may not completely fulfill the customer's
requirement.
_________________________________________ _________________________________________
/ \ / \
/ +------+ \ / +------+ \
| | PCE | | | | PCE | |
| +------+ | | +------+ |
| | | |
| | | |
| +------+ 10 +------+ | | +------+ 10 +------+ |
CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2 CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2
| +------+ | | +------+ | | +------+ | | +------+ |
| | | | | | | |
| | | | | | | |
| +------+ | | +------+ | | +------+ | | +------+ |
CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4 CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4
| +------+ \ | / +------+ | | +------+ \ | / +------+ |
| \ | 10 / | | \ | 10 / |
\ +-- R5 --------- R6 / \ +-- R5 --------- R6 /
\_________________________________________/ \_________________________________________/
Cost of all the links is 1, unless explicitly marked otherwise. Figure 4: Example Topology with Six Internal Routers
Figure 3 Note: In Figure 4, the cost of all the links is 1, unless explicitly
marked otherwise.
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 link 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 the primary (and CE3 and CE4 are hosted
remote site for redundancy purpose). in a 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
link disjoint LSPs together, leading to PE1->PE2 using a path link disjoint LSPs together, leading to PE1->PE2 using 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
not requested. was 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 link disjoint from this path. The second LSP other LSP should be link disjoint from this path. The second LSP
will be 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 a 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 finding 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 router R5 is down and 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
link disjointness constraint cannot be fulfilled). If PE1->PE2 has link disjointness constraint cannot be fulfilled). If PE1->PE2 has
the P flag unset, the algorithm may be able to place PE1->PE2 on the P flag unset, the algorithm may be able to place PE1->PE2 on the
R1->R2 link leaving a room for PE3->PE4 using the R3->R4 link. When R1->R2 link leaving room for PE3->PE4 using the R3->R4 link. When
using P flag or any additional constraint on top of the disjointness using the P flag or any additional constraint on top of the
constraint, the user should be aware that there is less chance to disjointness constraint, the user should be aware that there is less
fulfill the disjointness constraint. chance to fulfill the disjointness constraint.
_________________________________________ _________________________________________
/ \ / \
/ +------+ \ / +------+ \
| | PCE | | | | PCE | |
| +------+ | | +------+ |
| | | |
| | | |
| +------+ 10 +------+ | | +------+ 10 +------+ |
CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2 CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2
| +------+ | \ | +------+ | | +------+ | \ | +------+ |
| | \2 | | | | \2 | |
| | \ | | | | \ | |
| +------+ | \ | +------+ | | +------+ | \ | +------+ |
CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4 CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4
| +------+ +------+ | | +------+ +------+ |
| | | |
\ / \ /
\_________________________________________/ \_________________________________________/
Cost of all the links is 1, unless explicitly marked otherwise. Figure 5: Example Topology with Four Internal Routers
Figure 4 Note: In Figure 5, the cost of all the links is 1, unless explicitly
marked otherwise.
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 link 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 link disjointness. In our example, picking up one path may prevent link disjointness. In our example,
if path 2 is used for PE1->PE2, there is no room left for PE3->PE4 if path 2 is used for PE1->PE2, there is no room left for PE3->PE4,
while 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 the 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), if disjointness cannot
disjointness cannot be ensured for one or more LSPs, the PCE MUST be ensured for one or more LSPs, the PCE MUST reply to a PCReq with a
reply to a Path Computation Request (PCReq) with a Path Computation PCRep message containing a NO-PATH object. In case of a 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 a 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, Explicit Route Object (ERO) to the corresponding PCCs. In addition
the PCE MAY add the NO-PATH-VECTOR TLV ([RFC5440]) in the LSP Object. to the empty ERO 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 Flags field of the NO-PATH-VECTOR
TLV:
bit "TBD7": when set, the PCE indicates that it could not find a * bit 11: 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 10: When set, the PCE indicates that it does not support the
the requested disjointness computation. requested disjointness computation.
When the T flag is unset, the PCE is allowed to relax disjointness by When the T flag is unset, the PCE is allowed to relax disjointness by
applying a requested objective function (Section 5.3) if specified. applying a requested objective function (Section 5.3) if specified.
Otherwise, if no objective function is specified, the PCE is allowed Otherwise, if no objective function is specified, the PCE is allowed
to reduce the required level of disjointness as it deems fit. The to reduce the required level of disjointness as it deems fit. The
actual level of disjointness of the paths computed by the PCE can be actual level of disjointness of the paths computed by the PCE can be
reported through the DISJOINTNESS-STATUS-TLV by setting the reported through the DISJOINTNESS-STATUS TLV by setting the
appropriate flags in the TLV. While the DISJOINTNESS-CONFIGURATION- appropriate flags in the TLV. While the DISJOINTNESS-CONFIGURATION
TLV defines the desired level of disjointness required by TLV defines the desired level of disjointness required by
configuration, the DISJOINTNESS-STATUS-TLV defines the achieved level configuration, the DISJOINTNESS-STATUS TLV defines the achieved level
of disjointness computed. 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. See consequence, it is considered out of scope of the document. See
[I-D.dhody-pce-stateful-pce-optional] for a proposed mechanism. [PCE-OPTIONAL] for a proposed mechanism.
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 by 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], [RFC7470] and [I-D.ietf-pce-association-group]. [RFC5440], [RFC8231], [RFC7470], and [RFC8697]. But adding of a
But, adding of a spurious LSP into the disjointness association group spurious LSP into the Disjoint Association Group could lead to
could lead to re-computation and set-up of all LSPs in the group, recomputation and setup of all LSPs in the group, which could be used
that could be used to overwhelm the PCE and the network. 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. Also, certain combinations of legitimate LSPs to fail with an error. Also, certain combinations of
flags (notably, the 'T' bit) can result in conflicts that cannot be flags (notably, the 'T' bit) can result in conflicts that cannot be
resolved. resolved.
Also, as stated in [I-D.ietf-pce-association-group], much of the Also, as stated in [RFC8697], much of the information carried in the
information carried in the Disjointness Association object reflects ASSOCIATION object reflects information that can also be derived from
information that can also be derived from the LSP Database, but the LSP database, but association provides a much easier grouping of
association provides a much easier grouping of related LSPs and related LSPs and messages. This holds true for the DAT as well;
messages. The disjointness association could provide an adversary thus, this could provide an adversary with the opportunity to
with the opportunity to eavesdrop on the relationship between the eavesdrop on the relationship between the LSPs and understand the
LSPs and understand the network topology. 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 [RFC8697]. IANA has assigned the following new value in the
assignment of a new value for the sub-registry "ASSOCIATION Type "ASSOCIATION Type Field" subregistry [RFC8697] within the "Path
Field" (request to be created in [I-D.ietf-pce-association-group]), Computation Element Protocol (PCEP) Numbers" registry:
as follows:
+------------------+---------------------------------+--------------+ +======+======================+===========+
| Association type | Association Name | Reference | | Type | Name | Reference |
+------------------+---------------------------------+--------------+ +======+======================+===========+
| TBD1 | Disjointness Association Type | [This.I-D] | | 2 | Disjoint Association | RFC 8800 |
+------------------+---------------------------------+--------------+ +------+----------------------+-----------+
Table 1: ASSOCIATION Type Field
7.2. PCEP TLVs 7.2. PCEP TLVs
This document defines the following new PCEP TLVs and the IANA is This document defines two new PCEP TLVs. IANA has assigned the
requested to make the assignment of new values for the existing "PCEP following values in the "PCEP TLV Type Indicators" subregistry within
TLV Type Indicators" registry as follows: the "Path Computation Element Protocol (PCEP) Numbers" registry:
+----------+----------------------------------+--------------+ +==========+============================+===========+
| TLV Type | TLV Name | Reference | | TLV Type | TLV Name | Reference |
+----------+----------------------------------+--------------+ +==========+============================+===========+
| TBD2 | Disjointness Configuration TLV | [This.I-D] | | 46 | DISJOINTNESS-CONFIGURATION | RFC 8800 |
| TBD3 | Disjointness Status TLV | [This.I-D] | +----------+----------------------------+-----------+
+----------+----------------------------------+--------------+ | 47 | DISJOINTNESS-STATUS | RFC 8800 |
+----------+----------------------------+-----------+
This document requests that a new sub-registry, named "Disjointness Table 2: PCEP TLV Type Indicators
Configuration TLV Flag Field", is created within the "Path
Computation Element Protocol (PCEP) Numbers" registry to manage the
Flag field in the Disjointness Configuration TLV. New values are to
be assigned by Standards Action [RFC8126]. Each bit should be
tracked with the following qualities:
o Bit number (count from 0 as the most significant bit) IANA has created a new subregistry, named "DISJOINTNESS-CONFIGURATION
TLV Flag Field", within the "Path Computation Element Protocol (PCEP)
Numbers" registry to manage the Flags field in the DISJOINTNESS-
CONFIGURATION TLV. New values are to be assigned by Standards Action
[RFC8126]. Each bit should be tracked with the following qualities:
o Flag Name * Bit number (count from 0 as the most significant bit)
o Reference * Flag Name
+------------+-------------------------+--------------+ * Reference
| Bit Number | Name | Reference |
+------------+-------------------------+--------------+
| 31 | L - Link Diverse | [This.I-D] |
| 30 | N - Node Diverse | [This.I-D] |
| 29 | S - SRLG Diverse | [This.I-D] |
| 28 | P - Shortest Path | [This.I-D] |
| 27 | T - Strict Disjointness | [This.I-D] |
+------------+-------------------------+--------------+
Table 1: Disjointness Configuration TLV The initial contents of this subregistry are shown below:
+======+=========================+===========+
| Bit | Name | Reference |
+======+=========================+===========+
| 31 | L - Link Diverse | RFC 8800 |
+------+-------------------------+-----------+
| 30 | N - Node Diverse | RFC 8800 |
+------+-------------------------+-----------+
| 29 | S - SRLG Diverse | RFC 8800 |
+------+-------------------------+-----------+
| 28 | P - Shortest Path | RFC 8800 |
+------+-------------------------+-----------+
| 27 | T - Strict Disjointness | RFC 8800 |
+------+-------------------------+-----------+
| 0-26 | Unassigned | |
+------+-------------------------+-----------+
Table 3: DISJOINTNESS-CONFIGURATION TLV
Flag Field
7.3. Objective Functions 7.3. Objective Functions
Three new Objective Functions have been defined in this document. This document defines three new objective functions. IANA has made
IANA is requested to make the following allocations from the PCEP the following allocations in the "Objective Function" subregistry
"Objective Function" sub-registry: within the "Path Computation Element Protocol (PCEP) Numbers"
registry:
+------------+---------------------------------------+--------------+ +============+=======================+===========+
| Code Point | Name | Reference | | Code Point | Name | Reference |
+------------+---------------------------------------+--------------+ +============+=======================+===========+
| TBD4 | Minimize the number of shared Links | [This.I-D] | | 15 | Minimize the number | RFC 8800 |
| | (MSL) | | | | of Shared Links (MSL) | |
| TBD5 | Minimize the number of shared SRLGs | [This.I-D] | +------------+-----------------------+-----------+
| | (MSS) | | | 16 | Minimize the number | RFC 8800 |
| TBD6 | Minimize the number of shared Nodes | [This.I-D] | | | of Shared SRLGs (MSS) | |
| | (MSN) | | +------------+-----------------------+-----------+
+------------+---------------------------------------+--------------+ | 17 | Minimize the number | RFC 8800 |
| | of Shared Nodes (MSN) | |
+------------+-----------------------+-----------+
Table 4: Objective Function
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 document defines new bits for the NO-PATH-VECTOR TLV in the "NO-
"NO-PATH-VECTOR TLV Flag Field" sub-registry of the "Path Computation PATH-VECTOR TLV Flag Field" subregistry of the "Path Computation
Element Protocol (PCEP) Numbers" registry. IANA is requested to make Element Protocol (PCEP) Numbers" registry. IANA has made the
the following allocation: following allocations:
+-----------+-----------------------------------------+-------------+ +============+===========================+===========+
| Bit | Name | Reference | | Bit Number | Name | Reference |
| Number | | | +============+===========================+===========+
+-----------+-----------------------------------------+-------------+ | 11 | Disjoint path not found | RFC 8800 |
| TBD7 | Disjoint path not found | [This.I-D] | +------------+---------------------------+-----------+
| TBD8 | Requested disjoint computation not | [This.I-D] | | 10 | Requested disjoint | RFC 8800 |
| | supported | | | | computation not supported | |
+-----------+-----------------------------------------+-------------+ +------------+---------------------------+-----------+
Table 2: NO-PATH-VECTOR TLV Table 5: NO-PATH-VECTOR TLV Flag Field
7.5. PCEP-ERROR Codes 7.5. PCEP-ERROR Codes
This document defines new Error-Value within existing Error-Type This document defines two new Error-values within existing Error-
related to path protection association. IANA is requested to Types related to disjoint association. IANA has allocated the
allocate new error values within the "PCEP-ERROR Object Error Types following new Error-values in the "PCEP-ERROR Object Error Types and
and Values" sub-registry of the PCEP Numbers registry, as follows: Values" subregistry within the "Path Computation Element Protocol
(PCEP) Numbers" registry:
+----------+-------------------------+------------------------------+ +============+===========+============================+===========+
| Error- | Meaning | Reference | | Error-Type | Meaning | Error-value | Reference |
| Type | | | +============+===========+============================+===========+
+----------+-------------------------+------------------------------+ | 6 | Mandatory | | [RFC5440] |
| 6 | Mandatory Object | [I-D.ietf-pce-association-gr | | | Object | | |
| | missing | oup] | | | missing | | |
| | Error-value=TBD10: | [This.I-D] | +------------+-----------+----------------------------+-----------+
| | DISJOINTNESS- | | | | | 15: DISJOINTNESS- | RFC 8800 |
| | CONFIGURATION TLV | | | | | CONFIGURATION TLV missing | |
| | missing | | +------------+-----------+----------------------------+-----------+
| 10 | Reception of an | [RFC5440] | | 10 | Reception | | [RFC5440] |
| | invalid object | | | | of an | | |
| | Error-value=TBD9: | [This.I-D] | | | invalid | | |
| | Incompatible OF code | | | | object | | |
+----------+-------------------------+------------------------------+ +------------+-----------+----------------------------+-----------+
| | | 32: Incompatible OF code | RFC 8800 |
+------------+-----------+----------------------------+-----------+
Table 6: PCEP-ERROR Object Error Types and Values
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 Disjoint Association
association groups and disjoint parameters at the PCEP peers and Groups and disjoint parameters at the PCEP peers and associate them
associate it with the LSPs. The Operator-configured Association with the LSPs. The operator MUST be allowed to set the Operator-
Range MUST be allowed to be set by the operator. The operator SHOULD configured Association Range. The operator SHOULD be allowed to set
be allowed to set the local policies to define various disjoint the local policies to define various disjoint computational behavior
computational behavior at the PCE. 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. Furthermore, associations configured or created dynamically. Furthermore,
implementations SHOULD allow to view disjoint associations reported implementations SHOULD allow to view disjoint associations reported
by each peer, and the current set of LSPs in this association. The by each peer and the current set of LSPs in this association. The
PCEP YANG module [I-D.ietf-pce-pcep-yang] includes association groups PCEP YANG module [PCEP-YANG] includes association group 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
Apart from the operation verification requirements already listed in Apart from the operation verification requirements already listed in
[RFC5440], a PCEP implementation SHOULD provide parameters related to [RFC5440], a PCEP implementation SHOULD provide parameters related to
disjoint path computation, such as number of DAG, number of disjoint disjoint path computation, such as number of DAG, number of disjoint
path computation failures etc. A PCEP implementation SHOULD log path computation failures, etc. A PCEP implementation SHOULD log
failure events (e.g., incompatible Flags). 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 Section 8.6 of [RFC5440] 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. References
A special thanks to authors of [I-D.ietf-pce-association-group], this
document borrow some of the text from it. Authors would also like to
thank Adrian Farrel and Julien Meuric for the valuable comments.
Thanks to Emmanuel Baccelli for RTGDIR 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.1. Normative References 9.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
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
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 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific
Constraints in the Path Computation Element Communication Constraints in the Path Computation Element Communication
Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015,
<https://www.rfc-editor.org/info/rfc7470>. <https://www.rfc-editor.org/info/rfc7470>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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, [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the "PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)", Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017, RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>. <https://www.rfc-editor.org/info/rfc8253>.
[I-D.ietf-pce-association-group] [RFC8685] Zhang, F., Zhao, Q., Gonzalez de Dios, O., Casellas, R.,
Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., and D. King, "Path Computation Element Communication
Protocol (PCEP) Extensions for the Hierarchical Path
Computation Element (H-PCE) Architecture", RFC 8685,
DOI 10.17487/RFC8685, December 2019,
<https://www.rfc-editor.org/info/rfc8685>.
[RFC8697] 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)", RFC 8697, DOI 10.17487/RFC8697, January 2020,
progress), August 2019. <https://www.rfc-editor.org/info/rfc8697>.
10.2. Informative References 9.2. Informative References
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [PCE-OPTIONAL]
Element (PCE)-Based Architecture", RFC 4655, Li, C., Zheng, H., and S. Litkowski, "Extension for
Stateful PCE to allow Optional Processing of PCEP
Objects", Work in Progress, Internet-Draft, draft-dhody-
pce-stateful-pce-optional-06, 9 July 2020,
<https://tools.ietf.org/html/draft-dhody-pce-stateful-pce-
optional-06>.
[PCEP-YANG]
Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A
YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", Work in Progress,
Internet-Draft, draft-ietf-pce-pcep-yang-14, 7 July 2020,
<https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-14>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation 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>.
[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>.
[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] Acknowledgments
Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A
YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", draft-ietf-pce-pcep-
yang-13 (work in progress), October 2019.
[I-D.dhody-pce-stateful-pce-optional] A special thanks to the authors of [RFC8697]; this document borrows
Li, C., Zheng, H., and S. Litkowski, "Extension for some text from it. The authors would also like to thank Adrian
Stateful PCE to allow Optional Processing of PCEP Farrel and Julien Meuric for the valuable comments.
Objects", draft-dhody-pce-stateful-pce-optional-05 (work
in progress), January 2020.
Appendix A. Contributor Addresses Thanks to Emmanuel Baccelli for the RTGDIR review.
Thanks to Dale Worley for a detailed GENART review.
Thanks to Alvaro Retana, Benjamin Kaduk, Suresh Krishnan, Roman
Danyliw, Alissa Cooper, and Éric Vyncke for the IESG review.
Contributors
Dhruv Dhody Dhruv Dhody
Huawei Technologies Huawei Technologies
Divyashree Techno Park, Whitefield Divyashree Techno Park, Whitefiled
Bangalore, Karnataka 560066 Bangalore 560066
Karnataka
India India
EMail: dhruv.ietf@gmail.com Email: dhruv.ietf@gmail.com
Authors' Addresses Authors' Addresses
Stephane Litkowski Stephane Litkowski
Cisco Systems, Inc. Cisco Systems, Inc.
EMail: slitkows.ietf@gmail.com Email: slitkows.ietf@gmail.com
Siva Sivabalan Siva Sivabalan
Cisco Systems, Inc. Ciena Corporation
2000 Innovation Drive
Kanata, Ontario K2K 3E8
Canada
EMail: msiva@cisco.com Email: msiva282@gmail.com
Colby Barth Colby Barth
Juniper Networks Juniper Networks
EMail: cbarth@juniper.net Email: cbarth@juniper.net
Mahendra Singh Negi Mahendra Singh Negi
RtBrick India RtBrick India
N-17L, Floor-1, 18th Cross Rd, HSR Layout Sector-3 N-17L, Floor-1, 18th Cross Rd, HSR Layout Sector-3
Bangalore, Karnataka 560102 Bangalore 560102
Karnataka
India India
EMail: mahend.ietf@gmail.com Email: mahend.ietf@gmail.com
 End of changes. 164 change blocks. 
574 lines changed or deleted 593 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/