draft-ietf-pce-association-diversity-13.txt   draft-ietf-pce-association-diversity-14.txt 
PCE Working Group S. Litkowski PCE Working Group S. Litkowski
Internet-Draft S. Sivabalan Internet-Draft S. Sivabalan
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: June 20, 2020 C. Barth Expires: July 29, 2020 C. Barth
Juniper Networks Juniper Networks
M. Negi M. Negi
Huawei Technologies Huawei Technologies
December 18, 2019 January 26, 2020
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-13 draft-ietf-pce-association-diversity-14
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 (disjointed) paths for those LSPs. The proposed computing diverse (disjointed) paths for those LSPs. The proposed
extension allows a Path Computation Client (PCC) to advertise to a extension allows a Path Computation Client (PCC) to advertise to a
PCE that a particular LSP belongs to a particular disjoint-group, PCE that a particular LSP belongs to a particular disjoint-group,
thus the PCE knows that the LSPs in the same group need to be thus the PCE knows that the LSPs in the same group need to be
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 June 20, 2020. This Internet-Draft will expire on July 29, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
skipping to change at page 2, line 39 skipping to change at page 2, line 39
5.6. Disjointness Computation Issues . . . . . . . . . . . . . 16 5.6. Disjointness Computation Issues . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7.1. Association Type . . . . . . . . . . . . . . . . . . . . 18 7.1. Association Type . . . . . . . . . . . . . . . . . . . . 18
7.2. PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . . . 18 7.2. PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . . . 18
7.3. Objective Functions . . . . . . . . . . . . . . . . . . . 19 7.3. Objective Functions . . . . . . . . . . . . . . . . . . . 19
7.4. NO-PATH-VECTOR Bit Flags . . . . . . . . . . . . . . . . 19 7.4. NO-PATH-VECTOR Bit Flags . . . . . . . . . . . . . . . . 19
7.5. PCEP-ERROR Codes . . . . . . . . . . . . . . . . . . . . 20 7.5. PCEP-ERROR Codes . . . . . . . . . . . . . . . . . . . . 20
8. Manageability Considerations . . . . . . . . . . . . . . . . 20 8. Manageability Considerations . . . . . . . . . . . . . . . . 20
8.1. Control of Function and Policy . . . . . . . . . . . . . 20 8.1. Control of Function and Policy . . . . . . . . . . . . . 20
8.2. Information and Data Models . . . . . . . . . . . . . . . 20 8.2. Information and Data Models . . . . . . . . . . . . . . . 21
8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 20 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 21
8.4. Verification of Correct Operations . . . . . . . . . . . 21 8.4. Verification of Correct Operations . . . . . . . . . . . 21
8.5. Requirements on Other Protocols . . . . . . . . . . . . . 21 8.5. Requirements on Other Protocols . . . . . . . . . . . . . 21
8.6. Impact on Network Operations . . . . . . . . . . . . . . 21 8.6. Impact on Network Operations . . . . . . . . . . . . . . 21
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . 21 10.1. Normative References . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 24 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
[RFC5440] describes the Path Computation Element communication [RFC5440] describes the Path Computation Element communication
Protocol (PCEP) which enables the communication between a Path Protocol (PCEP) which enables the communication between a Path
Computation Client (PCC) and a Path Control Element (PCE), or between Computation Client (PCC) and a Path Control Element (PCE), or between
two PCEs based on the PCE architecture [RFC4655]. two PCEs based on the PCE architecture [RFC4655].
skipping to change at page 12, line 48 skipping to change at page 12, line 48
can be fully same or partially overlapping with the LSPs grouped by can be fully same or partially overlapping with the LSPs grouped by
the SVEC object in PCReq message. the SVEC object in PCReq message.
Some examples of usage are listed below: Some examples of usage are listed below:
o PCReq with SVEC object with node-diverse bit=1 (LSP1,LSP2) and DAG o PCReq with SVEC object with node-diverse bit=1 (LSP1,LSP2) and DAG
with S=1 (LSP1,LSP2) - both node and SRLG diverse path between with S=1 (LSP1,LSP2) - both node and SRLG diverse path between
LSP1, LSP2. LSP1, LSP2.
o PCReq with SVEC object with link-diverse bit=1 (LSP1,LSP2) and DAG o PCReq with SVEC object with link-diverse bit=1 (LSP1,LSP2) and DAG
with L=1 (LSP1,LSP3) - link diverse paths between LSP1, LSP2, with L=1 (LSP1,LSP3) - link diverse paths between LSP1 & LSP2, and
LSP3. But any future change in LSP2 will have no impact. LSP1 & LSP3. If the DAG is part of the stateful database, any
future change in LSP3 will have an impact on LSP1. But any future
change in LSP2 will have no impact on LSP1, as LSP2 is part of
SVEC object (which is considered once on receipt of the 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 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
skipping to change at page 16, line 12 skipping to change at page 16, line 35
Figure 4 Figure 4
In the figure above, we still consider the same previous In the figure above, we still consider the same previous
requirements, so PE1->PE2 LSP should be optimized (P flag set) while requirements, so PE1->PE2 LSP should be optimized (P flag set) while
PE3->PE4 should be 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 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
skipping to change at page 16, line 50 skipping to change at page 17, line 22
the PCE MAY add the NO-PATH-VECTOR TLV ([RFC5440]) in the LSP Object. the PCE MAY add the NO-PATH-VECTOR TLV ([RFC5440]) in the LSP Object.
This document adds new bits in the NO-PATH-VECTOR TLV: This document adds new bits in the NO-PATH-VECTOR TLV:
bit "TBD7": when set, the PCE indicates that it could not find a bit "TBD7": when set, the PCE indicates that it could not find a
disjoint path for this LSP. disjoint path for this LSP.
bit "TBD8": when set, the PCE indicates that it does not support bit "TBD8": when set, the PCE indicates that it does not support
the requested disjointness computation. the requested disjointness computation.
When the T flag is unset, When the T flag is unset, the PCE is allowed to relax disjointness by
the PCE is allowed to relax disjointness by applying a requested applying a requested objective function (Section 5.3) if specified.
objective function (Section 5.3) if specified. Otherwise, if no Otherwise, if no objective function is specified, the PCE is allowed
objective function is specified, the PCE is allowed to reduce the to reduce the required level of disjointness as it deems fit. The
required level of disjointness as it deems fit. The actual level of actual level of disjointness of the paths computed by the PCE can be
disjointness of the paths computed by the PCE can be reported through reported through the DISJOINTNESS-STATUS-TLV by setting the
the DISJOINTNESS-STATUS-TLV by setting the appropriate flags in the appropriate flags in the TLV. While the DISJOINTNESS-CONFIGURATION-
TLV. While the DISJOINTNESS-CONFIGURATION-TLV defines the desired TLV defines the desired level of disjointness required by
level of disjointness required by configuration, the DISJOINTNESS- configuration, the DISJOINTNESS-STATUS-TLV defines the achieved level
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. consequence, it is considered as out of scope of the document. See
[I-D.dhody-pce-stateful-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 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], [RFC7470] and [I-D.ietf-pce-association-group]. [RFC5440], [RFC8231], [RFC7470] and [I-D.ietf-pce-association-group].
But, adding of a spurious LSP into the disjointness association group But, adding of a spurious LSP into the disjointness association group
could lead to re-computation and set-up of all LSPs in the group, could lead to re-computation and set-up of all LSPs in the group,
that could be used to overwhelm the PCE and the network. that could be used to overwhelm the PCE and the network.
skipping to change at page 18, line 15 skipping to change at page 18, line 30
7. IANA Considerations 7. IANA Considerations
7.1. Association Type 7.1. Association Type
This document defines a new Association type, originally described in This document defines a new Association type, originally described in
[I-D.ietf-pce-association-group]. IANA is requested to make the [I-D.ietf-pce-association-group]. IANA is requested to make the
assignment of a new value for the sub-registry "ASSOCIATION Type assignment of a new value for the sub-registry "ASSOCIATION Type
Field" (request to be created in [I-D.ietf-pce-association-group]), Field" (request to be created in [I-D.ietf-pce-association-group]),
as follows: as follows:
+------------------+---------------------------------+--------------+ +------------------+--------------------------------+-------------+
| Association type | Association Name | Reference | | Association type | Association Name | Reference |
+------------------+---------------------------------+--------------+ +------------------+--------------------------------+-------------+
| TBD1 | Disjointness Association Type | [This.I-D] | | TBD1 | Disjointness Association Type | [This.I-D] |
+------------------+---------------------------------+--------------+ +------------------+--------------------------------+-------------+
7.2. PCEP TLVs 7.2. PCEP TLVs
This document defines the following new PCEP TLVs and the IANA is This document defines the following new PCEP TLVs and the IANA is
requested to make the assignment of new values for the existing "PCEP requested to make the assignment of new values for the existing "PCEP
TLV Type Indicators" registry as follows: TLV Type Indicators" registry as follows:
+----------+----------------------------------+--------------+ +----------+---------------------------------+-------------+
| TLV Type | TLV Name | Reference | | TLV Type | TLV Name | Reference |
+----------+----------------------------------+--------------+ +----------+---------------------------------+-------------+
| TBD2 | Disjointness Configuration TLV | [This.I-D] | | TBD2 | Disjointness Configuration TLV | [This.I-D] |
| TBD3 | Disjointness Status TLV | [This.I-D] | | TBD3 | Disjointness Status TLV | [This.I-D] |
+----------+----------------------------------+--------------+ +----------+---------------------------------+-------------+
This document requests that a new sub-registry, named "Disjointness This document requests that a new sub-registry, named "Disjointness
Configuration TLV Flag Field", is created within the "Path Configuration TLV Flag Field", is created within the "Path
Computation Element Protocol (PCEP) Numbers" registry to manage the Computation Element Protocol (PCEP) Numbers" registry to manage the
Flag field in the Disjointness Configuration TLV. New values are to Flag field in the Disjointness Configuration TLV. New values are to
be assigned by Standards Action [RFC8126]. Each bit should be be assigned by Standards Action [RFC8126]. Each bit should be
tracked with the following qualities: tracked with the following qualities:
o Bit number (count from 0 as the most significant bit) o Bit number (count from 0 as the most significant bit)
o Flag Name o Flag Name
o Reference o Reference
+------------+-------------------------+--------------+
| Bit Number | Name | Reference | +------------+-------------------------+-------------+
+------------+-------------------------+--------------+ | Bit Number | Name | Reference |
| 31 | L - Link Diverse | [This.I-D] | +------------+-------------------------+-------------+
| 30 | N - Node Diverse | [This.I-D] | | 31 | L - Link Diverse | [This.I-D] |
| 29 | S - SRLG Diverse | [This.I-D] | | 30 | N - Node Diverse | [This.I-D] |
| 28 | P - Shortest Path | [This.I-D] | | 29 | S - SRLG Diverse | [This.I-D] |
| 27 | T - Strict Disjointness | [This.I-D] | | 28 | P - Shortest Path | [This.I-D] |
+------------+-------------------------+--------------+ | 27 | T - Strict Disjointness | [This.I-D] |
+------------+-------------------------+-------------+
Table 1: Disjointness Configuration TLV Table 1: Disjointness Configuration TLV
7.3. Objective Functions 7.3. Objective Functions
Three new Objective Functions have been defined in this document. Three new Objective Functions have been defined in this document.
IANA is requested to make the following allocations from the PCEP IANA is requested to make the following allocations from the PCEP
"Objective Function" sub-registry: "Objective Function" sub-registry:
+------------+---------------------------------------+--------------+ +------------+----------------------------------------+-------------+
| Code Point | Name | Reference | | Code Point | Name | Reference |
+------------+---------------------------------------+--------------+ +------------+----------------------------------------+-------------+
| TBD4 | Minimize the number of shared Links | [This.I-D] | | TBD4 | Minimize the number of shared Links | [This.I-D] |
| | (MSL) | | | | (MSL) | |
| TBD5 | Minimize the number of shared SRLGs | [This.I-D] | | TBD5 | Minimize the number of shared SRLGs | [This.I-D] |
| | (MSS) | | | | (MSS) | |
| TBD6 | Minimize the number of shared Nodes | [This.I-D] | | TBD6 | Minimize the number of shared Nodes | [This.I-D] |
| | (MSN) | | | | (MSN) | |
+------------+---------------------------------------+--------------+ +------------+----------------------------------------+-------------+
7.4. NO-PATH-VECTOR Bit Flags 7.4. NO-PATH-VECTOR Bit Flags
This documents defines new bits for the NO-PATH-VECTOR TLV in the This documents defines new bits for the NO-PATH-VECTOR TLV in the
"NO-PATH-VECTOR TLV Flag Field" sub-registry of the "Path Computation "NO-PATH-VECTOR TLV Flag Field" sub-registry of the "Path Computation
Element Protocol (PCEP) Numbers" registry. IANA is requested to make Element Protocol (PCEP) Numbers" registry. IANA is requested to make
the following allocation: the following allocation:
+-----------+-----------------------------------------+-------------+ +------------+-----------------------------------------+------------+
| Bit | Name | Reference | | Bit Number | Name | Reference |
| Number | | | +------------+-----------------------------------------+------------+
+-----------+-----------------------------------------+-------------+ | TBD7 | Disjoint path not found | [This.I-D] |
| TBD7 | Disjoint path not found | [This.I-D] | | TBD8 | Requested disjoint computation not | [This.I-D] |
| TBD8 | Requested disjoint computation not | [This.I-D] | | | supported | |
| | supported | | +------------+-----------------------------------------+------------+
+-----------+-----------------------------------------+-------------+
Table 2: NO-PATH-VECTOR TLV Table 2: NO-PATH-VECTOR TLV
7.5. PCEP-ERROR Codes 7.5. PCEP-ERROR Codes
This document defines new Error-Value within existing Error-Type This document defines new Error-Value within existing Error-Type
related to path protection association. IANA is requested to related to path protection association. IANA is requested to
allocate new error values within the "PCEP-ERROR Object Error Types allocate new error values within the "PCEP-ERROR Object Error Types
and Values" sub-registry of the PCEP Numbers registry, as follows: and Values" sub-registry of the PCEP Numbers registry, as follows:
+----------+-------------------------+------------------------------+ +----------+-------------------------+------------------------------+
| Error- | Meaning | Reference | | Error- | Meaning | Reference |
| Type | | | | Type | | |
+----------+-------------------------+------------------------------+ +----------+-------------------------+------------------------------+
| 6 | Mandatory Object | [I-D.ietf-pce-association-gr | | 6 | Mandatory Object | [I-D.ietf-pce-association-gr |
| | missing | oup] | | | missing | oup] |
| | Error-value=TBD10: | [This.I-D] | | | Error-value=TBD10: | [This.I-D] |
| | DISJOINTNESS- | | | | DISJOINTNESS- | |
| | CONFIGURATION TLV | | | | CONFIGURATION TLV | |
| | missing | | | | missing | |
| 10 | Reception of an | [RFC5440] | | 10 | Reception of an invalid | [RFC5440] |
| | invalid object | | | | object | |
| | Error-value=TBD9: | [This.I-D] | | | Error-value=TBD9: | [This.I-D] |
| | Incompatible OF code | | | | Incompatible OF code | |
+----------+-------------------------+------------------------------+ +----------+-------------------------+------------------------------+
8. Manageability Considerations 8. Manageability Considerations
8.1. Control of Function and Policy 8.1. Control of Function and Policy
An operator SHOULD be allowed to configure the disjointness An operator SHOULD be allowed to configure the disjointness
association groups and disjoint parameters at the PCEP peers and association groups and disjoint parameters at the PCEP peers and
associate it with the LSPs. The Operator-configured Association associate it with the LSPs. The Operator-configured Association
skipping to change at page 24, line 5 skipping to change at page 23, line 43
Extensions for PCE-Initiated LSP Setup in a Stateful PCE Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>. <https://www.rfc-editor.org/info/rfc8281>.
[I-D.ietf-pce-pcep-yang] [I-D.ietf-pce-pcep-yang]
Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A
YANG Data Model for Path Computation Element YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", draft-ietf-pce-pcep- Communications Protocol (PCEP)", draft-ietf-pce-pcep-
yang-13 (work in progress), October 2019. yang-13 (work in progress), October 2019.
[I-D.dhody-pce-stateful-pce-optional]
Li, C., Zheng, H., and S. Litkowski, "Extension for
Stateful PCE to allow Optional Processing of PCEP
Objects", draft-dhody-pce-stateful-pce-optional-05 (work
in progress), January 2020.
Appendix A. Contributor Addresses Appendix A. Contributor Addresses
Dhruv Dhody Dhruv Dhody
Huawei Technologies Huawei Technologies
Divyashree Techno Park, Whitefield Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066 Bangalore, Karnataka 560066
India India
EMail: dhruv.ietf@gmail.com EMail: dhruv.ietf@gmail.com
 End of changes. 21 change blocks. 
70 lines changed or deleted 79 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/