rfc8741xml2.original.xml   rfc8741.xml 
<?xml version="1.0" encoding="windows-1252"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes" ?>
<?rfc tocompact="yes"?> <rfc number="8741" consensus="true" xmlns:xi="http://www.w3.org/2001/XInclude"
<?rfc tocdepth="4"?> category="std" docName="draft-ietf-pce-lsp-control-request-11"
<?rfc tocindent="yes"?> ipr="trust200902" obsoletes="" updates="" submissionType="IETF"
<?rfc symrefs="yes" ?> xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true"
<?rfc sortrefs="no"?> sortRefs="true" version="3">
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?> <!-- xml2rfc v2v3 conversion 2.37.3 -->
<?rfc compact="yes" ?>
<?rfc iprnotified="Yes" ?>
<?rfc strict="no" ?>
<rfc category="std" docName="draft-ietf-pce-lsp-control-request-11" ipr="trust20
0902" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front> <front>
<title abbrev="LSP Control Request"> <title abbrev="LSP Control Request">
Ability for a Stateful Path Computation Element (PCE) to request and obtain Ability for a Stateful Path Computation Element (PCE) to Request and
control of a Label Switched Path (LSP)</title> Obtain Control of a Label Switched Path (LSP)</title>
<seriesInfo name="RFC" value="8741"/>
<author fullname="Aswatnarayan Raghuram" initials="A." surname="Raghuram"> <author fullname="Aswatnarayan Raghuram" initials="A." surname="Raghuram">
<organization>AT&amp;T</organization> <organization>AT&amp;T</organization>
<address> <address>
<postal> <postal>
<street>200 S Laurel Aevenue</street> <street>200 S Laurel Avenue</street>
<city>Middletown</city> <city>Middletown</city>
<region>NJ</region> <region>NJ</region>
<code>07748</code> <code>07748</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>ar2521@att.com</email> <email>ar2521@att.com</email>
</address> </address>
</author> </author>
<author fullname="Al Goddard" initials="A." surname="Goddard">
<author fullname="Al Goddard" initials="A." surname="Goddard">
<organization>AT&amp;T</organization> <organization>AT&amp;T</organization>
<address> <address>
<postal> <postal>
<street>200 S Laurel Aevenue</street> <street>200 S Laurel Avenue</street>
<city>Middletown</city> <city>Middletown</city>
<region>NJ</region> <region>NJ</region>
<code>07748</code> <code>07748</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>ag6941@att.com</email> <email>ag6941@att.com</email>
</address> </address>
</author> </author>
<author fullname="Jay Karthik" initials="J." surname="Karthik">
<author fullname="Jay Karthik" initials="J." surname="Karthik">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>125 High Street</street> <street>125 High Street</street>
<city>Boston</city> <city>Boston</city>
<region>Massachusetts</region> <region>Massachusetts</region>
<code>02110</code> <code>02110</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>jakarthi@cisco.com</email> <email>jakarthi@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Siva Sivabalan" initials="S." surname="Sivabalan">
<author fullname="Siva Sivabalan" initials="S." surname="Sivabalan">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>2000 Innovation Drive</street> <street>2000 Innovation Drive</street>
<city>Kanata</city> <city>Kanata</city>
<region>Ontario</region> <region>Ontario</region>
<code>K2K 3E8</code> <code>K2K 3E8</code>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>msiva@cisco.com</email> <email>msiva@cisco.com</email>
</address> </address>
</author> </author>
<author initials="M" surname="Negi" fullname="Mahendra Singh Negi">
<author initials="M" surname="Negi" fullname="Mahendra Singh Negi">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street>Divyashree Techno Park, Whitefield</street> <street>Divyashree Techno Park, Whitefield</street>
<city>Bangalore</city> <city>Bangalore</city>
<region>Karnataka</region> <region>Karnataka</region>
<code>560066</code> <code>560066</code>
<country>India</country> <country>India</country>
</postal> </postal>
<email>mahend.ietf@gmail.com</email> <email>mahend.ietf@gmail.com</email>
</address> </address>
</author> </author>
<date month="February" year="2020"/>
<date year="2019"/>
<workgroup>PCE Working Group</workgroup> <workgroup>PCE Working Group</workgroup>
<abstract> <abstract>
<t>A stateful Path Computation Element (PCE) retains information about
<t>A Stateful Path Computation Element (PCE) retains information about the place the placement of Multiprotocol Label Switching (MPLS) Traffic
ment of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Engineering Label Switched Paths (TE LSPs). When a PCE has stateful
Paths (TE LSPs). When a PCE has stateful control over LSPs it may send indicatio control over LSPs, it may send indications to LSP head-ends to modify the
ns to LSP head-ends to modify the attributes (especially the paths) of the LSPs. attributes (especially the paths) of the LSPs. A Path Computation Client
A Path Computation Client (PCC) that has set up LSPs under local configuration (PCC) that has set up LSPs under local configuration may delegate
may delegate control of those LSPs to a stateful PCE.</t> control of those LSPs to a stateful PCE.</t>
<t>There are use cases in which a stateful PCE may wish to obtain
<t>There are use-cases in which a stateful PCE may wish to obtain control of loc control of locally configured LSPs that it is aware of but have
ally configured LSPs of which it is aware but that have not been delegated to th not been delegated to the PCE.</t>
e PCE.</t> <t>This document describes an extension to the Path Computation Element
Communication Protocol (PCEP) to enable a PCE to make requests for
<t>This document describes an extension to the Path Computation Element
communication Protocol (PCEP) to enable a PCE to make requests for
such control.</t> such control.</t>
</abstract>
</abstract> </front>
<middle>
</front> <section anchor="Introduction" numbered="true" toc="default">
<name>Introduction</name>
<middle> <t>"Path Computation Element Communication Protocol (PCEP) Extensions
for Stateful PCE"
<section anchor="Introduction" title="Introduction"> <xref target="RFC8231" format="default"/> specifies a set of
extensions to PCEP <xref target="RFC5440" format="default"/> to enable
<t>Stateful Path Computation Element (PCE) communication Protocol (PCEP) extensi stateful control of Traffic Engineering Label Switched Paths (TE LSPs)
ons <xref target="RFC8231"/> specifies a set of extensions to PCEP <xref target= between and across PCEP sessions in compliance with <xref
"RFC5440"/> to enable stateful control of Traffic Engineering Label Switched Pat target="RFC4657" format="default"/>.
hs (TE LSPs) between and across PCEP sessions in compliance with <xref target="R It includes mechanisms to
FC4657"/>. It includes mechanisms to synchronize LSP state between Path Computat synchronize LSP state between Path Computation Clients (PCCs) and PCEs,
ion Clients (PCCs) and PCEs, delegate control of LSPs to PCE, and PCE-control of delegate control of LSPs to PCEs, and allow PCEs to control the timing and
timing and sequence of path computations within and across PCEP sessions. The s sequence
tateful PCEP defines the following two useful network operations: of path computations within and across PCEP sessions. The stateful PCEP
defines the following two useful network operations:
<list style="symbols"> </t>
<t>Delegation: As per <xref target="RFC8051"/>, an operation to grant a <dl newline="false" indent="13" spacing="normal">
PCE temporary rights to modify a <dt>Delegation:</dt>
<dd>As per <xref target="RFC8051" format="default"/>, an operation to
grant a PCE temporary rights to modify a
subset of LSP parameters on one or more LSPs of a PCC. LSPs are subset of LSP parameters on one or more LSPs of a PCC. LSPs are
delegated from a PCC to a PCE and are referred to as "delegated" delegated from a PCC to a PCE and are referred to as "delegated"
LSPs.</t> LSPs.</dd>
<dt>Revocation:</dt>
<t>Revocation: As per <xref target="RFC8231"/>, an operation performed by a PCC <dd>As per <xref target="RFC8231" format="default"/>, an operation
on a previously performed by a PCC on a previously delegated LSP. Revocation revokes
delegated LSP. Revocation revokes the rights granted to the PCE the rights granted to the PCE in the delegation operation.</dd>
in the delegation operation.</t> </dl>
</list> <t>For redundant stateful PCEs (<xref target="RFC8231"
</t> sectionFormat="of" section="5.7.4"/>), during a PCE failure, one of the re
dundant PCEs
<t>For Redundant Stateful PCEs (section 5.7.4. of <xref target="RFC8231"/>), dur might want to request to take control over an LSP. The redundant PCEs
ing a PCE failure, one of the redundant PCE might want to request to take contro may use a local policy or a proprietary election mechanism to decide
l over an LSP. The redundant PCEs may use a local policy or a proprietary elect which PCE would take control. In this case, a mechanism is needed for a
ion mechanism to decide which PCE would take control. In this case, a mechanism stateful PCE to request control of one or more LSPs from a PCC so that
is needed for a stateful PCE to request control of one or more LSPs from a PCC, a newly elected primary PCE can request to take over control.</t>
so that a newly elected primary PCE can request to take over control.</t> <t>In case of virtualized PCEs (vPCEs) running in virtual network
function (VNF) mode, as the computation load in the network increases, a
<t>In case of virtualized PCEs (vPCEs) running in virtual network function (VNF) new instance of vPCE could be instantiated to balance the current
mode, as the computation load in the network increases, a new instance of vPCE load.
could be instantiated to balance the current load. The PCEs could use a propriet The PCEs could use a proprietary algorithm to decide which LSPs can
ary algorithm to decide which LSPs to be assigned to the new vPCE. Thus, having be assigned to the new vPCE. Thus, having a mechanism for the PCE to
a mechanism for the PCE to request control of some LSPs is needed.</t> request control of some LSPs is needed.</t>
<t>In some deployments, the operator would like to use stateful PCE for
<t>In some deployments, the operator would like to use stateful PCE for global o global optimization algorithms but would still like to keep the control
ptimization algorithms but would still like to keep the control of the LSP at th of the LSP at the PCC. In such cases, a stateful PCE could request to
e PCC. In such cases, a stateful PCE could request to take control during the gl take control during the global optimization and return the delegation
obal optimization and return the delegation once done.</t> once done.</t>
<t>Note that <xref target="RFC8231" format="default"/> specifies a
<t>Note that <xref target="RFC8231"/> specifies a mechanism for a PCC to delegat mechanism for a PCC to delegate an orphaned LSP to another PCE. The
e an orphaned LSP to another PCE. The mechanism defined in this document can be mechanism defined in this document can be used in conjunction with <xref
used in conjunction to <xref target="RFC8231"/>. Ultimately, it is the PCC that target="RFC8231" format="default"/>. Ultimately, it is the PCC that
decides which PCE to delegate the orphaned LSP to.</t> decides which PCE to delegate the orphaned LSP to.</t>
<!-- Dhruv commented this section
<t>Some network operators prefer head-end (PCC) based reactivity to network even
ts (e.g., link failure). For example, typically operators would like to reduce t
he time that backup LSP are being used for fast-reroute protection as the links
that a backup LSP traverses may be congested when fast-reroute is active. PCC ba
sed LSP failure detection and re-routing mechanisms enable operators to minimize
the duration of such congestion and meet operational requirements/constraints.
As such, during normal operations, it may be preferable for PCC to have full con
trol of its LSPs. However, operators shall prefer to use PCE for planned events
such as centralized optimization and placement of LSPs. In this case, it is pref
erable for a PCE to obtain the control of one or more LSPs from a PCC, rather th
an waiting for the PCC to delegate the control. Once the PCE completes its opera
tion, it relinquishes the control of the LSPs. Such capability enables operators
to combine the benefits of both centralized and distributed control of TE LSPs
to get the best of both worlds.</t>
<t>This specification provides a simple extension: by using it a PCE can request
control of one or more LSPs from any PCC over the stateful PCEP session. The pr
ocedures for granting and relinquishing control of the LSPs are specified in acc
ordance with the specification <xref target="RFC8231"/> unless explicitly set as
ide in this document. </t>
</section> <!-- Introduction -->
<section title="Terminology">
<t> This document uses the following terms defined in <xref target="RFC5440"/>:
<list style="hanging">
<t hangText=" PCC:">Path Computation Client.</t>
<t hangText=" PCE:">Path Computation Element.</t>
<t hangText=" PCEP:">Path Computation Element communication Protocol.</t>
</list>
</t>
<t>This document uses the following terms defined in <xref target="RFC8231"/>:
<list style="hanging">
<t hangText=" PCRpt:">Path Computation State Report message.</t>
<t hangText=" PCUpd:">Path Computation Update Request message.</t>
<t hangText=" PLSP-ID:">A PCEP-specific identifier for the LSP.</t>
<t hangText=" SRP:">Stateful PCE Request Parameters.</t>
</list>
</t>
<t>Readers of this document are expected to have some familiarity with <xref tar
get="RFC8231"/>.</t>
<section title="Requirements Language">
<t>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 BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when
, and only when, they
appear in all capitals, as shown here.</t>
</section>
</section> <!-- Terminology -->
<section anchor="LSP-Gain-Flag" title="LSP Control Request Flag">
<t>The Stateful PCE Request Parameters (SRP) object is defined in Section 7.2 of
<xref target="RFC8231"/> and it includes a Flags field.</t>
<!-- changed from LSp to SRP by Dhruv
<figure anchor="LSP-Object" title="The LSP Object">
<artwork align="center"><![CDATA[
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|G|C| O|A|R|S|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
-->
<!--
<figure anchor="SRP-Object" title="The SRP Object">
<artwork align="center"><![CDATA[
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 |C|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRP-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure> -->
<t>A new flag, the "LSP-Control Request Flag" (C) - TBD, is introduced in the SR
P object. On a PCUpd message, a PCE sets the C Flag to 1 to indicate that it wis
hes to gain control of LSPs. The LSPs are identified by the PLSP-ID in the LSP o
bject following the SRP object. A PLSP-ID of value other than 0 and 0xFFFFF is u
sed to identify the LSP for which the PCE requests control. The PLSP-ID value of
0 indicates that the PCE is requesting control of all LSPs originating from the
PCC that it wishes to delegate. The C Flag has no meaning in other PCEP message
s that carry SRP objects and for which the C flag MUST be set to 0 on transmissi
on and MUST be ignored on receipt.</t>
</section> <t>This specification provides a simple extension that allows a PCE
to request control of one or more LSPs from any PCC over the stateful
PCEP session. The procedures for granting and relinquishing control of
the LSPs are specified in accordance with <xref
target="RFC8231" format="default"/> unless explicitly set aside in this
document.</t>
</section>
<!-- Introduction -->
<section numbered="true" toc="default">
<name>Terminology</name>
<t> This document uses the following terms defined in <xref target="RFC544
0" format="default"/>:
</t>
<section anchor="Operation" title="Operation"> <dl newline="false" spacing="normal" indent="6">
<dt> PCC:</dt>
<dd>Path Computation Client</dd>
<dt> PCE:</dt>
<dd>Path Computation Element</dd>
<dt> PCEP:</dt>
<dd>Path Computation Element communication Protocol</dd>
</dl>
<t>This document uses the following terms defined in <xref target="RFC8231
" format="default"/>:
</t>
<dl newline="false" spacing="normal" indent="6">
<dt> PCRpt:</dt>
<dd>Path Computation State Report message</dd>
<dt> PCUpd:</dt>
<dd>Path Computation Update Request message</dd>
<dt> PLSP-ID:</dt>
<dd>A PCEP-specific identifier for the LSP</dd>
<dt> SRP:</dt>
<dd>Stateful PCE Request Parameters</dd>
</dl>
<t>Readers of this document are expected to have some familiarity with <xr
ef target="RFC8231" format="default"/>.</t>
<section numbered="true" toc="default">
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
</section>
<!-- Terminology -->
<section anchor="LSP-Gain-Flag" numbered="true" toc="default">
<name>LSP Control Request Flag</name>
<t>The Stateful PCE Request Parameters (SRP) object is defined in
<xref target="RFC8231" sectionFormat="of" section="7.2"/> and includes
a Flags field.</t>
<t>During normal operation, a PCC that wishes to delegate the control of an LSP <t>A new "LSP-Control Request" flag (30), also called the C
sets the D Flag (delegate, Section 7.3 of <xref target="RFC8231"/>) to 1 in all flag, is introduced in the SRP object. In a PCUpd message, a PCE sets
PCRpt messages pertaining to the LSP. The PCE confirms the delegation by setting the C flag to 1 to indicate that it wishes to gain control of LSPs. The
D Flag to 1 in all PCUpd messages pertaining to the LSP. The PCC revokes the co LSPs are identified by the PLSP-ID in the LSP object following the SRP
ntrol of the LSP from the PCE by setting D Flag to 0 in PCRpt messages pertainin object. A PLSP-ID value other than 0 and 0xFFFFF is used to identify
g to the LSP. If the PCE wishes to relinquish the control of the LSP, it sets D the LSP for which the PCE requests control. A PLSP-ID value of 0
Flag to 0 in all PCUpd messages pertaining to the LSP.</t> indicates that the PCE is requesting control of all LSPs originating
from the PCC that it wishes to delegate. The C flag has no meaning in
other PCEP messages that carry SRP objects and for which the C flag
<bcp14>MUST</bcp14> be set to 0 on transmission and <bcp14>MUST</bcp14>
be ignored on receipt.</t>
<t>The C flag is ignored in case the R flag <xref target="RFC8281"/> in th
e SRP object
is set.</t>
</section>
<section anchor="Operation" numbered="true" toc="default">
<name>Operation</name>
<t>During normal operation, a PCC that wishes to delegate the control of
an LSP sets the Delegate (D) flag (<xref target="RFC8231"
sectionFormat="of" section="7.3"/>) to 1 in all PCRpt messages pertaining
to the
LSP. The PCE confirms the delegation by setting the D flag to 1 in all PCU
pd
messages pertaining to the LSP. The PCC revokes the control of the LSP
from the PCE by setting the D flag to 0 in PCRpt messages pertaining to th
e
LSP. If the PCE wishes to relinquish the control of the LSP, it sets the
D flag to 0 in all PCUpd messages pertaining to the LSP.</t>
<t>If a PCE wishes to gain control over an LSP, it sends a PCUpd message with C <t>If a PCE wishes to gain control over an LSP, it sends a PCUpd message
Flag set to 1 in SRP object. The LSP for which the PCE requests control is ident with the C flag set to 1 in the SRP object. The LSP for which the PCE requ
ified by the PLSP-ID in the associated LSP object. The PLSP-ID of 0 indicates th ests
at the PCE wants control over all LSPs originating from the PCC. <!--A PCC that control is identified by the PLSP-ID in the associated LSP object. A
receives a PCUpd message with C Flag set to 1 and PLSP-ID of 0 MUST NOT trigger PLSP-ID value of 0 indicates that the PCE wants control over all LSPs
the error condition for unknown PLSP-ID in an LSP update request as per <xref ta originating from the PCC.
rget="RFC8231"/>.--> An implementation of this feature needs to make sure to che An implementation of this feature needs to make
ck for the LSP control feature (C flag set to 1) before any check for PLSP-ID (a sure to check for the LSP control feature (C flag set to 1) before any
s prescribed in <xref target="RFC8231"/>). The D Flag and C Flag are mutually ex check for PLSP-ID (as per <xref target="RFC8231"
clusive in a PCUpd message. The PCE MUST NOT send a control request for the LSP format="default"/>). The D flag and C flag are mutually exclusive in a
which is already delegated to the PCE, i.e. if the D Flag is set in the PCUpd me PCUpd message. The PCE <bcp14>MUST NOT</bcp14> send a control request
ssage, then the C Flag MUST NOT be set. If a PCC receives a PCUpd message with D for the LSP that is already delegated to the PCE, i.e., if the D flag is
Flag set in the LSP object (i.e. LSP is already delegated) and set in the PCUpd message, then the C flag <bcp14>MUST NOT</bcp14> be
the C Flag is also set (i.e. PCE is making a control request), the PCC MUST igno set. If a PCC receives a PCUpd message with the D flag set in the LSP obje
re the C Flag. A PCC can decide to delegate the control of the LSP at its own di ct
scretion. If the PCC grants or denies the control, it sends a PCRpt message with (i.e., LSP is already delegated) and
D Flag set to 1 and 0 respectively in accordance with stateful PCEP <xref targe the C flag is also set (i.e., PCE is making a control request), the PCC
t="RFC8231"/>. If the PCC does not grant the control, it MAY choose to not respo <bcp14>MUST</bcp14> ignore the C flag. A PCC can decide to delegate the
nd, and the PCE MAY choose to retry requesting the control preferably using expo control of the LSP at its own discretion. If the PCC grants or denies the
nentially increasing timer. Note that, if the PCUpd message with C Flag set is r control, it sends a PCRpt message with the D flag set to 1 and 0, respectively,
eceived for a currently non-delegated LSP (for which the PCE is requesting deleg in
ation), this MUST NOT trigger the error handling as specified in <xref target="R accordance with stateful PCEP <xref target="RFC8231" format="default"/>. If
FC8231"/> (a PCErr with Error-type=19 (Invalid Operation) the PCC does not grant the control, it <bcp14>MAY</bcp14> choose to not
and error-value 1 (Attempted LSP Update Request for a non-delegated respond, and the PCE <bcp14>MAY</bcp14> choose to retry requesting the control,
preferably using an exponentially increasing timer. Note that, if the PCUpd
message with the C flag set is received for a currently non-delegated LSP (for
which the PCE is requesting delegation), this <bcp14>MUST NOT</bcp14> trigger
the error handling as specified in <xref target="RFC8231" format="default"/>
(a PCErr with Error-type=19 (Invalid Operation) and error-value 1 (Attempted
LSP Update Request for a non-delegated
LSP)).</t> LSP)).</t>
<t>As per <xref target="RFC8231" format="default"/>, a PCC cannot
delegate an LSP to more than one PCE at any time. If a PCE requests
control of an LSP that has already been delegated by the PCC to another
PCE, the PCC <bcp14>MAY</bcp14> ignore the request or
<bcp14>MAY</bcp14> revoke
the delegation to the first PCE before delegating it to the second. This
choice is a matter of local policy.</t>
<t>As per <xref target="RFC8231"/>, a PCC cannot delegate an LSP to more than on <t>
e PCE at any time. If a PCE requests control of an LSP that has already been del It should be noted that a legacy implementation of PCC that does not
egated by the PCC to another PCE, the PCC MAY ignore the request, or MAY revoke support this extension may receive an LSP control request: a PCUpd
the delegation to the first PCE before delegating it to the second. This choi message with the C flag set and the D flag unset. The legacy implementation
ce is a matter of local policy.</t> would ignore the C flag and trigger the error condition for the D flag, as
specified in <xref target="RFC8231" format="default"/> (i.e., a PCErr with
<!--<t>It should be noted that a legacy implementation of PCC, that does not und Error-type=19 (Invalid Operation) and error-value 1 (Attempted LSP Update
erstand the C Flag in PCUpd message, would simply ignore the flag (and the reque Request for a non-delegated LSP)). Further, in case of a PLSP-ID value of
st to grant control over the LSP). At the same time it would trigger the error c 0, the error condition, as specified in <xref target="RFC8231"
ondition as specified in <xref target="RFC8231"/> (a PCErr with Error-type=19 (I format="default"/>, (i.e., a PCErr with Error-type=19 (Invalid Operation)
nvalid Operation) and error-value 3 (Attempted LSP Update Request for an LSP identified by an
and error-value 1 (Attempted LSP Update Request for a non-delegated unknown PSP-ID)) would be triggered.</t>
LSP)).</t>--> <t><xref target="RFC8281" format="default"/> describes the setup,
maintenance, and teardown of PCE-initiated LSPs under the stateful PCE
<t>It should be noted that a legacy implementation of PCC that does not
support this extension would receive an LSP control request: PCUpd message wit
h C flag set and D flag (delegate) unset, it would ignore the C flag and trigger
the error condition for the D flag as specified in <xref target="RFC8231"/> (a
PCErr with Error-type=19 (Invalid Operation) and
error-value 1 (Attempted LSP Update Request for a non-delegated LSP)). Further
, in case of PLSP-ID of 0, the error condition as specified
in <xref target="RFC8231"/> (a PCErr with Error-type=19 (Invalid Operation) an
d
error-value 3 (Attempted LSP Update Request for an LSP identified by an unknow
n PSP-ID)) would be triggered.</t>
<t><xref target="RFC8281"/> describes the setup,
maintenance and teardown of PCE-initiated LSPs under the stateful PCE
model. It also specifies how a PCE may obtain control over an orphaned LSP model. It also specifies how a PCE may obtain control over an orphaned LSP
that was PCE-initiated. A PCE implementation can apply the mechanism describe d that was PCE-initiated. A PCE implementation can apply the mechanism describe d
in this document in conjunction with those in <xref target="RFC8281"/>.</t> in this document in conjunction with those in <xref target="RFC8281"
format="default"/>.</t>
</section> </section>
<section anchor="Imp" title="Implementation Status"> <section anchor="Security" numbered="true" toc="default">
<t>[Note to the RFC Editor - remove this section before publication, as well as <name>Security Considerations</name>
remove the reference to RFC 7942.]</t> <t>The security considerations listed in <xref target="RFC8231"
<t>This section records the status of known implementations of the format="default"/> and <xref target="RFC8281" format="default"/>
protocol defined by this specification at the time of posting of
this Internet-Draft, and is based on a proposal described in
<xref target="RFC7942"/>. The description of implementations in this secti
on 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.</t>
<t>According to <xref target="RFC7942"/>, "this will allow reviewers and wo
rking
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".</t>
<section anchor="Onos" title="Huawei's Proof of Concept based on ONOS">
<t>The PCE function was developed in the ONOS open source platform. This exten
sion was implemented on a private version as a proof of concept to enable multi-
instance support.
<list style="symbols">
<t>Organization: Huawei</t>
<t>Implementation: Huawei's PoC based on ONOS</t>
<t>Description: PCEP as a southbound plugin was added to ONOS. To support mu
lti-instance ONOS deployment in a cluster, this extension in PCEP is used. Refer
https://wiki.onosproject.org/display/ONOS/PCEP+Protocol</t>
<t>Maturity Level: Prototype</t>
<t>Coverage: Full</t>
<t>Contact: satishk@huawei.com</t>
</list></t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>The security considerations listed in <xref target="RFC8231"/> and <xref targ
et="RFC8281"/>
apply to this document as well. However, this document also apply to this document as well. However, this document also
introduces a new attack vector. An attacker may flood the PCC with request to introduces a new attack vector. An attacker may flood the PCC with requests
delegate all of its LSPs to delegate all of its LSPs
at a rate which exceeds the PCC's ability to process them, either by spoofing at a rate that exceeds the PCC's ability to process them, either by
messages or by compromising the PCE itself. spoofing messages or by compromising the PCE itself.
The PCC SHOULD be configured with a threshold rate for the delegation request The PCC <bcp14>SHOULD</bcp14> be configured with a threshold rate for the
s received from the PCE. If the threshold is reached, it is RECOMMENDED to log t delegation requests received from the PCE. If the threshold is reached,
he issue.</t> it is <bcp14>RECOMMENDED</bcp14> to log the issue.</t>
<t>A PCC is the ultimate arbiter of delegation. As per <xref
<t>A PCC is the ultimate arbiter of delegation. As per <xref target="RFC8231" target="RFC8231" format="default"/>, a local policy at the PCC is used to
/>, a local policy at PCC is used to influence the delegation. A PCC can also re influence the delegation. A PCC can also revoke the delegation at any
voke the delegation at any time. A PCC need not blindly trust the control reques time. A PCC need not blindly trust the control requests and
ts and SHOULD take local policy and other factors into consideration before hono <bcp14>SHOULD</bcp14> take local policy and other factors into
ring the request. </t> consideration before honoring the request. </t>
<t>Note that a PCE may not be sure if a PCC supports this feature. A
<t>Note that, a PCE may not be sure if a PCC supports this feature. A PCE wou PCE would try sending a control request to a 'legacy' PCC that would
ld try sending a control request to a 'legacy' PCC, which would in turn respond in turn respond with an error, as described in <xref target="Operation"
with an error as described in <xref target="Operation"/>. So a PCE would learn t format="default"/>. So, a PCE would learn this fact only when it wants to
his fact only when it wants to take control over an LSP. A PCE might also be sus take control over an LSP. A PCE might also be susceptible to downgrade
ceptible to a downgrade attacks by falsifying the error condition.</t> attacks by falsifying the error condition.</t>
<t>As per <xref target="RFC8231" format="default"/>, it is <bcp14>RECOMMEN
<t>As per <xref target="RFC8231"/>, it is RECOMMENDED DED</bcp14>
that these PCEP extensions only be activated on authenticated and that these PCEP extensions only be activated on authenticated and
encrypted sessions across PCEs and PCCs belonging to the same encrypted sessions across PCEs and PCCs belonging to the same
administrative authority, using Transport Layer Security (TLS) administrative authority, using Transport Layer Security (TLS)
<xref target="RFC8253"/>, as per the recommendations and best current practic <xref target="RFC8253" format="default"/>, as per the recommendations and
es in best current practices in
BCP 195 <xref target="RFC7525"/> (unless explicitly excluded in <xref target= BCP 195 <xref target="RFC7525" format="default"/> (unless explicitly
"RFC8253"/>). excluded in <xref target="RFC8253" format="default"/>).
</t> </t>
</section>
</section> <section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<section anchor="IANA" title="IANA Considerations">
<section anchor="IANA-srp" title="SRP Object Flags">
<t>IANA maintains a registry called the "Path Computation Element Protocol (PCEP
) Numbers" registry. It contains a subregistry called
the "SRP Object Flag Field" registry. This document requests IANA to allocat
e following code point in the "SRP Object Flag Field" subregistry.</t>
<texttable style="none" suppress-title="true" title="" align="center"> <t>IANA has allocated the following code point in the "SRP Object Flag
<ttcol align="left" width="20%">Bit</ttcol> Field" subregistry in the "Path Computation Element Protocol (PCEP)
<ttcol align="left" width="30%">Description</ttcol> Numbers" registry.</t>
<ttcol align="left" width="20%">Reference</ttcol> <table align="center">
<c>TBD</c> <thead>
<c>LSP-Control Request Flag</c> <tr>
<c>This document</c> <th align="left">Bit</th>
</texttable></section> <th align="left">Description</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">30</td>
<td align="left">LSP Control Request</td>
<td align="left">RFC 8741</td>
</tr>
</tbody>
</table>
</section>
</section> <section toc="default" numbered="true">
<name>Manageability Considerations</name>
<t>
All manageability requirements and considerations listed in <xref
target="RFC5440" format="default"/>
and <xref target="RFC8231" format="default"/>
apply to PCEP extensions defined in this document. In addition,
requirements and considerations listed in this section apply.
</t>
<section toc="default" numbered="true">
<name>Control of Function and Policy</name>
<section title="Manageability Considerations" toc="default"> <t>
<t> A PCC implementation <bcp14>SHOULD</bcp14> allow the operator to configure
All manageability requirements and considerations listed in <xref target="RFC5 the policy rules that specify the conditions under which it honors the
440" pageno="false" format="default"/> request to control the LSPs. This includes the handling of the case where an
and <xref target="RFC8231" pageno="false" format="default"/> LSP control request is received for an LSP that is currently delegated to
apply to PCEP protocol extensions defined in this document. In addition, requi some other PCE. A PCC implementation <bcp14>SHOULD</bcp14> also allow the
rements and considerations listed in this section apply. operator to configure the threshold rate for the delegation requests
</t> received from the PCE. Further, the operator <bcp14>MAY</bcp14> be allowed
<section title="Control of Function and Policy" toc="default"> to trigger the LSP control request for a particular LSP at the PCE. A PCE
<t> implementation <bcp14>SHOULD</bcp14> also allow the operator to configure an
A PCC implementation SHOULD allow the operator to configure the policy based o exponentially increasing timer to retry the control requests for which the
n which it honors the request to control the LSPs. This includes the handling of PCE did not get a response.
the case where an LSP </t>
control request is received for an LSP that is currently delegated to some oth </section>
er PCE. A PCC implementation SHOULD also allow the operator to configure the thr <section toc="default" numbered="true">
eshold rate based on which it accepts the delegation requests from the PCE. <name>Information and Data Models</name>
Further, the operator MAY be allowed to trigger the LSP control request for a <t>The PCEP YANG module <xref target="I-D.ietf-pce-pcep-yang"
particular LSP at the PCE. format="default"/> could be extended to include a mechanism to trigger
A PCE implementation SHOULD also allow the operator to configure an exponentia the LSP control request.</t>
lly increasing timer to retry the control requests for which the PCE did not get </section>
a response. <section toc="default" numbered="true">
</t> <name>Liveness Detection and Monitoring</name>
</section> <t>
<section title="Information and Data Models" toc="default"> Mechanisms defined in this document do not imply any new liveness detection
<t>The PCEP YANG module <xref target="I-D.ietf-pce-pcep-yang"/> could be exten and monitoring requirements in addition to those already listed in <xref
ded to include mechanism to trigger the LSP control request.</t> target="RFC5440" format="default"/>.
</section> </t>
<section title="Liveness Detection and Monitoring" toc="default"> </section>
<t> <section toc="default" numbered="true">
Mechanisms defined in this document do not imply any new liveness detection an <name>Verify Correct Operations</name>
d monitoring requirements in addition to those already listed in <xref target="R <t>
FC5440" pageno="false" format="default"/>. Mechanisms defined in this document do not imply any new operation
</t> verification requirements in addition to those already listed in <xref
</section> target="RFC5440" format="default"/>
<section title="Verify Correct Operations" toc="default"> and <xref target="RFC8231" format="default"/>.
<t> </t>
Mechanisms defined in this document do not imply any new operation verificatio </section>
n requirements in addition to those already listed in <xref target="RFC5440" pag <section toc="default" numbered="true">
eno="false" format="default"/> <name>Requirements on Other Protocols</name>
and <xref target="RFC8231" pageno="false" format="default"/>. <t>Mechanisms defined in this document do not imply any new
</t> requirements on other protocols.</t>
</section> </section>
<section title="Requirements On Other Protocols" toc="default"> <section toc="default" numbered="true">
<t>Mechanisms defined in this document do not imply any new requirements on ot <name>Impact on Network Operations</name>
her protocols.</t> <t>
</section> Mechanisms defined in <xref target="RFC5440" format="default"/>
<section title="Impact On Network Operations" toc="default">
<t>
Mechanisms defined in <xref target="RFC5440" pageno="false" format="default"/>
and and
<xref target="RFC8231" pageno="false" format="default"/> also apply to PCEP ex <xref target="RFC8231" format="default"/> also apply to PCEP extensions define
tensions defined in this document. d in this document.
Further, the mechanism described in this document can help the operator to req Further, the mechanism described in this document can help the operator to
uest control of the LSPs at a particular PCE.</t> request control of the LSPs at a particular PCE.</t>
</section> </section>
</section> </section>
<section anchor="Acknowledgement" title="Acknowledgements">
<t>Thanks to Jonathan Hardwick to remind the authors to not use suggested values
in IANA section.</t>
<t>Thanks to Adrian Farrel, Haomian Zheng and Tomonori Takeda for their valuable
comments.</t>
<t>Thanks to Shawn M. Emery for security directorate's review.</t>
<t>Thanks to Francesca Palombini for GENART review.</t>
<t>Thanks to Benjamin Kaduk, Martin Vigoureux, Alvaro Retana, and Barry Leiba fo
r IESG reviews.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.211
9.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.544
0.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.817
4.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.823
1.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.828
1.xml"?>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4657.xml"
?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7525.xml"
?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7942.xml"
?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8051.xml"
?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8253.xml"
?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pce
-pcep-yang"?>
</references> </middle>
<section title="Contributor Addresses" toc="default"> <back>
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height=
"">
<artwork xml:space="preserve" name="" type="" align="left" alt="" widt
h="" height=""><![CDATA[
Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
EMail: dhruv.ietf@gmail.com <displayreference target="I-D.ietf-pce-pcep-yang" to="PCEP-YANG"/>
]]></artwork> <references>
</figure> <name>References</name>
</t> <references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5440.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8231.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8281.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4657.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7525.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8051.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8253.xml"/>
<t> <!-- ietf-pce-pcep-yang I-D Exists -->
<figure title="" suppress-title="false" align="left" alt="" width="" height=
"">
<artwork xml:space="preserve" name="" type="" align="left" alt="" widt
h="" height=""><![CDATA[
Jon Parker
Cisco Systems, Inc.
2000 Innovation Drive
Kanata, Ontario K2K 3E8
Canada
EMail: jdparker@cisco.com <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe rence.I-D.ietf-pce-pcep-yang.xml"/>
]]></artwork> </references>
</figure> </references>
</t> <section anchor="Acknowledgement" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>Thanks to <contact fullname="Jonathan Hardwick"/> for reminding the aut
hors to not use
suggested values in IANA section.</t>
<t>Thanks to <contact fullname="Adrian Farrel"/>, <contact
fullname="Haomian Zheng"/>, and <contact fullname="Tomonori Takeda"/> for
their
valuable comments.</t>
<t>Thanks to <contact fullname="Shawn M. Emery"/> for his Security Directo
rate review.</t>
<t>Thanks to <contact fullname="Francesca Palombini"/> for GENART review.<
/t>
<t>Thanks to <contact fullname="Benjamin Kaduk"/>, <contact
fullname="Martin Vigoureux"/>, <contact fullname="Alvaro Retana"/>, and
<contact fullname="Barry Leiba"/> for IESG reviews.</t>
</section>
<section anchor="constributors" numbered="false">
<t> <name>Contributors</name>
<figure title="" suppress-title="false" align="left" alt="" width="" height= <t>The following people contributed substantially to the content of this
""> document and should be considered coauthors:</t>
<artwork xml:space="preserve" name="" type="" align="left" alt="" widt <contact fullname="Dhruv Dhody">
h="" height=""><![CDATA[ <organization> Huawei Technologies</organization>
Chaitanya Yadlapalli <address>
AT&T <postal>
200 S Laurel Aevenue <street>Divyashree Techno Park, Whitefield</street>
Middletown NJ 07748 <city>Bangalore</city>
USA <region>Karnataka</region>
<code>560066</code>
<country>India</country>
</postal>
<email>dhruv.ietf@gmail.com</email>
</address>
</contact>
EMail: cy098d@att.com <contact fullname="Jon Parker">
]]></artwork> <organization>Cisco Systems, Inc.</organization>
</figure> <address>
</t> <postal>
<street>2000 Innovation Drive</street>
<city>Kanata</city>
<region>Ontario</region>
<code>K2K 3E8</code>
<country>Canada</country>
</postal>
<email>jdparker@cisco.com</email>
</address>
</contact>
<contact fullname="Chaitanya Yadlapalli">
<organization>AT&amp;T</organization>
<address>
<postal>
<street>200 S Laurel Avenue</street>
<city>Middletown</city>
<region>NJ</region>
<code>07748</code>
<country>United States of America</country>
</postal>
<email>cy098@att.com</email>
</address>
</contact>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 38 change blocks. 
502 lines changed or deleted 438 lines changed or added

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