draft-ietf-pce-association-diversity-10.txt   draft-ietf-pce-association-diversity-11.txt 
PCE Working Group S. Litkowski PCE Working Group S. Litkowski
Internet-Draft Orange Internet-Draft Orange
Intended status: Standards Track S. Sivabalan Intended status: Standards Track S. Sivabalan
Expires: March 2, 2020 Cisco Systems, Inc. Expires: April 30, 2020 Cisco Systems, Inc.
C. Barth C. Barth
Juniper Networks Juniper Networks
M. Negi M. Negi
Huawei Technologies Huawei Technologies
August 30, 2019 October 28, 2019
Path Computation Element Communication Protocol (PCEP) Extension for LSP Path Computation Element Communication Protocol (PCEP) Extension for LSP
Diversity Constraint Signaling Diversity Constraint Signaling
draft-ietf-pce-association-diversity-10 draft-ietf-pce-association-diversity-11
Abstract Abstract
This document introduces a simple mechanism to associate a group of This document introduces a simple mechanism to associate a group of
Label Switched Paths (LSPs) via an extension to the Path Computation Label Switched Paths (LSPs) via an extension to the Path Computation
Element (PCE) communication Protocol (PCEP) with the purpose of Element (PCE) communication Protocol (PCEP) with the purpose of
computing diverse paths for those LSPs. The proposed extension computing diverse paths for those LSPs. The proposed extension
allows a Path Computation Client (PCC) to advertise to a PCE that a allows a Path Computation Client (PCC) to advertise to a PCE that a
particular LSP belongs to a disjoint-group, thus the PCE knows that particular LSP belongs to a particular disjoint-group, thus the PCE
the LSPs in the same group need to be disjoint from each other. knows that the 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 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 March 2, 2020. This Internet-Draft will expire on April 30, 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 25 skipping to change at page 2, line 25
Table of Contents Table of Contents
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. Relationship to SVEC . . . . . . . . . . . . . . . . . . 10 5.3. Disjointness Objective Functions . . . . . . . . . . . . 10
5.4. Disjointness Objective functions . . . . . . . . . . . . 10 5.4. Relationship to SVEC . . . . . . . . . . . . . . . . . . 11
5.5. P Flag Considerations . . . . . . . . . . . . . . . . . . 12 5.5. P Flag Considerations . . . . . . . . . . . . . . . . . . 12
5.6. Disjointness Computation Issues . . . . . . . . . . . . . 15 5.6. Disjointness Computation Issues . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7.1. Association Type . . . . . . . . . . . . . . . . . . . . 16 7.1. Association Type . . . . . . . . . . . . . . . . . . . . 17
7.2. PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . . . 17 7.2. PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . . . 17
7.3. Objective Functions . . . . . . . . . . . . . . . . . . . 18 7.3. Objective Functions . . . . . . . . . . . . . . . . . . . 18
7.4. NO-PATH-VECTOR Bit Flags . . . . . . . . . . . . . . . . 18 7.4. NO-PATH-VECTOR Bit Flags . . . . . . . . . . . . . . . . 18
7.5. PCEP-ERROR Codes . . . . . . . . . . . . . . . . . . . . 18 7.5. PCEP-ERROR Codes . . . . . . . . . . . . . . . . . . . . 19
8. Manageability Considerations . . . . . . . . . . . . . . . . 19 8. Manageability Considerations . . . . . . . . . . . . . . . . 19
8.1. Control of Function and Policy . . . . . . . . . . . . . 19 8.1. Control of Function and Policy . . . . . . . . . . . . . 19
8.2. Information and Data Models . . . . . . . . . . . . . . . 19 8.2. Information and Data Models . . . . . . . . . . . . . . . 20
8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 19 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 20
8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 19 8.4. Verification of Correct Operations . . . . . . . . . . . 20
8.5. Requirements On Other Protocols . . . . . . . . . . . . . 20 8.5. Requirements on Other Protocols . . . . . . . . . . . . . 20
8.6. Impact On Network Operations . . . . . . . . . . . . . . 20 8.6. Impact on Network Operations . . . . . . . . . . . . . . 20
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . 20 10.1. Normative References . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 23 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
[RFC5440] describes the Path Computation Element communication [RFC5440] describes the Path Computation Element communication
skipping to change at page 3, line 25 skipping to change at page 3, line 25
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 [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 particular This document specifies a PCEP extension to signal that a set of LSPs
group of LSPs should use diverse paths including the requested type in a particular group should use diverse paths, including the
of diversity. A PCC can use this extension to signal to a PCE that a requested type of diversity. A PCC can use this extension to signal
particular LSP belongs to a disjoint-group. When a PCE receives LSP to a PCE that a particular LSP belongs to a particular disjoint-
states belonging to the same disjoint-group from some PCCs, the PCE group. When a PCE receives LSP states belonging to the same
should ensure that the LSPs within the group are disjoint from each disjoint-group from some PCCs, the PCE should ensure that the LSPs
other. 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
The following terminology is used in this document. The following terminology is used in this document.
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 a
path computation to be performed by a Path Computation Element. 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, application,
skipping to change at page 4, line 19 skipping to change at page 4, line 22
PCEP: Path Computation Element communication Protocol. PCEP: Path Computation Element communication Protocol.
SRLG: Shared Risk Link Group. 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
IP/MPLS core. The customer may use those paths as primary/backup or operator's IP/MPLS core. The customer may use these paths as
active/active. primary/backup or active/active configuration.
Different level of disjointness may be offered: Different levels of disjointness may be offered:
o Link disjointness: the paths of the associated LSPs should transit o 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 o 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 o SRLG disjointness: the paths of the associated LSPs should transit
skipping to change at page 5, line 26 skipping to change at page 5, line 26
| +------+ | | +------+ | | +------+ | | +------+ |
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 between CE1/CE2 and CE3/CE4. From an IP/MPLS two disjoint paths, one between CE1 and CE2 and one between CE3 and
network point view, in this example, the CEs are connected to CE4. From an IP/MPLS network point view, in this example, the CEs
different PEs to maximize their disjointness. When LSPs originate are connected to different PEs to maximize their disjointness. When
from different head-ends, distributed computation of diverse paths LSPs originate from different head-ends, distributed computation of
can be difficult, whereas, computation via a centralized PCE ensures diverse paths can be difficult, whereas, computation via a
path disjointness, correctness and simplicity. centralized PCE ensures path disjointness, correctness and
simplicity.
Section 5.3 describes the relationship between the disjoint Section 5.4 describes the relationship between the Disjoint
association group 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 PLSP-ID in the LSP object for identification. Moreover
to allow diversity between LSPs originating from different PCCs, the to allow diversity between LSPs originating from different PCCs, the
generic mechanism to create a grouping of LSPs is described in generic mechanism to create a grouping of LSPs is described in
[I-D.ietf-pce-association-group] (that is equally applicable to the [I-D.ietf-pce-association-group] (that is equally applicable to the
active and passive modes of a stateful PCE). active and passive modes of a stateful PCE).
Using PCEP, the PCC could indicate that a disjoint path computation Using the extension to PCEP defined in this document, the PCC uses
is required, such indication should include disjointness parameters the [I-D.ietf-pce-association-group] extension to indicate that a
such as the type of disjointness, the disjoint group identifiers, and group of LSPs are required to be disjoint; such indication should
any customization parameters according to the configured local include disjointness parameters such as the type of disjointness, the
policy. As mentioned previously, the extension described in disjoint group identifiers, and any customization parameters
according to the configured local policy.
[I-D.ietf-pce-association-group] is well suited to associate a set of
LSPs with a particular disjoint-group.
The management of the disjoint group IDs will be a key point for the The management of the disjoint group IDs will be a key point for the
operator as the Association ID field is limited to 65535. The local operator as the Association ID field is limited to 65535. The local
configuration of IPv4/IPv6 association source, or Global Association configuration of IPv4/IPv6 association source, or Global Association
Source/Extended Association ID allows to overcome this limitation as Source/Extended Association ID allows to overcome this limitation as
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 disjoint association group. the DAG.
Initiate Disjoint LSPs Initiate Disjoint LSPs
| |
| PCReq/PCRpt | PCReq/PCRpt
V {Disjoint-group Y} V {Disjoint-group Y}
+-----+ ----------------> +-----+ +-----+ ----------------> +-----+
_ _ _ _ _ _| PCE | | | PCE | _ _ _ _ _ _| PCE | | | PCE |
| +-----+ | ----------> +-----+ | +-----+ | ----------> +-----+
| PCInitiate | | PCReq/PCRpt | PCInitiate | | PCReq/PCRpt
|{Disjoint-group X} | | {Disjoint-group Y} |{Disjoint-group X} | | {Disjoint-group Y}
| | | | | |
| .-----. | | .-----. | .-----. | | .-----.
| ( ) | +----+ ( ) | ( ) | +-----+ ( )
| .--( )--. | |PE 1|--.--( )--. | .--( )--. | |PCC 2|--.--( )--.
V ( ) | +----+ ( ) V ( ) | +-----+ ( )
+---+ ( ) | ( ) +---+ ( ) | ( )
|PCC|----( (G)MPLS network ) +----+ ( (G)MPLS network ) |PCC|----( (G)MPLS network ) +-----+ ( (G)MPLS network )
+---+ ( ) |PE 3|-----( ) +---+ ( ) |PCC 1|-----( )
Disjoint-group X ) +----+ ( ) Disjoint-group 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 may have two purpose: 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
requirement to a PCEP peer. requirement to a PCEP peer.
o Status: Used to communicate the status of the computed o Status: Used to communicate the status of the computed
disjointness. disjointness.
5. Protocol Extension 5. Protocol Extension
5.1. Association Group 5.1. Association Group
As per [I-D.ietf-pce-association-group], LSPs are associated with As per [I-D.ietf-pce-association-group], LSPs are associated with
other LSPs with which they interact by adding them to a common other LSPs with which they interact by adding them to a common
association group. The Association parameters, as described in association group. As described in [I-D.ietf-pce-association-group]
[I-D.ietf-pce-association-group] as the combination of the mandatory the association A A group is uniquely identified by the combination
fields Association type, Association ID and Association Source in the of these fields in the ASSOCIATION object:A Association Type,
ASSOCIATION object, that uniquely identify the association group Association ID, Association Source, and (if present) Global
belonging to this association. If the optional TLVs - Global Association Source or Extended Association ID.
Association Source or Extended Association ID - are included, then
they are included in combination with mandatory fields to uniquely
identify the association group. This document defines a new
Association type, based on the generic Association object:
o Association type = TBD1 ("Disjointness Association Type") for This document defines a new Association type, based on the generic
Disjoint Association Group (DAG). Association object:
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 association type OPEN object. This capability exchange for the Disjointness
described in this document (i.e. Disjointness Association Type) MUST Association Type (TBD1) MUST be done before using the disjointness
be done before using the disjointness association. Thus the PCEP association. Thus the PCEP speaker MUST include the Disjointness
speaker MUST include the Disjointness Association Type (TBD1) in the Association Type in the ASSOC-Type-List TLV before using the Disjoint
ASSOC-Type-List TLV before using the disjoint association group (DAG) Association Group (DAG) in PCEP messages.
in PCEP messages.
This association type is considered to be both dynamic and operator- This association type is considered to be both dynamic and operator-
configured in nature. The association group could be created by the configured in nature. The association group could be created by the
operator manually on the PCEP peers and the LSPs belonging to this operator manually on the PCEP peers and the LSPs belonging to this
associations is conveyed via PCEP messages to the PCEP peer; or the associations is conveyed via PCEP messages to the PCEP peer; or the
association group could be created dynamically by the PCEP speaker association group could be created dynamically by the PCEP speaker
and both the association group information and the LSPs belonging to and both the association group information and the LSPs belonging to
the association group is conveyed to the PCEP peer. The Operator- the association group is conveyed to the PCEP peer. The Operator-
configured Association Range MUST be set for this association-type to configured Association Range MUST be set for this association-type to
mark a range of association identifiers that are used for operator- mark a range of association identifiers that are used for operator-
skipping to change at page 8, line 15 skipping to change at page 8, line 12
in the number of LSPs it can take into account when computing in the number of LSPs it can take into account when computing
disjointness. If a PCE receives more LSPs in the group than it can disjointness. If a PCE receives more LSPs in the group than it can
handle in its computation algorithm, it SHOULD apply disjointness handle in its computation algorithm, it SHOULD apply disjointness
computation to only a subset of LSPs in the group. The subset of computation to only a subset of LSPs in the group. The subset of
disjoint LSPs will be decided by PCE as a local policy. Local disjoint LSPs will be decided by PCE as a local policy. Local
polices MAY define the computational behavior for the other LSPs in polices MAY define the computational behavior for the other LSPs in
the group. For example, the PCE may provide no path, a shortest the group. For example, the PCE may provide no path, a shortest
path, or a constrained path based on relaxing disjointness, etc. The path, or a constrained path based on relaxing disjointness, etc. The
disjoint status is informed to the PCC. disjoint status is informed to the PCC.
All LSPs in a particular disjoint group MUST use the same combination
of T, S, N, L flags in the DISJOINTNESS-CONFIGURATION-TLVSection 5.2.
If a PCEP peer receives a PCEP messages for LSPs belonging to the
same disjoint group but having an inconsistent combination of T, S,
N, L flags, the PCEP peer SHOULD NOT try to add the LSPs in disjoint
group and SHOULD reply with a PCErr with Error-type 26 (Association
Error) and Error- Value 6 (Association information mismatch).
Associating a particular LSP to multiple disjoint groups is Associating a particular LSP to multiple disjoint groups is
authorized from a protocol perspective, however there is no assurance authorized from a protocol perspective, however there is no assurance
that the PCE will be able to compute properly the multi-disjointness that the PCE will be able to compute properly the multi-disjointness
constraint. constraint.
5.2. Disjoint TLVs 5.2. Disjoint TLVs
The disjoint group MUST carry the following TLV: The disjoint group MUST carry the following TLV:
o DISJOINTNESS-CONFIGURATION-TLV: Used to communicate some o DISJOINTNESS-CONFIGURATION-TLV: Used to communicate some
skipping to change at page 8, line 37 skipping to change at page 8, line 42
In addition, the disjoint group MAY carry the following TLV: In addition, the disjoint group MAY carry the following TLV:
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 PCE
to PCC (PCUpd, PCInitiate or PCRep message). to PCC (PCUpd, PCInitiate or PCRep message).
o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor- o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor-
specific behavioral information, described in [RFC7470]. specific behavioral information, described in [RFC7470].
o OF-List TLV: Used to communicate the disjointness objective o OF-List TLV: Used to communicate the disjointness objective
function. See Section 5.4. function. See Section 5.3.
The DISJOINTNESS-CONFIGURATION-TLV is shown in the following figure: The DISJOINTNESS-CONFIGURATION-TLV is shown in the following figure:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD2 | Length | | Type = TBD2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |T|P|S|N|L| | Flags |T|P|S|N|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD2. Type: TBD2.
Length: Fixed value of 4 bytes. Length: Fixed value of 4 bytes.
skipping to change at page 9, line 22 skipping to change at page 9, line 34
computed paths within the disjoint group MUST NOT have any node computed paths within the disjoint group MUST NOT have any node
in common. in common.
* S (SRLG diverse) bit: when set, this indicates that the * S (SRLG diverse) bit: when set, this indicates that the
computed paths within the disjoint group MUST NOT share any computed paths within the disjoint group MUST NOT share any
SRLG (Shared Risk Link Group). SRLG (Shared Risk Link Group).
* P (Shortest path) bit: when set, this indicates that the * P (Shortest path) bit: when set, this indicates that the
computed path of the LSP SHOULD satisfy all the constraints and computed path of the LSP SHOULD satisfy all the constraints and
objective functions first without considering the diversity objective functions first without considering the diversity
constraint. This means that an LSP with P flag set should be constraint, this means that all of the LSPs with P flag set in
placed as if the disjointness constraint has not been the association group are computed first, and then with those
configured, while the other LSP in the association with P flag LSPs fixed, the other LSPs with P flag unset in the association
unset should be placed by taking into account the disjointness group are computed. The role of P flag is further described
constraint. Setting P flag changes the relationship between with example inA Section 5.5
LSPs to a one-sided relationship (LSP 1 with P=0 depends of LSP
2 with P=1, but LSP 2 with P=1 does not depend of LSP 1 with
P=0). Multiple LSPs in the same disjoint group may have the P
flag set. In such a case, those LSPs may not be disjoint from
each other but will be disjoint from others LSPs in the group
that have the P flag unset.
* T (Strict disjointness) bit: when set, if disjoint paths cannot * T (Strict disjointness) bit: when set, if disjoint paths cannot
be found, PCE SHOULD return no path for LSPs that could not be be found, PCE SHOULD return no path for LSPs that could not be
be disjoint. When unset, the PCE is allowed to relax be disjoint. When unset, the PCE is allowed to relax
disjointness by either applying a requested objective function disjointness by Section 5.5either applying a requested
(cf. Section 5.4 below) or using any other behavior if no objective function (cf. Section 5.3 below) or using the local
objective function is requested (e.g. using a lower disjoint policy if no objective function is requested (e.g. using a
type (link instead of node) or fully relaxing disjointness lower disjoint type (link instead of node) or fully relaxing
constraint). Further see Section 5.6 for details. disjointness constraint). Further see Section 5.6 for details.
* Unassigned bits are considered reserved. They MUST be set to 0 * Unassigned bits are considered reserved. They MUST be set to 0
on transmission and MUST be ignored on receipt. on transmission and MUST be ignored on receipt.
If a PCEP speaker receives a disjoint-group without DISJOINTNESS- If a PCEP speaker receives a disjoint-group without DISJOINTNESS-
CONFIGURATION-TLV, it SHOULD reply with a PCErr Error-type=6 CONFIGURATION-TLV, it SHOULD reply with a PCErr Error-type=6
(Mandatory Object missing) and Error-value=TBD8 (DISJOINTNESS- (Mandatory Object missing) and Error-value=TBD8 (DISJOINTNESS-
CONFIGURATION-TLV missing). CONFIGURATION-TLV missing).
The DISJOINTNESS-STATUS-TLV uses the same format as the DISJOINTNESS- The DISJOINTNESS-STATUS-TLV uses the same format as the DISJOINTNESS-
CONFIGURATION-TLV with a different type TBD3 (in the TLV). The L, N, CONFIGURATION-TLV with a different type TBD3 (in the TLV). The L, N,
and S flags are set based if the computed path meet the disjointness and S flags are set if the respective disjointness criterion was
criteria. The P flag is set to indicate that the computed path is requested and the computed paths meet it. The P flag is set to
the shortest and the T flag has no meaning in the DISJOINTNESS- indicate that the computed path is the shortest.
STATUS-TLV and MUST NOT be set while sending and ignored on receipt.
Any new flag defined for the DISJOINTNESS-CONFIGURATION-TLV is be
automatically applicable to the DISJOINTNESS-STATUS-TLV.
5.3. Relationship to SVEC
[RFC5440] defines a mechanism for the synchronization of a set of The T flag has no meaning in the DISJOINTNESS-STATUS-TLV and MUST NOT
path computation requests by using the SVEC object, that specifies be set while sending and MUST be ignored on receipt.
the list of synchronized requests that can either be dependent or
independent. The SVEC object identify the relationship between the
set of path computation requests, identified by 'Request-ID-number'
in RP (Request Parameters) object. [RFC6007] further clarified the
use of the SVEC list for synchronized path computations when
computing dependent requests as well as described a number of usage
scenarios for SVEC lists within single-domain and multi-domain
environments.
The SVEC object includes a Flags field that indicates the potential Any document defining a new flag for the DISJOINTNESS-CONFIGURATION-
dependency between the set of path computation request in a similar TLV automatically defines a new flag A A with the same name and in
way as the Flags field in the TLVs defined in this document. The the same location in DISJOINTNESS-STATUS-TLV; the semantics of the
path computation request in the PCReq message MAY use both the SVEC flag in A A DISJOINTNESS-STATUS-TLV MUST be specified in the
and ASSOCIATION objects to identify the related path computation document that specifies the flag in DISJOINTNESS-CONFIGURATION-TLV.
request as well as the diversity association group. The PCE MUST try
to find a path that meets both the constraints. It is possible that
the diversity requirement in the association group is different from
the one in the SVEC object. The PCE would consider both the objects
as per the processing rules and aim to find a path that meets both of
these constraints. In case no such path is possible (or the
constraints are incompatible), the PCE MUST send a path computation
reply (PCRep) with a NO-PATH object indicating path computation
failure as per [RFC5440].
5.4. Disjointness Objective functions 5.3. Disjointness Objective Functions
An objective function (OF) MAY be applied to the disjointness An objective function (OF) MAY be applied to the disjointness
computation to drive the PCE computation behavior. In this case, the computation to drive the PCE computation behavior. In this case, the
OF-List TLV (defined in ([RFC5541]) is used as an optional TLV in the OF-List TLV (defined in ([RFC5541]) is used as an optional TLV in the
Association Group Object. Whereas the PCEP OF-List TLV allows Association Group Object. Whereas the PCEP OF-List TLV allows
multiple OF-codes inside the TLV, a sender SHOULD include a single multiple OF-codes inside the TLV, a sender SHOULD include a single
OF-code in the OF-List TLV when included in the Association Group, OF-code in the OF-List TLV when included in the Association Group,
and the receiver MUST consider the first OF-code only and ignore and the receiver MUST consider the first OF-code only and ignore
others if included. others if included.
skipping to change at page 11, line 33 skipping to change at page 11, line 16
* 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.
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 it passes 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.
If the OF-list TLV is included in the Association Object, the OF-code If the OF-list TLV is included in the Association Object, the OF-code
inside the OF Object MUST include one of the disjoint OFs defined in inside the OF Object MUST include one of the disjoint OFs defined in
this document. If this condition is not met, the PCEP speaker MUST this document. If this condition is not met, the PCEP speaker MUST
respond with a PCErr message with Error-Type=10 (Reception of an respond with a PCErr message with Error-Type=10 (Reception of an
invalid object) and Error-Value=TBD9 (Incompatible OF code). invalid object) and Error-Value=TBD9 (Incompatible OF code).
5.4. Relationship to SVEC
[RFC5440] defines a mechanism for the synchronization of a set of
path computation requests by using the SVEC object, that specifies
the list of synchronized requests that can either be dependent or
independent. The SVEC object identify the relationship between the
set of path computation requests, identified by 'Request-ID-number'
in RP (Request Parameters) object. [RFC6007] further clarified the
use of the SVEC list for synchronized path computations when
computing dependent requests as well as described a number of usage
scenarios for SVEC lists within single-domain and multi-domain
environments.
The SVEC object includes a Flags field that indicates the potential
dependency between the set of path computation request in a similar
way as the Flags field in the TLVs defined in this document. The
path computation request in the PCReq message MAY use both the SVEC
and ASSOCIATION objects to identify the related path computation
request as well as the diversity association group. The PCE MUST try
to find a path that meets both the constraints. It is possible that
the diversity requirement in the association group is different from
the one in the SVEC object. The PCE MUST consider both the objects
as per the processing rules and aim to find a path that meets both of
these constraints. In case no such path is possible, the PCE MUST
send a path computation reply (PCRep) with a NO-PATH object
indicating path computation failure as per [RFC5440].
[RFC5440] uses SVEC diversity flag for node, link or SRLG to describe [RFC5440] uses SVEC diversity flag for node, link or SRLG to describe
the potential disjointness between the set of path computation the potential disjointness between the set of path computation
requests used in PCEP protocol. requests used in PCEP protocol.
This document defines three new OF-codes to maximize diversity as This document defines three new OF-codes Section 5.3 to maximize
much as possible, in other words, minimize the common shared diversity as much as possible, in other words, new OF-codes allow
resources (Node, Link or SRLG) between a set of paths. specification of minimization of common A A shared resources (Node,
Link or SRLG) among a set of paths during path computation.
It may be interesting to note that the diversity flags in the SVEC It may be interesting to note that the diversity flags in the SVEC
object and OF for diversity can be used together. Some examples of object and OF for diversity can be used together. Some examples of
usage are listed below: usage are listed below:
o SVEC object with node-diverse bit=1 - ensure full node-diversity. o SVEC object with node-diverse bit=1 - ensure full node-diversity.
o SVEC object with node-diverse bit=1 and OF=MSS - full node diverse o SVEC object with node-diverse bit=1 and OF=MSS - full node diverse
with as much as SRLG-diversity as possible. with as much as SRLG-diversity as possible.
skipping to change at page 12, line 27 skipping to change at page 12, line 40
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 satisfies all constraints and
objective functions first without considering the diversity objective functions first without considering the diversity
constraint. This could be required in some primary/backup scenarios constraint.
where the primary path should use the more optimal path available
(taking into account the other constraints). When disjointness is This means that an LSP with P flag set should be placed as if the
computed, it is important for the algorithm to know that it should disjointness constraint has not been configured, while the other LSPs
try to optimize the path of one or more LSPs in the disjoint group in the association with P flag unset should be placed by taking into
(for instance the primary path) while other paths are allowed to be account the disjointness constraint. Setting P flag changes the
costlier (compared to a similar path without the disjointness relationship between LSPs to a one-sided relationship (LSP 1 with P=0
constraint). Without such a hint, the disjointness algorithm may set depends of LSP 2 with P=1, but LSP 2 with P=1 does not depend of LSP
a path for all LSPs that may not completely fulfill the customer's 1 with P=0). Multiple LSPs in the same disjoint group may have the P
requirement. flag set. In such a case, those LSPs may not be disjoint from each
other but will be disjoint from others LSPs in the group that have
the P flag unset.
This could be required in some primary/backup scenarios where the
primary path should use the more optimal path available (taking into
account the other constraints). When disjointness is computed, it is
important for the algorithm to know that it should try to optimize
the path of one or more LSPs in the disjoint group (for instance the
primary path) while other paths are allowed to be costlier (compared
to a similar path without the disjointness constraint). Without such
a hint, the disjointness algorithm may set a path for all LSPs that
may not completely fulfill the customer's requirement.
_________________________________________ _________________________________________
/ \ / \
/ +------+ \ / +------+ \
| | 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 15, line 26 skipping to change at page 16, line 7
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". Also, in case of network event leading to an impossible group".
strict disjointness, the PCE MUST send a PCUpd message containing an
empty ERO to the corresponding PCCs. In addition to the empty ERO In case of network event leading to an impossible strict
Object, the PCE MAY add the NO-PATH-VECTOR TLV ([RFC5440]) in the LSP disjointness, the PCE MUST send a PCUpd message containing an empty
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.
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, the PCE is allowed to relax disjointness by
applying a requested objective function (Section 5.4) 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 computed by the PCE can be reported actual level of disjointness of the paths computed by the PCE can be
through the DISJOINTNESS-STATUS-TLV by setting the appropriate flags reported through the DISJOINTNESS-STATUS-TLV by setting the
in the TLV. While the DISJOINTNESS-CONFIGURATION-TLV defines the appropriate flags in the TLV. While the DISJOINTNESS-CONFIGURATION-
expected level of disjointness required by configuration, the TLV defines the desired level of disjointness required by
DISJOINTNESS-STATUS-TLV defines the actual level of disjointness configuration, the DISJOINTNESS-STATUS-TLV defines the achieved level
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. consequence, it is considered as out of scope of the document.
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
peer receives a PCEP messages for LSPs belonging to the same disjoint
group but having an inconsistent combination of T, S, N, L flags, the
PCEP peer SHOULD NOT try to add the LSPs in disjoint group and SHOULD
reply with a PCErr with Error-type 26 (Association Error) and Error-
Value 6 (Association information mismatch).
6. Security Considerations 6. Security Considerations
This document defines one new type for association, 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] and [I-D.ietf-pce-association-group]. But,
adding of a spurious LSP into the disjointness association group 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
legitimate LSPs of the group and thus cause LSP allocation for the
legitimate LSPs to fail with an error.
Also, as stated in [I-D.ietf-pce-association-group], much of the Also, as stated in [I-D.ietf-pce-association-group], much of the
information carried in the Disjointness Association object, as per information carried in the Disjointness Association object, as per
this document is not extra sensitive. It often reflects information this document is not extra sensitive. It often reflects information
that can also be derived from the LSP Database, but association that can also be derived from the LSP Database, but association
provides a much easier grouping of related LSPs and messages. The provides a much easier grouping of related LSPs and messages. The
disjointness association could provide an adversary with the disjointness association could provide an adversary with the
opportunity to eavesdrop on the relationship between the LSPs. opportunity to eavesdrop on the relationship between the LSPs.
Thus securing the PCEP session using Transport Layer Security (TLS) Thus securing the PCEP session using Transport Layer Security (TLS)
[RFC8253], as per the recommendations and best current practices in [RFC8253], as per the recommendations and best current practices in
skipping to change at page 19, line 47 skipping to change at page 20, line 20
each peer, and the current set of LSPs in this association. The PCEP each peer, and the current set of LSPs in this association. The PCEP
YANG module [I-D.ietf-pce-pcep-yang] includes association groups 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. Verify Correct Operations 8.4. Verification of Correct Operations
Mechanisms defined in this document do not imply any new operation Mechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in verification requirements in addition to those already listed in
[RFC5440]. [RFC5440].
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 disjoint association group. LSPs that can belong to a DAG.
9. Acknowledgments 9. Acknowledgments
A special thanks to authors of [I-D.ietf-pce-association-group], this A special thanks to authors of [I-D.ietf-pce-association-group], this
document borrow some of the text from it. Authors would also like to document borrow some of the text from it. Authors would also like to
thank Adrian Farrel and Julien Meuric for the valuable comments. thank Adrian Farrel and Julien Meuric for the valuable comments.
Thanks to Emmanuel Baccelli for RTGDIR reviews. Thanks to Emmanuel Baccelli for RTGDIR reviews.
10. References 10. References
 End of changes. 46 change blocks. 
175 lines changed or deleted 190 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/