wdiff rfc8281.alt-original rfc8281.txt

PCE Working Group
Internet Engineering Task Force (IETF) E. Crabbe
Internet-Draft
Request for Comments: 8281 Individual Contributor
Intended status:
Category: Standards Track I. Minei
Expires: April 8, 2018
ISSN: 2070-1721 Google, Inc.
S. Sivabalan
Cisco Systems, Inc.
R. Varga
Pantheon Technologies SRO
October 5,
December 2017

PCEP

Path Computation Element Communication Protocol (PCEP) Extensions for PCE-initiated
PCE-Initiated LSP Setup in a Stateful PCE Model
draft-ietf-pce-pce-initiated-lsp-11

Abstract

The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs) Client (PCC) requests.

The extensions for stateful PCE provide active control of
Multiprotocol Label Switching (MPLS) Traffic Engineering Label
Switched Paths (TE LSP) LSPs) via PCEP, for a model where the PCC
delegates control over one or more locally configured LSPs to the
PCE. This document describes the creation and deletion of PCE-initiated PCE-
initiated LSPs under the stateful PCE model.

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for a maximum publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 8, 2018.
https://www.rfc-editor.org/info/rfc8281.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info)
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. Architectural Overview . . . . . . . . . . . . . . . . . . . 4
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Operation Overview . . . . . . . . . . . . . . . . . . . 5
4. Support of PCE-initiated PCE-Initiated LSPs . . . . . . . . . . . . . . . . 6
4.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 6
5. PCE-initiated PCE-Initiated LSP Instantiation and Deletion . . . . . . . . 7
5.1. The LSP Initiate Request . . . . . . . . . . . . . . . . 7
5.2. The R flag Flag in the SRP Object . . . . . . . . . . . . . . 8
5.3. LSP Instantiation . . . . . . . . . . . . . . . . . . . . 9
5.3.1. The Create Flag . . . . . . . . . . . . . . . . . . . 11
5.3.2. The SPEAKER-ENTITY-ID TLV . . . . . . . . . . . . . . 11 12
5.4. LSP Deletion . . . . . . . . . . . . . . . . . . . . . . 12
6. LSP Delegation and Cleanup . . . . . . . . . . . . . . . . . 12
7. LSP State Synchronization . . . . . . . . . . . . . . . . . . 13
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9.1.
8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 14
9.2.
8.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 15
9.3. 14
8.3. SRP object . . . . . . . . . . . . . . . . . . . . . . . 15
9.4. 14
8.4. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 15
9.5.
8.5. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 15
10.
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10.1.
9.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 16
10.2.
9.2. Malicious PCC . . . . . . . . . . . . . . . . . . . . . 17
11. Acknowledgements . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.
10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . 17
12.1. Normative References . . . . . . . . . . 17
Acknowledgments . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18

1. Introduction

[RFC5440] describes the Path Computation Element Communication
Protocol (PCEP). PCEP defines the communication between a Path
Computation Client (PCC) and a Path Computation Element (PCE), or
between PCE and PCE, enabling computation of Multiprotocol Label
Switching (MPLS) for Traffic Engineering Label Switched Path (TE LSP)
characteristics.

[RFC8231] specifies a set of extensions to PCEP to enable stateful
control of TE LSPs between and across PCEP sessions in compliance
with [RFC4657]. It includes includes:

o mechanisms to effect LSP state synchronization State Synchronization between PCCs and
PCEs

o delegation of control of LSPs to PCEs

o PCE control of timing and sequence of path computations within and
across PCEP sessions

It focuses on a model where LSPs are configured on the PCC PCC, and
control over them is delegated to the PCE.

This document describes the setup, maintenance maintenance, and teardown of PCE-
initiated LSPs under the stateful PCE model, without the need for
local configuration on the PCC, thus allowing for a dynamic network
that is centrally controlled and deployed.

2. Terminology

This document uses the following terms defined in [RFC5440]: PCC,
PCE, and PCEP Peer.

