rfc9757.original.xml   rfc9757.xml 
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!-- [rfced] pre-edited by ST 09/04/24 -->
<!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;">
]> ]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" docName="draft-ie tf-pce-pcep-extension-native-ip-39" number="0000" consensus="true" ipr="trust200 902" sortRefs="true" submissionType="IETF" symRefs="true" tocInclude="true" obso letes="" updates="" xml:lang="en" tocDepth="3" version="3"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" docName="draft-ie tf-pce-pcep-extension-native-ip-40" number="9757" consensus="true" ipr="trust200 902" sortRefs="true" submissionType="IETF" symRefs="true" tocInclude="true" obso letes="" updates="" xml:lang="en" tocDepth="3" version="3">
<front> <front>
<title abbrev="PCEP for Native IP">Path Computation Element Communication <title abbrev="PCEP for Native IP">Path Computation Element Communication
Protocol (PCEP) Extensions for Native IP Networks</title> Protocol (PCEP) Extensions for Native IP Networks</title>
<seriesInfo name="RFC" value="0000"/> <seriesInfo name="RFC" value="9757"/>
<author fullname="Aijun Wang" initials="A" surname="Wang"> <author fullname="Aijun Wang" initials="A" surname="Wang">
<organization>China Telecom</organization> <organization>China Telecom</organization>
<address> <address>
<postal> <postal>
<street>Beiqijia Town, Changping District</street> <street>Beiqijia Town, Changping District</street>
<city>Beijing</city> <city>Beijing</city>
<region>Beijing</region>
<code>102209</code> <code>102209</code>
<country>China</country> <country>China</country>
</postal> </postal>
<email>wangaijun@tsinghua.org.cn</email> <email>wangaijun@tsinghua.org.cn</email>
</address> </address>
</author> </author>
<author fullname="Boris Khasanov" initials="B" surname="Khasanov"> <author fullname="Boris Khasanov" initials="B" surname="Khasanov">
<organization abbrev="">MTS Web Services (MWS)</organization> <organization abbrev="">MTS Web Services (MWS)</organization>
<address> <address>
<postal> <postal>
<street>Andropova av.,18/9 115432</street> <street>Andropova av., 18/9</street>
<city>Moscow</city> <city>Moscow</city>
<code>115432</code>
<country>Russian Federation</country> <country>Russian Federation</country>
</postal> </postal>
<email>bhassanov@yahoo.com</email> <email>bhassanov@yahoo.com</email>
</address> </address>
</author> </author>
<author fullname="Sheng Fang" initials="S" surname="Fang"> <author fullname="Sheng Fang" initials="S" surname="Fang">
<organization abbrev="">Huawei Technologies</organization> <organization abbrev="">Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street>Huawei Bld., No.156 Beiqing Rd.</street> <street>Huawei Bld., No.156 Beiqing Rd.</street>
<city>Beijing</city> <city>Beijing</city>
<country>China</country> <country>China</country>
</postal> </postal>
<email>fsheng@huawei.com</email> <email>fsheng@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Ren Tan" initials="R" surname="Tan">
<organization abbrev="">Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Bld., No.156 Beiqing Rd.</street>
<city>Beijing</city>
<country>China</country>
</postal>
<email>tanren@huawei.com</email>
</address>
</author>
<author fullname="Chun Zhu" initials="C" surname="Zhu"> <author fullname="Chun Zhu" initials="C" surname="Zhu">
<organization>ZTE Corporation</organization> <organization>ZTE Corporation</organization>
<address> <address>
<postal> <postal>
<street>50 Software Avenue, Yuhua District</street> <street>50 Software Avenue, Yuhua District</street>
<city>Nanjing</city> <city>Nanjing</city>
<region>Jiangsu</region> <region>Jiangsu</region>
<code>210012</code> <code>210012</code>
<country>China</country> <country>China</country>
</postal> </postal>
<email>zhu.chun1@zte.com.cn</email> <email>zhu.chun1@zte.com.cn</email>
</address> </address>
</author> </author>
<date month="September" year="2024"/> <date month="March" year="2025"/>
<area>RTG</area> <area>RTG</area>
<workgroup>pce</workgroup> <workgroup>pce</workgroup>
<keyword>CCDR</keyword> <keyword>CCDR</keyword>
<keyword>PCECC</keyword> <keyword>PCECC</keyword>
<abstract> <abstract>
<t>This document introduces extensions to the PCE Communication Protocol <t>This document introduces extensions to the Path Computation Element Com
(PCEP) to support path computation in native IP networks through a munication Protocol
(PCEP) to support path computation in Native IP networks through a
PCE-based central control mechanism known as Centralized Control Dynamic PCE-based central control mechanism known as Centralized Control Dynamic
Routing (CCDR). These extensions empower a PCE to calculate and manage Routing (CCDR). These extensions empower a PCE to calculate and manage
paths specifically for native IP networks, expand PCEP's paths specifically for Native IP networks, thereby expanding PCEP's
capabilities beyond its traditional use in MPLS and GMPLS networks. By capabilities beyond its past use in MPLS and GMPLS networks. By
implementing these extensions, IP network resources can be utilized more implementing these extensions, IP network resources can be utilized more
efficiently, facilitating the deployment of traffic engineering in efficiently, facilitating the deployment of traffic engineering in
native IP environments.</t> Native IP environments.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" numbered="true" toc="default"> <section anchor="intro" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>Generally, Multiprotocol Label Switching Traffic Engineering <t>Generally, Multiprotocol Label Switching Traffic Engineering
(MPLS-TE) requires the corresponding network devices to support Resource (MPLS-TE) requires the corresponding network devices to support the Resour
ReSerVation Protocol (RSVP)<xref target="RFC3209" format="default"/>/Label ce
Distribution ReSerVation Protocol (RSVP) <xref target="RFC3209" format="default"/> and
Protocol (LDP)<xref target="RFC5036" format="default"/> protocols to ensur the Label Distribution
e the Protocol (LDP) <xref target="RFC5036" format="default"/> to ensure
End-to-End (E2E) traffic performance. But in native IP network scenarios End-to-End (E2E) traffic performance. But in Native IP network scenarios
described in <xref target="RFC8735" format="default"/>, there will be no s uch signaling described in <xref target="RFC8735" format="default"/>, there will be no s uch signaling
protocol to synchronize the actions among different network devices. It protocol to synchronize the actions among different network devices. It
is feasible to use the central control mode described in <xref target="RFC 8283" format="default"/> to correlate the forwarding behavior among different is feasible to use the central control mode described in <xref target="RFC 8283" format="default"/> to correlate the forwarding behavior among different
network devices. <xref target="RFC8821" format="default"/> describes the a network devices.
rchitecture and <xref target="RFC8821" format="default"/> describes the architecture and
solution philosophy for the E2E traffic assurance in the Native IP solution philosophy for the E2E traffic assurance in the Native IP
network via multiple Border Gateway Protocol (BGP) sessions-based network via a solution based on multiple Border Gateway Protocol (BGP) ses
solution. It requires only the PCE to send the instructions to the PCCs, sions.
It requires only the PCE to send the instructions to the Path Computation
Clients (PCCs)
to build multiple BGP sessions, distribute different prefixes on the to build multiple BGP sessions, distribute different prefixes on the
established BGP sessions and assign the different paths to the BGP next established BGP sessions, and assign the different paths to the BGP next
hops.</t> hops.</t>
<t>This document describes the corresponding Path Computation Element <t>This document describes the corresponding Path Computation Element
Communication Protocol (PCEP) extensions to transfer the key information Communication Protocol (PCEP) extensions to transfer the key information
about BGP peer, peer prefix advertisement, and the explicit peer route about the BGP peer, peer prefix advertisement, and explicit peer route
on on-path routers.</t> on on-path routers.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Conventions used in this document</name> <name>Conventions Used in This Document</name>
<t>The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"OPTIONAL" in this document are to be interpreted as described in BCP 14 IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
<xref target="RFC2119" format="default"/> <xref target="RFC8174" format="d NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
efault"/> when, and only when, RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
they appear in all capitals, as shown here.</t> "<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 numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Use of RBNF</name> <name>Use of RBNF</name>
<t>The message formats in this document are illustrated using Routing <t>The message formats in this document are illustrated using Routing
Backus-Naur Form (RBNF) encoding, as specified in <xref target="RFC5511" format="default"/>. The use of RBNF is illustrative only and may elide Backus-Naur Form (RBNF) encoding, as specified in <xref target="RFC5511" format="default"/>. The use of RBNF is illustrative only and may elide
certain important details; the normative specification of messages is certain important details; the normative specification of messages is
found in the prose description. If there is any divergence between the found in the prose description. If there is any divergence between the
RBNF and the prose, the prose is considered authoritative.</t> RBNF and the prose, the prose is considered authoritative.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Experimental Status Consideration</name> <name>Experimental Status Consideration</name>
<t>The procedures outlined in this document are experimental. The <t>The procedures outlined in this document are experimental. The
experiment aims to explore the use of PCE (and PCEP) for end-to-end experiment aims to explore the use of PCE (and PCEP) for E2E
traffic assurance in Native IP networks through multiple BGP sessions. traffic assurance in Native IP networks through multiple BGP sessions.
Additional implementation is necessary to gain a deeper understanding Additional implementation is necessary to gain a deeper understanding
of the operational impact, scalability, and stability of the mechanism of the operational impact, scalability, and stability of the mechanism
described. Feedback from deployments will be crucial in determining described. Feedback from deployments will be crucial in determining
whether this specification should advance from Experimental to the whether this specification should advance from Experimental to the
IETF Standards Track.</t> IETF Standards Track.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Terminology</name> <name>Terminology</name>
<t>This document uses the following terms defined in <xref target="RFC5440 <t>This document uses the following terms defined in <xref target="RFC5440
" format="default"/>: PCC, PCE, PCEP.</t> " format="default"/>: PCC, PCE, and PCEP.</t>
<t>The following terminology is used in this document:</t> <t>Additionally, the following terminology is used in this document:</t>
<ul spacing="normal"> <dl spacing="normal" newline="false">
<li> <dt>BPI:</dt><dd>BGP Peer Info</dd>
<t>BPI: BGP Peer Info</t> <dt>CCDR:</dt><dd>Centralized Control Dynamic Routing</dd>
</li> <dt>CCI:</dt><dd>Central Controller Instructions (defined in <xref tar
<li> get="RFC9050" format="default"/>)</dd>
<t>CCDR: Central Control Dynamic Routing</t> <dt>E2E:</dt><dd>End-to-End</dd>
</li> <dt>EPR:</dt><dd>Explicit Peer Route</dd>
<li> <dt>Native IP network:</dt><dd>Network that forwards traffic based sol
<t>CCI: Central Controller Instructions, defined in <xref target="RFC9 ely on
050" format="default"/></t> the IP address, instead of another indicator, for example, MPLS,
</li> etc.</dd>
<li> <dt>PCECC:</dt><dd>PCE as a Central Controller (defined in <xref targe
<t>E2E: End-to-End</t> t="RFC8283" format="default"/>)</dd>
</li> <dt>PPA:</dt><dd>Peer Prefix Advertisement</dd>
<li> <dt>PST:</dt><dd>Path Setup Type (defined in <xref target="RFC8408" fo
<t>EPR: Explicit Peer Route</t> rmat="default"/>)</dd>
</li> <dt>SRP:</dt><dd>Stateful PCE Request Parameter (defined in <xref targ
<li> et="RFC8231" format="default"/>)</dd>
<t>Native IP network: Network that forwards traffic based solely on <dt>RR:</dt><dd>Route Reflector</dd>
the IP address, instead of other indicator, for example MPLS </dl>
etc.</t>
</li>
<li>
<t>PCECC: PCE as a Central Controller, defined in <xref target="RFC828
3" format="default"/></t>
</li>
<li>
<t>PPA: Peer Prefix Advertisement</t>
</li>
<li>
<t>PST: Path Setup Type, defined in <xref target="RFC8408" format="def
ault"/></t>
</li>
<li>
<t>SRP: Stateful PCE Request Parameters, defined in <xref target="RFC8
231" format="default"/></t>
</li>
<li>
<t>RR: Route Reflector</t>
</li>
</ul>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Capability Advertisement</name> <name>Capability Advertisement</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Open Message</name> <name>Open Message</name>
<t>During the PCEP Initialization Phase, PCEP Speakers (PCE or PCC) <t>During the PCEP Initialization Phase, PCEP speakers (PCE or PCC)
advertise their support of Native IP extensions.</t> advertise their support of Native IP extensions.</t>
<t>This document defines a new Path Setup Type (PST) <xref target="RFC84 08" format="default"/> for Native-IP, as follows: </t> <t>This document defines a new Path Setup Type (PST) <xref target="RFC84 08" format="default"/> for Native IP, as follows: </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>PST = 4: Path is a Native IP TE path as per <xref target="RFC8821"
<t>PST = 4: Path is a Native IP TE path as per <xref target="RFC8821 format="default"/>.</li>
" format="default"/>.</t>
</li>
</ul> </ul>
<t>A PCEP speaker MUST indicate its support of the function described <t>A PCEP speaker <bcp14>MUST</bcp14> indicate its support of the functi on described
in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the
OPEN object with this new PST included in the PST list.</t> OPEN object with this new PST included in the PST list.</t>
<t><xref target="RFC9050" format="default"/> defined the PCECC-CAPABILIT Y sub-TLV to <t><xref target="RFC9050" format="default"/> defined the PCECC-CAPABILIT Y sub-TLV to
exchange information about their PCECC capability. A new flag is exchange information about the PCEP speakers' PCECC capability. A new fl
defined in PCECC-CAPABILITY sub-TLV for Native IP:</t> ag is
defined in the PCECC-CAPABILITY sub-TLV for Native IP:</t>
<t>N (NATIVE-IP-TE-CAPABILITY - 1 bit - 30): When set to 1 by a PCEP <t>N (NATIVE-IP-TE-CAPABILITY - 1 bit - 30): When set to 1 by a PCEP
speaker, this flag indicates that the PCEP speaker is capable of TE in speaker, this flag indicates that the PCEP speaker is capable of TE in
a Native IP network, as specified in this document. Both the PCC and a Native IP network, as specified in this document. Both the PCC and
PCE MUST set this flag to support this extension.</t> PCE <bcp14>MUST</bcp14> set this flag to support this extension.</t>
<t>If a PCEP speaker receives the PATH-SETUP-TYPE-CAPABILITY TLV with <t>If a PCEP speaker receives the PATH-SETUP-TYPE-CAPABILITY TLV with
the newly defined path setup type, but without the N bit set in the newly defined PST, but without the N bit set in
PCECC-CAPABILITY sub-TLV, it MUST:</t> PCECC-CAPABILITY sub-TLV, it <bcp14>MUST</bcp14>:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>send a PCErr message with Error-Type=10 (Reception of an <t>send a PCErr message with Error-Type=10 (Reception of an
invalid object) and Error-Value=39 (PCECC NATIVE-IP-TE-CAPABILITY invalid object) and Error-value=39 (PCECC NATIVE-IP-TE-CAPABILITY
bit is not set).</t> bit is not set) and</t>
</li> </li>
<li> <li>
<t>terminate the PCEP session</t> <t>terminate the PCEP session.</t>
</li> </li>
</ul> </ul>
<t>If a PCEP speaker receives the PATH-SETUP-TYPE-CAPABILITY TLV with <t>If a PCEP speaker receives the PATH-SETUP-TYPE-CAPABILITY TLV with
the newly defined path setup type, but without the PCECC-CAPABILITY the newly defined PST, but without the PCECC-CAPABILITY
sub-TLV, it MUST:</t> sub-TLV, it <bcp14>MUST</bcp14>:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>send a PCErr message with Error-Type=10(Reception of an invalid <t>send a PCErr message with Error-Type=10 (Reception of an invalid
object) and Error-Value=33 (Missing PCECC Capability sub-TLV).</t> object) and Error-value=33 (Missing PCECC Capability sub-TLV) and</t
>
</li> </li>
<li> <li>
<t>terminate the PCEP session</t> <t>terminate the PCEP session.</t>
</li> </li>
</ul> </ul>
<t>If one or both speakers (PCE and PCC) have not indicated the <t>If one or both speakers (PCE and PCC) have not indicated the
support for Native-IP, the PCEP extensions for the Native-IP MUST NOT support for Native IP, the PCEP extensions for the Native IP <bcp14>MUST
be used. If a Native-IP operation is attempted when both speakers have NOT</bcp14>
not agreed on the OPEN messages, the receiver of the message MUST:</t> be used. If a Native IP operation is attempted when both speakers have
not agreed on the OPEN messages, the receiver of the message <bcp14>MUST
</bcp14>:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>send a PCErr message with Error-Type=19 (Invalid Operation) and <t>send a PCErr message with Error-Type=19 (Invalid Operation) and
Error-value=TBD1 (Attempted Native-IP operations when the Error-value=29 (Attempted Native IP operations when the
capability was not advertised) and</t> capability was not advertised) and</t>
</li> </li>
<li> <li>
<t>terminate the PCEP session.</t> <t>terminate the PCEP session.</t>
</li> </li>
</ul> </ul>
</section> </section>
</section> </section>
<section toc="default" numbered="true"> <section toc="default" numbered="true">
<name>PCEP Messages</name> <name>PCEP Messages</name>
<t>PCECC Native IP TE solution uses the existing PCE Label Switched Path
(LSP) Initiate Request message (PCInitiate) <xref target="RFC8281" format= <t>The PCECC Native IP TE solution uses the existing PCE Label Switched Pa
"default"/>, th
and PCE Report message (PCRpt) <xref target="RFC8231" format="default"/> t (LSP) Initiate Request message (PCInitiate) <xref target="RFC8281" format=
o accomplish "default"/>
the multiple BGP sessions establishment, E2E Native-IP TE path and PCE Report message (PCRpt) <xref target="RFC8231" format="default"/> t
deployment, and route prefixes advertisement among different BGP o establish
sessions. A new PST for Native-IP is used to indicate the path setup multiple BGP sessions, deploy the E2E Native IP TE path,
and advertise route prefixes among different BGP
sessions. A new PST for Native IP is used to indicate the path setup
based on TE in Native IP networks.</t> based on TE in Native IP networks.</t>
<t>The extended PCInitiate message described in <xref target="RFC9050" for mat="default"/> <t>The extended PCInitiate message described in <xref target="RFC9050" for mat="default"/>
is used to download or remove the central controller's instructions is used to download or remove the Central Controller Instructions
(CCIs). <xref target="RFC9050" format="default"/> specifies an object call (CCI). <xref target="RFC9050" format="default"/> specifies an object calle
ed CCI for the d CCI for the
encoding of the central controller's instructions. This document encoding of the central controller's instructions. This document
specifies a new CCI Object-Type for Native IP. The PCEP messages are specifies a new CCI Object-Type for Native IP. The PCEP messages are
extended in this document to handle the PCECC operations for Native IP. extended in this document to handle the PCECC operations for Native IP.
Three new PCEP Objects (BGP Peer Info (BPI) Object, Explicit Peer Route Three new PCEP objects (BGP Peer Info (BPI), Explicit Peer Route
(EPR) Object, and Peer Prefix Advertisement (PPA) Object) are defined in (EPR), and Peer Prefix Advertisement (PPA)) are defined in
this document. Refer to <xref target="Obj-Def-Sec" format="default"/> for detailed object this document. Refer to <xref target="Obj-Def-Sec" format="default"/> for detailed object
definitions. All PCEP procedures specified in <xref target="RFC9050" forma t="default"/> definitions. All PCEP procedures specified in <xref target="RFC9050" forma t="default"/>
continue to apply unless specified otherwise.</t> continue to apply unless specified otherwise.</t>
<section anchor="SEC_PCInitiate" toc="default" numbered="true"> <section anchor="SEC_PCInitiate" toc="default" numbered="true">
<name>The PCInitiate Message</name> <name>The PCInitiate Message</name>
<t>The PCInitiate Message defined in <xref target="RFC8281" format="defa ult"/> and <t>The PCInitiate message defined in <xref target="RFC8281" format="defa ult"/> and
extended in <xref target="RFC9050" format="default"/> is further extende d to support extended in <xref target="RFC9050" format="default"/> is further extende d to support
Native-IP CCI.</t> Native IP CCI.</t>
<t>The format of the extended PCInitiate message is as follows: <t>The format of the extended PCInitiate message is as follows:
</t> </t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode name="" type="abnf"><![CDATA[
<PCInitiate Message> ::= <Common Header> <PCInitiate Message> ::= <Common Header>
<PCE-initiated-lsp-list> <PCE-initiated-lsp-list>
Where: ]]></sourcecode>
<Common Header> is defined in [RFC5440]
<t>Where:</t>
<sourcecode name="" type="abnf"><![CDATA[
<Common Header> is defined in RFC 5440
<PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request> <PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>
[<PCE-initiated-lsp-list>] [<PCE-initiated-lsp-list>]
<PCE-initiated-lsp-request> ::= <PCE-initiated-lsp-request> ::=
(<PCE-initiated-lsp-instantiation>| (<PCE-initiated-lsp-instantiation>|
<PCE-initiated-lsp-deletion>| <PCE-initiated-lsp-deletion>|
<PCE-initiated-lsp-central-control>) <PCE-initiated-lsp-central-control>)
<PCE-initiated-lsp-central-control> ::= <SRP> <PCE-initiated-lsp-central-control> ::= <SRP>
<LSP> <LSP>
<cci-list> <cci-list>
<cci-list> ::= <CCI> <cci-list> ::= <CCI>
[<BPI>|<EPR>|<PPA>] [<BPI>|<EPR>|<PPA>]
[<cci-list>] [<cci-list>]
]]></artwork> ]]></sourcecode>
<t>Where: </t> <t>Where:</t>
<ul empty="true" spacing="normal"> <ul spacing="normal">
<li> <li>
<t>&lt;PCE-initiated-lsp-instantiation&gt; and <t>&lt;PCE-initiated-lsp-instantiation&gt; and
&lt;PCE-initiated-lsp-deletion&gt; are as per [RFC8281].</t> &lt;PCE-initiated-lsp-deletion&gt; are as per <xref target="RFC8281" />.</t>
</li> </li>
<li> <li>
<t>The LSP and SRP objects are defined in [RFC8231].</t> <t>The LSP and SRP objects are defined in <xref target="RFC8231"/>.< /t>
</li> </li>
</ul> </ul>
<t>When the PCInitiate message is used for Native IP instructions, <t>When the PCInitiate message is used for Native IP instructions,
i.e. When the CCI Object-Type is 2, the SRP, LSP and CCI objects MUST i.e., when the CCI Object-Type is 2, the SRP, LSP, and CCI objects <bcp1
be present. Error handling for missing SRP, LSP or CCI objects MUST be 4>MUST</bcp14>
be present. Error handling for missing SRP, LSP, or CCI objects <bcp14>M
UST</bcp14> be
performed as specified in <xref target="RFC9050" format="default"/>. Add itionally, performed as specified in <xref target="RFC9050" format="default"/>. Add itionally,
exactly one object among the BPI, EPR, or PPA objects MUST be present. exactly one object among the BPI, EPR, or PPA objects <bcp14>MUST</bcp14
The PLSP-ID and Symbolic Path Name TLVs are set as per the existing > be present.
The PCEP-specific LSP
identifier (PLSP-ID) and Symbolic Path Name TLVs are set as per the existing
rules in <xref target="RFC8231" format="default"/>, <xref target="RFC828 1" format="default"/>, and <xref target="RFC9050" format="default"/>. The Symbol ic Path Name is used by the PCE/PCC to rules in <xref target="RFC8231" format="default"/>, <xref target="RFC828 1" format="default"/>, and <xref target="RFC9050" format="default"/>. The Symbol ic Path Name is used by the PCE/PCC to
uniquely identify the E2E native IP TE path. The related Native-IP uniquely identify the E2E Native IP TE path. The related Native IP
instructions with BPI, EPR or PPA objects are identified by the same instructions with BPI, EPR, or PPA objects are identified by the same
Symbolic Path Name.</t> Symbolic Path Name.</t>
<t>If none of the BPI, EPR or PPA objects are present, the receiving <t>If none of the BPI, EPR, or PPA objects are present, the receiving
PCC MUST send a PCErr message with Error-type=6 (Mandatory Object PCC <bcp14>MUST</bcp14> send a PCErr message with Error-Type=6 (Mandator
missing) and Error-value=19 (Native IP object missing). If there is y Object
more than one instance of BPI, EPR or PPA object present, the missing) and Error-value=19 (Native IP object missing). If there
receiving PCC MUST send a PCErr message with Error-type=19 (Invalid is
Operation) and Error-value=22 (Only one BPI, EPR or PPA object can be more than one BPI, EPR, or PPA object present, the
receiving PCC <bcp14>MUST</bcp14> send a PCErr message with Error-Type=1
9 (Invalid
Operation) and Error-value=22 (Only one BPI, EPR, or PPA object can be
included in this message).</t> included in this message).</t>
<t>When the PCInitiate message is not used for Native IP instructions, <t>When the PCInitiate message is not used for Native IP instructions,
i.e. When CCI Object-Type is not equal to 2, the BPI, EPR and PPA i.e., when the CCI Object-Type is not equal to 2, the BPI, EPR, and PPA
objects SHOULD NOT be present. If present, they MUST be ignored by the objects <bcp14>SHOULD NOT</bcp14> be present. If present, they <bcp14>MU
ST</bcp14> be ignored by the
receiver.</t> receiver.</t>
<t>To clean up the existing Native IP instructions, the SRP object <t>To clean up the existing Native IP instructions, the SRP object
MUST set the R (remove) bit.</t> <bcp14>MUST</bcp14> set the R (remove) bit.</t>
</section> </section>
<section anchor="SEC_PCRpt" toc="default" numbered="true"> <section anchor="SEC_PCRpt" toc="default" numbered="true">
<name>The PCRpt Message</name> <name>The PCRpt Message</name>
<t>The PCRpt message is used to acknowledge the Native-IP instructions <t>The PCRpt message is used to acknowledge the Native IP instructions
received from the central controller (PCE) as well as during the State received from the central controller (PCE) as well as during the State
Synchronization phase.</t> Synchronization phase.</t>
<t>The format of the PCRpt message is as follows: </t> <t>The format of the PCRpt message is as follows: </t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<sourcecode name="" type="abnf"><![CDATA[
<PCRpt Message> ::= <Common Header> <PCRpt Message> ::= <Common Header>
<state-report-list> <state-report-list>
Where: ]]></sourcecode>
<t>Where:</t>
<sourcecode name="" type="abnf"><![CDATA[
<state-report-list> ::= <state-report>[<state-report-list>] <state-report-list> ::= <state-report>[<state-report-list>]
<state-report> ::= (<lsp-state-report>| <state-report> ::= (<lsp-state-report>|
<central-control-report>) <central-control-report>)
<lsp-state-report> ::= [<SRP>] <lsp-state-report> ::= [<SRP>]
<LSP> <LSP>
<path> <path>
<central-control-report> ::= [<SRP>] <central-control-report> ::= [<SRP>]
<LSP> <LSP>
<cci-list> <cci-list>
<cci-list> ::= <CCI> <cci-list> ::= <CCI>
[<BPI>|<EPR>|<PPA>] [<BPI>|<EPR>|<PPA>]
[<cci-list>] [<cci-list>]
]]></artwork> ]]></sourcecode>
<ul empty="true" spacing="normal">
<li> <t>Where:</t>
<t>Where: &lt;path&gt; is as per [RFC8231] and the LSP and SRP
objects are also defined in [RFC8231].</t> <ul spacing="normal">
</li> <li>&lt;path&gt; is as per <xref target="RFC8231"/>.</li>
</ul> <li>The LSP and SRP objects are also defined in <xref target="RFC82
<t>The error handling for missing CCI objects is as per <xref target="RF 31"/>.</li>
C9050" format="default"/>. Furthermore, one, and only one, object among BPI, </ul>
EPR or PPA object MUST be present.</t>
<t>If none of the BPI, EPR or PPA objects are present, the receiving <t>The error handling for missing CCI objects is as per <xref target="RF
PCE MUST send a PCErr message with Error-type=6 (Mandatory Object C9050" format="default"/>. Furthermore, one and only one BPI,
missing) and Error-value=19 (Native IP object missing). If there are EPR, or PPA object <bcp14>MUST</bcp14> be present.</t>
more than one instance of BPI, EPR or PPA objects present, the <t>If none of the BPI, EPR, or PPA objects are present, the receiving
receiving PCE MUST send a PCErr message with Error-type=19 (Invalid PCE <bcp14>MUST</bcp14> send a PCErr message with Error-Type=6 (Mandator
Operation) and Error-value=22 (Only one BPI, EPR or PPA object can be y Object
missing) and Error-value=19 (Native IP object missing). If there is
more than one BPI, EPR, or PPA object present, the
receiving PCE <bcp14>MUST</bcp14> send a PCErr message with Error-Type=1
9 (Invalid
Operation) and Error-value=22 (Only one BPI, EPR, or PPA object can be
included in this message).</t> included in this message).</t>
<t>When the PCInitiate message is not used for Native IP instructions, <t>When the PCInitiate message is not used for Native IP instructions,
i.e. When CCI Object-Type is not equal to 2, the BPI, EPR and PPA i.e., when the CCI Object-Type is not equal to 2, the BPI, EPR, and PPA
objects SHOULD NOT be present. If present, they MUST be ignored by the objects <bcp14>SHOULD NOT</bcp14> be present. If present, they <bcp14>MU
ST</bcp14> be ignored by the
receiver.</t> receiver.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>PCECC Native IP TE Procedures</name> <name>PCECC Native IP TE Procedures</name>
<t>The detailed procedures for the TE in the native IP environment are <t>The detailed procedures for the TE in the Native IP environment are
described in the following sections.</t> described in the following sections.</t>
<section anchor="BGPSess" numbered="true" toc="default"> <section anchor="BGPSess" numbered="true" toc="default">
<name>BGP Session Establishment Procedures</name> <name>BGP Session Establishment Procedures</name>
<t>The PCInitiate and PCRpt message pair is used to exchange the <t>The PCInitiate and PCRpt message pair is used to exchange the
configuration parameters for a BGP peer session. This pair of PCEP configuration parameters for a BGP peer session. This pair of PCEP
messages are exchanged between a PCE and each BGP peer (acting as PCC) messages are exchanged between a PCE and each BGP peer (acting as the PC C),
which needs to establish a BGP session. After the BGP peer session has which needs to establish a BGP session. After the BGP peer session has
been initiated via this pair of PCEP messages, the BGP session been initiated via this pair of PCEP messages, the BGP session
establishes and operates in a normal fashion. The BGP peers can be establishes and operates in a normal fashion. The BGP peers can be
used for External BGP (EBGP) peers or Internal BGP (IBGP) peers. For used for External BGP (EBGP) peers or Internal BGP (IBGP) peers. For
IBGP connection topologies, the Route Reflector (RR) is required.</t> IBGP connection topologies, the Route Reflector (RR) is required.</t>
<t>The PCInitiate message is sent to the BGP router and/or RR (which <t>The PCInitiate message is sent to the BGP router and/or RR (which
are acting as PCC).</t> are acting as the PCC).</t>
<t>The RR topology for a single Autonomous System (AS) is shown in <t>The RR topology for a single Autonomous System (AS) is shown in
Figure 1. The BGP routers R1, R3, and R7 are within a single AS. R1 <xref target="fig-1"/>. The BGP routers R1, R3, and R7 are within a sing
and R7 are BGP RR clients, and R3 is a RR. The PCInitiate message is le AS. R1
sent to the BGP routers R1, R3 and R7 that need to establish a BGP and R7 are BGP RR clients, and R3 is an RR. The PCInitiate message is
sent to the BGP routers R1, R3, and R7, which need to establish a BGP
session.</t> session.</t>
<t>PCInitiate message creates an auto-configuration function for these <t>PCInitiate message creates an autoconfiguration function for these
BGP peers by providing the indicated Peer AS and the Local/Peer IP BGP peers by providing the indicated Peer AS and the Local/Peer IP
Address.</t> Address.</t>
<t>When the PCC receives the BPI and CCI object (with the R bit set to <t>When the PCC receives the BPI and CCI objects (with the R bit set to
0 in the SRP object) in the PCInitiate message, the PCC SHOULD try to 0 in the SRP object) in the PCInitiate message, the PCC <bcp14>SHOULD</b
establish the BGP session with the indicated Peer as per AS and cp14> try to
Local/Peer IP address.</t> establish the BGP session with the indicated Peer as per the AS and
<t>During the establishment procedure, the PCC MUST report to the PCE Local/Peer IP Address.</t>
the status of the BGP session via the PCRpt message, with the status <t>During the establishment procedure, the PCC <bcp14>MUST</bcp14> repor
t
the status of the BGP session to the PCE via the PCRpt message, with the
status
field in the BPI object set to the appropriate value and the field in the BPI object set to the appropriate value and the
corresponding SRP and CCI objects included.</t> corresponding SRP and CCI objects included.</t>
<t>When the PCC receives this message with the R bit set to 1 in the <t>When the PCC receives this message with the R bit set to 1 in the
SRP object in the PCInitiate message, the PCC MUST clear the BGP SRP object in the PCInitiate message, the PCC <bcp14>MUST</bcp14> clear the BGP
configuration and tear down the BGP session that is indicated by the configuration and tear down the BGP session that is indicated by the
BPI object.</t> BPI object.</t>
<t>When the PCC clears successfully the specified BGP session <t>When the PCC successfully clears the specified BGP session
configuration, it MUST report the result via the PCRpt message, with configuration, it <bcp14>MUST</bcp14> report the result via the PCRpt me
the BPI object included, and the corresponding SRP and CCI ssage, with
objects.</t> the BPI object and the corresponding SRP and CCI
<artwork name="" type="" align="left" alt=""><![CDATA[ objects included.</t>
+------------------+
+-----------> PCE <----------+ <figure anchor="fig-1">
| +--------^---------+ | <name>BGP Session Establishment Procedures (R3 acts as the RR)</name>
| | | <artwork name="" type="" align="center" alt=""><![CDATA[
| PCInitiate/PCRpt | +------------------+
| | | +-----------> PCE <----------+
| +----v--+ | | +--------^---------+ |
+---------------+ R3(RR)+-----------------+ | | |
| +-------+ | | PCInitiate/PCRpt |
PCInitiate/PCRpt PCInitiate/PCRpt | | |
| | | +----v--+ |
+v-+ +--+ +--+ +-v+ +---------------+ R3(RR)+-----------------+
|R1+----------+R5+----------+R6+---------+R7| | +-------+ |
++-+ +-++ +--+ +-++ PCInitiate/PCRpt PCInitiate/PCRpt
| | | | |
| +--+ +--+ | +v-+ +--+ +--+ +-v+
+------------+R2+----------+R4+-----------+ |R1+----------+R5+----------+R6+---------+R7|
+--+ +--+ ++-+ +-++ +--+ +-++
Figure 1: BGP Session Establishment Procedures(R3 act as RR) | | |
| +--+ +--+ |
+------------+R2+----------+R4+-----------+
+--+ +--+
]]></artwork> ]]></artwork>
<t/> </figure>
<t>The message peers, message type, message key parameters and
procedures in the above figures are shown below:</t> <t>The message peers, message types, message key parameters, and
<artwork name="" type="" align="left" alt=""><![CDATA[ procedures in the above figure are shown below:</t>
<figure anchor="fig-2">
<name>Message Information and Procedures</name>
<artwork name="" type="" align="center" alt=""><![CDATA[
+-------+ +-------+ +-------+ +-------+
|PCC | | PCE | |PCC | | PCE |
|R1 | +-------+ |R1 | +-------+
+------| | | +------| | |
| PCC +-------+ | | PCC +-------+ |
| R3 | | (For R1/R3 BGP Session on R1) | | R3 | | (For R1/R3 BGP Session on R1) |
+------| | |<-PCInitiate,CC-ID=X,Symbolic Path Name=Class A-| +------| | |<-PCInitiate,CC-ID=X,Symbolic Path Name=Class A-|
| | | |BPI Object(Peer AS, Local_IP=R1_A, Peer_IP=R3_A)| | | | |BPI Object(Peer AS, Local_IP=R1_A, Peer_IP=R3_A)|
|PCC +--------+ | | |PCC +--------+ | |
|R7 | | |----PCRpt,CC-ID=X(Symbolic Path Name=Class A)-->| |R7 | | |----PCRpt,CC-ID=X(Symbolic Path Name=Class A)-->|
skipping to change at line 475 skipping to change at line 460
| |<--PCInitiate,CC-ID=Y2,Symbolic Path Name=Class A-----| | |<--PCInitiate,CC-ID=Y2,Symbolic Path Name=Class A-----|
| | BPI Object(Peer AS, Local_IP=R3_A, Peer_IP=R7_A) | | | BPI Object(Peer AS, Local_IP=R3_A, Peer_IP=R7_A) |
| |----PCRpt,CC-ID=Y2,Symbolic Path Name=Class A-------->| | |----PCRpt,CC-ID=Y2,Symbolic Path Name=Class A-------->|
| | BPI Object(Peer AS, Local_IP=R3_A, Peer_IP=R7_A) | | | BPI Object(Peer AS, Local_IP=R3_A, Peer_IP=R7_A) |
| | | |
| (For R3/R7 BGP Session on R7) | | (For R3/R7 BGP Session on R7) |
|<--PCInitiate,CC-ID=Z,Symbolic Path Name=Class A--------------| |<--PCInitiate,CC-ID=Z,Symbolic Path Name=Class A--------------|
| BPI Object(Peer AS, Local_IP=R7_A, Peer_IP=R3_A) | | BPI Object(Peer AS, Local_IP=R7_A, Peer_IP=R3_A) |
|---PCRpt,CC-ID=Z,Symbolic Path Name=Class A------------------>| |---PCRpt,CC-ID=Z,Symbolic Path Name=Class A------------------>|
| BPI Object(Peer AS, Local_IP=R7_A, Peer_IP=R3_A) | | BPI Object(Peer AS, Local_IP=R7_A, Peer_IP=R3_A) |
Figure 2: Message Information and Procedures
]]></artwork> ]]></artwork>
<t>The Local/Peer IP address MUST be dedicated to the usage of the </figure>
native IP TE solution, and MUST NOT be used by other BGP sessions that <t>The Local/Peer IP Address <bcp14>MUST</bcp14> be dedicated to the usa
ge of the
Native IP TE solution and <bcp14>MUST NOT</bcp14> be used by other BGP s
essions that
are established manually or in other ways. If the Local IP Address or are established manually or in other ways. If the Local IP Address or
Peer IP Address within the BPI object is used in other existing BGP Peer IP Address within the BPI object is used in other existing BGP
sessions, the PCC MUST report such an error situation via a PCErr sessions, the PCC <bcp14>MUST</bcp14> report such an error situation via a PCErr
message with:</t> message with:</t>
<ul empty="true" spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Error-type=33 (Native IP TE failure) and Error-value=1 (Local <t>Error-Type=33 (Native IP TE failure) and Error-value=1 (Local
IP is in use), or</t> IP is in use) or</t>
</li> </li>
<li> <li>
<t>Error-type=33 (Native IP TE failure )and Error-value=2 (Remote <t>Error-Type=33 (Native IP TE failure) and Error-value=2 (Remote
IP is in use).</t> IP is in use).</t>
</li> </li>
<li> </ul>
<t>The detailed Error-Types and Error-Values are defined in <xref ta <t>The detailed Error-Types and Error-values are defined in <xref target
rget="NewErrorTypeAndValue" format="default"/></t> ="NewErrorTypeAndValue" format="default"/>.</t>
</li>
</ul> <t>If the established BGP session is broken, the PCC <bcp14>MUST</bcp14>
<t>If the established BGP session is broken, the PCC MUST report such report such
information via PCRpt message with the status field set to "BGP information via a PCRpt message with the status field set to "BGP
session down" in the associated BPI Object. The error code field session down" in the associated BPI object. The error code field
within the BPI object SHOULD indicate the reason that leads to the BGP within the BPI object <bcp14>SHOULD</bcp14> indicate the reason that lea
ds to the BGP
session being down. In the future, when the BGP session is up again, session being down. In the future, when the BGP session is up again,
the PCC MUST report that as well via the PCRpt message with the status the PCC <bcp14>MUST</bcp14> report that as well via the PCRpt message wi th the status
field set to "BGP Session Established".</t> field set to "BGP Session Established".</t>
</section> </section>
<section anchor="BGPEx" numbered="true" toc="default"> <section anchor="BGPEx" numbered="true" toc="default">
<name>Explicit Route Establishment Procedures</name> <name>Explicit Route Establishment Procedures</name>
<t>The explicit route establishment procedures can be used by PCE to <t>The explicit route establishment procedures can be used by a PCE to
install a route on the PCC, using the PCInitiate and PCRpt message install a route on the PCC, using the PCInitiate and PCRpt message
pair. Such explicit routes operate the same as static routes installed pair. Such explicit routes operate the same as static routes installed
by network management protocols (Network Configuration Protocol by network management protocols (e.g., Network Configuration Protocol
(NETCONF)/YANG). The procedures of such explicit route addition and (NETCONF) / YANG). The procedures of such explicit route addition and
removal MUST be controlled by the PCE in a specific order so that the removal <bcp14>MUST</bcp14> be controlled by the PCE in a specific order
so that the
pathways are established without loops.</t> pathways are established without loops.</t>
<t>For the purpose of explicit route addition, the PCInitiate message <t>For the purpose of explicit route addition, the PCInitiate message
ought to be sent to every router on the explicit path. In the example, ought to be sent to every router on the explicit path. In the example,
for the explicit route from R1 to R7, the PCInitiate message is sent for the explicit route from R1 to R7, the PCInitiate message is sent
to R1, R2 and R4, as shown in Figure 3. For the explicit route from R7 to R1, R2, and R4, as shown in <xref target="fig-3"/>. For the explicit
to R1, the PCInitiate message is sent to R7, R4 and R2, as shown in route from R7
Figure 5.</t> to R1, the PCInitiate message is sent to R7, R4, and R2, as shown in
<xref target="fig-5"/>.</t>
<t>When the PCC receives the EPR and the CCI object (with the R bit <t>When the PCC receives the EPR and the CCI object (with the R bit
set to 0 in the SRP object) in the PCInitiate message, the PCC SHOULD set to 0 in the SRP object) in the PCInitiate message, the PCC <bcp14>SH OULD</bcp14>
install the explicit route to the peer in the RIB/FIB.</t> install the explicit route to the peer in the RIB/FIB.</t>
<t>When the PCC installs successfully the explicit route to the peer, <t>When the PCC successfully installs the explicit route to the peer,
it MUST report the result via the PCRpt messages, with the EPR object it <bcp14>MUST</bcp14> report the result via the PCRpt message, with the
EPR object
and the corresponding SRP and CCI objects included.</t> and the corresponding SRP and CCI objects included.</t>
<t>When the PCC receives the EPR and the CCI object with the R bit set <t>When the PCC receives the EPR and the CCI object with the R bit set
to 1 in the SRP object in the PCInitiate message, the PCC MUST remove to 1 in the SRP object in the PCInitiate message, the PCC <bcp14>MUST</b cp14> remove
the explicit route to the peer that is indicated by the EPR the explicit route to the peer that is indicated by the EPR
object.</t> object.</t>
<t>When the PCC has removed the explicit route that is indicated by <t>When the PCC has removed the explicit route that is indicated by
this object, it MUST report the result via the PCRpt message, with the this object, it <bcp14>MUST</bcp14> report the result via the PCRpt mess
EPR object included, and the corresponding SRP and CCI object.</t> age, with the
<artwork name="" type="" align="left" alt=""><![CDATA[ EPR object and the corresponding SRP and CCI objects included.</t>
+------------------+
+----------> PCE + <figure anchor="fig-3">
| +----^-----------^-+ <name>Explicit Route Establish Procedures (from R1 to R7)</name>
| | | <artwork name="" type="" align="center" alt=""><![CDATA[
| | | +------------------+
| | +------+ | +----------> PCE +
+---------------|-+R3(RR)+--|-------------+ | +----^-----------^-+
PCInitiate/PCRpt | +------+ | | | | |
| | | | | | |
+v-+ +--+ | | +--+ +--+ | | +------+ |
|R1+------+R5+---+-----------|---+R6+----+R7| +---------------|-+R3(RR)+--|-------------+
++-+ +--+ | | +--+ +-++ PCInitiate/PCRpt | +------+ | |
| PCInitiate/PCRpt PCInitiate/PCRpt | | | | |
| | | | +v-+ +--+ | | +--+ +--+
| +--v--+ +--v-+ | |R1+------+R5+---+-----------|---+R6+----+R7|
+------------+- R2 +-----+ R4 +-----------+ ++-+ +--+ | | +--+ +-++
+--+--+ +--+-+ | PCInitiate/PCRpt PCInitiate/PCRpt |
Figure 3: Explicit Route Establish Procedures(From R1 to R7) | | | |
| +--v--+ +--v-+ |
+------------+- R2 +-----+ R4 +-----------+
+--+--+ +--+-+
]]></artwork> ]]></artwork>
<t>The message peers, message type, message key parameters and </figure>
procedures in the above figures are shown below:</t> <t>The message peers, message types, message key parameters, and
<artwork name="" type="" align="left" alt=""><![CDATA[ procedures in the above figure are shown below:</t>
<figure anchor="fig-4">
<name>Message Information and Procedures</name>
<artwork name="" type="" align="center" alt=""><![CDATA[
+-------+ +-------+ +-------+ +-------+
|PCC | | PCE | |PCC | | PCE |
|R4 | +-------+ |R4 | +-------+
+------| | | +------| | |
| PCC +-------+ | | PCC +-------+ |
| R2 | | (EPR route on R4) | | R2 | | (EPR route on R4) |
+------| | |<-PCInitiate,CC-ID=Z,Symbolic Path Name=Class A| +------| | |<-PCInitiate,CC-ID=Z,Symbolic Path Name=Class A|
| | | | EPR Object(Peer Address=R7_A, Next Hop=R7_A)| | | | | EPR Object(Peer Address=R7_A, Next Hop=R7_A)|
|PCC +--------+ | | |PCC +--------+ | |
|R1 | | |----PCRpt,CC-ID=Z,Symbolic Path Name=Class A-->| |R1 | | |----PCRpt,CC-ID=Z,Symbolic Path Name=Class A-->|
skipping to change at line 579 skipping to change at line 569
| | EPR Object(Peer Address=R7_A, Next Hop=R4_A) | | | EPR Object(Peer Address=R7_A, Next Hop=R4_A) |
| |----PCRpt,CC-ID=Y,Symbolic Path Name=Class A-------->| | |----PCRpt,CC-ID=Y,Symbolic Path Name=Class A-------->|
| | EPR Object(Peer Address=R7_A, Next Hop=R4_A) | | | EPR Object(Peer Address=R7_A, Next Hop=R4_A) |
| | | | | |
| | | |
| (EPR route on R1) | | (EPR route on R1) |
|<--PCInitiate,CC-ID=X,Symbolic Path Name=Class A-------------| |<--PCInitiate,CC-ID=X,Symbolic Path Name=Class A-------------|
| EPR Object(Peer Address=R7_A, Next Hop=R2_A) | | EPR Object(Peer Address=R7_A, Next Hop=R2_A) |
|---PCRpt,CC-ID=X1(Symbolic Path Name=Class A)--------------->| |---PCRpt,CC-ID=X1(Symbolic Path Name=Class A)--------------->|
| EPR Object(Peer Address=R7_A, Next Hop=R2_A) | | EPR Object(Peer Address=R7_A, Next Hop=R2_A) |
Figure 4: Message Information and Procedures
]]></artwork> ]]></artwork>
<artwork name="" type="" align="left" alt=""><![CDATA[ </figure>
+------------------+
+ PCE <-----------+ <figure anchor="fig-5">
+----^-----------^-+ | <name>Explicit Route Establish Procedures (from R7 to R1)</name>
| | | <artwork name="" type="" align="center" alt=""><![CDATA[
| | | +------------------+
| +------+ | | + PCE <-----------+
+-----------------+R3(RR)+--|-------------+ +----^-----------^-+ |
| | +------+ | PCInitiate/PCRpt | | |
| | | | | | |
+--+ +--+ | | +--+ +-v+ | +------+ | |
|R1+------+R5+---+-----------|---+R6+----+R7| +-----------------+R3(RR)+--|-------------+
++-+ +--+ | | +--+ +-++ | | +------+ | PCInitiate/PCRpt
| PCInitiate/PCRpt PCInitiate/PCRpt | | | | |
| | | | +--+ +--+ | | +--+ +-v+
| +--v--+ +--v-+ | |R1+------+R5+---+-----------|---+R6+----+R7|
+------------+- R2 +-----+ R4 +-----------+ | PCInitiate/PCRpt PCInitiate/PCRpt |
+--+--+ +--+-+ | | | |
Figure 5: Explicit Route Establish Procedures(From R7 to R1) | +--v--+ +--v-+ |
+------------+- R2 +-----+ R4 +-----------+
+--+--+ +--+-+
]]></artwork> ]]></artwork>
<t>The message peers, message type, message key parameters and </figure>
procedures in the above figures are shown below:</t> <t>The message peers, message types, message key parameters, and
<artwork name="" type="" align="left" alt=""><![CDATA[ procedures in the above figure are shown below:</t>
<figure anchor="fig-6">
<name>Explicit Route Establish Procedures (from R7 to R1)</name>
<artwork name="" type="" align="center" alt=""><![CDATA[
+-------+ +-------+ +-------+ +-------+
|PCC | | PCE | |PCC | | PCE |
|R2 | +-------+ |R2 | +-------+
+------| | | +------| | |
| PCC +-------+ | | PCC +-------+ |
| R4 | | (EPR route on R2) | | R4 | | (EPR route on R2) |
+------| | |<-PCInitiate,CC-ID=X,Symbolic Path Name=Class A| +------| | |<-PCInitiate,CC-ID=X,Symbolic Path Name=Class A|
| | | | EPR Object(Peer Address=R1_A, Next Hop=R1_A) | | | | | EPR Object(Peer Address=R1_A, Next Hop=R1_A) |
|PCC +--------+ | | |PCC +--------+ | |
|R7 | | |----PCRpt,CC-ID=X,Symbolic Path Name=Class A-->| |R7 | | |----PCRpt,CC-ID=X,Symbolic Path Name=Class A-->|
skipping to change at line 629 skipping to change at line 624
| | EPR Object(Peer Address=R1_A, Next Hop=R2_A) | | | EPR Object(Peer Address=R1_A, Next Hop=R2_A) |
| |----PCRpt,CC-ID=Y,Symbolic Path Name=Class A-------->| | |----PCRpt,CC-ID=Y,Symbolic Path Name=Class A-------->|
| | EPR Object(Peer Address=R1_A, Next Hop=R2_A) | | | EPR Object(Peer Address=R1_A, Next Hop=R2_A) |
| | | | | |
| | | |
| (EPR route on R7) | | (EPR route on R7) |
|<--PCInitiate,CC-ID=Z,Symbolic Path Name=Class A-------------| |<--PCInitiate,CC-ID=Z,Symbolic Path Name=Class A-------------|
| EPR Object(Peer Address=R1_A, Next Hop=R4_A) | | EPR Object(Peer Address=R1_A, Next Hop=R4_A) |
|---PCRpt,CC-ID=Z,Symbolic Path Name=Class A----------------->| |---PCRpt,CC-ID=Z,Symbolic Path Name=Class A----------------->|
| EPR Object(Peer Address=R1_A, Next Hop=R4_A) | | EPR Object(Peer Address=R1_A, Next Hop=R4_A) |
Figure 6: Explicit Route Establish Procedures(From R7 to R1)
]]></artwork> ]]></artwork>
</figure>
<t>To avoid the transient loop while deploying the explicit peer <t>To avoid the transient loop while deploying the explicit peer
route, the EPR object MUST be sent to the PCCs in the reverse order of route, the EPR object <bcp14>MUST</bcp14> be sent to the PCCs in the rev
the E2E path. To remove the explicit peer route, the EPR object MUST erse order of
the E2E path. To remove the explicit peer route, the EPR object <bcp14>M
UST</bcp14>
be sent to the PCCs in the same order as the E2E path.</t> be sent to the PCCs in the same order as the E2E path.</t>
<t>To accomplish ECMP effects, the PCE can send multiple EPR/CCI <t>To accomplish ECMP effects, the PCE can send multiple EPR/CCI
objects to the same node, with the same route priority and peer objects to the same node, with the same route priority and peer
address value but a different next-hop address.</t> address value but a different next-hop address.</t>
<t>The PCC MUST verify that the next hop address is reachable. In case <t>The PCC <bcp14>MUST</bcp14> verify that the next-hop address is reach
of failure, the PCC MUST send the corresponding error via PCErr able. In case
message, with the error information: Error-type=33 (Native IP TE of failure, the PCC <bcp14>MUST</bcp14> send the corresponding error via
failure), Error-value=3 (Explicit Peer Route Error).</t> a PCErr
message, with the error information: Error-Type=33 (Native IP TE
failure) and Error-value=3 (Explicit Peer Route Error).</t>
<t>When the peer info is not the same as the peer info that is <t>When the peer info is not the same as the peer info that is
indicated in the BPI object in PCC for the same path that is indicated in the BPI object in the PCC for the same path that is
identified by Symbolic Path Name TLV, a PCErr message MUST be identified by Symbolic Path Name TLV, a PCErr message <bcp14>MUST</bcp14
reported, with the error information: Error-type=33 (Native IP TE > be
failure), Error-value=4, EPR/BPI Peer Info Mismatch. Note that the reported, with the error information Error-Type=33 (Native IP TE
failure) and Error-value=4 (EPR/BPI Peer Info mismatch). Note that the
same error can be used in case no BPI is received at the PCC.</t> same error can be used in case no BPI is received at the PCC.</t>
<t>If the PCE needs to update the path, it MUST first instruct the new <t>If the PCE needs to update the path, it <bcp14>MUST</bcp14> first ins
CCI with updated EPR corresponding to the new next hop to use and then truct the new
CCI with the updated EPR corresponding to the new next hop to use and th
en
instruct the removal of the older CCI.</t> instruct the removal of the older CCI.</t>
</section> </section>
<section anchor="BGPPrefix" numbered="true" toc="default"> <section anchor="BGPPrefix" numbered="true" toc="default">
<name>BGP Prefix Advertisement Procedures</name> <name>BGP Prefix Advertisement Procedures</name>
<t>The detailed procedures for BGP prefix advertisement are shown <t>The detailed procedures for BGP prefix advertisement are shown
below, using the PCInitiate and PCRpt message pair.</t> below, using the PCInitiate and PCRpt message pair.</t>
<t>The PCInitiate message SHOULD be sent to PCC that acts as a BGP <t>The PCInitiate message <bcp14>SHOULD</bcp14> be sent to the PCC that
peer edge router only. In the example, it is sent to R1 and R7 acts as a BGP
peer edge router only. In the example, it is sent to R1 and R7,
respectively.</t> respectively.</t>
<t>When the PCC receives the PPA and the CCI object (with the R bit <t>When the PCC receives the PPA and the CCI object (with the R bit
set to 0 in the SRP object) in the PCInitiate message, the PCC SHOULD set to 0 in the SRP object) in the PCInitiate message, the PCC <bcp14>SH OULD</bcp14>
send the prefixes indicated in this object to the identified BGP peer send the prefixes indicated in this object to the identified BGP peer
via the corresponding BGP session <xref target="RFC4271" format="default "/>.</t> via the corresponding BGP session <xref target="RFC4271" format="default "/>.</t>
<t>When the PCC has successfully sent the prefixes to the appointed <t>When the PCC has successfully sent the prefixes to the appointed
BGP peer, it MUST report the result via the PCRpt messages, with the BGP peer, it <bcp14>MUST</bcp14> report the result via the PCRpt message s, with the
PPA object and the corresponding SRP and CCI objects included.</t> PPA object and the corresponding SRP and CCI objects included.</t>
<t>When the PCC receives the PPA and the CCI object with the R bit set <t>When the PCC receives the PPA and the CCI object with the R bit set
to 1 in the SRP object in the PCInitiate message, the PCC MUST to 1 in the SRP object in the PCInitiate message, the PCC <bcp14>MUST</b
withdraw the prefixes advertisement to the peer indicated by this cp14>
withdraw the prefix advertisement to the peer indicated by this
object.</t> object.</t>
<t>When the PCC withdraws successfully the prefixes that are indicated <t>When the PCC successfully withdraws the prefixes that are indicated
by this object, it MUST report the result via the PCRpt message, with by this object, it <bcp14>MUST</bcp14> report the result via the PCRpt m
the PPA object included, and the corresponding SRP and CCI essage, with
objects.</t> the PPA object and the corresponding SRP and CCI
<artwork name="" type="" align="left" alt=""><![CDATA[ objects included.</t>
<figure anchor="fig-7">
<name>BGP Prefix Advertisement Procedures</name>
<artwork name="" type="" align="center" alt=""><![CDATA[
+------------------+ +------------------+
+----------> PCE <-----------+ +----------> PCE <-----------+
| +------------------+ | | +------------------+ |
| +--+ | | +--+ |
+------------------+R3+-------------------+ +------------------+R3+-------------------+
PCInitiate/PCRpt +--+ PCInitiate/PCRpt PCInitiate/PCRpt +--+ PCInitiate/PCRpt
| | | |
+v-+ +--+ +--+ +-v+ +v-+ +--+ +--+ +-v+
|R1+----------+R5+----------+R6+---------+R7| |R1+----------+R5+----------+R6+---------+R7|
++-+ +--+ +--+ +-++ ++-+ +--+ +--+ +-++
(BGP Router) (BGP Router) (BGP Router) (BGP Router)
| | | |
| | | |
| +--+ +--+ | | +--+ +--+ |
+------------+R2+----------+R4+-----------+ +------------+R2+----------+R4+-----------+
+--+ +--+ +--+ +--+
Figure 7: BGP Prefix Advertisement Procedures
]]></artwork> ]]></artwork>
<t>The message peers, message type, message key parameters and </figure>
procedures in the above figures are shown below:</t> <t>The message peers, message types, message key parameters, and
<artwork name="" type="" align="left" alt=""><![CDATA[ procedures in the above figure are shown below:</t>
+-------+ +-------+
|PCC | | PCE |
|R1 | +-------+
+------| | |
| PCC +-------+ |
| R7 | | (Instruct R1 to advertise Prefix 1_A to R7) |
| | |<-PCInitiate,CC-ID=X,Symbolic Path Name=Class A|
| | | PPA Object(Peer IP=R7_A, Prefix=1_A) |
+--------+ | |
| |----PCRpt,CC-ID=X,Symbolic Path Name=Class A-->|
| | PPA Object(Peer IP=R7_A, Prefix=1_A) |
| |
| (Instruct R7 to advertise Prefix 7_A to R1 ) |
|<--PCInitiate,CC-ID=Z,Symbolic Path Name=Class A-----|
| PPA Object(Peer IP=R1_A, Prefix=7_A) |
|----PCRpt,CC-ID=Z,Symbolic Path Name=Class A-------->|
| PPA Object(Peer IP=R1_A, Prefix=7_A) |
| |
Figure 8: Message Information and Procedures <figure anchor="fig-8">
<name>Message Information and Procedures</name>
<artwork name="" type="" align="center" alt=""><![CDATA[
+-------+ +-------+
|PCC | | PCE |
|R1 | +-------+
+------| | |
| PCC +-------+ |
| R7 | | (Instruct R1 to advertise Prefix 1_A to R7) |
| | |<-PCInitiate,CC-ID=X,Symbolic Path Name=Class A|
| | | PPA Object(Peer IP=R7_A, Prefix=1_A) |
+--------+ | |
| |----PCRpt,CC-ID=X,Symbolic Path Name=Class A-->|
| | PPA Object(Peer IP=R7_A, Prefix=1_A) |
| |
| (Instruct R7 to advertise Prefix 7_A to R1 ) |
|<--PCInitiate,CC-ID=Z,Symbolic Path Name=Class A-----|
| PPA Object(Peer IP=R1_A, Prefix=7_A) |
|----PCRpt,CC-ID=Z,Symbolic Path Name=Class A-------->|
| PPA Object(Peer IP=R1_A, Prefix=7_A) |
| |
]]></artwork> ]]></artwork>
<t>The AFI/SAFI for the corresponding BGP session SHOULD match the </figure>
Peer Prefix Advertisement Object-Type, AFI/SAFI SHOULD be 1/1 for the <t>The AFI/SAFI for the corresponding BGP session <bcp14>SHOULD</bcp14>
match the
Peer Prefix Advertisement Object-Type, i.e., AFI/SAFI <bcp14>SHOULD</bcp
14> be 1/1 for the
IPv4 prefix and 2/1 for the IPv6 prefix. In case of mismatch, an IPv4 prefix and 2/1 for the IPv6 prefix. In case of mismatch, an
error: Error-type=33 (Native IP TE failure), Error-value=5 (BPI/PPA error, i.e., Error-Type=33 (Native IP TE failure) and Error-value=5 (BPI
address family mismatch) MUST be reported via PCErr message.</t> /PPA
<t>When the peer info is not the same as the peer info that is Address Family mismatch), <bcp14>MUST</bcp14> be reported via the PCErr
indicated in the BPI object in PCC for the same path that is message.</t> <t>When the peer info is not the same as the peer info that
identified by Symbolic Path Name TLV, an error: Error-type=33 (Native is
IP TE failure), Error-value=6 (PPA/BPI peer info mismatch) MUST be indicated in the BPI object in the PCC for the same path that is
identified by Symbolic Path Name TLV, an error, i.e., Error-Type=33 (Nat
ive
IP TE failure) and Error-value=6 (PPA/BPI Peer Info mismatch), <bcp14>MU
ST</bcp14> be
reported via the PCErr message. Note that the same error can be used reported via the PCErr message. Note that the same error can be used
in case no BPI is received at the PCC.</t> in case no BPI is received at the PCC.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Selection of Raw Mode and Tunnel Mode Forwarding Strategy</name> <name>Selection of the Raw Mode and Tunnel Mode Forwarding Strategy</nam e>
<t>Normally, when the above procedures are finished, the user traffic <t>Normally, when the above procedures are finished, the user traffic
will be forwarded via the appointed path, but the forwarding will be will be forwarded via the appointed path, but the forwarding will be
based solely on the destination of user traffic. If there is traffic based solely on the destination of user traffic.
from different attached points to the same destination coming into the If traffic is coming into the network
network, they could share the priority path which may not be the from different attached points but to the same destination,
initial desire. For example, as illustrated in Figure 1, the initial they could share the priority path, which may not be the
aim is to ensure traffic that enters the network via R1 and exits the initial desire. For example, as illustrated in <xref target="fig-1"/>, t
he initial
aim is to ensure that traffic enters the network via R1 and exits the
network at R7 via R5-R6-R7. If some traffic enters the network via the network at R7 via R5-R6-R7. If some traffic enters the network via the
R2 router, passes through R5 and exits at R7, they may share the R2 router, passes through R5, and exits at R7, they may share the
priority path among R5-R6-R7, which may not be the desired effect.</t> priority path among R5-R6-R7, which may not be the desired effect.</t>
<t>The above normal traffic forwarding behavior is clarified as a Raw <t>The above normal traffic forwarding behavior is clarified as a Raw
mode forwarding strategy. Such a mode can achieve only the moderate mode forwarding strategy. Such a mode can only achieve the moderate
traffic path control effect. To achieve the strict traffic path traffic path control effect. To achieve the strict traffic path
control effect, the entry point MUST tunnel the user traffic from the control effect, the entry point <bcp14>MUST</bcp14> tunnel the user traf fic from the
entry point of the network to the exit point of the network, which is entry point of the network to the exit point of the network, which is
also between the BGP peer established via <xref target="BGPSess" format= "default"/>. also between the BGP peer established via <xref target="BGPSess" format= "default"/>.
Such forwarding behavior is called the Tunnel mode forwarding Such forwarding behavior is called the Tunnel mode forwarding
strategy. For simplicity, the IPinIP tunnel type <xref target="RFC2003" format="default"/> is used between the BGP peers by default.</t> strategy. For simplicity, the IP-in-IP tunnel type <xref target="RFC2003 " format="default"/> is used between the BGP peers by default.</t>
<t>The selection of Raw mode and Tunnel mode forwarding strategies are <t>The selection of Raw mode and Tunnel mode forwarding strategies are
controlled via the "T" bit in BPI Object that is defined in <xref target ="BPI_Object" format="default"/></t> controlled via the T bit in the BPI object, which is defined in <xref ta rget="BPI_Object" format="default"/></t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Clean Up</name> <name>Cleanup</name>
<t>To remove the Native-IP state from the PCC, the PCE MUST send
explicit CCI cleanup instructions for PPA, EPR and BPI objects <t>To remove the Native IP state from the PCC, the PCE <bcp14>MUST</bcp1
respectively with the R flag set in the SRP object. If the PCC 4> send
receives a PCInitiate message but does not recognize the Native-IP explicit CCI cleanup instructions for PPA, EPR, and BPI objects,
information in the CCI, the PCC MUST generate a PCErr message with respectively, with the R bit set in the SRP object. If the PCC
Error-Type=19 (Invalid operation) and Error-value=TBD2 (Unknown receives a PCInitiate message but does not recognize the Native IP
Native-IP Info) and MUST include the SRP object to specify the error information in the CCI, the PCC <bcp14>MUST</bcp14> generate a PCErr mes
sage with
Error-Type=19 (Invalid Operation) and Error-value=30 (Unknown
Native IP Info) and <bcp14>MUST</bcp14> include the SRP object to specif
y the error
is for the corresponding cleanup (via a PCInitiate message).</t> is for the corresponding cleanup (via a PCInitiate message).</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Other Procedures</name> <name>Other Procedures</name>
<t>The handling of the state synchronization, redundant PCEs, <t>The handling of the State Synchronization, redundant PCEs,
re-delegation and clean up is the same as other CCIs as specified in redelegation, and cleanup is the same as other CCIs as specified in
<xref target="RFC9050" format="default"/>.</t> <xref target="RFC9050" format="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="Obj-Def-Sec" numbered="true" toc="default"> <section anchor="Obj-Def-Sec" numbered="true" toc="default">
<name>New PCEP Objects</name> <name>New PCEP Objects</name>
<t>One new CCI Object type and three new PCEP objects are defined in <t>One new CCI Object-Type and three new PCEP objects are defined in
this document. All new PCEP objects are as per <xref target="RFC5440" form at="default"/>.</t> this document. All new PCEP objects are as per <xref target="RFC5440" form at="default"/>.</t>
<section anchor="CCI" numbered="true" toc="default"> <section anchor="CCI" numbered="true" toc="default">
<name>CCI Object</name> <name>CCI Object</name>
<t>The Central Control Instructions (CCI) Object (defined in <xref targe t="RFC9050" format="default"/>) is used by the PCE to specify the forwarding <t>The Central Control Instructions (CCI) Object (defined in <xref targe t="RFC9050" format="default"/>) is used by the PCE to specify the forwarding
instructions. This document defines another object type for Native-IP instructions. This document defines another Object-Type for Native IP
procedures.</t> procedures.</t>
<t>CCI Object-Type is 2 for Native-IP as below: </t> <t>The CCI Object-Type is 2 for Native IP, as follows: </t>
<artwork name="" type="" align="left" alt=""><![CDATA[ 0
1 2 3 <figure anchor="fig-9">
<name>CCI Object for Native IP</name>
<artwork name="" type="" align="center" alt=""><![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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CC-ID | | CC-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | | Reserved | Flags |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| | | |
// Optional TLVs // // Optional TLVs //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
Figure 9: CCI Object for Native IP]]></artwork> </figure>
<t>The field CC-ID is as described in <xref target="RFC9050" format="def <t>The CC-ID field is as described in <xref target="RFC9050" format="def
ault"/>. The ault"/>. The
following fields are defined for CCI Object-Type 2 </t> following fields are defined for CCI Object-Type 2.</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Reserved:</dt> <dt>Reserved:</dt>
<dd>2 bytes, is set to zero while sending and <dd>2 bytes. Set to zero while sending and
ignored on receipt.</dd> ignored on receipt.</dd>
<dt>Flags:</dt> <dt>Flags:</dt>
<dd>2 bytes, is used to carry any additional <dd>2 bytes. Used to carry any additional
information about the Native-IP CCI. Currently, no flag bits are information about the Native IP CCI. Currently, no flag bits are
defined. Unassigned flags are set to zero while sending and defined. Unassigned flags are set to zero while sending and
ignored on receipt.</dd> ignored on receipt.</dd>
</dl> </dl>
<t>Optional TLVs may be included within the CCI object body. The <t>Optional TLVs may be included within the CCI object body. The
Symbolic Path Name TLV <xref target="RFC8231" format="default"/> MUST be included in Symbolic Path Name TLV <xref target="RFC8231" format="default"/> <bcp14> MUST</bcp14> be included in
the CCI Object-Type 2 to identify the E2E TE path in the Native IP the CCI Object-Type 2 to identify the E2E TE path in the Native IP
environment.</t> environment.</t>
</section> </section>
<section anchor="BPI_Object" numbered="true" toc="default"> <section anchor="BPI_Object" numbered="true" toc="default">
<name>BGP Peer Info Object</name> <name>BGP Peer Info Object</name>
<t>The BGP Peer Info object is used to specify the information about <t>The BGP Peer Info (BPI) object is used to specify the information abo
the peer with which the PCC want to establish the BGP session. This ut
the peer with which the PCC wants to establish the BGP session. This
object is included and sent to the source and destination router of object is included and sent to the source and destination router of
the E2E path in case there is no Route Reflection (RR) involved. If the E2E path in case there is no Route Reflection (RR) involved. If
the RR is used between the source and destination routers, then such the RR is used between the source and destination routers, then such
information is sent to the source router, RR and destination router information is sent to the source router, RR, and destination router,
respectively.</t> respectively.</t>
<t>By default, the Local/Peer IP address MUST be a unicast address and <t>By default, the Local/Peer IP Address <bcp14>MUST</bcp14> be a unicas
dedicated to the usage of the native IP TE solution, and MUST NOT be t address and
dedicated to the usage of the Native IP TE solution and <bcp14>MUST NOT<
/bcp14> be
used by other BGP sessions that are established by manual or other used by other BGP sessions that are established by manual or other
configuration mechanisms.</t> configuration mechanisms.</t>
<t>BGP Peer Info Object-Class is 46</t> <t>The BGP Peer Info Object-Class is 46.</t>
<t>BGP Peer Info Object-Type is 1 for IPv4 and 2 for IPv6</t> <t>The BGP Peer Info Object-Type is 1 for IPv4 and 2 for IPv6.</t>
<t>The format of the BGP Peer Info object body for IPv4 <t>The format of the BGP Peer Info object body for IPv4
(Object-Type=1) is as follows:</t> (Object-Type=1) is as follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ 0
1 2 3 <figure anchor="fig-10">
<name>BGP Peer Info Object Body Format for IPv4</name>
<artwork name="" type="" align="center" alt=""><![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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS Number | | Peer AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETTL | Status | Error Code | Flag |T| | ETTL | Status | Error Code | Flag |T|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP Address | | Local IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP Address | | Peer IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optional TLVs // // Optional TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: BGP Peer Info Object Body Format for IPv4 ]]></artwork> ]]></artwork>
<t/> </figure>
<t>The format of the BGP Peer Info object body for IPv6 <t>The format of the BGP Peer Info object body for IPv6
(Object-Type=2) is as follows:</t> (Object-Type=2) is as follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ 0
1 2 3 <figure anchor="fig-11">
<name>BGP Peer Info Object Body Format for IPv6</name>
<artwork name="" type="" align="center" alt=""><![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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS Number | | Peer AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETTL | Status | Error Code | Flag |T| | ETTL | Status | Error Code | Flag |T|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Local IP Address (16 bytes) | | Local IP Address (16 bytes) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Peer IP Address (16 bytes) | | Peer IP Address (16 bytes) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optional TLVs // // Optional TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: BGP Peer Info Object Body Format for IPv6 ]]></artwork> ]]></artwork>
<ul empty="true" spacing="normal"> </figure>
<li>
<t>Peer AS Number: 4 bytes, to indicate the AS number of Remote <dl spacing="normal" newline="false">
Peer. Note that if 2-byte AS numbers are in use, the low-order <dt>Peer AS Number:</dt><dd>4 bytes. Indicates the AS number of the Remote
bits (16 through 31) is used, and the high-order bits (0 through Peer. Note that if 2-byte AS numbers are in use, the low-order bits (16
15) is set to zero.</t> through 31) are used, and the high-order bits (0 through 15) are set to
</li> zero.</dd>
<li> <dt>ETTL:</dt><dd>1 byte. EBGP Time To Live. Indicates the multi-hop count
<t>ETTL: 1 byte, EBGP Time To Live, to indicate the multi-hop for the EBGP session. It should be 0 and ignored when Local AS and Peer AS
count for the EBGP session. It should be 0 and ignored when Local are the same.</dd>
AS and Peer AS are the same.</t> <dt>Status:</dt><dd><t>1 byte. Indicates the BGP session status between the
</li> peers. Its values are defined below:</t>
<li> <dl spacing="normal" newline="false">
<t>Status: 1 byte, Indicate BGP session status between the peers. <dt>0:</dt><dd>Reserved</dd>
Its values are defined below:</t> <dt>1:</dt><dd>BGP Session Established</dd>
</li> <dt>2:</dt><dd>BGP Session Establishment In Progress</dd>
<li> <dt>3:</dt><dd>BGP Session Down</dd>
<ul spacing="normal"> <dt>4-255:</dt><dd>Reserved</dd>
<li> </dl>
<t>0: Reserved</t> </dd>
</li> <dt>Error Code:</dt><dd><t>1 byte. Indicates the reason that the BGP session
<li> can't be established.</t>
<t>1: BGP Session Established</t> <dl spacing="normal" newline="false">
</li> <dt>0:</dt><dd>Unspecific</dd>
<li> <dt>1:</dt><dd>ASes do not match, BGP Session Failure</dd>
<t>2: BGP Session Establishment In Progress</t> <dt>2:</dt><dd>Peer IP can't be reached, BGP Session Failure</dd
</li> >
<li> <dt>3-255:</dt><dd>Reserved</dd>
<t>3: BGP Session Down</t> </dl>
</li> </dd>
<li> <dt>Flag:</dt><dd><t>1 byte.</t>
<t>4-255: Reserved</t> <t>Currently, only bit 7 (T bit) is defined. When the T bit is set, the
</li> traffic <bcp14>SHOULD</bcp14> be sent in the IP-in-IP tunnel (the tunnel sourc
</ul> e is
</li> the Local IP Address, and the tunnel destination is the Peer IP Address). When
<li> the T bit is
<t>Error Code: 1 byte, Indicate the reason that the BGP session cleared, the traffic is sent via its original source and destination
can't be established.</t> address. The Tunnel mode (i.e., the T bit is set) is used when the operator wa
</li> nts to
<li> ensure only the traffic from the specified (entry, exit) pair, and the Raw
<ul spacing="normal"> mode (i.e., the T bit is clear) is used when the operator wants to ensure traf
<li> fic from
<t>0: Unspecific</t> any entry to the specified destination. Unassigned flags are set to zero
</li> while sending and ignored on receipt.</t>
<li> </dd>
<t>1: ASes do not match, BGP Session Failure</t> <dt>Local IP Address(4/16 bytes):</dt><dd>Unicast IP address of the local
</li> router, used to peer with another end router. When the Object-Type is 1, the
<li> length is 4 bytes; when the Object-Type is 2, the length is 16 bytes.</dd>
<t>2: Peer IP can't be reached, BGP Session Failure</t> <dt>Peer IP Address(4/16 bytes):</dt><dd>Unicast IP address of the peer
</li> router, used to peer with the local router. When the Object-Type is 1, the
<li> length is 4 bytes; when the Object-Type is 2, the length is 16 bytes.</dd>
<t>3-255: Reserved</t> <dt>Optional TLVs:</dt><dd>TLVs that are associated with this object; can be
</li> used to convey other necessary information for dynamic BGP session
</ul> establishment. No TLVs are currently defined.</dd>
</li> </dl>
<li> <t>When the PCC receives a BPI object, with Object-Type=1, it <bcp14>SHO
<t>Flag: 1 byte.</t> ULD</bcp14>
</li>
<li>
<ul spacing="normal">
<li>
<t>Currently, only bit 7 (T bit) is defined. When the T bit is
set, the traffic SHOULD be sent in the IPinIP tunnel (Tunnel
source is Local IP Address, tunnel destination is Peer IP
Address). When the T bit is cleared, the traffic is sent via
its original source and destination address. The Tunnel mode(T
bit is set) is used when the operator wants to ensure only the
traffic from the specified (entry, exit) pair, and the Raw
mode (T bit is clear) is used when the operator wants to
ensure traffic from any entry to the specified destination.
Unassigned flags are set to zero while sending and ignored on
receipt.</t>
</li>
</ul>
</li>
<li>
<t>Local IP Address(4/16 bytes): Unicast IP address of the local
router, used to peer with another end router. When Object-Type is
1, the length is 4 bytes; when Object-Type is 2, the length is 16
bytes.</t>
</li>
<li>
<t>Peer IP Address(4/16 bytes): Unicast IP address of the peer
router, used to peer with the local router. When Object-Type is 1,
the length is 4 bytes; when Object-Type is 2, the length is 16
bytes;</t>
</li>
<li>
<t>Optional TLVs: TLVs that are associated with this object, can
be used to convey other necessary information for dynamic BGP
session establishment. No TLVs are currently defined.</t>
</li>
</ul>
<t>When the PCC receives a BPI object, with Object-Type=1, it SHOULD
try to establish a BGP session with the peer in AFI/SAFI=1/1.</t> try to establish a BGP session with the peer in AFI/SAFI=1/1.</t>
<t>When the PCC receives a BPI object with Object-Type=2, it SHOULD <t>When the PCC receives a BPI object, with Object-Type=2, it <bcp14>SHO ULD</bcp14>
try to establish a BGP session with the peer in AFI/SAFI=2/1.</t> try to establish a BGP session with the peer in AFI/SAFI=2/1.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Explicit Peer Route Object</name> <name>Explicit Peer Route Object</name>
<t>The Explicit Peer Route object is defined to specify the explicit <t>The Explicit Peer Route (EPR) object is defined to specify the explic it
peer route to the corresponding peer address on each device that is on peer route to the corresponding peer address on each device that is on
the E2E Native-IP TE path. This Object ought to be sent to all the the E2E Native IP TE path. This Object ought to be sent to all the
devices on the path that is calculated by the PCE. Although the object devices on the path that are calculated by the PCE. Although the object
is named as "Explicit Peer Route", it can be seen that the is named "Explicit Peer Route", it can be seen that the
routes it installs are simply host routes. The use of this object to routes it installs are simply host routes. The use of this object to
install host routes for any purpose other than reaching the install host routes for any purpose other than reaching the
corresponding peer address on each device that is on the E2E Native-IP corresponding peer address on each device that is on the E2E Native IP
TE path is outside the scope of this specification.</t> TE path is outside the scope of this specification.</t>
<t>By default, the path established by this object MUST have higher <t>By default, the path established by this object <bcp14>MUST</bcp14> h
priority than the other paths calculated by dynamic IGP protocol, and ave higher
MUST have lower priority than the static route configured by manual or priority than the other paths calculated by the dynamic IGP protocol and
NETCONF or any other static means.</t> <bcp14>MUST</bcp14> have lower priority than the static route configured
<t>Explicit Peer Route Object-Class is 47.</t> by manual,
<t>Explicit Peer Route Object-Type is 1 for IPv4 and 2 for IPv6</t> NETCONF, or any other static means.</t>
<t>The Explicit Peer Route Object-Class is 47.</t>
<t>The Explicit Peer Route Object-Type is 1 for IPv4 and 2 for IPv6.</t>
<t>The format of the Explicit Peer Route object body for IPv4 <t>The format of the Explicit Peer Route object body for IPv4
(Object-Type=1) is as follows:</t> (Object-Type=1) is as follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ 0
1 2 3 <figure anchor="fig-12">
<name>Explicit Peer Route Object Body Format for IPv4</name>
<artwork name="" type="" align="center" alt=""><![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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Priority | Reserved | | Route Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IPv4 Address | | Peer IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop IPv4 Address to the Peer | | Next Hop IPv4 Address to the Peer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optional TLVs // // Optional TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Explicit Peer Route Object Body Format for IPv4
]]></artwork> ]]></artwork>
<t/> </figure>
<t>The format of the Explicit Peer Route object body for IPv6 <t>The format of the Explicit Peer Route object body for IPv6
(Object-Type=2) is as follows:</t> (Object-Type=2) is as follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ 0
1 2 3 <figure anchor="fig-13">
<name>Explicit Peer Route Object Body Format for IPv6</name>
<artwork name="" type="" align="center" alt=""><![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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Priority | Reserved | | Route Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Peer IPv6 Address | | Peer IPv6 Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Next Hop IPv6 Address to the Peer | | Next Hop IPv6 Address to the Peer |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optional TLVs // // Optional TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Explicit Peer Route Object Body Format for IPv6
]]></artwork> ]]></artwork>
<ul empty="true" spacing="normal"> </figure>
<li>
<t>Route Priority: 2 bytes; the priority of this explicit route. <dl newline="false" spacing="normal">
The higher priority SHOULD be preferred by the device. This field <dt>Route Priority:</dt><dd>2 bytes. The priority of this explicit
is used to indicate the preferred path at each hop.</t> route. The higher priority <bcp14>SHOULD</bcp14> be preferred by
</li> the device. This field is used to indicate the preferred path at
<li> each hop.</dd>
<t>Reserved: is set to zero while sending, ignored on receipt.</t> <dt>Reserved:</dt><dd>Set to zero while sending and ignored on receipt
</li> .</dd>
<li> <dt>Peer (IPv4/IPv6) Address:</dt><dd>Peer address for the BGP
<t>Peer (IPv4/IPv6) Address: Peer Address for the BGP session session (4/16 bytes).</dd>
(4/16 bytes).</t> <dt>Next Hop (IPv4/IPv6) Address to the Peer:</dt><dd>Indicates
</li> the next-hop address (4/16 bytes) to the corresponding peer
<li> address.</dd>
<t>Next Hop (IPv4/IPv6) Address to the Peer: To indicate the next <dt>Optional TLVs:</dt><dd>TLVs that are associated with this
hop address (4/16 bytes) to the corresponding peer address.</t> object; can be used to convey other necessary information for
</li> explicit peer path establishment. No TLVs are currently defined.</dd>
<li> </dl>
<t>Optional TLVs: TLVs that are associated with this object, can
be used to convey other necessary information for explicit peer
path establishment. No TLVs are currently defined.</t>
</li>
</ul>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Peer Prefix Advertisement Object</name> <name>Peer Prefix Advertisement Object</name>
<t>The Peer Prefix Advertisement object is defined to specify the IP <t>The Peer Prefix Advertisement (PPA) object is defined to specify the IP
prefixes that are advertised to the corresponding peer. This object prefixes that are advertised to the corresponding peer. This object
needs only be included and sent to the source/destination router of only needs to be included and sent to the source/destination router of
the E2E path.</t> the E2E path.</t>
<t>The prefix information included in this object MUST only be <t>The prefix information included in this object <bcp14>MUST</bcp14> on
advertised to the indicated peer, and SHOULD NOT be advertised to ly be
advertised to the indicated peer and <bcp14>SHOULD NOT</bcp14> be advert
ised to
other BGP peers.</t> other BGP peers.</t>
<t>Peer Prefix Advertisement Object-Class is 48</t> <t>The Peer Prefix Advertisement Object-Class is 48.</t>
<t>Peer Prefix Advertisement Object-Type is 1 for IPv4 and 2 for <t>The Peer Prefix Advertisement Object-Type is 1 for IPv4 and 2 for
IPv6</t> IPv6.</t>
<t>The format of the Peer Prefix Advertisement object body is as <t>The format of the Peer Prefix Advertisement object body for IPv4 is a
s
follows:</t> follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ 0
1 2 3 <figure anchor="fig-14">
<name>Peer Prefix Advertisement Object Body Format for IPv4</name>
<artwork name="" type="" align="center" alt=""><![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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IPv4 Address | | Peer IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| No. of Prefix | Reserved | | No. of Prefix | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix #1 | | IPv4 Prefix #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Prefix #1 Len | Reserved | |Prefix #1 Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : | | : |
| : | | : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix #n | | IPv4 Prefix #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Prefix #n Len | Reserved | |Prefix #n Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optional TLVs // // Optional TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Peer Prefix Advertisement Object Body Format for IPv4]]></artwork> ]]></artwork>
<artwork name="" type="" align="left" alt=""><![CDATA[ 0 </figure>
1 2 3
<t>The format of the Peer Prefix Advertisement object body for IPv6 is a
s
follows:</t>
<figure anchor="fig-15">
<name>Peer Prefix Advertisement Object Body Format for IPv6</name>
<artwork name="" type="" align="center" alt=""><![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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Peer IPv6 Address | | Peer IPv6 Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| No. of Prefix | Reserved | | No. of Prefix | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Prefix #1 | | IPv6 Prefix #1 |
skipping to change at line 1105 skipping to change at line 1088
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Prefix #n | | IPv6 Prefix #n |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Prefix #n Len | Reserved | |Prefix #n Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optional TLVs // // Optional TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Peer Prefix Advertisement Object Body Format for IPv6]]></artwork> ]]></artwork>
<ul empty="true" spacing="normal"> </figure>
<li>
<t>Common Fields:</t> <dl newline="true">
</li> <dt>Common Fields:</dt>
<li> <dd>
<ul empty="true" spacing="normal"> <dl newline="false" spacing="normal">
<li> <dt>No. of Prefix:</dt><dd>1 byte. Identifies the
<t>No. of Prefix: 1 byte. Identifies the number of prefixes number of prefixes that are advertised to the peer in the PPA
that are advertised to the peer in the PPA object.</t> object.</dd>
</li> <dt>Reserved:</dt><dd>3 bytes. Ought to be set to zero
<li> while sending and ignored on receipt.</dd>
<t>Reserved: 3 bytes. Ought to be set to zero while sending <dt>Prefix Len:</dt><dd>1 byte. Identifies the length
and be ignored on receipt.</t> of the prefix.</dd>
</li> <dt>Optional TLVs:</dt><dd>TLVs that are associated with this
<li> object; can be used to convey other necessary information for
<t>Prefix Len: 1 byte. Identifies the length of the prefix advertisement. No TLVs are currently defined.</dd>
prefix.</t> </dl>
</li> </dd>
<li> <dt>For IPv4:</dt>
<t>Optional TLVs: TLVs that are associated with this object, <dd>
can be used to convey other necessary information for prefix <dl newline="false" spacing="normal">
advertisement. No TLVs are currently defined.</t> <dt>Peer IPv4 Address:</dt><dd>4 bytes. Identifies the
</li> Peer IPv4 Address that the associated prefixes will be sent
</ul> to.</dd>
</li> <dt>IPv4 Prefix:</dt><dd>4 bytes. Identifies the prefix
<li> that will be sent to the peer identified by the Peer IPv4
<t>For IPv4:</t> Address.</dd>
</li> </dl>
<li> </dd>
<ul empty="true" spacing="normal"> <dt>For IPv6:</dt>
<li> <dd>
<t>Peer IPv4 Address: 4 bytes. Identifies the peer IPv4 <dl newline="false" spacing="normal">
address that the associated prefixes will be sent to.</t> <dt>Peer IPv6 Address:</dt><dd>16 bytes. Identifies the
</li> Peer IPv6 Address that the associated prefixes will be sent
<li> to.</dd>
<t>IPv4 Prefix: 4 bytes. Identifies the prefix that will be <dt>IPv6 Prefix:</dt><dd>Identifies the prefix that will be
sent to the peer identified by Peer IPv4 Address.</t> sent to the peer identified by the Peer IPv6 Address.</dd>
</li> </dl>
</ul> </dd>
</li> </dl>
<li> <t>If in the future a requirement is identified to advertise IPv4
<t>For IPv6:</t> prefixes towards an IPv6 peering address or IPv6 prefixes towards an
<ul empty="true" spacing="normal"> IPv4 peering address, then a new Peer Prefix Advertisement
<li> Object-Type can be defined for these purposes.</t>
<t>Peer IPv6 Address: 16 bytes. Identifies the peer IPv6
address that the associated prefixes will be sent to.</t>
</li>
<li>
<t>IPv6 Prefix: Identifies the prefix that will be sent to the
peer identified by Peer IPv6 Address.</t>
</li>
</ul>
<t>If in the future, a requirement is identified to
advertise IPv4 prefixes toward an IPv6 peering address, or IPv6
prefixes towards an IPv4 peering address, then a new Peer Prefix
Advertisement Object-Types can be defined for these purposes.</t>
</li>
</ul>
</section> </section>
</section> </section>
<section anchor="NewErrorTypeAndValue" numbered="true" toc="default"> <section anchor="NewErrorTypeAndValue" numbered="true" toc="default">
<name>New Error-Types and Error-Values Defined</name> <name>New Error-Type and Error-Values Defined</name>
<t>A PCEP-ERROR object is used to report a PCEP error and is <t>A PCEP-ERROR object is used to report a PCEP error and is
characterized by an Error-Type that specifies that type of error and an characterized by an Error-Type that specifies that type of error and an
Error-value that provides additional information about the error. An Error-value that provides additional information about the error. An
additional Error-Type and several Error-values are defined to represent additional Error-Type and several Error-values are defined to represent
the errors related to the newly defined objects that are related to the errors related to the newly defined objects that are related to
Native IP TE procedures.</t> Native IP TE procedures. See <xref target="err-type-value-reg"/> for the n
<artwork name="" type="" align="left" alt=""><![CDATA[ +============ ewly defined
+==========+=====================================+ Error-Type and Error-values.</t>
| Error-Type | Meaning | Error-value |
+=======+===============+=====================================+
| 33 | Native IP TE failure |
| | |
+-------+---------------+-------------------------------------+
| | |0:Unassigned |
+-------+---------------+-------------------------------------+
| | |1:Local IP is in use |
+-------+---------------+-------------------------------------+
| | |2:Remote IP is in use |
+-------+---------------+-------------------------------------+
| | |3:Explicit Peer Route Error |
+-------+---------------+-------------------------------------+
| | |4:EPR/BPI Peer Info mismatch |
+-------+---------------+-------------------------------------+
| | |5:BPI/PPA Address Family mismatch |
+-------+---------------+-------------------------------------+
| | |6:PPA/BPI Peer Info mismatch |
+-------+---------------+-------------------------------------+
| 6 | Mandatory Object missing |
| | |
+-------+---------------+-------------------------------------+
| | |19:Native IP object missing |
+-------+---------------+-------------------------------------+
| 10 | Reception of an invalid object |
| | |
+-------+---------------+-------------------------------------+
| | |39:PCECC NATIVE-IP-TE-CAPABILITY bit |
| | |is not set |
+-------+---------------+-------------------------------------+
| 19 | Invalid Operation |
| | |
+-------+---------------+-------------------------------------+
| | |22:Only one BPI, EPR or PPA object |
| | |can be included in this message |
+-------+---------------+-------------------------------------+
| | |TBD1:Attempted Native-IP operations |
| | |when the capability was not |
| | | advertised |
+-------+---------------+-------------------------------------+
| | |TBD2:Unknown Native-IP Info |
+-------+---------------+-------------------------------------+
Figure 16: Newly defined Error-Type and Error-Value
]]></artwork>
</section> </section>
<section anchor="BGP_Considerations" numbered="true" toc="default"> <section anchor="BGP_Considerations" numbered="true" toc="default">
<name>BGP Considerations</name> <name>BGP Considerations</name>
<t>This document defines the procedures and objects to create the BGP
sessions and advertise the associated prefixes dynamically. Only the key <t>This document defines procedures and objects to create the BGP
information, for example, peer IP addresses, and peer AS numbers are sessions and to advertise the associated prefixes dynamically. Only the ke
exchanged via the PCEP protocol. Other parameters that are needed for y
the BGP session setup SHOULD be derived from their default values.</t> information, for example, Peer IP Addresses, and Peer AS numbers are
exchanged via the PCEP. Other parameters that are needed for
the BGP session setup <bcp14>SHOULD</bcp14> be derived from their default
values.</t>
<t>When the PCE sends out the PCInitiate message with the BPI object <t>When the PCE sends out the PCInitiate message with the BPI object
embedded to establish the BGP session between the PCC peers, the PCC embedded to establish the BGP session between the PCC peers, the PCC
SHOULD report the BGP session status. For instance, the PCC could <bcp14>SHOULD</bcp14> report the BGP session status. For instance, the PCC
respond with "BGP Session Establishment In Progress" initially and on could
session establishment send another PCRpt message with the state updated respond with "BGP Session Establishment In Progress" initially and, on
session establishment, send another PCRpt message with the state updated
to "BGP Session Established". If there is any error during the BGP to "BGP Session Established". If there is any error during the BGP
session establishment, the PCC SHOULD indicate the reason with the session establishment, the PCC <bcp14>SHOULD</bcp14> indicate the reason w ith the
appropriate status value set in the BPI object.</t> appropriate status value set in the BPI object.</t>
<t>Upon receiving such key information, the BGP module on the PCC SHOULD <t>Upon receiving such key information, the BGP module on the PCC <bcp14>S
try to accomplish the task appointed by the PCEP protocol and report the HOULD</bcp14>
try to accomplish the task appointed by the PCEP and report the
successful status to the PCEP modules after the session is set up.</t> successful status to the PCEP modules after the session is set up.</t>
<t>There is no influence on the current implementation of BGP Finite <t>There is no influence on the current implementation of the BGP Finite
State Machine (FSM). The PCEP focuses only on the success and failure State Machine (FSM). PCEP focuses only on the success and failure
status of the BGP session and acts upon such information status of the BGP session and acts upon such information
accordingly.</t> accordingly.</t>
<t>The error-handling procedures related to incorrect BGP parameters are <t>The error-handling procedures related to incorrect BGP parameters are
specified in <xref target="BGPSess" format="default"/>, <xref target="BGPE x" format="default"/>, and <xref target="BGPPrefix" format="default"/>.</t> specified in Sections <xref target="BGPSess" format="counter"/>, <xref tar get="BGPEx" format="counter"/>, and <xref target="BGPPrefix" format="counter"/>. </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Deployment Considerations</name> <name>Deployment Considerations</name>
<t>The information transferred in this document is mainly used for the <t>The information transferred in this document is mainly used for the
BGP session setup, explicit route deployment and the prefix BGP session setup, explicit route deployment, and prefix
distribution. The planning, allocation and distribution of the peer distribution. The planning, allocation, and distribution of the peer
addresses within IGP needs to be accomplished in advance and they are addresses within IGP need to be accomplished in advance, and they are
out of the scope of this document.</t> out of the scope of this document.</t>
<t>The communication of PCE and PCC described in this document MUST <t>The communication of PCE and PCC described in this document <bcp14>MUST
follow the state synchronization procedures described in <xref target="RFC </bcp14>
8232" format="default"/>, treat the three newly defined objects (BPI, EPR and follow the State Synchronization procedures described in <xref target="RFC
PPA) associated with the same symbolic path name as the attribute of the 8232" format="default"/>, i.e., treat the three newly defined objects (BPI, EPR,
same path in the LSP-DB (LSP State Database).</t> and
<t>When PCE detects one or some of the PCCs are out of its control, it PPA) associated with the same Symbolic Path Name as the attribute of the
MUST recompute and redeploy the traffic engineering path for native IP same path in the LSP Database (LSP-DB).</t>
on the currently active PCCs. The PCE MUST ensure the avoidance of the <t>When the PCE detects that one or some of the PCCs are out of its contro
l, it
<bcp14>MUST</bcp14> recompute and redeploy the traffic engineering path fo
r Native IP
on the currently active PCCs. The PCE <bcp14>MUST</bcp14> ensure the avoid
ance of the
possible transient loop in such node failure when it deploys the possible transient loop in such node failure when it deploys the
explicit peer route on the PCCs.</t> explicit peer route on the PCCs.</t>
<t>In case of a PCE failure, a new PCE can gain control over the central <t>In case of a PCE failure, a new PCE can gain control over the Central
controller instructions as described in <xref target="RFC9050" format="def Controller Instructions as described in <xref target="RFC9050" format="def
ault"/>.</t> ault"/>.</t>
<t>As per the PCEP procedures in <xref target="RFC8281" format="default"/> , the State <t>As per the PCEP procedures in <xref target="RFC8281" format="default"/> , the State
Timeout Interval timer is used to ensure that a PCE failure does not Timeout Interval timer is used to ensure that a PCE failure does not
result in automatic and immediate disruption for the services. result in automatic and immediate disruption for the services.
Similarly, as per <xref target="RFC9050" format="default"/>, the central c Similarly, as per <xref target="RFC9050" format="default"/>, the Central C
ontroller ontroller
instructions are not removed immediately upon PCE failure. Instead, they Instructions are not removed immediately upon PCE failure. Instead, they
could be re-delegated to the new PCE before the expiration of this could be redelegated to the new PCE before the expiration of this
timer, or be cleaned up on the expiration of this timer. This allows for timer or be cleaned up on the expiration of this timer. This allows for
network clean up without manual intervention. The PCC supports the network cleanup without manual intervention. The PCC supports the
removal of CCI as one of the behaviors applied on the expiration of the removal of CCI as one of the behaviors applied on the expiration of the
State Timeout Interval timer.</t> State Timeout Interval timer.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Manageability Considerations</name> <name>Manageability Considerations</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Control of Function and Policy</name> <name>Control of Function and Policy</name>
<t>A PCE or PCC implementation SHOULD allow the PCECC Native-IP <t>A PCE or PCC implementation <bcp14>SHOULD</bcp14> allow the PCECC Nat ive IP
capability to be enabled/disabled as part of the global capability to be enabled/disabled as part of the global
configuration.</t> configuration.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Information and Data Models</name> <name>Information and Data Models</name>
<t><xref target="RFC7420" format="default"/> describes the PCEP MIB; thi s MIB could be <t><xref target="RFC7420" format="default"/> describes the PCEP MIB; thi s MIB could be
extended to get the PCECC Native-IP capability status. The PCEP YANG extended to get the PCECC Native IP capability status. The PCEP YANG mod
<xref target="I-D.ietf-pce-pcep-yang" format="default"/> module could be ule
extended to <xref target="I-D.ietf-pce-pcep-yang" format="default"/> could be extend
enable/disable the PCECC Native-IP capability.</t> ed to
enable/disable the PCECC Native IP capability.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Liveness Detection and Monitoring</name> <name>Liveness Detection and Monitoring</name>
<t>Mechanisms defined in this document do not imply any new liveness <t>Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already detection and monitoring requirements beyond those already listed in
listed in <xref target="RFC5440" format="default"/>. The operator relies <xref target="RFC5440" format="default"/>. The operator relies on existin
on existing IP g IP
liveness detection and monitoring.</t> liveness detection and monitoring.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Verify Correct Operations</name> <name>Verify Correct Operations</name>
<t>Verification of the mechanisms defined in this document can be <t>Verification of the mechanisms defined in this document can be
built on those already listed in <xref target="RFC5440" format="default" />, <xref target="RFC8231" format="default"/> and <xref target="RFC9050" format= "default"/>. Further, the operator built on those already listed in <xref target="RFC5440" format="default" />, <xref target="RFC8231" format="default"/>, and <xref target="RFC9050" format ="default"/>. Further, the operator
needs to be able to verify the status of BGP sessions and prefix needs to be able to verify the status of BGP sessions and prefix
advertisements.</t> advertisements.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Requirements on Other Protocols</name> <name>Requirements on Other Protocols</name>
<t>Mechanisms defined in this document require the interaction with <t>Mechanisms defined in this document require the interaction with
BGP. <xref target="BGP_Considerations" format="default"/> describes in d etail the BGP. <xref target="BGP_Considerations" format="default"/> describes in d etail the
considerations regarding the BGP. During the BGP session considerations regarding the BGP. During the BGP session
establishment, the Local/Peer IP address MUST be dedicated to the establishment, the Local/Peer IP Address <bcp14>MUST</bcp14> be dedicate
usage of the native IP TE solution, and MUST NOT be used by other BGP d to the
usage of the Native IP TE solution and <bcp14>MUST NOT</bcp14> be used b
y other BGP
sessions that are established manually or in other ways.</t> sessions that are established manually or in other ways.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Impact on Network Operations</name> <name>Impact on Network Operations</name>
<t><xref target="RFC8821" format="default"/> describes the various deplo yment <t><xref target="RFC8821" format="default"/> describes the various deplo yment
considerations in CCDR architecture and their impact on network considerations in CCDR architecture and their impact on network
operations.</t> operations.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>In this setup, the BGP sessions, prefix advertisement, and explicit <t>In this setup, the BGP sessions, prefix advertisement, and explicit
peer route establishment are all controlled by the PCE. See <xref target=" peer route establishment are all controlled by the PCE. See <xref target="
RFC4271" format="default"/> for security consideration of classical BGP RFC4271" format="default"/> for classical BGP
implementation, and <xref target="RFC4272" format="default"/> for classica implementation security considerations and <xref target="RFC4272" format="
l BGP default"/> for classical BGP
vulnerabilities analysis. Security considerations in <xref target="RFC5440 vulnerabilities analysis. Security considerations in <xref target="RFC5440
" format="default"/>for basic PCEP protocol, <xref target="RFC8231" format="defa " format="default"/> for the basic PCEP, <xref target="RFC8231" format="default"
ult"/> for /> for
PCEP extension for stateful PCE and <xref target="RFC8281" format="default PCEP extension for stateful PCE, and <xref target="RFC8281" format="defaul
"/> for t"/> for
PCE-Initiated LSP setup SHOULD be considered. To prevent a bogus PCE PCE-initiated LSP setup <bcp14>SHOULD</bcp14> be considered. To prevent a
bogus PCE
from sending harmful messages to the network nodes, the network devices from sending harmful messages to the network nodes, the network devices
SHOULD authenticate the PCE and ensure a secure communication channel <bcp14>SHOULD</bcp14> authenticate the PCE and ensure a secure communicati on channel
between them. Thus, the mechanisms described in <xref target="RFC8253" for mat="default"/> between them. Thus, the mechanisms described in <xref target="RFC8253" for mat="default"/>
for the usage of TLS for PCEP and <xref target="RFC9050" format="default"/ > for for the usage of TLS for PCEP and <xref target="RFC9050" format="default"/ > for
protection against malicious PCEs SHOULD be used.</t> protection against malicious PCEs <bcp14>SHOULD</bcp14> be used.</t>
<t>If suitable default values as discussed in <xref target="BGP_Considerat <t>If the default values discussed in <xref target="BGP_Considerations" fo
ions" format="default"/> aren't enough and securing the BGP rmat="default"/> aren't enough and securing the BGP
transport is required(for example, the TCP-AO <xref target="RFC5925" forma transport is required (for example, by using TCP Authentication Option (TC
t="default"/>, P-AO) <xref target="RFC5925" format="default"/>),
it can be provided through the addition of optional TLVs to the BGP Peer a suitable value can be provided through the addition of optional TLVs to
the BGP Peer
Info object that conveys the necessary additional information (for Info object that conveys the necessary additional information (for
example, a key chain <xref target="RFC8177" format="default"/>name).</t> example, a key chain <xref target="RFC8177" format="default"/> name).</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Path Setup Type Registry</name> <name>PCEP Path Setup Types</name>
<t><xref target="RFC8408" format="default"/> created a sub-registry with <t><xref target="RFC8408" format="default"/> created the "PCEP
in the "Path Path Setup Types" registry within the "Path
Computation Element Protocol (PCEP) Numbers" registry called "PCEP Computation Element Protocol (PCEP) Numbers" registry group. IANA has
Path Setup Types". IANA is requested to allocate a new code point allocated a new codepoint
within this sub-registry, as follows:</t> within this registry, as follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
Value Description Reference <table>
4 Native IP TE Path This document <name>PCEP Path Setup Types Registry</name>
]]></artwork> <thead>
<tr>
<th>Value</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>4</td>
<td>Native IP TE Path</td>
<td>RFC 9757</td>
</tr>
</tbody>
</table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>PCECC-CAPABILITY sub-TLV's Flag field</name> <name>PCECC-CAPABILITY Sub-TLV Flag Field</name>
<t>Editorial Note (To be removed by RFC Editor): This experimental <t><xref target="RFC9050" format="default"/> created the "PCECC-CAPABILI
track document is allocating a code point in the registry under the TY sub-TLV" registry within the "Path
standards action registry which is not allowed. <xref target="RFCYYY1" f Computation Element Protocol (PCEP) Numbers" registry group to manage th
ormat="default"/> updates the registration policy to e
IETF review allowing for this allocation. Note that an early value of the PCECC-CAPABILITY sub-TLV's 32-bit Flag field. IANA
allocation was made when the document was being progressed in the has allocated a new bit position within this registry, as
standards track. At the time of publication, please remove this note
and the reference to <xref target="RFCYYY1" format="default"/>.</t>
<t><xref target="RFC9050" format="default"/> created a sub-registry with
in the "Path
Computation Element Protocol (PCEP) Numbers" registry to manage the
value of the PCECC-CAPABILITY sub-TLV's 32-bit Flag field. IANA is
requested to allocate a new bit position within this registry, as
follows:</t> follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <table>
Bit Name Reference <name>PCECC-CAPABILITY Sub-TLV Registry</name>
30 NATIVE IP This document <thead>
]]></artwork> <tr>
</section> <th>Bit</th>
<section numbered="true" toc="default"> <th>Name</th>
<name>PCEP Object</name> <th>Reference</th>
<t>IANA is requested to allocate new codepoints in the "PCEP Objects" </tr>
sub-registry as follows:</t> </thead>
<artwork name="" type="" align="left" alt=""><![CDATA[ <tbody>
Object-Class Value Name Reference <tr>
44 CCI Object This document <td>30</td>
Object-Type <td>Native IP</td>
2: Native IP <td>RFC 9757</td>
</tr>
46 BGP Peer Info This document </tbody>
Object-Type </table>
1: IPv4 address
2: IPv6 address
47 Explicit Peer Route This document
Object-Type
1: IPv4 address
2: IPv6 address
48 Peer Prefix Advertisement This document
Object-Type
1: IPv4 address
2: IPv6 address
]]></artwork>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>PCEP-Error Object</name> <name>PCEP Objects</name>
<t>IANA is requested to allocate new error types and error values <t>IANA has allocated new codepoints in the "PCEP Objects"
within the "PCEP-ERROR Object Error Types and Values" sub-registry of registry, as follows:</t>
the PCEP Numbers registry for the following errors:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
Error-Type Meaning Error-value
6 Mandatory Object missing
19:Native IP object missing
10 Reception of an invalid object <table>
39:PCECC NATIVE-IP-TE-CAPABILITY bit <name>PCEP Objects Registry</name>
is not set <thead>
<tr>
<th>Object-Class Value</th>
<th>Name</th>
<th>Object-Type</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>44</td>
<td>CCI Object-Type</td>
<td>2: Native IP</td>
<td>RFC 9757</td>
</tr>
<tr>
<td rowspan="3">46</td>
<td rowspan="3">BGP Peer Info Object-Type</td>
<td>0: Reserved</td>
<td>RFC 9757</td>
</tr>
<tr>
<td>1: IPv4 address</td>
<td>RFC 9757</td>
</tr>
<tr>
<td>2: IPv6 address</td>
<td>RFC 9757</td>
</tr>
<tr>
<td rowspan="3">47</td>
<td rowspan="3">Explicit Peer Route Object-Type</td>
<td>0: Reserved</td>
<td>RFC 9757</td>
</tr><tr>
<td>1: IPv4 address</td>
<td>RFC 9757</td>
</tr>
<tr>
<td>2: IPv6 address</td>
<td>RFC 9757</td>
</tr>
<tr>
<td rowspan="3">48</td>
<td rowspan="3">Peer Prefix Advertisement Object-Type</td>
<td>0: Reserved</td>
<td>RFC 9757</td>
</tr>
<tr>
<td>1: IPv4 address</td>
<td>RFC 9757</td>
</tr>
<tr>
<td>2: IPv6 address</td>
<td>RFC 9757</td>
</tr>
</tbody>
</table>
19 Invalid Operation </section>
22:Only one BPI, EPR or PPA object can <section numbered="true" toc="default" anchor="pcep-err-ob">
be included in this message <name>PCEP-Error Objects</name>
TBD1:Attempted Native-IP operations <t>IANA has allocated a new Error-Type and several Error-values
when the capability was not advertised in the "PCEP-ERROR Object Error Types and Values" registry within
TBD2:Unknown Native-IP Info the "Path Computation Element Protocol (PCEP) Numbers" registry group, a
s follows:</t>
33 Native IP TE failure <table anchor="err-type-value-reg">
1:Local IP is in use <name>PCEP-ERROR Object Error Types and Values Registry</name>
2:Remote IP is in use <thead>
3:Explicit Peer Route Error <tr>
4:EPR/BPI Peer Info mismatch <th>Error-Type</th>
5:BPI/PPA Address Family mismatch <th>Meaning</th>
6:PPA/BPI Peer Info mismatch <th>Error-value</th>
]]></artwork> <th>Reference</th>
<t>The reference for the new Error-type/value should be set to this </tr>
</thead>
<tbody>
<tr>
<td>6</td>
<td>Mandatory Object missing</td>
<td>19: Native IP object missing</td>
<td>RFC 9757</td>
</tr>
<tr>
<td>10</td>
<td>Reception of an invalid object</td>
<td>39: PCECC NATIVE-IP-TE-CAPABILITY bit is not set</td>
<td>RFC 9757</td>
</tr>
<tr>
<td rowspan="3">19</td>
<td rowspan="3">Invalid Operation</td>
<td> 22: Only one BPI, EPR, or PPA object can be included in this message<
/td>
<td>RFC 9757</td>
</tr>
<tr>
<td>29: Attempted Native IP operations when the capability was not adverti
sed</td>
<td>RFC 9757</td>
</tr>
<tr>
<td>30: Unknown Native IP Info</td>
<td>RFC 9757</td>
</tr>
<tr>
<td rowspan="7">33</td>
<td rowspan="7">Native IP TE failure</td>
<td>0: Unassigned</td>
<td>RFC 9757</td>
</tr>
<tr>
<td>1: Local IP is in use</td>
<td>RFC9757</td>
</tr>
<tr>
<td>2: Remote IP is in use</td>
<td>RFC 9757</td>
</tr>
<tr>
<td>3: Explicit Peer Route Error</td>
<td>RFC 9757</td>
</tr>
<tr>
<td>4: EPR/BPI Peer Info mismatch</td>
<td>RFC 9757</td>
</tr>
<tr>
<td>5: BPI/PPA Address Family mismatch</td>
<td>RFC 9757</td>
</tr>
<tr>
<td>6: PPA/BPI Peer Info mismatch</td>
<td>RFC 9757</td>
</tr>
</tbody>
</table>
<t>The reference for each new Error-Type/Error-value should be set to th
is
document.</t> document.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>CCI Object Flag Field</name> <name>CCI Object Flag Field</name>
<t>IANA is requested to create a new sub-registry to manage the <t>IANA has created the "CCI Object Flag Field
16-bits Flag field of the new CCI Object called "CCI Object Flag Field for Native IP" registry to manage the
for Native-IP". New values are to be assigned by IETF review <xref targe 16-bit Flag field of the new CCI object. New values are to be assigned b
t="RFC8126" format="default"/>. Each bit should be tracked with the following y
qualities:</t> IETF Review <xref target="RFC8126" format="default"/>. Each bit should
<ul empty="true" spacing="normal"> be tracked with the following qualities:</t>
<li> <ul spacing="normal">
<t>bit number (counting from bit 0 as the most significant bit, <li>bit number (counting from bit 0 as the most significant bit
and bit 15 as the lest significant bit)</t> and bit 15 as the least significant bit)</li>
</li> <li>capability description</li>
<li> <li>defining RFC</li>
<t>capability description</t>
</li>
<li>
<t>defining RFC</t>
</li>
</ul> </ul>
<t>Currently, no flags are assigned.</t> <t>Currently, no flags are assigned.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>BPI Object Status Code</name> <name>BPI Object Status Codes</name>
<t>IANA is requested to create a new sub-registry "BPI Object Status <t>IANA has created the "BPI Object Status
Code Field" within the "Path Computation Element Protocol (PCEP) Code Field" registry within the "Path Computation Element Protocol (PCEP
Numbers". New values are assigned by IETF review <xref target="RFC8126" )
format="default"/>. Each value should be tracked with the following Numbers" registry group. New values are assigned by IETF Review <xref ta
rget="RFC8126" format="default"/>. Each value should be tracked with the followi
ng
qualities: value, meaning, and defining RFC. The following values are qualities: value, meaning, and defining RFC. The following values are
defined in this document:</t> defined in this document:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
Value Meaning Reference <table>
0 Reserved This document <name>BPI Object Status Code Field Registry</name>
1 BGP Session Established This document <thead>
2 BGP Session Establishment In Progress This document <tr>
3 BGP Session Down This document <th>Value</th>
4-255 Unassigned This document <th>Meaning</th>
]]></artwork> <th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>Reserved</td>
<td>RFC 9757</td>
</tr>
<tr>
<td>1</td>
<td>BGP Session Established</td>
<td>RFC 9757</td>
</tr>
<tr>
<td>2</td>
<td>BGP Session Establishment In Progress</td>
<td>RFC 9757</td>
</tr>
<tr>
<td>3</td>
<td>BGP Session Down</td>
<td>RFC 9757</td>
</tr>
<tr>
<td>4-255</td>
<td>Unassigned</td>
<td>RFC 9757</td>
</tr>
</tbody>
</table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>BPI Object Error Code</name> <name>BPI Object Error Codes</name>
<t>IANA is requested to create a new sub-registry "BPI Object Error <t>IANA has created the "BPI Object Error
Code Field" within the "Path Computation Element Protocol (PCEP) Code Field" registry within the "Path Computation Element Protocol (PCEP
Numbers". New values are assigned by IETF review <xref target="RFC8126" )
format="default"/>. Each value should be tracked with the following Numbers" registry group. New values are assigned by IETF Review <xref ta
rget="RFC8126" format="default"/>. Each value should be tracked with the followi
ng
qualities: value, meaning, and defining RFC. The following values are qualities: value, meaning, and defining RFC. The following values are
defined in this document:</t> defined in this document:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
Value Meaning Reference <table>
0 Reserved This document <name>BPI Object Error Code Field Registry</name>
1 ASes does not match, BGP Session Failure This document <thead>
2 Peer IP can't be reached, BGP Session Failure This document <tr>
3-255 Unassigned This document <th>Value</th>
]]></artwork> <th>Meaning</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>Reserved</td>
<td>RFC 9757</td>
</tr>
<tr>
<td>1</td>
<td>ASes do not match - BGP Session Failure</td>
<td>RFC 9757</td>
</tr>
<tr>
<td>2</td>
<td>Peer IP can't be reached - BGP Session Failure</td>
<td>RFC 9757</td>
</tr>
<tr>
<td>3-255</td>
<td>Unassigned</td>
<td>RFC 9757</td>
</tr>
</tbody>
</table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>BPI Object Flag Field</name> <name>BPI Object Flag Field</name>
<t>IANA is requested to create a new sub-registry "BPI Object Flag <t>IANA has created the "BPI Object Flag Field" registry
Field" within the "Path Computation Element Protocol (PCEP) Numbers". within the "Path Computation Element Protocol (PCEP) Numbers" registry g
New values are to be assigned by IETF review <xref target="RFC8126" form roup.
at="default"/>. New values are to be assigned by IETF Review <xref target="RFC8126" form
at="default"/>.
Each bit should be tracked with the following qualities:</t> Each bit should be tracked with the following qualities:</t>
<ul empty="true" spacing="normal"> <ul spacing="normal">
<li> <li>
<t>bit number (counting from bit 0 as the most significant <t>bit number (counting from bit 0 as the most significant
bit)</t> bit)</t>
</li> </li>
<li> <li>
<t>capability description</t> <t>capability description</t>
</li> </li>
<li> <li>
<t>defining RFC</t> <t>defining RFC</t>
</li> </li>
</ul> </ul>
<t>The following values are defined in this document:</t> <t>The following values are defined in this document:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
Bit Meaning Reference <table>
0-6 Unassigned <name>BPI Object Flag Field Registry</name>
7 T (IPnIP) bit This document <thead>
]]></artwork> <tr>
<th>Bit</th>
<th>Meaning</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>0-6</td>
<td colspan="2">Unassigned</td>
</tr>
<tr>
<td>7</td>
<td>T (IP-in-IP) bit</td>
<td>RFC 9757</td>
</tr>
</tbody>
</table>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<name>Contributor</name>
<t>Dhruv Dhody has contributed to this document.</t>
</section>
<section numbered="true" toc="default">
<name>Acknowledgement</name>
<t>Thanks Mike Koldychev, Susan Hares, Siva Sivabalan and Adam Simpson
for their valuable suggestions and comments.</t>
</section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-pce-pcep-yang" to="YANG-PCEP"/> <displayreference target="I-D.ietf-pce-pcep-yang" to="YANG-PCEP"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 003.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 003.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4 271.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4 271.xml"/>
skipping to change at line 1537 skipping to change at line 1634
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 420.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 420.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 126.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 231.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 231.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 232.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 232.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 253.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 253.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 281.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 281.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 408.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 408.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 050.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 050.xml"/>
<!-- [rfced] [I-D.ietf-pce-iana-update] IESG state: I-D Exists as of 09/04/24; c
ompanion document RFC YYY1-->
<reference anchor="RFCYYY1" target="https://www.rfc-editor.org/info/rfcY
YY1">
<front>
<title>Update to the IANA PCEP Registration Procedures and Allowing E
xperimental Error Codes</title>
<author initials="D." surname="Dhody" fullname="Dhruv Dhody">
<organization>Huawei</organization>
</author>
<author initials="A." surname="Farrel" fullname="Adrian Farrel">
<organization>Old Dog Consulting</organization>
</author>
<date month="August" day="27" year="2024"/>
</front>
<seriesInfo name="RFC" value="YYY1"/>
<seriesInfo name="DOI" value="10.17487/RFCYYY1"/>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3 209.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3 209.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4 272.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4 272.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5 036.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5 036.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 942.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 177.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 177.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 283.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 283.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 735.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 735.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 821.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 821.xml"/>
<!-- [rfced] [I-D.ietf-pce-pcep-yang] IESG state: Publication requested as of 09
/04/24 -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D .ietf-pce-pcep-yang.xml"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D .ietf-pce-pcep-yang.xml"/>
</references> </references>
</references> </references>
<section numbered="false" toc="default">
<name>Acknowledgements</name>
<t>Thanks to <contact fullname="Mike Koldychev"/>, <contact fullname="Susa
n
Hares"/>, <contact fullname="Siva Sivabalan"/>, and <contact
fullname="Adam Simpson"/> for their valuable suggestions and
comments.</t>
</section>
<section numbered="false" toc="default">
<name>Contributors</name>
<t><contact fullname="Ren Tan"/> and <contact fullname="Dhruv Dhody"/> hav
e contributed to this document.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 185 change blocks. 
877 lines changed or deleted 1048 lines changed or added

This html diff was produced by rfcdiff 1.48.