draft-ietf-pce-association-diversity-03.txt   draft-ietf-pce-association-diversity-04.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: August 31, 2018 Cisco Systems, Inc. Expires: December 22, 2018 Cisco Systems, Inc.
C. Barth C. Barth
Juniper Networks Juniper Networks
D. Dhody D. Dhody
Huawei Huawei
February 27, 2018 June 20, 2018
Path Computation Element communication Protocol extension for signaling Path Computation Element communication Protocol extension for signaling
LSP diversity constraint LSP diversity constraint
draft-ietf-pce-association-diversity-03 draft-ietf-pce-association-diversity-04
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 Communication Protocol (PCEP) with the purpose of computing Element Communication Protocol (PCEP) with the purpose of computing
diverse paths for those LSPs. The proposed extension allows a PCC to diverse paths for those LSPs. The proposed extension allows a PCC to
advertise to a PCE the belonging of a particular LSP to a disjoint- advertise to a PCE the belonging of a particular LSP to a disjoint-
group, thus the PCE knows that LSPs in the same group must be group, thus the PCE knows that LSPs in the same group must be
disjoint from each other. disjoint from each other.
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 August 31, 2018. This Internet-Draft will expire on December 22, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 23 skipping to change at page 2, line 23
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol extension . . . . . . . . . . . . . . . . . . . . . 7 4. Protocol extension . . . . . . . . . . . . . . . . . . . . . 7
4.1. Association group . . . . . . . . . . . . . . . . . . . . 7 4.1. Association group . . . . . . . . . . . . . . . . . . . . 7
4.2. Mandatory TLV . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Disjoint TLVs . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Optional TLVs . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Disjointness objective functions . . . . . . . . . . . . 10
4.4. Disjointness objective functions . . . . . . . . . . . . 10 4.4. P-flag considerations . . . . . . . . . . . . . . . . . . 12
4.5. P-flag considerations . . . . . . . . . . . . . . . . . . 11 4.5. Disjointness computation issues . . . . . . . . . . . . . 14
4.6. Disjointness computation issues . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6.1. Association object Type Indicators . . . . . . . . . . . 15 6.1. Association object Type Indicators . . . . . . . . . . . 15
6.2. PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . . . 15 6.2. PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . . . 16
6.3. Objective Functions . . . . . . . . . . . . . . . . . . . 16 6.3. Objective Functions . . . . . . . . . . . . . . . . . . . 16
6.4. NO-PATH-VECTOR bit Flags . . . . . . . . . . . . . . . . 16 6.4. NO-PATH-VECTOR bit Flags . . . . . . . . . . . . . . . . 16
6.5. PCEP-ERROR codes . . . . . . . . . . . . . . . . . . . . 16 6.5. PCEP-ERROR codes . . . . . . . . . . . . . . . . . . . . 17
7. Manageability Considerations . . . . . . . . . . . . . . . . 16 7. Manageability Considerations . . . . . . . . . . . . . . . . 17
7.1. Control of Function and Policy . . . . . . . . . . . . . 16 7.1. Control of Function and Policy . . . . . . . . . . . . . 17
7.2. Information and Data Models . . . . . . . . . . . . . . . 17 7.2. Information and Data Models . . . . . . . . . . . . . . . 17
7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 17 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 17
7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 17 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 17
7.5. Requirements On Other Protocols . . . . . . . . . . . . . 17 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 17
7.6. Impact On Network Operations . . . . . . . . . . . . . . 17 7.6. Impact On Network Operations . . . . . . . . . . . . . . 18
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
[RFC5440] describes the Path Computation Element communication [RFC5440] describes the Path Computation Element communication
Protocol (PCEP) which enables the communication between a Path Protocol (PCEP) which enables the communication between a Path
Computation Client (PCC) and a Path Control Element (PCE), or between Computation Client (PCC) and a Path Control Element (PCE), or between
two PCEs based on the PCE architecture [RFC4655]. two PCEs based on the PCE architecture [RFC4655].
PCEP Extensions for Stateful PCE Model [RFC8231] describes a set of PCEP Extensions for Stateful PCE Model [RFC8231] describes a set of
extensions to PCEP to enable active control of MPLS-TE and GMPLS extensions to PCEP to enable active control of MPLS-TE and GMPLS
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 [I-D.ietf-pce-association-group] introduces a generic mechanism to
create a grouping of LSPs which can then be used to define create a grouping of LSPs which can then be used to define
associations between a set of LSPs and a set of attributes (such as associations between a set of LSPs and a set of attributes (such as
configuration parameters or behaviours) and is equally applicable to configuration parameters or behaviors) and is equally applicable to
the active and passive modes of a stateful PCE [RFC8231] or a the active and passive modes of a stateful PCE [RFC8231] or a
stateless PCE [RFC5440]. stateless PCE [RFC5440].
This document specifies a PCEP extension to signal that a particular This document specifies a PCEP extension to signal that a particular
group of LSPs should use diverse paths including the requested type group of LSPs should use diverse paths including the requested type
of diversity. A PCC can use this extension to signal to a PCE the of diversity. A PCC can use this extension to signal to a PCE the
belonging of a particular LSP to a disjoint-group. When a PCE belonging of a particular LSP to a disjoint-group. When a PCE
receives LSP states belonging to the same disjoint-group from some receives LSP states belonging to the same disjoint-group from some
PCCs, the PCE should ensure that the LSPs within the group are PCCs, the PCE should ensure that the LSPs within the group are
disjoint from each other. 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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Terminology 2. Terminology
The following terminology is used in this document. The following terminology is used in this document.
LSR: Label Switch Router. LSR: Label Switch Router.
MPLS: Multiprotocol Label Switching. MPLS: Multiprotocol Label Switching.
PCC: Path Computation Client. Any client application requesting a PCC: Path Computation Client. Any client application requesting a
skipping to change at page 4, line 9 skipping to change at page 4, line 7
or network node) that is capable of computing a network path or or network node) that is capable of computing a network path or
route based on a network graph and applying computational route based on a network graph and applying computational
constraints. constraints.
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 today in 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 IP/MPLS core. The customer may use those paths as primary/backup or
active/active. active/active.
Different level of disjointness may be offered: Different level 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).
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, the customer wants to have two disjoint paths In the figure above, consider that the customer wants to have two
between CE1/CE2 and CE3/CE4. From an IP/MPLS network point view, in disjoint paths between CE1/CE2 and CE3/CE4. From an IP/MPLS network
this example, the CEs are connected to different PEs to maximize point view, in this example, the CEs are connected to different PEs
their disjointness. When LSPs originate from different head-ends, to maximize their disjointness. When LSPs originate from different
distributed computation of diverse paths can be difficult. Whereas, head-ends, distributed computation of diverse paths can be difficult.
computation via a centralized PCE ensures path disjointness Whereas, computation via a centralized PCE ensures path disjointness
correctness and simplicity. correctness and simplicity.
[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 (Synchronization VECtor) path computation requests by using the SVEC (Synchronization VECtor)
object, that specifies the list of synchronized requests that can object, that specifies the list of synchronized requests that can
either be dependent or independent. The SVEC object identify the either be dependent or independent. The SVEC object identify the
relationship between the set of path computation requests, identified relationship between the set of path computation requests, identified
by 'Request-ID-number' in RP (Request Parameters) object. [RFC6007] by 'Request-ID-number' in RP (Request Parameters) object. [RFC6007]
further clarifies the use of the SVEC list for synchronized path further clarified the use of the SVEC list for synchronized path
computations when computing dependent requests as well as describes a computations when computing dependent requests as well as described a
number of usage scenarios for SVEC lists within single-domain and number of usage scenarios for SVEC lists within single-domain and
multi-domain environments. multi-domain environments.
The SVEC object includes a Flags field that indicates the potential The SVEC object includes a Flags field that indicates the potential
dependency between the set of path computation request in a similar dependency between the set of path computation request 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 (PCReq) message MAY use both SVEC object to path computation request in the PCReq message MAY use both SVEC
identify the related path computation request as well as to identify object to identify the related path computation request as well as to
the diversity association group. The PCE MUST try to find a path identify the diversity association group. The PCE MUST try to find a
that meets both the constraints. It is possible that the diversity path that meets both the constraints. It is possible that the
set in the association group is different from the one in SVEC diversity set in the association group is different from the one in
object, this might be true for the same LSP as well. The PCE would SVEC object, this might be true for the same LSP as well. The PCE
consider both the objects as per the processing rules and aim to find would consider both the objects as per the processing rules and aim
a path that meets both these constraints. In case no such path is to find a path that meets both these constraints. In case no such
possible (or the constraints are incompatible), the PCE MUST send a path is possible (or the constraints are incompatible), the PCE MUST
path computation reply (PCRep) with NO-PATH object indicating path send a path computation reply (PCRep) with NO-PATH object indicating
computation failure as per [RFC5440]. path computation failure as per [RFC5440].
The PCEP extension for stateful PCE [RFC8231] defined new PCEP The PCEP extension for stateful PCE [RFC8231] defined new PCEP
messages - PCRpt, PCUpd and PCInitiate. These messages uses PLSP-ID messages - PCRpt, PCUpd and PCInitiate [RFC8281]. These messages
in the LSP object for identification. Moreover to allow diversity uses PLSP-ID in the LSP object for identification. Moreover to allow
between LSPs originating from different PCCs, the generic mechanism diversity between LSPs originating from different PCCs, the generic
to create a grouping of LSPs as described in mechanism to create a grouping of LSPs is described in
[I-D.ietf-pce-association-group] equally applicable to the active and [I-D.ietf-pce-association-group] (that is equally applicable to the
passive modes of a stateful PCE is better suited. active and passive modes of a stateful PCE).
Using PCEP, the PCC MUST indicate that disjoint path computation is Using PCEP, the PCC could indicate that the disjoint path computation
required, such indication SHOULD include disjointness parameters such is required, such indication should include disjointness parameters
as the type of disjointness, the disjoint group-id, and any such as the type of disjointness, the disjoint group identifiers, and
customization parameters according to the configured local policy. any customization parameters according to the configured local
As mentioned previously, the extension described in policy. As mentioned previously, the extension described in
[I-D.ietf-pce-association-group] is well suited to associated a set [I-D.ietf-pce-association-group] is well suited to associate a set of
of LSPs with a particular disjoint-group. 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 should allow to overcome this Source/Extended Association ID should allow to overcome this
limitation. For example, when a PCC or PCE initiates all the LSPs in limitation as described in [I-D.ietf-pce-association-group]. When a
a particular disjoint-group, it can set the IPv4/IPv6 association PCC or PCE initiates all the LSPs in a particular disjoint-group, it
source can be set to one of its IP address. When disjoint LSPs are can set the IPv4/IPv6 association source as one of its own IP
initiated from different head-ends, a unique association identifier address. When disjoint LSPs are initiated from different head-ends,
SHOULD be used for those LSPs: this can be achieved by setting the association source could be the PCE address or any other unique value
IPv4/IPv6 source address to a common value (zero value can be used) to identify the disjoint association group.
as well as the Association ID.
Initiate & Monitor LSP 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|--.--( )--. | .--( )--. | |PE 1|--.--( )--.
V ( ) | +----+ ( ) V ( ) | +----+ ( )
+---+ ( ) | ( ) +---+ ( ) | ( )
|PCC|----( (G)MPLS network ) +----+ ( (G)MPLS network ) |PCC|----( (G)MPLS network ) +----+ ( (G)MPLS network )
+---+ ( ) |PE 3|------( ) +---+ ( ) |PE 3|-----( )
Disjoint-group X ) +----+ ( ) Disjoint-group X ) +----+ ( )
{Monitor LSP} '--( )--' '--( )--' '--( )--' '--( )--'
( ) ( ) ( ) ( )
'-----' '-----' '-----' '-----'
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 PCUpd or PCInitiate may have two Using the disjoint-group within a PCEP messages may have two purpose:
purposes:
o Information: in case the PCE is performing the path computation, o Information: in case the PCE is performing the path computation,
it may communicate to the PCC the locally used parameters in the it may communicate to the PCC the disjoint parameters.
attribute-list of the LSP.
o Configuration: in case the PCE is updating the diversity o Configuration: in case the PCC are configured with disjoint
parameters. requirements, these are communicated to the PCE.
4. Protocol extension 4. Protocol extension
4.1. Association group 4.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 ID will be used to identify the association group. The Association parameters, as described in
disjoint group a set of LSPs belongs to. This document defines a new [I-D.ietf-pce-association-group] as the combination of the mandatory
fields Association type, Association ID and Association Source in the
ASSOCIATION object, that uniquely identify the association group,
uniquely identify the disjoint group. If the optional TLVs - Global
Association Source or Extended Association ID are included, then they
are included in combination with mandatory fields to uniquely
identifying the association group. This document defines a new
Association type, based on the generic Association object - Association type, based on the generic Association object -
o Association type = TBD1 ("Disjointness Association Type"). o Association type = TBD1 ("Disjointness Association Type").
The association type is considered to be both dynamic and operator- [I-D.ietf-pce-association-group] specify the mechanism for the
configured. capability advertisement of the association types supported by a PCEP
speaker by defining a ASSOC-Type-List TLV to be carried within an
OPEN object. This capability exchange for the association type
described in this document (i.e. Disjointness Association Type) MUST
be done before using the disjointness association. Thus the PCEP
speaker MUST include the Disjointness Association Type (TBD1) in the
ASSOC-Type-List TLV before using the disjoint association group in
the PCEP messages.
This association type is considered to be both dynamic and operator-
configured in nature. The association group could be created by the
operator manually on the PCEP peers and the LSPs belonging to this
associations is conveyed via PCEP messages to the PCEP peer; or the
association group could be created dynamically by the PCEP speaker
and both the association group information and the LSPs belonging to
the association group is conveyed to the PCEP peer. The Operator-
configured Association Range MUST be set for this association-type to
mark a range of association identifiers that are used for operator-
configured associations to avoid any association identifier clash
within the scope of the association source. (Refer
[I-D.ietf-pce-association-group].)
A disjoint group can have two or more LSPs. But a PCE may be limited A disjoint group can have two or more LSPs. But a PCE may be limited
in how many LSPs it can take into account when computing in how many 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 the implementation. disjoint LSPs will be decided by PCE as a local matter.
Local polices on the PCC or PCE MAY define the computational behavior Local polices on the PCC or PCE MAY define the computational behavior
for the other LSPs in the group. For example, the PCE may provide no for the other LSPs in the group. For example, the PCE may provide no
path, a shortest path, or a constrained path based on relaxing path, a shortest path, or a constrained path based on relaxing
disjointness, etc. disjointness, etc.
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 insurance authorized from a protocol perspective, however there is no insurance
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.
4.2. Mandatory TLV 4.2. Disjoint TLVs
The disjoint group MUST carry the following TLV: The disjoint group MUST carry the following TLV:
o DISJOINTNESS-CONFIGURATION-TLV: Used to communicate some o DISJOINTNESS-CONFIGURATION-TLV: Used to communicate some
disjointness configuration parameters. disjointness configuration parameters.
In addition, the disjoint group MAY carry the following TLV in a In addition, the disjoint group MAY carry the following TLV:
PCUpd or PCRep message:
o DISJOINTNESS-STATUS-TLV: Used to communicate the status of the o DISJOINTNESS-STATUS-TLV: Used to communicate the status of the
computed disjointness. computed disjointness. This is applicable for messages from PCE
to PCC (PCUpd, PCInitiate or PCRep message).
o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor
specific behavioral information, described in [RFC7470].
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.
Length: Fixed value of 4 bytes.
Flags: Flags:
* L (Link diverse) bit: when set, this indicates that the * L (Link diverse) bit: when set, this indicates that the
computed paths within the disjoint group MUST NOT have any link computed paths within the disjoint group MUST NOT have any link
in common. in common.
* N (Node diverse) bit: when set, this indicates that the * N (Node diverse) bit: when set, this indicates that the
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.
skipping to change at page 9, line 39 skipping to change at page 10, line 22
* 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, PCE is allowed to relax disjointness be disjoint. When unset, PCE is allowed to relax disjointness
by using either applying a requested objective function or any by using either applying a requested objective function or any
other behavior if no objective function is requested (e.g.: other behavior if no objective function is requested (e.g.:
using a lower disjoint type (link instead of node) or relaxing using a lower disjoint type (link instead of node) or relaxing
disjointness constraint at all). disjointness constraint at all).
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=TBD7. (Mandatory Object missing) and Error-value=TBD7 (DISJOINTNESS-
CONFIGURATION-TLV missing).
The DISJOINTNESS-STATUS-TLV uses the same format as the DISJOINTNESS- The DISJOINTNESS-STATUS-TLV uses the same format as the DISJOINTNESS-
CONFIGURATION-TLV with a different type: CONFIGURATION-TLV with a different type TBD3 (in TLV):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = [TBD3] | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |T|P|S|N|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Any new flag defined for the DISJOINTNESS-CONFIGURATION-TLV MUST be
automatically added to the DISJOINTNESS-STATUS-TLV.
4.3. Optional TLVs
The disjoint group MAY carry some optional TLVs including but not
limited to:
o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor Any new flag defined for the DISJOINTNESS-CONFIGURATION-TLV is be
specific behavioral information, described in [RFC7150]. automatically applicable to the DISJOINTNESS-STATUS-TLV.
4.4. Disjointness objective functions 4.3. Disjointness objective functions
An objective function MAY be applied to the disjointness computation An objective function (OF) MAY be applied to the disjointness
to drive the PCE computation behavior. In this case, the OF-List TLV computation to drive the PCE computation behavior. In this case, the
(defined in ([RFC5541]) is used as an optional TLV in the Association OF-List TLV (defined in ([RFC5541]) is used as an optional TLV in the
Group Object. The PCEP OF-List TLV allow multiple OF-Codes inside Association Group Object. The PCEP OF-List TLV allow multiple OF-
the TLV, a sender SHOULD include a single OF-Code in the OF-List TLV Codes inside the TLV, a sender SHOULD include a single OF-Code in the
when included in the Association Group, and the receiver MUST OF-List TLV when included in the Association Group, and the receiver
consider the first OF-code only and ignore others if included. MUST consider the first OF-code only and ignore 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: proposed:
MSL MSL
* Name: Minimize the number of shared (common) Links. * Name: Minimize the number of shared (common) Links.
* Objective Function Code: TBD4 * Objective Function Code: TBD4
skipping to change at page 11, line 31 skipping to change at page 12, line 5
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.
o SVEC object with domain-diverse bit=1;link diverse bit=1 and o SVEC object with domain-diverse bit=1;link diverse bit=1 and
OF=MSS - full domain and node diverse path with as much as SRLG- OF=MSS - full domain and node diverse path with as much as SRLG-
diversity as possible. diversity as possible.
o SVEC object with node-diverse bit=1 and OF=MSN - ensure full node- o SVEC object with node-diverse bit=1 and OF=MSN - ensure full node-
diversity. diversity.
4.5. P-flag considerations 4.4. P-flag considerations
As mentioned in Section 4.2, the P-flag (when set) indicates that the As mentioned in Section 4.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. This could be required in some primary/backup scenarios
where the primary path should use the more optimal path available where the primary path should use the more optimal path available
(taking into account the other constraints). When disjointness is (taking into account the other constraints). When disjointness is
computed, it is important for the algorithm to know that it should 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 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 (for instance the primary path) while other paths are allowed to be
longer (compared to a similar path without the disjointness longer (compared to a similar path without the disjointness
constraint). Without such a hint, the disjointness algorithm may set constraint). Without such a hint, the disjointness algorithm may set
a path for all LSPs that may not completely fulfil the customer a path for all LSPs that may not completely fulfill the customer
requirement. requirement.
_________________________________________ _________________________________________
/ \ / \
/ +------+ \ / +------+ \
| | PCE | | | | PCE | |
| +------+ | | +------+ |
| | | |
| | | |
| +------+ 10 +------+ | | +------+ 10 +------+ |
skipping to change at page 12, line 27 skipping to change at page 12, line 43
| +------+ | | +------+ | | +------+ | | +------+ |
CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4 CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4
| +------+ \ | / +------+ | | +------+ \ | / +------+ |
| \ | 10 / | | \ | 10 / |
\ +-- R5 --------- R6 / \ +-- R5 --------- R6 /
\_________________________________________/ \_________________________________________/
Figure 3 Figure 3
In the figure above, a customer has two dual homed sites (CE1/CE3 and In the figure above, a customer has two dual homed sites (CE1/CE3 and
CE2/CE4). This customer wants two disjoint paths between the two CE2/CE4). Consider, this customer wants two disjoint paths between
sites. Due to physical meshings, the customer wants to use CE1 and the two sites. Due to physical meshing, the customer wants to use
CE2 as primary (for instance CE3 and CE4 are hosted in a remote site CE1 and CE2 as primary ( and CE3 and CE4 are hosted in a remote site
for redundancy purpose compared the customer hosts). for redundancy purpose).
Without any hint (constraint) provided, the PCE may compute the two Without any hint (constraint) provided, the PCE may compute the two
disjoint LSPs as a batch leading to PE1->PE2 using a path disjoint LSPs together, leading to PE1->PE2 using a path
PE1->R1->R2->PE2 and PE3->PE4 using PE3->R3->R4->PE4. In this case, PE1->R1->R2->PE2 and PE3->PE4 using PE3->R3->R4->PE4. In this case,
even if the disjointness constraint is fulfilled, the path from PE1 even if the disjointness constraint is fulfilled, the path from PE1
to PE2 does not use the best optimal path available in the network to PE2 does not use the best optimal path available in the network
(RTD may be higher): the customer requirement is thus not completely (RTD may be higher): the customer requirement is thus not completely
fulfilled. fulfilled.
The usage of the P-Flag allows the PCE to know that a particular LSP The usage of the P-Flag allows the PCE to know that a particular LSP
should be tied to the best path as if the disjointness constraint was should be tied to the best path as if the disjointness constraint was
not requested. not requested.
skipping to change at page 14, line 4 skipping to change at page 14, line 33
Figure 4 Figure 4
In the figure above, we still consider the same previous In the figure above, we still consider the same previous
requirements, so PE1->PE2 LSP should be optimized (P-flag set) while requirements, so PE1->PE2 LSP should be optimized (P-flag set) while
PE3->PE4 should be disjoint and may use a longer path. PE3->PE4 should be disjoint and may use a longer 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 or even use boths (using both may happen in case Segment of the paths or even use both (using both may happen in case Segment
Routing TE is used, allowing ECMP). Routing TE is used, allowing ECMP).
If the implementation elects only one path, there is a chance that If the implementation elects only one path, there is a chance that
picking up one path may prevent disjointness. In our example, if picking up one path may prevent disjointness. In our example, if
path 2 is used for PE1->PE2, there is no room left for PE3->PE4 while 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. 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 MAY select a path that allows disjointness. implementation MAY select a path that allows disjointness.
4.6. Disjointness computation issues 4.5. 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-bit is set (Strict disjointness requested), if When the T-bit is set (Strict disjointness requested), if
disjointness cannot be ensured for one or more LSPs, the PCE SHOULD disjointness cannot be ensured for one or more LSPs, the PCE SHOULD
reply with a PCUpd message containing an empty ERO. In addition to reply with a PCUpd message containing an empty ERO. In addition to
the empty ERO Object, the PCE MAY add the NO-PATH-VECTOR TLV the empty ERO Object, the PCE MAY add the NO-PATH-VECTOR TLV
([RFC5440]) in the LSP Object. ([RFC5440]) in the LSP Object.
skipping to change at page 15, line 6 skipping to change at page 15, line 35
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 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 PCE of T,S,N,L flags in the DISJOINTNESS-CONFIGURATION-TLV. If a PCE
receives PCRpt messages for LSPs belonging to the same disjoint group receives PCRpt messages for LSPs belonging to the same disjoint group
but having an inconsistent combination of T,S,N,L flags, the PCE but having an inconsistent combination of T,S,N,L flags, the PCE
SHOULD NOT try to compute disjointness path and SHOULD reply a PCErr SHOULD NOT try to compute disjointness path and SHOULD reply a PCErr
with Error-type 5 (Policy Violation) and Error-Value TBD6 with Error-type 26 (Association Error) and Error-Value 6 (Association
(Inconsistent parameters in DISJOINTNESS-CONFIGURATION TLV) to all information mismatch) to all PCCs involved in the disjoint group.
PCCs involved in the disjoint group.
5. Security Considerations 5. Security Considerations
This document defines one new type for association, which do not add This document defines one new type for association, which do not add
any new security concerns beyond those discussed in [RFC5440], any new security concerns beyond those discussed in [RFC5440],
[RFC8231] and [I-D.ietf-pce-association-group] in itself. [RFC8231] and [I-D.ietf-pce-association-group] in itself.
6. IANA Considerations 6. IANA Considerations
6.1. Association object Type Indicators 6.1. Association object Type Indicators
This document defines the following new association type originally This document defines the following new association type originally
defined in [I-D.ietf-pce-association-group]. defined in [I-D.ietf-pce-association-group].
Value Name Reference Value Name Reference
TBD1 Disjoint-group TBD1 Disjoint-group
Association Type [This I.D.] Association Type [This I.D.]
6.2. PCEP TLVs 6.2. PCEP TLVs
This document defines the following new PCEP TLVs: This document defines the following new PCEP TLVs:
Value Name Reference Value 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.]
IANA is requested to manage the space of flags carried in the IANA is requested to manage the space of flags carried in the
DISJOINTNESS-CONFIGURATION-TLV defined in this document, numbering DISJOINTNESS-CONFIGURATION-TLV defined in this document, numbering
them from 0 as the least significant bit. them from 0 as the least significant bit.
New bit numbers may be allocated in future. New bit numbers may be allocated in future.
IANA is requested to allocate the following bit numbers in the IANA is requested to allocate the following bit numbers in the
DISJOINTNESS-CONFIGURATION-TLV flag space: DISJOINTNESS-CONFIGURATION-TLV flag space:
Bit Number Name Reference Bit Number Name Reference
0 Link disjointness [This I.D.] 0 Link disjointness [This I.D.]
1 Node disjointness [This I.D.] 1 Node disjointness [This I.D.]
2 SRLG disjointness [This I.D.] 2 SRLG disjointness [This I.D.]
3 Shortest-path [This I.D.] 3 Shortest-path [This I.D.]
4 Strict disjointness [This I.D.] 4 Strict disjointness [This I.D.]
6.3. Objective Functions 6.3. Objective Functions
three new Objective Functions have been defined. IANA has made the three new Objective Functions have been defined. IANA has made the
following allocations from the PCEP "Objective Function" sub- following allocations from the PCEP "Objective Function" sub-
registry: registry:
Value Description Reference Value Description Reference
TBD4 MSL [This I.D.] TBD4 MSL [This I.D.]
TBD5 MSN [This I.D.] TBD5 MSN [This I.D.]
TBD6 MSS [This I.D.] TBD6 MSS [This I.D.]
6.4. NO-PATH-VECTOR bit Flags 6.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: Element Protocol (PCEP) Numbers" registry:
Bit Number Name Reference Bit Number Name Reference
TBD7 Disjoint path not found [This I.D.] TBD7 Disjoint path not found [This I.D.]
TBD8 Requested disjointness [This I.D.] TBD8 Requested disjointness [This I.D.]
computation not supported computation not supported
6.5. PCEP-ERROR codes 6.5. PCEP-ERROR codes
IANA is requested to allocate new Error Types and Error Values within IANA is requested to allocate new Error Types and Error Values within
the " PCEP-ERROR Object Error Types and Values" sub-registry of the the " PCEP-ERROR Object Error Types and Values" sub-registry of the
PCEP Numbers registry, as follows: PCEP Numbers registry, as follows:
Error-Type Meaning Error-Type Meaning
5 Policy violation 6 Mandatory Object missing
Error-value=TBD6: Inconsistent parameters Error-value=TBD7: DISJOINTNESS-CONFIGURATION
in DISJOINTNESS-CONFIGURATION TLV TLV missing
6 Mandatory Object missing
Error-value=TBD7: DISJOINTNESS-CONFIGURATION TLV missing
7. Manageability Considerations 7. Manageability Considerations
7.1. Control of Function and Policy 7.1. Control of Function and Policy
An operator MUST be allowed to configure the disjointness An operator MUST be allowed to configure the disjointness
associations and parameters at PCEP peers and associate it with the associations and parameters at PCEP peers and associate it with the
LSPs. LSPs.
7.2. Information and Data Models 7.2. Information and Data Models
skipping to change at page 17, line 47 skipping to change at page 18, line 25
9. References 9. References
9.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>.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[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>.
[I-D.ietf-pce-association-group] [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
Dhody, D., and Y. Tanaka, "PCEP Extensions for May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Establishing Relationships Between Sets of LSPs", draft-
ietf-pce-association-group-04 (work in progress), August
2017.
[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>.
[I-D.ietf-pce-association-group]
Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H.,
Dhody, D., and Y. Tanaka, "PCEP Extensions for
Establishing Relationships Between Sets of LSPs", draft-
ietf-pce-association-group-06 (work in progress), June
2018.
9.2. Informative References 9.2. Informative References
[RFC7150] Zhang, F. and A. Farrel, "Conveying Vendor-Specific [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[RFC6007] Nishioka, I. and D. King, "Use of the Synchronization
VECtor (SVEC) List for Synchronized Dependent Path
Computations", RFC 6007, DOI 10.17487/RFC6007, September
2010, <https://www.rfc-editor.org/info/rfc6007>.
[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 7150, DOI 10.17487/RFC7150, March 2014, Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015,
<https://www.rfc-editor.org/info/rfc7150>. <https://www.rfc-editor.org/info/rfc7470>.
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
Hardwick, "Path Computation Element Communication Protocol Hardwick, "Path Computation Element Communication Protocol
(PCEP) Management Information Base (MIB) Module", (PCEP) Management Information Base (MIB) Module",
RFC 7420, DOI 10.17487/RFC7420, December 2014, RFC 7420, DOI 10.17487/RFC7420, December 2014,
<https://www.rfc-editor.org/info/rfc7420>. <https://www.rfc-editor.org/info/rfc7420>.
[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
 End of changes. 56 change blocks. 
188 lines changed or deleted 210 lines changed or added

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