This document uses the following terms defined in [RFC8051]: Stateful
PCE,
PCE and Delegation.

This document uses the following terms defined in [RFC8231]:
Redelegation Timeout Interval, State Timeout Interval, LSP State
Report, and LSP Update Request.

The following terms are defined in this document:

PCE-initiated LSP: LSP that is instantiated as a result of a request
from the PCE.

The message formats in this document are specified using Routing
Backus-Naur Form (RBNF) encoding as specified in [RFC5511].

2.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in [RFC2119].
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.

3. Architectural Overview

3.1. Motivation

[RFC8231] provides active control over LSPs that are locally
configured on the PCC. This model relies on the Label Edge Router
(LER) taking an active role in delegating locally configured LSPs to
the PCE, PCE and is well suited in environments where the LSP placement is
fairly static. However, in environments where the LSP placement
needs to change in response to application demands, it is useful to
support dynamic creation and tear down teardown of LSPs. The ability for a PCE
to trigger the creation of LSPs on demand can be seamlessly
integrated into a controller-based network architecture, where
intelligence in the controller can determine when and where to set up
paths.

A possible use case is a software-defined network, where applications
request network resources and paths from the network infrastructure.
For example, an application can request a path with certain
constraints between two LSRs Label Switching Routers (LSRs) by contacting
the PCE. The PCE can compute a path satisfying the constraints, and
instruct the head end LSR to instantiate and signal it. When the
path is no longer required by the application, the PCE can request
its teardown.

Another use case is dynamically adjusting aggregate bandwidth between
two points in the network using multiple LSPs. This functionality is
very similar to auto-bandwidth, but it allows for providing the
desired capacity through multiple LSPs. This approach overcomes two
of the limitations auto-bandwidth can experience: 1) growing the
capacity between the endpoints beyond the capacity of individual
links in the path and 2) achieving good bin-packing bin packing through use of
several small LSPs instead of a single large one. The number of LSPs
varies based on the demand, and LSPs are created and deleted
dynamically to satisfy the bandwidth requirements.

Another use case is demand engineering, where a PCE with visibility
into both the network state and the demand matrix can anticipate and
optimize how traffic is distributed across the infrastructure. Such
optimizations may require creating new paths across the
infrastructure.

3.2. Operation Overview

This document defines the new I flag in the STATEFUL-PCE-CAPABILITY
TLV to indicate that the sender supports PCE-initiated LSPs (see
details in Section 4.1). A PCC or PCE sets this flag in the Open
message during the PCEP Initialization Phase initialization phase to indicate that it
supports the procedures of this document.

This document defines a new PCEP message, the LSP Initiate Request
(PCInitiate) message, which a PCE can send to a PCC to request the
initiaton
initiation or deletion of an LSP. The decision when to instantiate
or delete a PCE-initiated LSP is out of the scope of this document.

The PCE sends a PCInitiate message to the PCC to request the
initiation of an LSP. The PCC creates the LSP using the attributes
communicated by the PCE and local values for any unspecified
parameters. The PCC generates an LSP a Path Computation State Report
(PCRpt) for the LSP, carrying a newly assigned PLSP-ID for the LSP
and delegating the LSP to the PCE via the Delegate flag in the LSP
object.

The PCE can update the attributes of the LSP by sending subsequent
PCUpd messages. Subsequent LSP State Report (PCRpt) and LSP
Path Computation Update Request (PCUpd) messages. Subsequent PCRpt
and PCUpd messages that the PCC and PCE, respectively, send for the
LSP will carry the PCC-assigned PLSP-ID, which uniquely identifies
the LSP. See details in Section 5.3.

The PCE sends a PCInitiate message to the PCC to request the deletion
of an LSP. To indicate a delete operation, this document defines the
new R flag in the SRP object Stateful PCE Request Parameter (SRP) object in the
PCInitiate message, as described in Section 5.2. As a result of the
deletion request, the PCC removes the LSP and sends a PCRpt for the
removed state. See details in Section 5.4.

