< draft-litkowski-pce-state-sync-05.txt   draft-litkowski-pce-state-sync-06.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: September 9, 2019 Cisco Expires: January 8, 2020 Cisco
C. Li C. Li
H. Zheng H. Zheng
Huawei Technologies Huawei Technologies
March 8, 2019 July 7, 2019
Inter Stateful Path Computation Element (PCE) Communication Procedures. Inter Stateful Path Computation Element (PCE) Communication Procedures.
draft-litkowski-pce-state-sync-05 draft-litkowski-pce-state-sync-06
Abstract Abstract
The Path Computation Element communication Protocol (PCEP) provides The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs) requests. computations in response to Path Computation Clients (PCCs) requests.
The stateful PCE extensions allow stateful control of Multi-Protocol The stateful PCE extensions allow stateful control of Multi-Protocol
Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE
LSPs) using PCEP. LSPs) using PCEP.
A Path Computation Client (PCC) can synchronize an LSP state A Path Computation Client (PCC) can synchronize an LSP state
information to a Stateful Path Computation Element (PCE). The information to a Stateful Path Computation Element (PCE). The
stateful PCE extension allows a redundancy scenario where a PCC can stateful PCE extension allows a redundancy scenario where a PCC can
have redundant PCEP sessions towards multiple PCEs. In such a case, have redundant PCEP sessions towards multiple PCEs. In such a case,
a PCC gives control on a LSP to only a single PCE, and only one PCE a PCC gives control on a LSP to only a single PCE, and only one PCE
is responsible for path computation for this delegated LSP. The is responsible for path computation for this delegated LSP. The
document does not state the procedures related to an inter-PCE document does not state the procedures related to an inter-PCE
stateful communication. stateful communication.
There are some use cases, where an inter-PCE stateful communication There are some use cases, where an inter-PCE stateful communication
can bring additional resiliency in the design, for instance when some can bring additional resiliency in the design, for instance when some
PCC-PCE sessions fails. The inter-PCE stateful communication may PCC-PCE sessions fails. The inter-PCE stateful communication may
also provide a faster update of the LSP states when an event occurs. also provide a faster update of the LSP states when such an event
Finally, when, in a redundant PCE scenario, there is a need to occurs. Finally, when, in a redundant PCE scenario, there is a need
compute a set of paths that are part of a group (so there is a to compute a set of paths that are part of a group (so there is a
dependency between the paths), there may be some cases where the dependency between the paths), there may be some cases where the
computation of all paths in the group is not handled by the same PCE: computation of all paths in the group is not handled by the same PCE:
this situation is called a split-brain. This split-brain scenario this situation is called a split-brain. This split-brain scenario
may lead to computation loops between PCEs or suboptimal path may lead to computation loops between PCEs or suboptimal path
computation. computation.
This document describes the procedures to allow a stateful This document describes the procedures to allow a stateful
communication between PCEs for various use-cases and also the communication between PCEs for various use-cases and also the
procedures to prevent computations loops. procedures to prevent computations loops.
skipping to change at page 2, line 28 skipping to change at page 2, line 28
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 September 9, 2019. This Internet-Draft will expire on January 8, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and problem statement . . . . . . . . . . . . . 3 1. Introduction and Problem Statement . . . . . . . . . . . . . 3
1.1. Reporting LSP changes . . . . . . . . . . . . . . . . . . 3 1.1. Reporting LSP changes . . . . . . . . . . . . . . . . . . 4
1.2. Split-brain . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Split-brain . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Applicability to H-PCE . . . . . . . . . . . . . . . . . 11 1.3. Applicability to H-PCE . . . . . . . . . . . . . . . . . 12
2. Proposed solution . . . . . . . . . . . . . . . . . . . . . . 11 2. Proposed solution . . . . . . . . . . . . . . . . . . . . . . 12
2.1. State-sync session . . . . . . . . . . . . . . . . . . . 11 2.1. State-sync session . . . . . . . . . . . . . . . . . . . 12
2.2. Master/Slave relationship between PCE . . . . . . . . . . 13 2.2. Master/Slave relationship between PCE . . . . . . . . . . 14
3. Procedures and protocol extensions . . . . . . . . . . . . . 13 3. Procedures and Protocol Extensions . . . . . . . . . . . . . 14
3.1. Opening a state-sync session . . . . . . . . . . . . . . 13 3.1. Opening a state-sync session . . . . . . . . . . . . . . 14
3.1.1. Capability advertisement . . . . . . . . . . . . . . 13 3.1.1. Capability Advertisement . . . . . . . . . . . . . . 14
3.2. State synchronization . . . . . . . . . . . . . . . . . . 14 3.2. State synchronization . . . . . . . . . . . . . . . . . . 15
3.3. Incremental updates and report forwarding rules . . . . . 14 3.3. Incremental updates and report forwarding rules . . . . . 16
3.4. Maintaining LSP states from different sources . . . . . . 16 3.4. Maintaining LSP states from different sources . . . . . . 17
3.5. Computation priority between PCEs and sub-delegation . . 16 3.5. Computation priority between PCEs and sub-delegation . . 18
3.6. Passive stateful procedures . . . . . . . . . . . . . . . 18 3.6. Passive stateful procedures . . . . . . . . . . . . . . . 19
3.7. PCE initiation procedures . . . . . . . . . . . . . . . . 18 3.7. PCE initiation procedures . . . . . . . . . . . . . . . . 20
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 19 4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 20 4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 22 4.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 24
5. Using Master/Slave computation and state-sync sessions to 5. Using Master/Slave computation and state-sync sessions to
increase scaling . . . . . . . . . . . . . . . . . . . . . . 23 increase scaling . . . . . . . . . . . . . . . . . . . . . . 25
6. PCEP-PATH-VECTOR-TLV . . . . . . . . . . . . . . . . . . . . 25 6. PCEP-PATH-VECTOR-TLV . . . . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
9.1. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 26 9.1. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 28
9.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 26 9.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 28
9.3. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 27 9.3. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Normative References . . . . . . . . . . . . . . . . . . 27 10.1. Normative References . . . . . . . . . . . . . . . . . . 29
10.2. Informative References . . . . . . . . . . . . . . . . . 27 10.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 28 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction and problem statement 1. Introduction and Problem Statement
The Path Computation Element communication Protocol (PCEP) [RFC5440]"
provides mechanisms for Path Computation Elements (PCEs) to perform
path computations in response to Path Computation Clients' (PCCs)
requests.
A stateful PCE [RFC8231] is capable of considering, for the purposes
of path computation, not only the network state in terms of links and
nodes (referred to as the Traffic Engineering Database or TED) but
also the status of active services (previously computed paths, and
currently reserved resources, stored in the Label Switched Paths
Database (LSP-DB).
[RFC8051] describes general considerations for a stateful PCE
deployment and examines its applicability and benefits, as well as
its challenges and limitations through a number of use cases.
The examples in this section are for illustrative purpose to showcase
the need for inter-PCE stateful PCEP sessions.
1.1. Reporting LSP changes 1.1. Reporting LSP changes
When using a stateful PCE ([RFC8231]), a Path Computation Client When using a stateful PCE ([RFC8231]), a PCC can synchronize an LSP
(PCC) can synchronize an LSP state information to the stateful Path state information to the stateful PCE. If the PCC grants the control
Computation Element (PCE). If the PCC grants the control on the LSP on the LSP to the PCE (called delegation [RFC8231]), the PCE can
to the PCE (called delegation [RFC8231]), the PCE can update the LSP update the LSP parameters at any time.
parameters at any time.
In a multi PCE deployment (redundancy, loadbalancing...), with the In a multi PCE deployment (redundancy, loadbalancing...), with the
current specification defined in [RFC8231], when a PCE makes an current specification defined in [RFC8231], when a PCE makes an
update, it is the PCC that is in charge of reporting the LSP status update, it is the PCC that is in charge of reporting the LSP status
to all PCEs with LSP parameter change which brings additional hops to all PCEs with LSP parameter change which brings additional hops
and delays in notifying the overall network of the LSP parameter and delays in notifying the overall network of the LSP parameter
change. change.
This delay may affect the reaction time of the other PCEs, if they This delay may affect the reaction time of the other PCEs, if they
need to take action after being notified of the LSP parameter change. need to take action after being notified of the LSP parameter change.
skipping to change at page 4, line 25 skipping to change at page 4, line 45
/ \ / \
+---------+ +---------+ +---------+ +---------+
| PCE1 | | PCE2 | | PCE1 | | PCE2 |
+---------+ +---------+ +---------+ +---------+
\ / \ /
\ / \ /
+----------+ +----------+
| PCC2 | LSP2 | PCC2 | LSP2
+----------+ +----------+
In the figure above, we consider a loadbalanced PCE architecture, so In the figure above, we consider a load-balanced PCE architecture, so
PCE1 is responsible to compute paths for PCC1 and PCE2 is responsible PCE1 is responsible to compute paths for PCC1 and PCE2 is responsible
to compute paths for PCC2. When PCE1 triggers an LSP update for to compute paths for PCC2. When PCE1 triggers an LSP update for
LSP1, it sends a PCUpd message to PCC1 for LSP1 containing the new LSP1, it sends a PCUpd message to PCC1 containing the new parameters
parameters. PCC1 will take the parameters into account and will send for LSP1. PCC1 will take the parameters into account and will send a
a PCRpt message to PCE1 and PCE2 reflecting the changes. PCE2 will PCRpt message to PCE1 and PCE2 reflecting the changes. PCE2 will so
so be notified of the change only after receiving the PCRpt message be notified of the change only after receiving the PCRpt message from
from PCC1. PCC1.
Let's consider that the LSP1 parameters changed in such a way that Let's consider that the LSP1 parameters changed in such a way that
LSP1 will take over resources from LSP2 with a higher priority. LSP1 will take over resources from LSP2 with a higher priority.
After receiving the report from PCC1, PCE2 will therefore try to find After receiving the report from PCC1, PCE2 will therefore try to find
a new path for LSP2. If we consider that there is a round trip delay a new path for LSP2. If we consider that there is a round trip delay
of about 150msec between the PCEs and PCC1 and a round trip delay of of about 150 milliseconds (ms) between the PCEs and PCC1 and a round
10msec between the two PCEs, if will take more than 150msec for PCE2 trip delay of 10 ms between the two PCEs, if will take more than 150
to be notified of the change. ms for PCE2 to be notified of the change.
Adding a PCEP session between PCE1 and PCE2 may allow to reduce the Adding a PCEP session between PCE1 and PCE2 may allow to reduce the
syncronization time, so PCE2 can react more quickly by taking the synchronization time, so PCE2 can react more quickly by taking the
pending LSPs and attached resources into account during path pending LSPs and attached resources into account during path
computation and reoptimization. computation and reoptimization.
1.2. Split-brain 1.2. Split-brain
In a resiliency case, a PCC has redundant PCEP sessions towards In a resiliency case, a PCC has redundant PCEP sessions towards
multiple PCEs. In such a case, a PCC gives control on an LSP to a multiple PCEs. In such a case, a PCC gives control on an LSP to a
single PCE only, and only this PCE is responsible for the path single PCE only, and only this PCE is responsible for the path
computation for the delegated LSP: the PCC achieves this by setting computation for the delegated LSP: the PCC achieves this by setting
the D flag only towards the active PCE [RFC8231]. The election of the D flag only towards the active PCE [RFC8231] selected for
the active PCE to delegate an LSP is controlled by each PCC. The PCC delegation. The election of the active PCE to delegate an LSP is
usually elects the active PCE by a local configured policy (by controlled by each PCC. The PCC usually elects the active PCE by a
setting a priority). Upon PCEP session failure, or active PCE local configured policy (by setting a priority). Upon PCEP session
failure, PCC may decide to elect a new active PCE by sending new failure, or active PCE failure, PCC may decide to elect a new active
PCRpt message with D flag set to this new active PCE. When the PCE by sending new PCRpt message with D flag set to this new active
failed PCE or PCEP session comes back online, it will be up to the PCE. When the failed PCE or PCEP session comes back online, it will
implementation to do preemption. Doing preemption may lead to some be up to the implementation to do pre-emption. Doing pre-emption may
traffic disruption on the existing path if path results from both lead to some disruption on the existing path if path results from
PCEs are not exactly the same. By considering a network with both PCEs are not exactly the same. By considering a network with
multiple PCCs and implementing multiple stateful PCEs for redundancy multiple PCCs and implementing multiple stateful PCEs for redundancy
purpose, there is no guarantee that at any time all the PCCs delegate purpose, there is no guarantee that at any time all the PCCs delegate
their LSPs to the same PCE. their LSPs to the same PCE.
+----------+ +----------+
| PCC1 | LSP1 | PCC1 | LSP1
+----------+ +----------+
/ \ / \
/ \ / \
+---------+ +---------+ +---------+ +---------+
| PCE1 | | PCE2 | | PCE1 | | PCE2 |
+---------+ +---------+ +---------+ +---------+
\ / \ /
*fail* \ / *fail* \ /
+----------+ +----------+
| PCC2 | LSP2 | PCC2 | LSP2
+----------+ +----------+
In the example above, we consider that by configuration, both PCCs In the example above, we consider that by configuration, both PCCs
will firstly delegate their LSP to PCE1. So PCE1 is responsible for will firstly delegate their LSPs to PCE1. So, PCE1 is responsible
computing a path for LSP1 and LSP2. If the PCEP session between PCC2 for computing a path for both LSP1 and LSP2. If the PCEP session
and PCE1 fails, PCC2 will delegate LSP2 to PCE2. So PCE1 becomes between PCC2 and PCE1 fails, PCC2 will delegate LSP2 to PCE2. So
responsible only for LSP1 path computation while PCE2 is responsible PCE1 becomes responsible only for LSP1 path computation while PCE2 is
for the path computation of LSP2. When the PCC2-PCE1 session is back responsible for the path computation of LSP2. When the PCC2-PCE1
online, PCC2 will keep using PCE2 as active PCE (no preemption in session is back online, PCC2 will keep using PCE2 as active PCE
this example). So the result is a permanent situation where each PCE (consider no pre-emption in this example). So the result is a
is responsible for a subset of path computation. permanent situation where each PCE is responsible for a subset of
path computation.
We call this situation a split-brain scenario as there are multiple This situation is called a split-brain scenario, as there are
computation brains running at the same time while a central multiple computation brains running at the same time while a central
computation unit was required in some deployments/usecases. computation unit was required in some deployments/usecases.
Further, there are use cases where a particular LSP path computation Further, there are use cases where a particular LSP path computation
is linked to another LSP path computation: the most common use case is linked to another LSP path computation: the most common use case
is path disjointness (see [I-D.ietf-pce-association-diversity]). The is path disjointness (see [I-D.ietf-pce-association-diversity]). The
set of LSPs that are dependant to each other may start from a set of LSPs that are dependant to each other may start from a
different head-end. different head-end.
_________________________________________ _________________________________________
/ \ / \
skipping to change at page 6, line 44 skipping to change at page 7, line 42
| | | | | | | |
| | | | | | | |
| +------+ | | +------+ | | +------+ | | +------+ |
| | PCC3 | ----- R3 ---- R4 ------- | PCC4 | | | | PCC3 | ----- R3 ---- R4 ------- | PCC4 | |
| +------+ +------+ | | +------+ +------+ |
| | | |
\ / \ /
\_________________________________________/ \_________________________________________/
In the figure above, the requirement is to create two link-disjoint In the figure above, the requirement is to create two link-disjoint
LSPs: PCC1->PCC2 and PCC3->PCC4. In the topology, all link metrics LSPs: PCC1->PCC2 and PCC3->PCC4. In the topology, all links cost
are equal to 1 except the link R1-R2 which has a metric of 10. The metric is set to 1 except for the link 'R1-R2' which has a metric of
PCEs are responsible for the path computation and PCE1 is the active 10. The PCEs are responsible for the path computation and PCE1 is
PCE for all PCCs in the nominal case. the active primary PCE for all PCCs in the nominal case.
Scenario 1: Scenario 1:
In the normal case (PCE1 as active PCE), we first configure In the normal case (PCE1 as active primary PCE), consider that
PCC1->PCC2 LSP, as the only constraint is path disjointness, PCE1 PCC1->PCC2 LSP is configured first with the link disjointness
sends a PCUpd message to PCC1 with the ERO: R1->R3->R4->R2->PCC2 constraint, PCE1 sends a PCUpd message to PCC1 with the ERO:
(shortest path). PCC1 signals and installs the path. When R1->R3->R4->R2->PCC2 (shortest path). PCC1 signals and installs the
PCC3->PCC4 is configured, the PCE already knows the path of path. When PCC3->PCC4 is configured, the PCEs already knows the path
PCC1->PCC2 and can compute a link-disjoint path : the solution of PCC1->PCC2 and can compute a link-disjoint path : the solution
requires to move PCC1->PCC2 onto a new path to let room for the new requires to move PCC1->PCC2 onto a new path to let room for the new
LSP. PCE1 sends a PCUpd message to PCC1 with the new ERO: LSP. PCE1 sends a PCUpd message to PCC1 with the new ERO:
R1->R2->PCC2 and a PCUpd to PCC3 with the following ERO: R1->R2->PCC2 and a PCUpd to PCC3 with the following ERO:
R3->R4->PCC4. In the normal case, there is no issue for PCE1 to R3->R4->PCC4. In the normal case, there is no issue for PCE1 to
compute a link-disjoint path. compute a link-disjoint path.
Scenario 2: Scenario 2:
Now we consider that PCC1 lost its PCEP session with PCE1 (all other Consider that PCC1 lost its PCEP session with PCE1 (all other PCEP
PCEP sessions are UP). PCC1 delegates its LSP to PCE2. sessions are UP). PCC1 delegates its LSP to PCE2.
+----------+ +----------+
| PCC1 | LSP: PCC1->PCC2 | PCC1 | LSP: PCC1->PCC2
+----------+ +----------+
\ \
\ D=1 \ D=1
+---------+ +---------+ +---------+ +---------+
| PCE1 | | PCE2 | | PCE1 | | PCE2 |
+---------+ +---------+ +---------+ +---------+
D=1 \ / D=0 D=1 \ / D=0
\ / \ /
+----------+ +----------+
| PCC3 | LSP: PCC3->PCC4 | PCC3 | LSP: PCC3->PCC4
+----------+ +----------+
We first configure PCC1->PCC2 LSP, as the only constraint is path Consider that the PCC1->PCC2 LSP is configured first with the link
disjointness, PCE2 (which is the new active PCE for PCC1) sends a disjointness constraint, PCE2 (which is the new active primary PCE
PCUpd message to PCC1 with the ERO: R1->32->R4->R2->PCC2 (shortest for PCC1) sends a PCUpd message to PCC1 with the ERO:
path). When PCC3->PCC4 is configured, PCE1 is not aware of LSPs from R1->R3->R4->R2->PCC2 (shortest path). When PCC3->PCC4 is configured,
PCC1 anymore, so it cannot compute a disjoint path for PCC3->PCC4 and PCE1 is not aware of LSPs from PCC1 any more, so it cannot compute a
will send a PCUpd message to PCC2 with a shortest path ERO: disjoint path for PCC3->PCC4 and will send a PCUpd message to PCC3
R3->R4->PCC4. When PCC3->PCC4 LSP will be reported to PCE2 by PCC2, with a shortest path ERO: R3->R4->PCC4. When PCC3->PCC4 LSP will be
PCE2 will ensure disjointness computation and will correctly move reported to PCE2 by PCC3, PCE2 will ensure disjointness computation
PCC1->PCC2 (as it owns delegation for this LSP) on the following and will correctly move PCC1->PCC2 (as it owns delegation for this
path: R1->R2->PCC2. With this sequence of event and this PCEP LSP) on the following path: R1->R2->PCC2. With this sequence of
session topology, disjointness is ensured. event and these PCEP sessions, disjointness is ensured.
Scenario 3: Scenario 3:
+----------+ +----------+
| PCC1 | LSP: PCC1->PCC2 | PCC1 | LSP: PCC1->PCC2
+----------+ +----------+
/ \ / \
D=1 / \ D=0 D=1 / \ D=0
+---------+ +---------+ +---------+ +---------+
| PCE1 | | PCE2 | | PCE1 | | PCE2 |
+---------+ +---------+ +---------+ +---------+
/ D=1 / D=1
/ /
+----------+ +----------+
| PCC3 | LSP: PCC3->PCC4 | PCC3 | LSP: PCC3->PCC4
+----------+ +----------+
With this new PCEP session topology, we first configure PCC1->PCC2, Consider the above PCEP sessions and the PCC1->PCC2 LSP is configured
PCE1 computes the shortest path as it is the only LSP in the disjoint first with the link disjointness constraint, PCE1 computes the
association group that it is aware of: R1->R3->R4->R2->PCC2 (shortest shortest path as it is the only LSP in the disjoint association group
path). When PCC3->PCC4 is configured, PCE2 must compute a disjoint that it is aware of: R1->R3->R4->R2->PCC2 (shortest path). When
path for this LSP. The only solution found is to move PCC1->PCC2 LSP PCC3->PCC4 is configured, PCE2 must compute a disjoint path for this
on another path, but PCE2 cannot do it as it does not have delegation LSP. The only solution found is to move PCC1->PCC2 LSP on another
for this LSP. In this setup, PCEs are not able to find a disjoint path, but PCE2 cannot do it as it does not have delegation for this
path. LSP. In this set-up, PCEs are not able to find a disjoint path.
Scenario 4: Scenario 4:
+----------+ +----------+
| PCC1 | LSP: PCC1->PCC2 | PCC1 | LSP: PCC1->PCC2
+----------+ +----------+
/ \ / \
D=1 / \ D=0 D=1 / \ D=0
+---------+ +---------+ +---------+ +---------+
| PCE1 | | PCE2 | | PCE1 | | PCE2 |
+---------+ +---------+ +---------+ +---------+
D=0 \ / D=1 D=0 \ / D=1
\ / \ /
+----------+ +----------+
| PCC3 | LSP: PCC3->PCC4 | PCC3 | LSP: PCC3->PCC4
+----------+ +----------+
With this new PCEP session topology, we consider that PCEs are Consider the above PCEP sessions and that PCEs are configured to
configured to fallback to shortest path if disjointness cannot be fallback to shortest path if disjointness cannot be found as
found. We first configure PCC1->PCC2, PCE1 computes shortest path as described in [I-D.ietf-pce-association-diversity]. The PCC1->PCC2
it is the only LSP in the disjoint association group that it is aware LSP is configured first, PCE1 computes shortest path as it is the
of: R1->R3->R4->R2->PCC2 (shortest path). When PCC3->PCC4 is only LSP in the disjoint association group that it is aware of:
configured, PCE2 must compute a disjoint path for this LSP. The only R1->R3->R4->R2->PCC2 (shortest path). When PCC3->PCC4 is configured,
solution found is to move PCC1->PCC2 LSP on another path, but PCE2 PCE2 must compute a disjoint path for this LSP. The only solution
cannot do it as it does not have delegation for this LSP. PCE2 then found is to move PCC1->PCC2 LSP on another path, but PCE2 cannot do
provides shortest path for PCC3->PCC4: R3->R4->PCC4. When PCC3 it as it does not have delegation for this LSP. PCE2 then provides
receives the ERO, it reports it back to both PCEs. When PCE1 becomes shortest path for PCC3->PCC4: R3->R4->PCC4. When PCC3 receives the
aware of PCC3->PCC4 path, it recomputes the constrained shortest path ERO, it reports it back to both PCEs. When PCE1 becomes aware of
first (CSPF) algorithm and provides a new path for PCC1->PCC2: PCC3->PCC4 path, it recomputes the constrained shortest path first
(CSPF) algorithm and provides a new path for PCC1->PCC2:
R1->R2->PCC2. The new path is reported back to all PCEs by PCC1. R1->R2->PCC2. The new path is reported back to all PCEs by PCC1.
PCE2 recomputes also CSPF to take into account the new reported path. PCE2 recomputes also CSPF to take into account the new reported path.
The new computation does not lead to any path update. The new computation does not lead to any path update.
Scenario 5: Scenario 5:
_____________________________________ _____________________________________
/ \ / \
/ +------+ +------+ \ / +------+ +------+ \
| | PCE1 | | PCE2 | | | | PCE1 | | PCE2 | |
skipping to change at page 9, line 34 skipping to change at page 10, line 35
| | | | | | | | | |
| 6 | | 2 | 2 | | 6 | | 2 | 2 |
| | | | | | | | | |
| +------+ | +------+ | | +------+ | +------+ |
| | PCC3 | ----- R3 ----------- | PCC4 | | | | PCC3 | ----- R3 ----------- | PCC4 | |
| +------+ 10 +------+ | | +------+ 10 +------+ |
| | | |
\ / \ /
\_____________________________________/ \_____________________________________/
Now we consider a new network topology with the same PCEP session Now, consider a new network topology with the same PCEP sessions as
topology as the previous example. We configure both LSPs almost at the previous example. Suppose that both LSPs are configured almost
the same time. PCE1 will compute a path for PCC1->PCC2 while PCE2 at the same time. PCE1 will compute a path for PCC1->PCC2 while PCE2
will compute a path for PCC3->PCC4. As each other is not aware of will compute a path for PCC3->PCC4. As each PCE is not aware of the
the path of the second LSP in the association group (not reported path of the second LSP in the association group (not reported yet),
yet), each PCE is computing shortest path for the LSP. PCE1 computes each PCE is computing shortest path for the LSP. PCE1 computes ERO:
ERO: R1->PCC2 for PCC1->PCC2 and PCE2 computes ERO: R1->PCC2 for PCC1->PCC2 and PCE2 computes ERO: R3->R1->PCC2->PCC4 for
R3->R1->PCC2->PCC4 for PCC3->PCC4. When these shortest paths will be PCC3->PCC4. When these shortest paths will be reported to each PCE.
reported to each PCE. Each PCE will recompute disjointness. PCE1 Each PCE will recompute disjointness. PCE1 will provide a new path
will provide a new path for PCC1->PCC2 with ERO: PCC1->PCC2. PCE2 for PCC1->PCC2 with ERO: PCC1->PCC2. PCE2 will provide also a new
will provide also a new path for PCC3->PCC4 with ERO: R3->PCC4. When path for PCC3->PCC4 with ERO: R3->PCC4. When those new paths will be
those new paths will be reported to both PCEs, this will trigger CSPF reported to both PCEs, this will trigger CSPF again. PCE1 will
again. PCE1 will provide a new more optimal path for PCC1->PCC2 with provide a new more optimal path for PCC1->PCC2 with ERO: R1->PCC2 and
ERO: R1->PCC2 and PCE2 will also provide a more optimal path for PCE2 will also provide a more optimal path for PCC3->PCC4 with ERO:
PCC3->PCC4 with ERO: R3->R1->PCC2->PCC4. So we come back to the R3->R1->PCC2->PCC4. So we come back to the initial state. When
initial state. When those paths will be reported to both PCEs, this those paths will be reported to both PCEs, this will trigger CSPF
will trigger CSPF again. An infinite loop of CSPF computation is again. An infinite loop of CSPF computation is then happening with a
then happening with a permanent flap of paths because of the split- permanent flap of paths because of the split-brain situation.
brain situation.
This permanent computation loop comes from the inconsistency between This permanent computation loop comes from the inconsistency between
the state of the LSPs as seen by each PCE due to the split-brain: the state of the LSPs as seen by each PCE due to the split-brain:
each PCE is trying to modify at the same time its delegated path each PCE is trying to modify at the same time its delegated path
based on the last received path information which defacto invalidates based on the last received path information which de facto
this received path information. invalidates this received path information.
Scenario 6: multi-domain Scenario 6: multi-domain
Domain/Area 1 Domain/Area 2 Domain/Area 1 Domain/Area 2
________________ ________________ ________________ ________________
/ \ / \ / \ / \
/ +------+ | | +------+ \ / +------+ | | +------+ \
| | PCE1 | | | | PCE3 | | | | PCE1 | | | | PCE3 | |
| +------+ | | +------+ | | +------+ | | +------+ |
| | | | | | | |
skipping to change at page 10, line 38 skipping to change at page 11, line 38
| | PCC1 | | | | PCC2 | | | | PCC1 | | | | PCC2 | |
| +------+ | | +------+ | | +------+ | | +------+ |
| | | | | | | |
| | | | | | | |
| +------+ | | +------+ | | +------+ | | +------+ |
| | PCC3 | | | | PCC4 | | | | PCC3 | | | | PCC4 | |
| +------+ | | +------+ | | +------+ | | +------+ |
\ | | | \ | | |
\_______________/ \________________/ \_______________/ \________________/
In the example above, we want to create disjoint LSPs from PCC1 to In the example above, suppose that the disjoint LSPs from PCC1 to
PCC2 and from PCC4 to PCC3. All the PCEs have the knowledge of both PCC2 and from PCC4 to PCC3 are created. All the PCEs have the
domain topologies (e.g. using BGP-LS). For operation/management knowledge of both domain topologies (e.g. using BGP-LS [RFC7752]).
reason, each domain uses its own group of redundant PCEs. PCE1/PCE2 For operation/management reason, each domain uses its own group of
in domain 1 have PCEP sessions with PCC1 and PCC3 while PCE3/PCE4 in redundant PCEs. PCE1/PCE2 in domain 1 have PCEP sessions with PCC1
domain 2 have PCEP sessions with PCC2 and PCC4. As PCE1/2 do not and PCC3 while PCE3/PCE4 in domain 2 have PCEP sessions with PCC2 and
know about LSPs from PCC2/4 and PCE3/4 do not know about LSPs from PCC4. As PCE1/2 do not know about LSPs from PCC2/4 and PCE3/4 do not
PCC1/3, there is no possibility to compute the disjointness know about LSPs from PCC1/3, there is no possibility to compute the
constraint. This scenario can also be seen as a split-brain disjointness constraint. This scenario can also be seen as a split-
scenario. This multi-domain architecture (with multiple groups of brain scenario. This multi-domain architecture (with multiple groups
PCEs) can also be used in a single domain, where an operator wants to of PCEs) can also be used in a single domain, where an operator wants
limit the failure domain by creating multiple groups of PCEs to limit the failure domain by creating multiple groups of PCEs
maintaining a subset of PCCs. As for the multi-domain example, there maintaining a subset of PCCs. As for the multi-domain example, there
will be no possibility to compute disjoint path starting from head- will be no possibility to compute disjoint path starting from head-
ends managed by different PCE groups. ends managed by different PCE groups.
In this document, we will propose a solution that address the In this document, we propose a solution that address the possibility
possibility to compute LSP association based constraints (like to compute LSP association based constraints (like disjointness) in
disjointness) in split-brain scenarios while preventing computation split-brain scenarios while preventing computation loops.
loops.
1.3. Applicability to H-PCE 1.3. Applicability to H-PCE
[I-D.ietf-pce-stateful-hpce] describes general considerations and use [I-D.ietf-pce-stateful-hpce] describes general considerations and use
cases for the deployment of Stateful PCE(s) using the Hierarchical cases for the deployment of Stateful PCE(s) using the Hierarchical
PCE [RFC6805] architecture. In this architecture there is a clear PCE [RFC6805] architecture. In this architecture there is a clear
need to communicate between a child stateful PCE and a parent need to communicate between a child stateful PCE and a parent
stateful PCE. The procedures and extensions as described in stateful PCE. The procedures and extensions as described in
Section 3 are equally applicable to H-PCE. Section 3 are equally applicable to H-PCE scenario.
2. Proposed solution 2. Proposed solution
Our solution is based on : Our solution is based on :
o The creation of the inter-PCE stateful PCEP session with specific o The creation of the inter-PCE stateful PCEP session with specific
procedures. procedures.
o A Master/Slave relationship between PCEs. o A Master/Slave relationship between PCEs.
2.1. State-sync session 2.1. State-sync session
We propose to create a PCEP session between the stateful PCEs. This document proposes to set-up a PCEP session between the stateful
Creating such session is already authorized by multiple scenarios PCEs. Creating such a session is already authorized by multiple
like the one described in [RFC4655] (multiple PCEs that are handling scenarios like the one described in [RFC4655] (multiple PCEs that are
part of the path computation) and [RFC6805] (hierarchical PCE) but handling part of the path computation) and [RFC6805] (hierarchical
was only focused on stateless PCEP sessions. As stateful PCE brings PCE) but was only focused on stateless PCEP sessions. As stateful
additional features (LSP state synchronization, path update ...), PCE brings additional features (LSP state synchronization, path
thus some new behaviors need to be defined. update, delegation, ...), thus some new behaviours need to be
defined.
This inter-PCE PCEP session will allow exchange of LSP states between This inter-PCE PCEP session will allow exchange of LSP states between
PCEs that would help some scenario where PCEP sessions are lost PCEs that would help some scenario where PCEP sessions are lost
between PCC and PCE. This inter-PCE PCEP session is called a state- between PCC and PCE. This inter-PCE PCEP session is called a state-
sync session. sync session.
For example, in the scenario below, there is no possibility to For example, in the scenario below, there is no possibility to
compute disjointness as there is no PCE aware of both LSPs. compute disjointness as there is no PCE that is aware of both LSPs.
+----------+ +----------+
| PCC1 | LSP: PCC1->PCC2 | PCC1 | LSP: PCC1->PCC2
+----------+ +----------+
/ /
D=1 / D=1 /
+---------+ +---------+ +---------+ +---------+
| PCE1 | | PCE2 | | PCE1 | | PCE2 |
+---------+ +---------+ +---------+ +---------+
/ D=1 / D=1
/ /
+----------+ +----------+
| PCC3 | LSP: PCC3->PCC4 | PCC3 | LSP: PCC3->PCC4
+----------+ +----------+
If we add a state-sync session, PCE1 will be able to send PCRpt If we add a state-sync session, PCE1 will be able to do state
messages for its LSP to PCE2 and PCE2 will do the same. All the PCEs synchronization via PCRpt messages for its LSP to PCE2 and PCE2 will
will be aware of all LSPs even if PCC->PCE session are down. PCEs do the same. All the PCEs will be aware of all LSPs even if PCC->PCE
will then be able to compute disjoint paths. session are down. PCEs will then be able to compute disjoint paths.
+----------+ +----------+
| PCC1 | LSP : PCC1->PCC2 | PCC1 | LSP : PCC1->PCC2
+----------+ +----------+
/ /
D=1 / D=1 /
+---------+ PCEP +---------+ +---------+ PCEP +---------+
| PCE1 | ----- | PCE2 | | PCE1 | ----- | PCE2 |
+---------+ +---------+ +---------+ +---------+
/ D=1 / D=1
/ /
+----------+ +----------+
| PCC3 | LSP : PCC3->PCC4 | PCC3 | LSP : PCC3->PCC4
+----------+ +----------+
The procedures associated with this state-sync session are defined in The procedures associated with this state-sync session are defined in
Section 3. Section 3.
Adding this state-sync session does not ensure that a path with LSP By just adding this state-sync session, it does not ensure that a
association based constraints can always be computed and does not path with LSP association based constraints can always be computed
prevent computation loop, but it increases resiliency and ensures and does not prevent computation loop, but it increases resiliency
that PCEs will have the state information for all LSPs. In addition, and ensures that PCEs will have the state information for all LSPs.
this session will allow for a PCE to update the other PCEs providing In addition, this session will allow for a PCE to update the other
a faster synchronization mechanism than relying on PCCs only. PCEs providing a faster synchronization mechanism than relying on
PCCs only.
2.2. Master/Slave relationship between PCE 2.2. Master/Slave relationship between PCE
As seen in Section 1, performing a path computation in a split-brain As seen in Section 1, performing a path computation in a split-brain
scenario (multiple PCEs responsible for computation) may provide a scenario (multiple PCEs responsible for computation) may provide a
non optimal LSP placement, no path or computation loops. To provide non optimal LSP placement, no path or computation loops. To provide
the best efficiency, an LSP association constraint based computation the best efficiency, an LSP association constraint based computation
requires that a single PCE performs the path computation for all LSPs requires that a single PCE performs the path computation for all LSPs
in the association group. Note that, it could be all LSPs belonging in the association group. Note that, it could be all LSPs belonging
to a particular association group, or all LSPs from a particular PCC, to a particular association group, or all LSPs from a particular PCC,
or all LSPs in the network that need to be delegated to a single PCE or all LSPs in the network that need to be delegated to a single PCE
based on the deployment scenarios. based on the deployment scenarios.
We propose to add a priority mechanism between PCEs to elect a single This document propose to add a priority mechanism between PCEs to
computing PCE. Using this priority mechanism, PCEs can agree on the elect a single computing PCE. Using this priority mechanism, PCEs
PCE that will be responsible for the computation for a particular can agree on the PCE that will be responsible for the computation for
association group, or set of LSPs. The priority could be set per a particular association group, or set of LSPs. The priority could
association, per PCC, or for all LSPs. How this priority is set or be set per association, per PCC, or for all LSPs. How this priority
advertised is out of scope of this document. The rest of the text is set or advertised is out of scope of this document. The rest of
consider association group as an example. the text consider association group as an example.
When a single PCE is performing the computation for a particular When a single PCE is performing the computation for a particular
association group, no computation loop can happen and an optimal association group, no computation loop can happen and an optimal
placement will be provided. The other PCEs will only act as state placement will be provided. The other PCEs will only act as state
collectors and forwarders. collectors and forwarders.
In the scenario described in Section 2.1, PCE1 and PCE2 will decide In the scenario described in Section 2.1, PCE1 and PCE2 will decide
that PCE1 will be responsible for the path computation of both LSPs. that PCE1 will be responsible for the path computation of both LSPs.
If we first configure PCC1->PCC2, PCE1 computes shortest path at it If we first configure PCC1->PCC2, PCE1 computes shortest path at it
is the only LSP in the disjoint-group that it is aware of: is the only LSP in the disjoint-group that it is aware of:
R1->R3->R4->R2->PCC2 (shortest path). When PCC3->PCC4 is configured, R1->R3->R4->R2->PCC2 (shortest path). When PCC3->PCC4 is configured,
PCE2 will not perform computation even if it has delegation but PCE2 will not perform computation even if it has delegation but
forwards the PCRpt to PCE1 through the state-sync session. PCE1 will forwards the delegation via PCRpt message to PCE1 through the state-
then perform disjointness computation and will move PCC1->PCC2 onto sync session. PCE1 will then perform disjointness computation and
R1->R2->PCC2 and provides an ERO to PCE2 for PCC3->PCC4: will move PCC1->PCC2 onto R1->R2->PCC2 and provides an ERO to PCE2
R3->R4->PCC4. for PCC3->PCC4: R3->R4->PCC4. The PCE2 will further update the PCC3
with the new path.
3. Procedures and protocol extensions 3. Procedures and Protocol Extensions
3.1. Opening a state-sync session 3.1. Opening a state-sync session
3.1.1. Capability advertisement 3.1.1. Capability Advertisement
A PCE indicates its support of state-sync procedures during the PCEP A PCE indicates its support of state-sync procedures during the PCEP
Initialization phase. The OPEN object in the Open message MUST Initialization phase [RFC5440]. The OPEN object in the Open message
contains the "Stateful PCE Capability" TLV defined in [RFC8231]. A MUST contains the "Stateful PCE Capability" TLV defined in [RFC8231].
new P (INTER-PCE-CAPABILITY) flag is introduced to indicate the A new P (INTER-PCE-CAPABILITY) flag is introduced to indicate the
support of state-sync. support of state-sync.
This document adds a new bit in the Flags field with : This document adds a new bit in the Flags field with :
P (INTER-PCE-CAPABILITY - 1 bit): If set to 1 by a PCEP Speaker, P (INTER-PCE-CAPABILITY - 1 bit): If set to 1 by a PCEP Speaker,
the PCEP speaker indicates that the session MUST follow the state- the PCEP speaker indicates that the session MUST follow the state-
sync procedures as described in this document. The P bit MUST be sync procedures as described in this document. The P bit MUST be
set by both speakers: if a PCEP Speaker receives a STATEFUL-PCE- set by both speakers: if a PCEP Speaker receives a STATEFUL-PCE-
CAPABILITY TLV with P=0 while it advertised P=1 or if both set P CAPABILITY TLV with P=0 while it advertised P=1 or if both set P
flag to 0, the session SHOULD be setup but the state-sync flag to 0, the session SHOULD be set-up but the state-sync
procedures MUST NOT be applied on this session. procedures MUST NOT be applied on this session.
The U flag [RFC8231] MUST be set when sending the STATEFUL-PCE- The U flag [RFC8231] MUST be set when sending the STATEFUL-PCE-
CAPABILITY TLV with the P flag set. S flag MAY be set if optimized CAPABILITY TLV with the P flag set. In case the U flag is not set
synchronization is required as per [RFC8232]. along with the P flag, the state sync capability is not enabled and
it is considered as if P flag is not set. The S flag MAY be set if
optimized synchronization is required as per [RFC8232].
3.2. State synchronization 3.2. State synchronization
When the INTER-PCE-CAPABILITY has been negotiated, each PCEP speaker When the state sync capability has been negotiated between stateful
will behave as a PCE and as a PCC at the same time regarding the PCEs, each PCEP speaker will behave as a PCE and as a PCC at the same
state synchronization as defined in [RFC8231]. This means that each time regarding the state synchronization as defined in [RFC8231].
PCEP Speaker: This means that each PCEP Speaker:
o MUST send a PCRpt message towards its neighbor with S flag set for o MUST send a PCRpt message towards its neighbour with S flag set
each LSP in its LSP database learned from a PCC. (PCC role) for each LSP in its LSP database learned from a PCC. (PCC role)
o MUST send the End Of Synchronization Marker towards its neighbor o MUST send the End Of Synchronization Marker towards its neighbour
when all LSPs have been reported. (PCC role) when all LSPs have been reported. (PCC role)
o MUST wait for the LSP synchronization from its neighbor to end o MUST wait for the LSP synchronization from its neighbour to end
(receiving an End Of Synchronization Marker). (PCE role) (receiving an End Of Synchronization Marker). (PCE role)
The process of synchronization runs in parallel on each PCE (no The process of synchronization runs in parallel on each PCE (with no
defined order). defined order).
Optimized synchronization MAY be used as defined in [RFC8232]. Optimized state synchronization procedures MAY be used, as defined in
[RFC8232].
When a PCEP Speaker sends a PCRpt on a state-sync session, it MUST When a PCEP Speaker sends a PCRpt on a state-sync session, it MUST
add the SPEAKER-IDENTITY-TLV (defined in [RFC8232]) in the LSP add the SPEAKER-IDENTITY-TLV (defined in [RFC8232]) in the LSP
Object, the value used will refer to the 'owner' PCC of the LSP. If Object, the value used will refer to the 'owner' PCC of the LSP. If
a PCEP Speaker receives a PCRpt on a state-sync session without this a PCEP Speaker receives a PCRpt on a state-sync session without this
TLV, it MUST discard the PCRpt message and it MUST reply with a PCErr TLV, it MUST discard the PCRpt message and it MUST reply with a PCErr
message using error-type=6 (Mandatory Object missing) and error- message using error-type=6 (Mandatory Object missing) and error-
value=TBD1 (SPEAKER-IDENTITY-TLV missing). value=TBD1 (SPEAKER-IDENTITY-TLV missing).
3.3. Incremental updates and report forwarding rules 3.3. Incremental updates and report forwarding rules
skipping to change at page 15, line 17 skipping to change at page 16, line 23
from the PCC. from the PCC.
When a PCE receives a new PCRpt from a PCC with the LSP-DB-VERSION, When a PCE receives a new PCRpt from a PCC with the LSP-DB-VERSION,
the PCE MUST forward the PCRpt to all its state-sync sessions and the PCE MUST forward the PCRpt to all its state-sync sessions and
MUST add the appropriate SPEAKER-IDENTITY-TLV in the PCRpt. In MUST add the appropriate SPEAKER-IDENTITY-TLV in the PCRpt. In
addition, it MUST add a new ORIGINAL-LSP-DB-VERSION TLV (described addition, it MUST add a new ORIGINAL-LSP-DB-VERSION TLV (described
below). The ORIGINAL-LSP-DB-VERSION contains the LSP-DB-VERSION below). The ORIGINAL-LSP-DB-VERSION contains the LSP-DB-VERSION
coming from the PCC. coming from the PCC.
When a PCE receives a new PCRpt from a PCC without the LSP-DB- When a PCE receives a new PCRpt from a PCC without the LSP-DB-
VERSION, it SHOULD NOT forward the PCRpt on any state-sync sessions. VERSION, it SHOULD NOT forward the PCRpt on any state-sync sessions
and log such an event on the first occurrence.
When a PCE receives a new PCRpt from a PCC with the R flag set and a When a PCE receives a new PCRpt from a PCC with the R flag set and a
LSP-DB-VERSION TLV, the PCE MUST forward the PCRpt to all its state- LSP-DB-VERSION TLV, the PCE MUST forward the PCRpt to all its state-
sync sessions keeping the R flag set (Remove) and MUST add the sync sessions keeping the R flag set (Remove) and MUST add the
appropriate SPEAKER-IDENTITY-TLV and ORIGINAL-LSP-DB-VERSION TLV in appropriate SPEAKER-IDENTITY-TLV and ORIGINAL-LSP-DB-VERSION TLV in
the PCRpt. the PCRpt message.
When a PCE receives a PCRpt from a state-sync session, it MUST NOT When a PCE receives a PCRpt from a state-sync session, it MUST NOT
forward the PCRpt to other state-sync sessions. This helps to forward the PCRpt to other state-sync sessions. This helps to
prevent message loops between PCEs. As a consequence, a full mesh of prevent message loops between PCEs. As a consequence, a full mesh of
PCEP sessions between PCEs is required. PCEP sessions between PCEs is REQUIRED.
When a PCRpt is forwarded, all the original objects and values are When a PCRpt is forwarded, all the original objects and values are
kept. As an example, the PLSP-ID used in the forwarded PCRpt will be kept. As an example, the PLSP-ID used in the forwarded PCRpt will be
the same as the original one used by the PCC. Thus an implementation the same as the original one used by the PCC. Thus an implementation
supporting this document MUST consider SPEAKER-IDENTITY-TLV and PLSP- supporting this document MUST consider SPEAKER-IDENTITY-TLV and PLSP-
ID together to uniquely identify an LSP on the state-sync session. ID together to uniquely identify an LSP on the state-sync session.
The ORIGINAL-LSP-DB-VERSION TLV is encoded as follows and SHOULD The ORIGINAL-LSP-DB-VERSION TLV is encoded as follows and MUST always
always contain the LSP-DB-VERSION received from the owner PCC of the contain the LSP-DB-VERSION received from the owner PCC of the LSP:
LSP:
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=8 | | Type=TBD2 | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP State DB Version Number | | LSP State DB Version Number |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 16, line 23 skipping to change at page 17, line 37
particular LSP and SHOULD maintain the list of sources it learned a particular LSP and SHOULD maintain the list of sources it learned a
particular state from. particular state from.
A PCEP speaker may receive a state information for a particular LSP A PCEP speaker may receive a state information for a particular LSP
from different sources: the PCC that owns the LSP (through a regular from different sources: the PCC that owns the LSP (through a regular
PCEP session) and some PCEs (through PCEP state-sync sessions). A PCEP session) and some PCEs (through PCEP state-sync sessions). A
PCEP speaker MUST always keep the freshest state in its LSP database, PCEP speaker MUST always keep the freshest state in its LSP database,
overriding the previously received information. overriding the previously received information.
A PCE, receiving a PCRpt from a PCC, updates the state of the LSP in A PCE, receiving a PCRpt from a PCC, updates the state of the LSP in
its LSPDB with the new received information. When receiving a PCRpt its LSP-DB with the new received information. When receiving a PCRpt
from another PCE, a PCE SHOULD update the LSP state only if the from another PCE, a PCE SHOULD update the LSP state only if the
ORIGINAL-LSP-DB-VERSION present in the PCRpt is greater than the ORIGINAL-LSP-DB-VERSION present in the PCRpt is greater than the
current ORIGINAL-LSP-DB-VERSION of the stored LSP state. This current ORIGINAL-LSP-DB-VERSION of the stored LSP state. This
ensures that a PCE never tries to update its stored LSP state with an ensures that a PCE never tries to update its stored LSP state with an
old information. Each time a PCE updates an LSP state in its LSPDB, old information. Each time a PCE updates an LSP state in its LSP-DB,
it SHOULD reset the source list associated with the LSP state and it SHOULD reset the source list associated with the LSP state and
SHOULD add the source speaker address in the source list. When a PCE SHOULD add the source speaker address in the source list. When a PCE
receives a PCRpt which has an ORIGINAL-LSP-DB-VERSION (if coming from receives a PCRpt which has an ORIGINAL-LSP-DB-VERSION (if coming from
a PCE) or an LSP-DB-VERSION (if coming from the PCC) equals to the a PCE) or an LSP-DB-VERSION (if coming from the PCC) equals to the
current ORIGINAL-LSP-DB-VERSION of the stored LSP state, it SHOULD current ORIGINAL-LSP-DB-VERSION of the stored LSP state, it SHOULD
add the source speaker address in the source list. add the source speaker address in the source list.
When a PCE receives a PCRpt requesting an LSP deletion from a When a PCE receives a PCRpt requesting an LSP deletion from a
particular source, it SHOULD remove this particular source from the particular source, it SHOULD remove this particular source from the
list of sources associated with this LSP. list of sources associated with this LSP.
skipping to change at page 17, line 14 skipping to change at page 18, line 25
All PCEs in the network that are handling LSPs in a common LSP All PCEs in the network that are handling LSPs in a common LSP
association group SHOULD be aware of each other including the association group SHOULD be aware of each other including the
computation priority of each PCE. Note that there is no need for PCC computation priority of each PCE. Note that there is no need for PCC
to be aware of this. The computation priority is a number and the to be aware of this. The computation priority is a number and the
PCE having the highest priority SHOULD be responsible for the PCE having the highest priority SHOULD be responsible for the
computation. If several PCEs have the same priority value, their IP computation. If several PCEs have the same priority value, their IP
address SHOULD be used as a tie-breaker to provide a rank: the address SHOULD be used as a tie-breaker to provide a rank: the
highest IP address has more priority. How PCEs are aware of the highest IP address has more priority. How PCEs are aware of the
priority of each other is out of scope of this document, but as priority of each other is out of scope of this document, but as
example learning priorities could be done through IGP informations or example learning priorities could be done through PCE discovery or
local configuration. local configuration.
The definition of the priority MAY be global so the highest priority The definition of the priority could be global so the highest
PCE will handle all path computations or more granular, so a PCE may priority PCE will handle all path computations or more granular, so a
have highest priority for only a subset of LSPs or association- PCE may have highest priority for only a subset of LSPs or
groups. association-groups.
A PCEP Speaker receiving a PCRpt from a PCC with D flag set that does A PCEP Speaker receiving a PCRpt from a PCC with D flag set that does
not have the highest computation priority, SHOULD forward the PCRpt not have the highest computation priority, SHOULD forward the PCRpt
on all state-sync sessions (as per Section 3.3) and SHOULD set D flag on all state-sync sessions (as per Section 3.3) and SHOULD set D flag
on the state-sync session towards the highest priority PCE, D flag on the state-sync session towards the highest priority PCE, D flag
will be unset to all other state-sync sessions. This behavior is will be unset to all other state-sync sessions. This behaviour is
similar to the delegation behavior handled at PCC side and is called similar to the delegation behaviour handled at PCC side and is called
a sub-delegation (the PCE sub-delegates the control of the LSP to a sub-delegation (the PCE sub-delegates the control of the LSP to
another PCE). When a PCEP Speaker sub-delegates a LSP to another another PCE). When a PCEP Speaker sub-delegates a LSP to another
PCE, it looses the control on the LSP and cannot update it anymore by PCE, it looses the control on the LSP and cannot update it any more
its own decision. When a PCE receives a PCRpt with D flag set on a by its own decision. When a PCE receives a PCRpt with D flag set on
state-sync session, as a regular PCE, it becomes granted to update a state-sync session, as a regular PCE, it is granted control over
the LSP. the LSP.
If the highest priority PCE is failing or if the state-sync session If the highest priority PCE is failing or if the state-sync session
between the local PCE and the highest priority PCE failed, the local between the local PCE and the highest priority PCE failed, the local
PCE MAY decide to delegate the LSP to the next highest priority PCE PCE MAY decide to delegate the LSP to the next highest priority PCE
or to take back control on the LSP. It is a local policy decision. or to take back control on the LSP. It is a local policy decision.
When a PCE has the delegation for an LSP and needs to update this When a PCE has the delegation for an LSP and needs to update this
LSP, it MUST send a PCUpda message to all state-sync sessions and to LSP, it MUST send a PCUpd message to all state-sync sessions and to
the PCC session on which it received the delegation. The D-Flag the PCC session on which it received the delegation. The D-Flag
would be unset in the PCUpd for state-sync sessions where as D-Flag would be unset in the PCUpd for state-sync sessions where as D-Flag
would be set for the PCC. In case of sub-delegation, the computing would be set for the PCC. In case of sub-delegation, the computing
PCE will send the PCUpd only to all state-sync sessions (as it has no PCE will send the PCUpd only to all state-sync sessions (as it has no
direct delegation from a PCC). The D-Flag would be set for the direct delegation from a PCC). The D-Flag would be set for the
state-sync session to the PCE that sub-delegated this LSP and the state-sync session to the PCE that sub-delegated this LSP and the
D-Flag would be unset for other state-sync sessions. D-Flag would be unset for other state-sync sessions.
The PCUpd sent over a state-sync session MUST contain the SPEAKER- The PCUpd sent over a state-sync session MUST contain the SPEAKER-
IDENTITY-TLV in the LSP Object (the value used must identify the IDENTITY-TLV in the LSP Object (the value used must identify the
skipping to change at page 18, line 14 skipping to change at page 19, line 25
the PCC and learned from the forwarded PCRpt. If a PCE receives a the PCC and learned from the forwarded PCRpt. If a PCE receives a
PCUpd on a state-sync session without the SPEAKER-IDENTITY-TLV, it PCUpd on a state-sync session without the SPEAKER-IDENTITY-TLV, it
MUST discard the PCUpd and MUST reply with a PCErr message using MUST discard the PCUpd and MUST reply with a PCErr message using
error-type=6 (Mandatory Object missing) and error-value=TBD1 error-type=6 (Mandatory Object missing) and error-value=TBD1
(SPEAKER-IDENTITY-TLV missing). (SPEAKER-IDENTITY-TLV missing).
When a PCE receives a valid PCUpd on a state-sync session, it SHOULD When a PCE receives a valid PCUpd on a state-sync session, it SHOULD
forward the PCUpd to the appropriate PCC (identified based on the forward the PCUpd to the appropriate PCC (identified based on the
SPEAKER-IDENTITY-TLV value) that delegated the LSP originally and SPEAKER-IDENTITY-TLV value) that delegated the LSP originally and
SHOULD remove the SPEAKER-IDENTITY-TLV from the LSP Object. The SHOULD remove the SPEAKER-IDENTITY-TLV from the LSP Object. The
acknowledgment of the PCUpd is done through a cascaded mechanism, and acknowledgement of the PCUpd is done through a cascaded mechanism,
the PCC is the only responsible of triggering the acknowledgment: and the PCC is the only responsible of triggering the
when the PCC receives the PCUpd from the local PCE, it acknowledges acknowledgement: when the PCC receives the PCUpd from the local PCE,
it with a PCRpt as per [RFC8231]. When receiving the new PCRpt from it acknowledges it with a PCRpt as per [RFC8231]. When receiving the
the PCC, the local PCE uses the defined forwarding rules on the new PCRpt from the PCC, the local PCE uses the defined forwarding
state-sync session so the acknowledgment is relayed to the computing rules on the state-sync session so the acknowledgement is relayed to
PCE. the computing PCE.
A PCE SHOULD NOT compute a path using an association-group constraint A PCE SHOULD NOT compute a path using an association-group constraint
if it has delegation for only a subset of LSPs in the group. In this if it has delegation for only a subset of LSPs in the group. In this
case, an implementation MAY use a local policy on PCE to decide if case, an implementation MAY use a local policy on PCE to decide if
PCE does not compute path at all for this set of LSP or if it can PCE does not compute path at all for this set of LSP or if it can
compute a path by relaxing the association-group constraint. compute a path by relaxing the association-group constraint.
3.6. Passive stateful procedures 3.6. Passive stateful procedures
In the passive stateful PCE architecture, the PCC is responsible of In the passive stateful PCE architecture, the PCC is responsible for
triggering a path computation request using a PCReq message to its triggering a path computation request using a PCReq message to its
PCE. Similarly to PCRpt Message, which remains unchanged for passive PCE. Similarly to PCRpt Message, which remains unchanged for passive
mode, if a PCE receives a PCReq for an LSP and if this PCE finds that mode, if a PCE receives a PCReq for an LSP and if this PCE finds that
it does not have the highest computation priority of this LSP, or it does not have the highest computation priority of this LSP, or
groups..., it MUST forward the PCRequest to the highest priority PCE groups..., it MUST forward the PCReq message to the highest priority
over the state-sync session. When the highest priority PCE receives PCE over the state-sync session. When the highest priority PCE
the PCRequest, it computes the path and generates a PCReply only to receives the PCReq, it computes the path and generates a PCRep
the PCE that is received the PCReq from. This PCE will then forward message towards the PCE that made the request. This PCE will then
the PCRep to the requesting PCC. The handling of LSP object and the forward the PCRep to the requesting PCC. The handling of LSP object
SPEAKER-IDENTITY-TLV in PCRequ and PCRep is similar to PCRpt/PCUpd. and the SPEAKER-IDENTITY-TLV in PCReq and PCRep is similar to PCRpt/
PCUpd messages.
3.7. PCE initiation procedures 3.7. PCE initiation procedures
TBD TBD
4. Examples 4. Examples
4.1. Example 1
The examples in this section are for illustrative purpose to show how
the behaviour of the state sync inter-PCE sessions.
4.1. Example 1
_________________________________________ _________________________________________
/ \ / \
/ +------+ +------+ \ / +------+ +------+ \
| | PCE1 | | PCE2 | | | | PCE1 | | PCE2 | |
| +------+ +------+ | | +------+ +------+ |
| | | |
| +------+ 10 +------+ | | +------+ 10 +------+ |
| | PCC1 | ----- R1 ---- R2 ------- | PCC2 | | | | PCC1 | ----- R1 ---- R2 ------- | PCC2 | |
| +------+ | | +------+ | | +------+ | | +------+ |
| | | | | | | |
skipping to change at page 19, line 41 skipping to change at page 21, line 39
+---------+ +---------+ +---------+ +---------+
/ D=1 / D=1
/ /
+----------+ +----------+
| PCC3 | LSP : PCC3->PCC4 | PCC3 | LSP : PCC3->PCC4
+----------+ +----------+
PCE1 computation priority 100 PCE1 computation priority 100
PCE2 computation priority 200 PCE2 computation priority 200
With this PCEP session topology where computation priority is global Consider the PCEP sessions as shown above, where computation priority
for all LSPs, we still want to have link disjoint LSPs PCC1->PCC2 and is global for all the LSPs and link disjoint between LSPs PCC1->PCC2
PCC3->PCC4. and PCC3->PCC4 is required.
We first configure PCC1->PCC2, PCC1 delegates the LSP to PCE1, but as Consider the PCC1->PCC2 is configured first and PCC1 delegates the
PCE1 does not have the highest computation priority, it will sub- LSP to PCE1, but as PCE1 does not have the highest computation
delegate the LSP to PCE2 by sending a PCRpt with D=1 and including priority, it sub-delegates the LSP to PCE2 by sending a PCRpt with
the SPEAKER-IDENTITY-TLV over the state-sync session. PCE2 receives D=1 and including the SPEAKER-IDENTITY-TLV over the state-sync
the PCRpt and as it has delegation for this LSP, it computes the session. PCE2 receives the PCRpt and as it has delegation for this
shortest path: R1->R3->R4->R2->PCC2. It then sends a PCUpd to PCE1 LSP, it computes the shortest path: R1->R3->R4->R2->PCC2. It then
(including the SPEAKER-IDENTITY-TLV) with the computed ERO. PCE1 sends a PCUpd to PCE1 (including the SPEAKER-IDENTITY-TLV) with the
forwards the PCUpd to PCC1 (removing the SPEAKER-IDENTITY-TLV). PCC1 computed ERO. PCE1 forwards the PCUpd to PCC1 (removing the SPEAKER-
acknowledges the PCUpd by a PCRpt to PCE1. PCE1 forwards the PCRpt IDENTITY-TLV). PCC1 acknowledges the PCUpd by a PCRpt to PCE1. PCE1
to PCE2. forwards the PCRpt to PCE2.
When PCC3->PCC4 is configured, PCC3 delegates the LSP to PCE2, PCE2 When PCC3->PCC4 is configured, PCC3 delegates the LSP to PCE2, PCE2
can compute a disjoint path as it has knowledge of both LSPs and has can compute a disjoint path as it has knowledge of both LSPs and has
delegation also for both. The only solution found is to move delegation also for both. The only solution found is to move
PCC1->PCC2 LSP on another path, PCE2 can move PCC3->PCC4 as it has PCC1->PCC2 LSP on another path, PCE2 can move PCC1->PCC2 as it has
delegation for it. It creates a new PCUpd with new ERO: R1->R2-PCC2 sub-delegation for it. It creates a new PCUpd with new ERO:
towards PCE1 which forwards to PCC1. PCE2 sends a PCUpd to PCC3 with R1->R2-PCC2 towards PCE1 which forwards to PCC1. PCE2 sends a PCUpd
the path: R3->R4->PCC4. to PCC3 with the path: R3->R4->PCC4.
In this setup, PCEs are able to find a disjoint path while without In this set-up, PCEs are able to find a disjoint path while without
state-sync and computation priority they could not. state-sync and computation priority they could not.
4.2. Example 2 4.2. Example 2
_____________________________________ _____________________________________
/ \ / \
/ +------+ +------+ \ / +------+ +------+ \
| | PCE1 | | PCE2 | | | | PCE1 | | PCE2 | |
| +------+ +------+ | | +------+ +------+ |
| | | |
| +------+ 100 +------+ | | +------+ 100 +------+ |
skipping to change at page 21, line 41 skipping to change at page 23, line 41
+---------+ +---------+ +---------+ +---------+
D=0 \ / D=1 D=0 \ / D=1
\ / \ /
+----------+ +----------+
| PCC3 | LSP : PCC3->PCC4 | PCC3 | LSP : PCC3->PCC4
+----------+ +----------+
PCE1 computation priority 200 PCE1 computation priority 200
PCE2 computation priority 100 PCE2 computation priority 100
In this example, we configure both LSPs almost at the same time. In this example, suppose both LSPs are configured almost at the same
PCE1 sub-delegates PCC1->PCC2 to PCE2 while PCE2 keeps delegation for time. PCE1 sub-delegates PCC1->PCC2 to PCE2 while PCE2 keeps
PCC3->PCC4, PCE2 computes a path for PCC1->PCC2 and PCC3->PCC4 and delegation for PCC3->PCC4, PCE2 computes a path for PCC1->PCC2 and
can achieve disjointness computation easily. No computation loop PCC3->PCC4 and can achieve disjointness computation easily. No
happens in this case. computation loop happens in this case.
4.3. Example 3 4.3. Example 3
_________________________________________ _________________________________________
/ \ / \
/ +------+ +------+ \ / +------+ +------+ \
| | PCE1 | | PCE2 | | | | PCE1 | | PCE2 | |
| +------+ +------+ | | +------+ +------+ |
| | | |
| +------+ 10 +------+ | | +------+ 10 +------+ |
skipping to change at page 22, line 41 skipping to change at page 24, line 41
| PCE1 |----| PCE2 |----| PCE3 | | PCE1 |----| PCE2 |----| PCE3 |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
/ D=1 / D=1
/ /
+----------+ +----------+
| PCC3 | LSP : PCC3->PCC4 | PCC3 | LSP : PCC3->PCC4
+----------+ +----------+
PCE1 computation priority 100 PCE1 computation priority 100
PCE2 computation priority 200 PCE2 computation priority 200
PCE2 computation priority 300 PCE3 computation priority 300
With this PCEP session topology, we still want to have link disjoint With the PCEP sessions as shown above, consider the need to have link
LSPs PCC1->PCC2 and PCC3->PCC4. disjoint LSPs PCC1->PCC2 and PCC3->PCC4.
We first configure PCC1->PCC2, PCC1 delegates the LSP to PCE1, but as Suppose PCC1->PCC2 is configured first, PCC1 delegates the LSP to
PCE1 does not have the highest computation priority, it will sub- PCE1, but as PCE1 does not have the highest computation priority, it
delegate the LSP to PCE2 (as it cannot reach PCE3 through a state- will sub-delegate the LSP to PCE2 (as it not aware of PCE3 and has no
sync session). PCE2 cannot compute a path for PCC1->PCC2 as it does way to reach it). PCE2 cannot compute a path for PCC1->PCC2 as it
not have the highest priority and cannot sub-delegate the LSP again does not have the highest priority and is not allowed to sub-delegate
towards PCE3. the LSP again towards PCE3 as per Section 3.
When PCC3->PCC4 is configured, PCC3 delegates the LSP to PCE2 that When PCC3->PCC4 is configured, PCC3 delegates the LSP to PCE2 that
performs sub-delegation to PCE3. As PCE3 will have knowledge of only performs sub-delegation to PCE3. As PCE3 will have knowledge of only
one LSP in the group, it cannot compute disjointness and can decide one LSP in the group, it cannot compute disjointness and can decide
to fallback to a less constrained computation to provide a path for to fallback to a less constrained computation to provide a path for
PCC3->PCC4. In this case, it will send a PCUpd to PCE2 that will be PCC3->PCC4. In this case, it will send a PCUpd to PCE2 that will be
forwarded to PCC3. forwarded to PCC3.
Disjointness cannot be achieved in this scenario because of lack of Disjointness cannot be achieved in this scenario because of lack of
state-sync session between PCE1 and PCE3, but no computation loop state-sync session between PCE1 and PCE3, but no computation loop
skipping to change at page 24, line 33 skipping to change at page 26, line 33
\ / \ /
+----------+ +----------+
| PCC501 | | PCC501 |
+----------+-+ +----------+-+
| PCC1000 | | PCC1000 |
+----------+ +----------+
In the figure above, two groups of PCEs are created: PCE1/2 maintain In the figure above, two groups of PCEs are created: PCE1/2 maintain
PCEP sessions with PCC1 up to PCC500, while PCE3/4 maintain PCEP PCEP sessions with PCC1 up to PCC500, while PCE3/4 maintain PCEP
sessions with PCC501 up to PCC1000. A granular master/slave policy sessions with PCC501 up to PCC1000. A granular master/slave policy
is setup as follows to loadshare computation between PCEs: is set-up as follows to load-share computation between PCEs:
o PCE1 has priority 200 for association ID 1 up to 300, association o PCE1 has priority 200 for association ID 1 up to 300, association
source 0.0.0.0. All other PCEs have a decreasing priority for source 0.0.0.0. All other PCEs have a decreasing priority for
those associations. those associations.
o PCE3 has priority 200 for association ID 301 up to 500, o PCE3 has priority 200 for association ID 301 up to 500,
association source 0.0.0.0. All other PCEs have a decreasing association source 0.0.0.0. All other PCEs have a decreasing
priority for those associations. priority for those associations.
If some PCCs delegate LSPs with association ID 1 up to 300 and If some PCCs delegate LSPs with association ID 1 up to 300 and
association source 0.0.0.0, the receiving PCE (if not PCE1) will sub- association source 0.0.0.0, the receiving PCE (if not PCE1) will sub-
delegate the LSPs to PCE1. PCE1 becomes responsible for the delegate the LSPs to PCE1. PCE1 becomes responsible for the
computation of these LSP associations while PCE3 is responsible for computation of these LSP associations while PCE3 is responsible for
the computation of another set of associations. the computation of another set of associations.
The procedures describe in this document could help greatly in load-
sharing between a group of stateful PCEs.
6. PCEP-PATH-VECTOR-TLV 6. PCEP-PATH-VECTOR-TLV
This document allows PCEP messages to be propagated among PCEP This document allows PCEP messages to be propagated among PCEP
speaker. It may be useful to track informations about the speaker. It may be useful to track informations about the
propagation of the messages. One of the use case is a message loop propagation of the messages. One of the use case is a message loop
detection mechanism, but other use cases like hop by hop information detection mechanism, but other use cases like hop by hop information
recording may also be implemented. recording may also be implemented.
This document introduces the PCEP-PATH-VECTOR-TLV (type TBD2) with This document introduces the PCEP-PATH-VECTOR-TLV (type TBD3) with
the following format: the following format:
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=TBD3 | Length (variable) | | Type=TBD3 | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCEP-SPEAKER-INFORMATION#1 | | PCEP-SPEAKER-INFORMATION#1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCEP-SPEAKER-INFORMATION#2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCEP-SPEAKER-INFORMATION#n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The TLV format and padding rules are as per [RFC5440]. The TLV format and padding rules are as per [RFC5440].
The PCEP-SPEAKER-INFORMATION field has the following format: The PCEP-SPEAKER-INFORMATION field has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (variable) | ID Length (variable) | | Length (variable) | ID Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 26, line 9 skipping to change at page 28, line 9
ID Length: defines the length of the Speaker identity actual field ID Length: defines the length of the Speaker identity actual field
(non-padded). (non-padded).
Speaker Entity identity: same possible values as the SPEAKER- Speaker Entity identity: same possible values as the SPEAKER-
IDENTIFIER-TLV. Padded with trailing zeroes to a 4-byte boundary. IDENTIFIER-TLV. Padded with trailing zeroes to a 4-byte boundary.
The PCEP-SPEAKER-INFORMATION may also carry some optional subTLVs The PCEP-SPEAKER-INFORMATION may also carry some optional subTLVs
so each PCEP speaker can add local informations that could be so each PCEP speaker can add local informations that could be
recorded. This document does not define any subTLV. recorded. This document does not define any subTLV.
The PCEP-PATH-VECTOR-TLV MAY be added in the LSP-Object. Its usage The PCEP-PATH-VECTOR-TLV MAY be added in the LSP Object. Its usage
is purely optional. is purely optional.
The list of speakers within the PCEP-PATH-VECTOR-TLV MUST be ordered. The list of speakers within the PCEP-PATH-VECTOR-TLV MUST be ordered.
When sending a PCEP message (PCRpt, PCUpd or PCInitiate), a PCEP When sending a PCEP message (PCRpt, PCUpd or PCInitiate), a PCEP
Speaker MAY add the PCEP-PATH-VECTOR-TLV with a PCEP-SPEAKER- Speaker MAY add the PCEP-PATH-VECTOR-TLV with a PCEP-SPEAKER-
INFORMATION containing its own informations. If the PCEP message INFORMATION containing its own informations. If the PCEP message
sent is the result of a previously received PCEP message, and if the sent is the result of a previously received PCEP message, and if the
PCEP-PATH-VECTOR-TLV was already present in the initial message, the PCEP-PATH-VECTOR-TLV was already present in the initial message, the
PCEP speaker MAY append a new PCEP-SPEAKER-INFORMATION containing its PCEP speaker MAY append a new PCEP-SPEAKER-INFORMATION containing its
own informations. own informations.
skipping to change at page 27, line 47 skipping to change at page 29, line 47
[RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,
and D. Dhody, "Optimizations of Label Switched Path State and D. Dhody, "Optimizations of Label Switched Path State
Synchronization Procedures for a Stateful PCE", RFC 8232, Synchronization Procedures for a Stateful PCE", RFC 8232,
DOI 10.17487/RFC8232, September 2017, DOI 10.17487/RFC8232, September 2017,
<https://www.rfc-editor.org/info/rfc8232>. <https://www.rfc-editor.org/info/rfc8232>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-pce-association-diversity] [I-D.ietf-pce-association-diversity]
Litkowski, S., Sivabalan, S., Barth, C., and M. Negi, Litkowski, S., Sivabalan, S., Barth, C., and M. Negi,
"Path Computation Element communication Protocol (PCEP) "Path Computation Element Communication Protocol (PCEP)
extension for signaling LSP diversity constraint", draft- Extension for LSP Diversity Constraint Signaling", draft-
ietf-pce-association-diversity-06 (work in progress), ietf-pce-association-diversity-08 (work in progress), July
February 2019. 2019.
[I-D.ietf-pce-stateful-hpce] [I-D.ietf-pce-stateful-hpce]
Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., King, D., Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King,
and O. Dios, "Hierarchical Stateful Path Computation "Hierarchical Stateful Path Computation Element (PCE).",
Element (PCE).", draft-ietf-pce-stateful-hpce-06 (work in draft-ietf-pce-stateful-hpce-11 (work in progress), July
progress), October 2018. 2019.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006, DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>. <https://www.rfc-editor.org/info/rfc4655>.
[RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the
Path Computation Element Architecture to the Determination Path Computation Element Architecture to the Determination
of a Sequence of Domains in MPLS and GMPLS", RFC 6805, of a Sequence of Domains in MPLS and GMPLS", RFC 6805,
DOI 10.17487/RFC6805, November 2012, DOI 10.17487/RFC6805, November 2012,
<https://www.rfc-editor.org/info/rfc6805>. <https://www.rfc-editor.org/info/rfc6805>.
[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path
Computation Element Architecture", RFC 7399, Computation Element Architecture", RFC 7399,
DOI 10.17487/RFC7399, October 2014, DOI 10.17487/RFC7399, October 2014,
<https://www.rfc-editor.org/info/rfc7399>. <https://www.rfc-editor.org/info/rfc7399>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>.
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
Stateful Path Computation Element (PCE)", RFC 8051,
DOI 10.17487/RFC8051, January 2017,
<https://www.rfc-editor.org/info/rfc8051>.
Appendix A. Contributors Appendix A. Contributors
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. 78 change blocks. 
284 lines changed or deleted 326 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/