rfc9916.original.xml   rfc9916.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.4 (Ruby 3.2.2 <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
) --> -ietf-pce-pceps-tls13-04" number="9916" category="std" consensus="true" submissi
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft onType="IETF" updates="8253" obsoletes="" tocInclude="true" sortRefs="true" symR
-ietf-pce-pceps-tls13-04" category="std" consensus="true" submissionType="IETF" efs="true" version="3" xml:lang="en">
updates="8253" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.19.0 -->
<front> <front>
<title abbrev="Updates for PCEPS">Updates for PCEPS: TLS Connection Establis <title abbrev="Updates for PCEPS">Updates to the Usage of TLS to Provide a S
hment Restrictions</title> ecure Transport for the Path Computation Element Communication Protocol (PCEP)</
<seriesInfo name="Internet-Draft" value="draft-ietf-pce-pceps-tls13-04"/> title>
<seriesInfo name="RFC" value="9916"/>
<author initials="D." surname="Dhody" fullname="Dhruv Dhody"> <author initials="D." surname="Dhody" fullname="Dhruv Dhody">
<organization>Huawei</organization> <organization>Huawei</organization>
<address> <address>
<email>dhruv.ietf@gmail.com</email> <email>dhruv.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author initials="S." surname="Turner" fullname="Sean Turner"> <author initials="S." surname="Turner" fullname="Sean Turner">
<organization>sn3rd</organization> <organization>sn3rd</organization>
<address> <address>
<email>sean@sn3rd.com</email> <email>sean@sn3rd.com</email>
</address> </address>
</author> </author>
<author initials="R." surname="Housley" fullname="Russ Housley"> <author initials="R." surname="Housley" fullname="Russ Housley">
<organization abbrev="Vigil Security">Vigil Security, LLC</organization> <organization abbrev="Vigil Security">Vigil Security, LLC</organization>
<address> <address>
<postal> <postal>
<street>516 Dranesville Road</street> <street>516 Dranesville Road</street>
<city>Herndon, VA</city> <city>Herndon</city>
<region>VA</region>
<code>20170</code> <code>20170</code>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<email>housley@vigilsec.com</email> <email>housley@vigilsec.com</email>
</address> </address>
</author> </author>
<date year="2024" month="January" day="09"/> <date year="2026" month="January"/>
<area>Routing</area> <area>RTG</area>
<workgroup>Path Computation Element</workgroup> <workgroup>pce</workgroup>
<keyword>PCEP</keyword> <keyword>PCEP</keyword>
<keyword>PCEPS</keyword> <keyword>PCEPS</keyword>
<keyword>TLS 1.3</keyword> <keyword>TLS 1.3</keyword>
<keyword>TLS 1.2</keyword> <keyword>TLS 1.2</keyword>
<keyword>Early Data</keyword> <keyword>Early Data</keyword>
<keyword>0-RTT</keyword> <keyword>0-RTT</keyword>
<abstract> <abstract>
<?line 48?>
<t>Section 3.4 of RFC 8253 specifies TLS connection establishment restrictions <t>Section 3.4 of RFC 8253 specifies TLS connection establishment restrictions
for PCEPS; PCEPS refers to usage of TLS to provide a secure transport for for PCEPS; PCEPS refers to usage of TLS to provide a secure transport for the Pa
PCEP (Path Computation Element Communication Protocol). This document adds th Computation Element Communication Protocol (PCEP). This document adds
restrictions to specify what PCEPS implementations do if they support restrictions to specify what PCEPS implementations do if they support
more than one version of the TLS protocol and to restrict the use of more than one version of the TLS protocol and to restrict the use of
TLS 1.3's early data.</t> TLS 1.3's early data.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-pce-pceps-tls13/"/>.
</t>
<t>
Discussion of this document takes place on the
Path Computation Element Working Group mailing list (<eref target="mailt
o:pce@ietf.org"/>),
which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
wse/pce/"/>.
Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/pce/"/>
.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/ietf-wg-pce/draft-ietf-pce-pceps-tls13"
/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 58?> <section anchor="introduction">
<section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t><xref section="3.4" sectionFormat="of" target="RFC8253"/> specifies TLS connection establishment <t><xref section="3.4" sectionFormat="of" target="RFC8253"/> specifies TLS connection establishment
restrictions for PCEPS; PCEPS refers to usage of TLS to restrictions for PCEPS; PCEPS refers to usage of TLS to
provide a secure transport for PCEP (Path Computation Element provide a secure transport for the Path Computation Element
Communication Protocol) <xref target="RFC5440"/>. This document adds restrictio Communication Protocol (PCEP) <xref target="RFC5440"/>. This document adds rest
ns to specify rictions to specify
what PCEPS implementations do if they support more than one version of what PCEPS implementations do if they support more than one version of
the TLS protocol, e.g., TLS 1.2 <xref target="RFC5246"/> and the TLS protocol, e.g., TLS 1.2 <xref target="RFC5246"/> and
TLS 1.3 <xref target="I-D.ietf-tls-rfc8446bis"/>, and to restrict the use of TLS 1.3 <xref target="RFC9846"/>, and to restrict the use of
TLS 1.3's early data, which is also known as 0-RTT data. All other TLS 1.3's early data, which is also known as 0-RTT data. All other
provisions set forth in <xref target="RFC8253"/> are unchanged, including connec tion provisions set forth in <xref target="RFC8253"/> are unchanged, including connec tion
initiation, message framing, connection closure, certificate validation, initiation, message framing, connection closure, certificate validation,
peer identity, and failure handling.</t> peer identity, and failure handling.</t>
</section> </section>
<section anchor="conventions-and-definitions"> <section anchor="conventions-and-definitions">
<name>Conventions and Definitions</name> <name>Conventions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 <t>
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and be interpreted as
only when, they described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
appear in all capitals, as shown here.</t> when, and only when, they appear in all capitals, as shown here.
<?line -18?> </t>
</section>
</section>
<section anchor="tls-connection-establishment-restrictions"> <section anchor="tls-connection-establishment-restrictions">
<name>TLS Connection Establishment Restrictions</name> <name>TLS Connection Establishment Restrictions</name>
<t><xref section="3.4" sectionFormat="of" target="RFC8253"/> Step 1 includ es restrictions on PCEPS TLS connection <t>Step 1 in <xref section="3.4" sectionFormat="of" target="RFC8253"/> inc ludes restrictions on PCEPS TLS connection
establishment. This document adds the following restrictions:</t> establishment. This document adds the following restrictions:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Implementations that support multiple versions of the TLS protocol <bcp14>MUST</bcp14> <t>Implementations that support multiple versions of the TLS protocol <bcp14>MUST</bcp14>
prefer to negotiate the latest version of the TLS protocol; see prefer to negotiate the latest version of the TLS protocol; see
<xref section="4.2.1" sectionFormat="of" target="I-D.ietf-tls-rfc8446bis"/>.</t> <xref section="4.2.1" sectionFormat="of" target="RFC9846"/>.</t>
</li> </li>
<li> <li>
<t>PCEPS implementations that support TLS 1.3 or later <bcp14>MUST NOT </bcp14> use early data.</t> <t>PCEPS implementations that support TLS 1.3 or later <bcp14>MUST NOT </bcp14> use early data.</t>
</li> </li>
</ul> </ul>
<dl>
<dt>NOTE:</dt> <aside><t>NOTE: Early data (aka 0-RTT data) is a mechanism defined in TLS 1.3
<dd> <xref target="RFC9846"/> that allows a client to send data ("early
<t>Early data (aka 0-RTT data) is a mechanism defined in TLS 1.3
<xref target="I-D.ietf-tls-rfc8446bis"/> that allows a client to send data ("ear
ly
data") as part of the first flight of messages to a server. Note data") as part of the first flight of messages to a server. Note
that TLS 1.3 can be used without early data as per Appendix F.5 of that TLS 1.3 can be used without early data as per <xref section="F.5" target="R
<xref target="I-D.ietf-tls-rfc8446bis"/>. In fact, early data is permitted by T FC9846"/>. In fact, early data is permitted by TLS
LS
1.3 only when the client and server share a Pre-Shared Key (PSK), 1.3 only when the client and server share a Pre-Shared Key (PSK),
either obtained externally or via a previous handshake. The client either obtained externally or via a previous handshake. The client
uses the PSK to authenticate the server and to encrypt the early uses the PSK to authenticate the server and to encrypt the early
data.</t> data.</t></aside>
</dd>
<dt>NOTE:</dt> <aside><t>NOTE: As noted in <xref section="2.3" sectionFormat="of"
<dd> target="RFC9846"/>, the security properties for early data are
<t>As noted in <xref section="2.3" sectionFormat="of" target="I-D.ietf weaker than those for subsequent TLS-protected data. In particular, early
-tls-rfc8446bis"/>, the security data is not forward secret, and there is no protection against the replay of
properties for early data are weaker than those for subsequent TLS- early data between connections. <xref section="E.5" sectionFormat="of"
protected data. In particular, early data is not forward secret, and target="RFC9846"/> requires applications not use early data
there is no protection against the replay of early data between without a profile that defines its use.</t></aside>
connections. <xref section="E.5" sectionFormat="of" target="I-D.ietf-tls-rfc844
6bis"/> requires
applications not use early data without a profile that defines its
use.</t>
</dd>
</dl>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The Security Considerations of PCEP <xref target="RFC5440"/>, <xref tar <t>The security considerations of PCEP <xref target="RFC5440"/> <xref targ
get="RFC8231"/>, <xref target="RFC8253"/>, et="RFC8231"/> <xref target="RFC8253"/>
<xref target="RFC8281"/>, and <xref target="RFC8283"/>; TLS 1.2 <xref target="RF <xref target="RFC8281"/> <xref target="RFC8283"/>, TLS 1.2 <xref target="RFC5246
C5246"/>; TLS 1.3 <xref target="I-D.ietf-tls-rfc8446bis"/>, "/>, TLS 1.3 <xref target="RFC9846"/>,
and; <xref target="RFC9325"/> apply here as well.</t> and TLS/DTLS recommendations <xref target="RFC9325"/> apply here as well.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>There are no IANA considerations.</t> <t>This document has no IANA actions.</t>
</section>
<section anchor="implementation-status">
<name>Implementation Status</name>
<aside>
<t>Note to the RFC Editor - remove this section before publication, as
well as remove the reference to RFC 7942.</t>
</aside>
<t>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 <xref target="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 catalogue 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 w
orking 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>
<t>At the time of posting the -04 version of this document, there are no
known implementations of this mechanism. It is believed that one
vendor has implementation, but these plans are too vague to make
any further assertions.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC8253">
<front>
<title>PCEPS: Usage of TLS to Provide a Secure Transport for the Pat
h Computation Element Communication Protocol (PCEP)</title>
<author fullname="D. Lopez" initials="D." surname="Lopez"/>
<author fullname="O. Gonzalez de Dios" initials="O." surname="Gonzal
ez de Dios"/>
<author fullname="Q. Wu" initials="Q." surname="Wu"/>
<author fullname="D. Dhody" initials="D." surname="Dhody"/>
<date month="October" year="2017"/>
<abstract>
<t>The Path Computation Element Communication Protocol (PCEP) defi
nes the mechanisms for the communication between a Path Computation Client (PCC)
and a Path Computation Element (PCE), or among PCEs. This document describes PC
EPS -- the usage of Transport Layer Security (TLS) to provide a secure transport
for PCEP. The additional security mechanisms are provided by the transport prot
ocol supporting PCEP; therefore, they do not affect the flexibility and extensib
ility of PCEP.</t>
<t>This document updates RFC 5440 in regards to the PCEP initializ
ation phase procedures.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8253"/>
<seriesInfo name="DOI" value="10.17487/RFC8253"/>
</reference>
<reference anchor="RFC5440">
<front>
<title>Path Computation Element (PCE) Communication Protocol (PCEP)<
/title>
<author fullname="JP. Vasseur" initials="JP." role="editor" surname=
"Vasseur"/>
<author fullname="JL. Le Roux" initials="JL." role="editor" surname=
"Le Roux"/>
<date month="March" year="2009"/>
<abstract>
<t>This document specifies the Path Computation Element (PCE) Comm
unication Protocol (PCEP) for communications between a Path Computation Client (
PCC) and a PCE, or between two PCEs. Such interactions include path computation
requests and path computation replies as well as notifications of specific state
s related to the use of a PCE in the context of Multiprotocol Label Switching (M
PLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be fl
exible and extensible so as to easily allow for the addition of further messages
and objects, should further requirements be expressed in the future. [STANDARDS
-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5440"/>
<seriesInfo name="DOI" value="10.17487/RFC5440"/>
</reference>
<reference anchor="RFC5246">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</titl
e>
<author fullname="T. Dierks" initials="T." surname="Dierks"/>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="August" year="2008"/>
<abstract>
<t>This document specifies Version 1.2 of the Transport Layer Secu
rity (TLS) protocol. The TLS protocol provides communications security over the
Internet. The protocol allows client/server applications to communicate in a way
that is designed to prevent eavesdropping, tampering, or message forgery. [STAN
DARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5246"/>
<seriesInfo name="DOI" value="10.17487/RFC5246"/>
</reference>
<reference anchor="I-D.ietf-tls-rfc8446bis">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author fullname="Eric Rescorla" initials="E." surname="Rescorla">
<organization>Windy Hill Systems, LLC</organization>
</author>
<date day="7" month="July" year="2023"/>
<abstract>
<t> This document specifies version 1.3 of the Transport Layer S
ecurity
(TLS) protocol. TLS allows client/server applications to communicate
over the Internet in a way that is designed to prevent eavesdropping,
tampering, and message forgery.
This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.82
RFCs 5077, 5246, 6961, and 8446. This document also specifies new 53.xml"/>
requirements for TLS 1.2 implementations. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.54
40.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.52
46.xml"/>
<!-- [I-D.ietf-tls-rfc8446bis] -> [RFC9846]
draft-ietf-tls-rfc8446bis-14
companion doc RFC 9846
in AUTH48 as of 1/16/26
-->
<reference anchor="RFC9846" target="https://www.rfc-editor.org/info/rfc9846">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author initials="E." surname="Rescorla" fullname="Eric Rescorla">
<organization>Independent</organization>
</author>
<date month="January" year="2026"/>
</front>
<seriesInfo name="RFC" value="9846"/>
<seriesInfo name="DOI" value="10.17487/RFC9846"/>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
19.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
74.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.93
25.xml"/>
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-rfc8446bis-09"
/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC9325">
<front>
<title>Recommendations for Secure Use of Transport Layer Security (T
LS) and Datagram Transport Layer Security (DTLS)</title>
<author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
"/>
<author fullname="T. Fossati" initials="T." surname="Fossati"/>
<date month="November" year="2022"/>
<abstract>
<t>Transport Layer Security (TLS) and Datagram Transport Layer Sec
urity (DTLS) are used to protect data exchanged over a wide range of application
protocols and can also form the basis for secure transport protocols. Over the
years, the industry has witnessed several serious attacks on TLS and DTLS, inclu
ding attacks on the most commonly used cipher suites and their modes of operatio
n. This document provides the latest recommendations for ensuring the security o
f deployed services that use TLS and DTLS. These recommendations are applicable
to the majority of use cases.</t>
<t>RFC 7525, an earlier version of the TLS recommendations, was pu
blished when the industry was transitioning to TLS 1.2. Years later, this transi
tion is largely complete, and TLS 1.3 is widely available. This document updates
the guidance given the new environment and obsoletes RFC 7525. In addition, thi
s document updates RFCs 5288 and 6066 in view of recent attacks.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="195"/>
<seriesInfo name="RFC" value="9325"/>
<seriesInfo name="DOI" value="10.17487/RFC9325"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC8231">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.82
<title>Path Computation Element Communication Protocol (PCEP) Extens 31.xml"/>
ions for Stateful PCE</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.82
<author fullname="E. Crabbe" initials="E." surname="Crabbe"/> 81.xml"/>
<author fullname="I. Minei" initials="I." surname="Minei"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.82
<author fullname="J. Medved" initials="J." surname="Medved"/> 83.xml"/>
<author fullname="R. Varga" initials="R." surname="Varga"/>
<date month="September" year="2017"/>
<abstract>
<t>The Path Computation Element Communication Protocol (PCEP) prov
ides mechanisms for Path Computation Elements (PCEs) to perform path computation
s in response to Path Computation Client (PCC) requests.</t>
<t>Although PCEP explicitly makes no assumptions regarding the inf
ormation available to the PCE, it also makes no provisions for PCE control of ti
ming and sequence of path computations within and across PCEP sessions. This doc
ument describes a set of extensions to PCEP to enable stateful control of MPLS-T
E and GMPLS Label Switched Paths (LSPs) via PCEP.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8231"/>
<seriesInfo name="DOI" value="10.17487/RFC8231"/>
</reference>
<reference anchor="RFC8281">
<front>
<title>Path Computation Element Communication Protocol (PCEP) Extens
ions for PCE-Initiated LSP Setup in a Stateful PCE Model</title>
<author fullname="E. Crabbe" initials="E." surname="Crabbe"/>
<author fullname="I. Minei" initials="I." surname="Minei"/>
<author fullname="S. Sivabalan" initials="S." surname="Sivabalan"/>
<author fullname="R. Varga" initials="R." surname="Varga"/>
<date month="December" year="2017"/>
<abstract>
<t>The Path Computation Element Communication Protocol (PCEP) prov
ides mechanisms for Path Computation Elements (PCEs) to perform path computation
s in response to Path Computation Client (PCC) requests.</t>
<t>The extensions for stateful PCE provide active control of Multi
protocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSP
s) via PCEP, for a model where the PCC delegates control over one or more locall
y configured LSPs to the PCE. This document describes the creation and deletion
of PCE-initiated LSPs under the stateful PCE model.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8281"/>
<seriesInfo name="DOI" value="10.17487/RFC8281"/>
</reference>
<reference anchor="RFC8283">
<front>
<title>An Architecture for Use of PCE and the PCE Communication Prot
ocol (PCEP) in a Network with Central Control</title>
<author fullname="A. Farrel" initials="A." role="editor" surname="Fa
rrel"/>
<author fullname="Q. Zhao" initials="Q." role="editor" surname="Zhao
"/>
<author fullname="Z. Li" initials="Z." surname="Li"/>
<author fullname="C. Zhou" initials="C." surname="Zhou"/>
<date month="December" year="2017"/>
<abstract>
<t>The Path Computation Element (PCE) is a core component of Softw
are- Defined Networking (SDN) systems. It can compute optimal paths for traffic
across a network and can also update the paths to reflect changes in the network
or traffic demands.</t>
<t>PCE was developed to derive paths for MPLS Label Switched Paths
(LSPs), which are supplied to the head end of the LSP using the Path Computatio
n Element Communication Protocol (PCEP).</t>
<t>SDN has a broader applicability than signaled MPLS traffic-engi
neered (TE) networks, and the PCE may be used to determine paths in a range of u
se cases including static LSPs, segment routing, Service Function Chaining (SFC)
, and most forms of a routed or switched network. It is, therefore, reasonable t
o consider PCEP as a control protocol for use in these environments to allow the
PCE to be fully enabled as a central controller.</t>
<t>This document briefly introduces the architecture for PCE as a
central controller, examines the motivations and applicability for PCEP as a con
trol protocol in this environment, and introduces the implications for the proto
col. A PCE-based central controller can simplify the processing of a distributed
control plane by blending it with elements of SDN and without necessarily compl
etely replacing it.</t>
<t>This document does not describe use cases in detail and does no
t define protocol extensions: that work is left for other documents.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8283"/>
<seriesInfo name="DOI" value="10.17487/RFC8283"/>
</reference>
<reference anchor="RFC7942">
<front>
<title>Improving Awareness of Running Code: The Implementation Statu
s Section</title>
<author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
<author fullname="A. Farrel" initials="A." surname="Farrel"/>
<date month="July" year="2016"/>
<abstract>
<t>This document describes a simple process that allows authors of
Internet-Drafts to record the status of known implementations by including an I
mplementation Status section. This will allow reviewers and working groups to as
sign due consideration to documents that have the benefit of running code, which
may serve as evidence of valuable experimentation and feedback that have made t
he implemented protocols more mature.</t>
<t>This process is not mandatory. Authors of Internet-Drafts are e
ncouraged to consider using the process for their documents, and working groups
are invited to think about applying the process to all of their protocol specifi
cations. This document obsoletes RFC 6982, advancing it to a Best Current Practi
ce.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="205"/>
<seriesInfo name="RFC" value="7942"/>
<seriesInfo name="DOI" value="10.17487/RFC7942"/>
</reference>
</references> </references>
</references> </references>
<?line 172?>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>We would like to thank Adrian Farrel, Stephane Litkowski, Cheng Li, and <t>We would like to thank <contact fullname="Adrian Farrel"/>, <contact fu
Andrew Stone for their review.</t> llname="Stephane Litkowski"/>, <contact fullname="Cheng Li"/>, and
<contact fullname="Andrew Stone"/> for their review.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA5VY23IbNxJ9x1dgmYeNt0jKlGjHoR3bjCSvVZFtrSgnldra
B8xMk0RpCEwADGmuS/+y37JftqeBGWooS17nQSVOD9Doy+nTjRkMBiLoUNJE
9j5WhQrk5dw6eXF8ejGbyKvzmTy2xlAetDXy1AeVldovV2SCvCQfnI5vfE+o
LHO0nsgvtIgczwvrthPpQyHq9H4inx0+ORKisLlRKxxfODUPA01hPqhy4r/K
D0LpR0eDx2Ph62ylvcdRYVth9dnp1RuR42Ayvoay4GoSOP1IKEcKzlzaOmiz
6ImNddcLZ+sKwgsVlvBnVdVBJYdKYld64pq2WFhMhBxEq9v/M/7BURgNj25/
HvLPU+XKrTxRQfHT48Hl1ZVYk6kJSuT/P1HK5EnvNxgIS+XfeQvLV0qXkCMC
rzkcQ+sWLFYuX0K8DKHyk4MDXsUivaZhu+yABQeZsxtPB9h/wPsWOizrDDtj
bDcLDu3Bw9HuCaHqsLSOY4HtUmqDAJ8M5cnSFtsoSRk7Wbp63ZHCAGX0v6Of
E/m2VhvS8QUljwpeH219vWDJMLervTNmQ3lVO0Ouc8iMlOlK9w/x5sgV3TM8
lr+O0q72pOqy9l6+tbUvaWfwRP6qF7rEMXntdNj25fn5cXzZ4nn/fXwF2BOF
iXwyeipPnDLk17osSV5alYzJsRIRIGcKa/ry12mS2gJWHD4e/fC4ea5N4LL4
OOu6sEwWvl7zwZ7y6IgYDAYwCSerPAgxawryaDiWdi4v3xzHcpK+olzPNcqP
gZrfVi7tVa7rVK7YFerz9A9v5+S8DFbWXi2ID2BteK6cXeuCpEKcEQ9C2Snj
K+sCl7vg7fL7hyDPslVtdJ6kF84Gm9vy0VDKq6X2EkxQx3WqKLzomshHJ8+2
crNUobFTr6qkWaVVhZV6LsOSttLXFVslVpaNXAJC1pBcwy0+2sZV0amqsUIq
U/Ax7bFxQe3ZedGU/1+9pFjy4C81FCklK10UJQnxnTxDLm1RR4uF+Pz5Tor+
ghxxim5uvjFJ+xH49iSJrydJfj1J4oEkyc+f2YMn4/Hjm5t7MyYfyJj4UxmT
D2VM3M1YX9JwMey3jNwaeDh+ihAjm23a+MXZ4CTyDjPcwM3zZ+Px00z7m5v+
n817HwDU+VLCe1V6K6+N3RipfOL/BA05LUtpocilXPjoq6cYf4RdG9h0Cwc0
LFmbHC4vqOjjbV7WBTeEW2QIbXTQMWh9uSIfMz53aoVl/S6C8tJ6pBwycgEY
49Yr16rURdosKiIngQ4TItmx93OwDsMEBhQlFDK0v+Ouv+ZVbDqvOqF5NIIZ
Q1whSOiYkluml713H2dXvX76L99/iL8vT//x8ezy9IR/z95Oz893P0SzYvb2
w8fzk9tftzuPP7x7d/r+JG2GVO6JRO/d9Pdesr334eLq7MP76XmPoxr2QclA
sjIjvArkKkeBCqRKFORzpzM8YM/Pxxf//c9o3MDncDT6ESlJD89GP4zxsFmS
SadZU26bR8asUFUFZLAWhYznqtIBoOgzHPyScQEIEML5t39yZP41kS+yvBqN
XzYCdnhP2MZsTxhj9qXki80piPeI7jlmF809+Z1I79s7/X3vuY17R/jiFdBD
cjB69uqliBj65unxHr68rY9ZoEqOmrqgOzzDHBWpZZ9KxR6VDu+jKy70uS1L
u+Fa6yqdIGPy7A5VBWaxHUnVZdB43/KTv7elcI7BAEzUDESDIZiLmOLKkofg
8LWW9ByUQZ3AjIeHwxEvfJDNGGoPMO2e+S0zohuwGU62aIzMt9fkIDydiEkz
7LJQfq+uVYfuHkUuBCsxg2m/kgUzRSqu3eCMinrQ6mSb4kyworzUnCNuIISa
S0f2olHQw4+9R1xhlYInTdjm2iGW81IvllHWUGRsQ9wGHcKMpvXeBuK5m89r
Y5Cj02SR8gu5waSMa0MnAvEgBGiKSjeF/iTfDJ9wa/iqQzjpzIBW89DvqtJR
1UoHpqFsyxZAT8xDyyvRmSYATDjJcpAJc5lCN6bBjH8X8hew7/cXs18e9aGD
NDcbabOgYuTpE5JqENEtp3it4QZQRWuNyTLSPBReU+zi7XHQghCkqoDaGDjc
ArgD5C1kG2uajkkmd9sqNcxudjqgmXppbEhQuMXxIXv8FRT3m8N2AzcKouJ2
1lwqu9lBWDYEX1waGZA+T3ER7oue/qg5kIjzIGkJsICKpklzjhhDOq9xj7qb
KdjNejbKcRZy9I7YAiJ6QOppSauTvVILxN6ncDiqSrVlJztKMwobIiNkh6b8
kIG0A9dpBNfDkYHiP2oNquLbYFWVzZSWrN0v3R2WOfN2rktKsE/F6aUOPqV8
yETd3m6YrT2mA6c6jf6Bl2xpnCXjLJMGwz4eXkXmPhqlpx2N90X76tmonbt2
Erx/3hnkdnPcc3k7xD2MFwFdz5ue/ePR4ROeqRCdbWy/XMEbKsvo59n0/fQ+
H3kZ/pDRuCLfW5F27vEpepIKNfa+ULwQN3Z3XaDh/9TLSptf916KRDZcJwwI
vp+dFjoAmAMkcWXXlIYV36AnoznPvVWdtUnlKQJa2HR2YbeJ0uSP6ovaWfMP
P44Ph+LFQbTlJTvU0ewoj0NarKloNScuja13m0RiU7FrYC2Tg6ySteni0twN
VAJ70Kt4+6is5w8uSYn24oyHLkNhcMKfGlLCoSNTzLS8Pda19YrP6QxkCRTs
Ezc0BmB6XYWmT961uh38Wo+1jwOfKYh5SijvdVOX/NGIlwP8UJrHwZytyNEu
KCrCwwL15dmR+ImEW4iAPVypFyXB+EhpqZhiH9c7t5XZQkehcfuq4dW+nSKi
rLCUqpVfbsGhhXU+3Y5jkJONOOtN7Zho+DbUZ1zSnO8OYgkoZGARTkVqkmBk
vhbzVm2wZpWSA7pH+2S2i+dGczdAFI8AIPyY0xgOYB2DT1YDm7691zX8t4ui
8il9qxqBxBuBhsk1wh/dijRj97lzg3dKu6gjHNSav09l4J0vUMZkTdqJOQGO
sBPHXpIq+Dob+1yBK1PSexvqeJ36QtVKbQV9QgZQo9Ocgc6pwMYuiHCHiPjY
aC4lHjMk90LaxAPh1qb5ABe/2XnBrQ8IWBhZ1LTPBay6nSKbmWqpmrLMyKBc
ePwQrjYmXeAKai+MMDU1UK5m4gs6VzAChdtZHeNEn9Dl9C1g4t2MqMhUft05
a4VIpXS3wUCs2pL16f68ioEdirPAuayrloc66Nx3On1HaEipiyNAJl3Piaes
0ONA31/3LBs8Hu9PtJ2pu990zkS04isMhE27aXIokw8ZAbVrRkVEgyH+1Iri
kVwR+1r6Emjmw+AP+rDxzU0QtaIYnHB1hZFBcLnOU5lxwnnCSGwfP+xw1Jn4
pzlbWlKxiEkXnyemXmVwpPipN8dtj3o3QvyGMcTWZQE2uG5IX5lrOS2cxlTy
RjlHZT9eZCAnea7DNYbda92XxxixFhCk6WJqCkcbLORvH/O2UBq4DsX/ABDi
ZoKtFwAA
</rfc> </rfc>
 End of changes. 29 change blocks. 
449 lines changed or deleted 102 lines changed or added

This html diff was produced by rfcdiff 1.48.