Figure 1 illustrates these message exchanges.

+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|<--PCInitiate-------------------| (Initiate LSP)
| |
|---PCRpt, PLSP_ID=1, D=1------->| (Confirm initiation)
| . |
| . |
| |
|<--PCUpd, PLSP_ID=1-------------| (Update LSP)
| |
|---PCRpt, PLSP_ID=1, D=1------->| (Confirm update)
| . |
| . |
| |
|<--PCInitiate, PLSP_ID=1, R=1---| (Delete LSP)
| |
|---PCRpt, PLSP_ID=1, R=1------->| (Confirm delete)

Figure 1: PCE-Initiated LSP lifecycle Life Cycle

4. Support of PCE-initiated PCE-Initiated LSPs

A PCEP speaker indicates its ability to support PCE-initiated LSPs
during the PCEP Initialization initialization phase, as follows. When the PCEP
session is created, it sends an Open message with an OPEN object that
contains the STATEFUL-PCE-CAPABILITY TLV, as defined in [RFC8231]. A
new flag, the I (LSP-INSTANTIATION-CAPABILITY) flag, is introduced to
this TLV to indicate support for instantiation of PCE-initiated LSPs.
A PCE can initiate LSPs only for PCCs that advertised this
capability. A PCC will follow the procedures described in this
document only on sessions where the PCE advertised the I flag.

4.1. STATEFUL-PCE-CAPABILITY TLV

The format of the STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231]
and included here for easy reference with the addition of the new I
flag.

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 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |I|S|U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+

Figure 2: STATEFUL-PCE-CAPABILITY TLV format Format

A new flag is defined to indicate the sender's support for LSP
instantiation by a PCE:

I (LSP-INSTANTIATION-CAPABILITY - -- 1 bit): If set to 1 by a PCC, the
I Flag flag indicates that the PCC allows instantiation of an LSP by a
PCE. If set to 1 by a PCE, the I flag indicates that the PCE
supports instantiating LSPs. The LSP-INSTANTIATION-CAPABILITY
flag must be set by both the PCC and PCE in order to enable PCE-
initiated LSP instantiation.

5. PCE-initiated PCE-Initiated LSP Instantiation and Deletion

To initiate an LSP, a PCE sends a PCInitiate message to a PCC. The
message format, objects objects, and TLVs are discussed separately below for
the creation and the deletion cases.

5.1. The LSP Initiate Request

An LSP Initiate Request (PCInitiate) message is a PCEP message sent
by a PCE to a PCC to trigger LSP instantiation or deletion. The
Message-Type field of the PCEP common header for the PCInitiate
message is set to 12. The PCInitiate message MUST include the SRP
and the LSP objects, objects and MAY contain other objects, as discussed later
in this section.

The format of a PCInitiate message is as follows:

<PCInitiate Message> ::= <Common Header>
<PCE-initiated-lsp-list>
Where:
<Common Header> is defined in [RFC5440] RFC 5440

<PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>
[<PCE-initiated-lsp-list>]

<PCE-initiated-lsp-request> ::= (<PCE-initiated-lsp-instantiation>|
<PCE-initiated-lsp-deletion>)

<PCE-initiated-lsp-instantiation> ::= <SRP>
<LSP>
[<END-POINTS>]
<ERO>
[<attribute-list>]

<PCE-initiated-lsp-deletion> ::= <SRP>
<LSP>

Where:
<attribute-list> is defined in [RFC5440] RFC 5440 and extended by
PCEP extensions.

The LSP object is defined in [RFC8231]. The END-POINTS and ERO
objects Explicit
Route Objects (EROs) are defined in [RFC5440].

The SRP object is defined in [RFC8231]. The SRP Object object contains an
SRP-ID-number which that is unique within a PCEP session. The PCE
increments the last-used SRP-ID-number before it sends each
PCInitiate message. The PCC MUST echo the value of the SRP-ID-number
in PCErr PCEP Error (PCErr) and PCRpt messages that it sends as a result of
the
PCInitiate to allow PCInitiate; this allows the PCE to correlate them with the
corresponding PCInitiate message.

