Table 1 summarizes the
impact of various PCC operational events on the status of PCE-initiated LSPs.
Table 1. Impact of PCC Operational Events
|
Event
|
Impact on PCE-initiated LSPs
|
|
Oper-down
|
Deleted
|
|
MPLS shutdown
|
✓ 1
|
|
|
no mpls
|
|
✓2
|
|
no pce-initiated-lsp
|
|
✓ (all) 2
|
|
no sr-te
|
|
✓ (sr-te)2
|
|
sr-te shutdown
|
✓ (sr-te) 1
|
|
|
pcc shutdown
|
|
✓ (all) 3
|
|
pcc peer shutdown
|
|
✓3
|
|
Delete LSP template ID
|
|
✓ (LSPs using template)2
|
|
Delete default LSP template
|
|
✓ (all) 2
|
Note:
-
Also results in a PCRpt to the PCE with LSP error admin down.
-
Also results in a PCRpt to the PCE with LSP deleted.
-
A PCRpt with delete and a special error code, for example, LSP_ERR_SYNC_DELETE, is
sent during the PCC rejoin synchronization that occurs when the PCC or PCC peer
comes back up.
The following list describes in more detail the actions that
the PCC takes on PCE-initiated LSPs as a result of PCC operational events.
-
If any event causes PCE-initiated LSPs to be deleted by the PCC,
the PCC sends a PCRpt with remove the flag in both the SRP object and the LSP object
set for each impacted LSP. If the event is a failure of the PCEP session to the PCE,
or a shutdown of the PCC or PCC peer, the PCRpt is sent, with the special error code
LSP_ERR_SYNC_DELETE, only after the PCEP session comes back up during the PCC
resynchronization with the PCE.
-
If any event causes PCE-initiated LSPs to go operationally down,
the PCC router sends a PCRpt with the operational bits in the LSP object set to DOWN
for each impacted LSP.
- If the user shuts down the PCC process on the router, all PCE-initiated LSPs
are deleted. When the user performs a no shutdown of the PCC
process, the PCC reports to the PCE so that the NSP is aware.
- If a PCEP peer is shut down, the PCEP session goes down but the PCC keeps the
state of all PCE-initiated LSPs, subject to the following rules regarding
redelegation and the cleanup of state. See section 5.7.5 of RFC 8231 and section 6 of
RFC 8281. These rules apply to all LSPs delegated to the PCE.
Redelegation timeout and state timeout timers are started when the PCEP session
goes down or the PCE signals overload. Configuration of these timers is described
in PCE-Initiated LSPs. The system enforces
that the state-timer be greater than the
redelegation-timer, as specified in RFC 8231.
The objectives of redelegation are described in Section 5.7.5 of RFC 8231. The
redelegation process is as follows for both PCE-initiated and PCC-initiated
LSPs.
The existing LSP delegation state is maintained while the LSP redelegation timer
is running. This gives the PCE time to recover. At the expiry of the redelegation
timer, the PCC attempts to redelegate the LSPs to the PCE, as follows:
-
if the PCEP session to the existing PCE is still down or the PCE is still in
overload, return delegation state to the PCC for all the delegated LSPs
-
wait until the PCEP session comes up and then attempt to redelegate the
remaining LSPs back to the PCE. For each LSP, set a redelegation attempted
flag once redelegation is attempted. If redelegation is accepted for all
PCE-initiated LSPs delegated to the PCC before the state timeout timer
expires, the system is behaving as expected.
-
if the state timeout timer expires, wait until all LSPs have been processed.
The LSPs that are not redelegated but have the redelegation attempted flag
set have the configured action applied to them. If this is
delete, LSPs are deleted; otherwise, wait until the
PCEP session comes up and then attempt to redelegate the remaining LSPs back
to the PCE.