5.2. The R flag Flag in the SRP Object

The format of the SRP object is is defined in [RFC8231] and included
here for easy reference with the addition of the new R flag.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRP-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: The SRP Object format Format

A new flag is defined to indicate a delete operation initiated by the
PCE:

R (LSP-REMOVE - -- 1 bit): If set to 0, it indicates a request to
create an LSP. If set to 1, it indicates a request to remove an
LSP.

5.3. LSP Instantiation

The LSP is instantiated by sending a PCInitiate message. The LSP is
set up using RSVP-TE. Extensions for other setup methods are outside
the scope of this draft. document.

The PCInitiate message, when used to instantiate an LSP, MUST contain
an LSP object with the reserved PLSP-ID 0. The LSP Object object MUST
include the SYMBOLIC-PATH-NAME TLV, which is used to correlate
between the PCC-assigned PLSP-ID and the LSP.

The PCInitiate message, when used to instantiate an LSP, MUST contain
an Explicit Route Object (ERO) ERO for the LSP.

For an instantiation request of an RSVP-signaled LSP, the destination
address may be needed. The PCC MAY determine it from a provided
object (e.g., ERO) or a local decision. Alternatively, the END-
POINTS
END-POINTS object MAY be included to explicitly convey the
destination addresses to be used in the RSVP-TE signaling. The
source address MUST either be either specified or left for the PCC to choose
by setting it to "0.0.0.0" (if the destination is an IPv4 address) or
"::" (if the destination is an IPv6 address).

The PCE MAY include various attributes as per [RFC5440]. The PCC
MUST use these values in the LSP instantiation, instantiation and local values for
unspecified parameters. After the LSP setup, the PCC MUST send a
PCRpt to the PCE, reflecting these values. The SRP object in the
PCRpt message MUST echo the value of the PCInitiate message that
triggered the setup. LSPs that were instantiated as a result of a
PCInitiate message MUST have the Create flag (Section 5.3.1) set in
the LSP object.

If the PCC receives a PCInitiate message with a non-zero PLSP-ID and
the R flag in the SRP object set to zero, then it MUST send a PCErr
message with Error-type=19 (Invalid Operation) and Error-value=8
(Non-zero PLSP-ID in the PCInitiate message). LSP Initiate Request).

If the PCC receives a PCInitiate message without an ERO and the R
flag in the SRP object set to zero, then it MUST send a PCErr message
with Error-type=6 (Mandatory Object missing) and Error-value=9 (ERO
Object
object missing).

If the PCC receives a PCInitiate message without a SYMBOLIC-PATH-NAME
TLV, then it MUST send a PCErr message with Error-type=10 (Invalid (Reception
of an invalid object) and Error-value=8 (SYMBOLIC-PATH-NAME TLV
missing).

The PCE MUST NOT provide a symbolic path name that conflicts with the
symbolic path name of any existing LSP in the PCC. (Existing LSPs
may be either statically configured, configured or initiated by another PCE). PCE.) If
there is a conflict with the symbolic path name of an existing LSP,
the PCC MUST send a PCErr message with Error-type=23 (Bad Parameter
value) and Error-value=1 (SYMBOLIC-PATH-NAME in use). The only
exception to this rule is for LSPs for which the State Timeout
Interval timer is running (see Section 6).

If the PCC determines that the LSP parameters proposed in the
PCInitiate message are unacceptable, it MUST send a PCErr message
with Error-type=24 (PCE instantiation error) and Error-value=1
(Unacceptable instantiation parameters). If the PCC encounters an
internal error during the processing of the PCInitiate message, it
MUST send a PCErr message with Error-type=24 (PCE instantiation
error) and Error-value=2 (Internal error).

A PCC MUST relay to the PCE errors it encounters in the setup of PCE-
initiated a PCE-initiated
LSP to the PCE by sending a PCErr message with Error-type=24 (PCE
instantiation error) and Error-value=3 (Signaling error). The PCErr
message MUST echo the SRP-ID-number of the PCInitiate message. The
PCEP-ERROR object SHOULD include the RSVP_ERROR_SPEC TLV (if an RSVP
ERROR_SPEC object was returned to the PCC by a downstream node).
After the LSP is set up, errors in RSVP signaling are reported in
PCRpt messages, as described in [RFC8231].

On successful completion of the LSP instantiation, the PCC MUST send
a PCRpt message. The LSP object message MUST contain a non-zero
PLSP-ID that uniquely identifies the LSP within this PCC, PCC and MUST
have the Create flag (Section 5.3.1) and Delegate flag set. The SRP
object MUST contain an SRP-ID-number that echoes the value from the
PCInitiate message that triggered the setup. The PCRpt MUST include
the attributes that the PCC used to instantiate the LSP.

A PCC SHOULD be able to place a limit on either the number of LSPs or
the percentage of resources that are allocated to honor PCE-initiated
LSP requests. As soon as that limit is reached, the PCC MUST send a
PCErr message with Error-type=19 (Invalid Operation) and Error-
value=6
Error-value=6 (PCE-initiated LSP limit reached) and is free to drop
any incoming PCInitiate messages without additional processing.

Similarly, the PCE SHOULD be able to place a limit on either the
number of PCInitiate messages pending for a particular PCC, PCC or on the
time it waits for a response (positive or negative) to a PCInitiate
message from a PCC PCC, and it MAY take further action (such as closing
the session or removing all its LSPs) if this limit is reached.

5.3.1. The Create Flag

The LSP object is defined in [RFC8231] and included here for easy
reference with the addition of the new C Create (C) flag.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PLSP-ID |Flags |C| O |A|R|S|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: The LSP Object format Format

A new flag, the Create (C) flag C flag, is introduced. On a PCRpt message, the C Flag
flag set to 1 indicates that this LSP was created via a PCInitiate
message. The C Flag flag MUST be set to 1 on each PCRpt message for the
LSP's duration of existence of the LSP. existence. The Create C flag allows PCEs to be aware of
which LSPs were PCE-initiated PCE initiated (a state that would otherwise only be
known by the PCC and the PCE that initiated them).

5.3.2. The SPEAKER-ENTITY-ID TLV

The optional SPEAKER-ENTITY-ID TLV defined in [RFC8232] MAY be
included in the LSP object in a PCRpt message, message as an optional TLV for
LSPs for which the C flag is 1. The SPEAKER-ENTITY-ID TLV identifies
the PCE which that initiated the creation of the LSP on all PCEP sessions,
a state that would otherwise only be known by the PCC and the PCE
that initiated the LSP. If the TLV appears in a PCRpt for an LSP for
which the C flag is 0, the LSP MUST be ignored ignored, and the PCE MUST send
a PCErr message with Error-type=23 ("Bad (Bad parameter value") value) and Error-
value=2 ("Speaker
Error-value=2 (Speaker identity included for an LSP that is not PCE-
initiated"). PCE
initiated).

5.4. LSP Deletion

A PCE can initiate the removal of a PCE-initiated LSP by sending a
PCInitiate message with an LSP object carrying the PLSP-ID of the LSP
to be removed and an SRP object with the R flag set (see
Section 5.2). A PLSP-ID of zero removes all LSPs with the C flag set
to 1 (in their LSP object) that are delegated to the PCE.

If the PLSP-ID is unknown, the PCC MUST send a PCErr message with
Error-type=19 ("Invalid operation") (Invalid Operation) and Error-value=3 ("Unknown PLSP-
ID") ([RFC8231]). (Unknown PLSP-ID)
[RFC8231].

If the PLSP-ID specified in the PCInitiate message is not delegated
to the PCE, the PCC MUST send a PCErr message with Error-type=19
("Invalid operation")
(Invalid operation) and Error-value=1 ("LSP (LSP is not delegated")
([RFC8231]). delegated)
[RFC8231].

If the PLSP-ID specified in the PCInitiate message was not created by
a PCE, the PCC MUST send a PCErr message with Error-type=19 ("Invalid
operation") (Invalid
operation) and Error-value=9 ("LSP (LSP is not PCE-initiated"). PCE initiated).

Following the removal of the LSP, the PCC MUST send a PCRpt as
described in [RFC8231]. The SRP object in the PCRpt MUST include the
SRP-ID-number from the PCInitiate message that triggered the removal.
The R flag in the SRP object MUST be set.

6. LSP Delegation and Cleanup

The PCC MUST delegate PCE-initiated LSPs to the PCE upon
instantiation. The PCC MUST set the delegation bit to 1 in the PCRpt
that includes the assigned PLSP-ID.

The PCC MUST NOT revoke the delegation for a PCE-initiated LSP on an
active PCEP session. Therefore, all PCRpt messages from the PCC to
the PCE that owns the delegation MUST have the delegation bit set to
1. If the PCE that owns the delegation receives a PCRpt message with
the delegation bit set to 0 0, then it MUST send a PCErr message with
Error-type=19 ("Invalid Operation") (Invalid Operation) and Error-value=7 ("Delegation (Delegation for
PCE-initiated LSP cannot be revoked"). revoked). The PCE MAY further react by
closing the session.

Control over a PCE-initiated LSP can revert to the PCC in two ways.
A PCE MAY return a delegation to the PCC to allow for LSP transfer
between PCEs. Alternatively, the PCC gains control of an LSP if the
PCEP session that it was delegated on fails and the Redelegation
Timeout Interval timer expires. In both cases, the LSP becomes an
orphan until the expiration of the State Timeout Interval timer
([RFC8231]).
[RFC8231].

The PCC MAY attempt to redelegate an orphaned LSP by following the
procedures of [RFC8231]. Alternatively, if the orphaned LSP was PCE-
initiated, then a PCE MAY obtain control over it, as follows.

A PCE (either the original or one of its backups) sends a PCInitiate
message, including
message that includes just the SRP and LSP objects, objects and carrying carries the
PLSP-ID of the LSP it wants to take control of. If the PCC receives
a PCInitiate message with a PLSP-ID pointing to an orphaned PCE-
initiated LSP, then it MUST redelegate that LSP to the PCE. Any
other non-zero PLSP-ID MUST result in the generation of a PCErr
message using the rules described in Section 5.4. The State Timeout
Interval timer for the LSP is stopped upon the redelegation. After
obtaining control of the LSP, the PCE may remove it using the
procedures described in this document.

The State Timeout Interval timer ensures that a PCE crash does not
result in automatic and immediate disruption for the services using
PCE-initiated LSPs. PCE-initiated LSPs are not removed immediately
upon PCE failure. Instead, they are cleaned up on the expiration of
this timer. This allows for network cleanup without manual
intervention. The PCC MUST support removal of PCE-initiated LSPs as
one of the behaviors applied on expiration of the State Timeout
Interval timer. The behavior MUST be picked based on local policy, policy
and can result either in either LSP removal, removal or in reverting to operator-
defined operator-defined
default parameters.

7. LSP State Synchronization

LSP State Synchronization procedures are described in section 5.4 Section 5.6 of
[RFC8231]. During State Synchronization, a PCC reports the state of
its LSPs to the PCE using PCRpt messages, setting the SYNC flag in
the LSP Object. object. For PCE-initiated LSPs, the PCC MUST also set the
Create Flag flag in the LSP Object object and MAY include the SPEAKER-ENTITY-ID
TLV identifying the PCE that requested the LSP creation. At the end
of state synchronization, State Synchronization, the PCE SHOULD send a PCInitiate message to
initiate any missing LSPs and/or remove any LSPs that are not wanted.
Under some circumstances, depending on the deployment, it might be
preferable for a PCE not to send this PCInitiate immediately, or at
all. For example, the PCC may be a slow device, or the operator
might prefer not to disrupt active flows.

8. Implementation Status

This section to be removed by the RFC editor.

This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.

According to RFC 7942, "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".

Two vendors are implementing the extensions described in this draft
and have included the functionality in releases that will be shipping
in the near future. An additional entity is working on implementing
these extensions in the scope of research projects.

9. IANA Considerations

This document requests

As detailed below, IANA actions to allocate has allocated code points for the protocol
elements defined in this document.

9.1.

8.1. PCEP Messages

IANA is requested to confirm the early allocation of has registered the following
new message type within the "PCEP
Messages" sub-registry subregistry of the PCEP Numbers registry, and to update the reference in registry. (Note that the registry to
point to
early allocation for this document, when message type was called "Initiate"; it is an RFC: has
been changed as follows.)

Value Meaning Reference
----- -------------------- -------------
12 LSP Initiate Request This document

Note to IANA: The early allocation was done for a message called
"Initiate". This name has changed to "LSP Initiate Request" as
above.

9.2. RFC 8281

8.2. LSP Object

[RFC8231] defines the LSP Object and requests object; per that RFC, IANA creates created a
registry to manage the value of the LSP Object's object's Flag field. IANA is
requested to allocate
has allocated a new bit in the LSP "LSP Object Flag Field
registry, Field" subregistry,
as follows:

Bit Description Reference
--- ----------- -------------

4 Create This document

9.3. RFC 8281

8.3. SRP object

This document requests that

IANA has created a new sub-registry, subregistry, named "SRP Object Flag Field", is created
within the "Path Computation Element Protocol (PCEP) Numbers" registry
registry, to manage the Flag field of the SRP object. New values are
to be assigned by Standards Action [RFC8126]. Each bit should be is tracked
with the following qualities: bit number (counting from bit 0 as the
most significant bit), description description, and defining RFC.

The following values are defined in this document:

Bit Description Reference
--- ----------- -------------

31 LSP-Remove This document

9.4. RFC 8281

8.4. STATEFUL-PCE-CAPABILITY TLV

[RFC8231] defines the STATEFUL-PCE-CAPABILITY TLV and requests TLV; per that RFC, IANA creates
created a registry to manage the value of the STATEFUL-PCE-
CAPABILITY STATEFUL-PCE-CAPABILITY
TLV's Flag field. IANA is requested to allocate has allocated a new bit in the STATEFUL-PCE-CAPABILITY STATEFUL-PCE-
CAPABILITY TLV Flag Field registry, as follows:

Bit Description Reference
--- -------------------------------- -------------

29 I (LSP-INSTANTIATION- This document
CAPABILITY)

9.5. LSP-INSTANTIATION-CAPABILITY (I) RFC 8281

8.5. PCEP-Error Object

IANA is requested to confirm the early allocation of has registered the following
new error types and error values within
the "PCEP-ERROR Object Error Types and Values" sub-registry subregistry of the
PCEP Numbers registry, and to
update the reference in the registry to point to this document, when
it is an RFC: registry.

Error-Type Meaning
---------- --------------
10 Invalid Object Reception of an invalid object

Error-value=8: SYMBOLIC-PATH-NAME TLV missing

19 Invalid operation Operation

Error-value=6: PCE-initiated LSP limit reached
Error-value=7: Delegation for PCE-initiated LSP cannot
be revoked
Error-value=8: Non-zero PLSP-ID in PCInitiate message LSP Initiate
Request
Error-value=9: LSP is not PCE-initiated PCE initiated
Error-value=10: PCE-initiated operation-frequency limit
reached

23 Bad parameter value

Error-value=1: SYMBOLIC-PATH-NAME in use
Error-value=2: Speaker identity included for an LSP
that is not PCE-initiated PCE initiated

24 LSP instantiation error
Error-value=1: Unacceptable instantiation parameters
Error-value=2: Internal error
Error-value=3: Signaling error

10.

9. Security Considerations

The security considerations described in [RFC8231] apply to the
extensions described in this document. Additional considerations
related to a malicious PCE are introduced.

10.1.

9.1. Malicious PCE

The LSP instantiation mechanism described in this document allows a
PCE to generate state on the PCC and throughout the network. As a
result, it introduces a new attack vector: an attacker may flood the
PCC with LSP instantiation requests and consume network and LSR
resources, either
resources by either spoofing messages or by compromising the PCE itself.

A PCC can protect itself from such an attack by imposing a limit on
either the number of LSPs or the percentage of resources that are
allocated to honor PCE-initiated LSP requests. As soon as that limit
is reached, the PCC MUST send a PCErr message with Error-type=19
("Invalid Operation")
(Invalid Operation) and Error-value=6 ("PCE-initiated (PCE-initiated LSP limit
reached")
reached) and is free to drop any incoming PCInitiate messages for LSP instantiation
initiation without additional processing.

Rapid flaps triggered by the PCE can also be an attack vector. A PCC
can protect itself from such an attack by imposing a limit on the
number of flaps per unit of time that it allows a PCE to generate.
As soon as that limit is reached, a PCC MUST send a PCErr message
with Error-type=19 ("Invalid Operation") (Invalid Operation) and Error-value=10 ("PCE- (PCE-
initiated operation frequency reached") operation-frequency limit reached) and is free to treat the
session as having reached the limit in terms of resources allocated
to honor PCE-initiated LSP requests, either permanently or for a
locally-defined cool-off period.

10.2.

9.2. Malicious PCC

The LSP instantiation mechanism described in this document requires
the PCE to keep state for LSPs that it instantiates and relies on the
PCC responding (with either a state report or an error message) to
requests for LSP instantiation. A malicious PCC or one that reached
the limit of the number of PCE-initiated LSPs, LSPs can ignore PCE requests
and consume PCE resources. A PCE can protect itself by imposing a
limit on the number of requests pending, pending or by setting a
timeout timeout, and
it MAY take further action such as closing the session or removing
all the LSPs it initiated.

12.

10. References

12.1.

10.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>.
<https://www.rfc-editor.org/info/rfc2119>.

[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009, <https://www.rfc-
editor.org/info/rfc5440>.
<https://www.rfc-editor.org/info/rfc5440>.

[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, DOI 10.17487/RFC5511, April
2009, <https://www.rfc-editor.org/info/rfc5511>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017, <https://www.rfc-
editor.org/info/rfc8231>.
<https://www.rfc-editor.org/info/rfc8231>.

[RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,
and D. Dhody, "Optimizations of Label Switched Path State
Synchronization Procedures for a Stateful PCE", RFC 8232,
DOI 10.17487/RFC8232, September 2017, <https://www.rfc-
editor.org/info/rfc8232>.

12.2.
<https://www.rfc-editor.org/info/rfc8232>.

10.2. Informative References

[RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol Generic
Requirements", RFC 4657, DOI 10.17487/RFC4657, September
2006, <https://www.rfc-editor.org/info/rfc4657>.

[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.

[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>.
<https://www.rfc-editor.org/info/rfc8051>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.

11. Acknowledgements

Acknowledgments

We would like to thank Jan Medved, Ambrose Kwong, Ramon Casellas,
Cyril Margaria, Dhruv Dhody, Raveendra Trovi Trovi, and Jon Hardwick for
their contributions to this document.

Authors' Addresses

Edward Crabbe
Individual Contributor

Email: edward.crabbe@gmail.com

Ina Minei
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
US
United States of America

Email: inaminei@google.com

Siva Sivabalan
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
US
United States of America

Email: msiva@cisco.com

Robert Varga
Pantheon Technologies SRO
Mlynske Nivy 56
Bratislava 821 05
Slovakia

Email: robert.varga@pantheon.tech