<?xml version='1.0' encoding='UTF-8'?><!-- [rfced] pre-edited by ST 09/04/24 --><!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp"docName="draft-ietf-pce-pcep-extension-native-ip-39" number="0000"docName="draft-ietf-pce-pcep-extension-native-ip-40" number="9757" consensus="true" ipr="trust200902" sortRefs="true" submissionType="IETF" symRefs="true" tocInclude="true" obsoletes="" updates="" xml:lang="en" tocDepth="3" version="3"> <front> <title abbrev="PCEP for Native IP">Path Computation Element Communication Protocol (PCEP) Extensions for Native IP Networks</title> <seriesInfo name="RFC"value="0000"/>value="9757"/> <author fullname="Aijun Wang" initials="A" surname="Wang"> <organization>China Telecom</organization> <address> <postal> <street>Beiqijia Town, Changping District</street> <city>Beijing</city><region>Beijing</region><code>102209</code> <country>China</country> </postal> <email>wangaijun@tsinghua.org.cn</email> </address> </author> <author fullname="Boris Khasanov" initials="B" surname="Khasanov"> <organization abbrev="">MTS Web Services (MWS)</organization> <address> <postal> <street>Andropovaav.,18/9 115432</street>av., 18/9</street> <city>Moscow</city> <code>115432</code> <country>Russian Federation</country> </postal> <email>bhassanov@yahoo.com</email> </address> </author> <author fullname="Sheng Fang" initials="S" surname="Fang"> <organization abbrev="">Huawei Technologies</organization> <address> <postal> <street>Huawei Bld., No.156 Beiqing Rd.</street> <city>Beijing</city> <country>China</country> </postal> <email>fsheng@huawei.com</email> </address> </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"> <organization>ZTE Corporation</organization> <address> <postal> <street>50 Software Avenue, Yuhua District</street> <city>Nanjing</city> <region>Jiangsu</region> <code>210012</code> <country>China</country> </postal> <email>zhu.chun1@zte.com.cn</email> </address> </author> <datemonth="September" year="2024"/>month="February" year="2025"/> <area>RTG</area> <workgroup>pce</workgroup> <keyword>CCDR</keyword> <keyword>PCECC</keyword> <abstract> <t>This document introduces extensions to thePCEPath Computation Element Communication Protocol (PCEP) to support path computation in native IP networks through a PCE-based central control mechanism known as Centralized Control Dynamic Routing (CCDR). <!--[rfced] How may we clarify the latter part of this sentence? Original: These extensions empower a PCE to calculate and manage paths specifically for native IP networks, expand PCEP's capabilities beyond its traditional use in MPLS and GMPLS networks. Perhaps: These extensions empower a PCE to calculate and manage paths specifically for native IP networks, thereby expanding PCEP's capabilities beyond its traditional use in MPLS and GMPLS networks. --> These extensions empower a PCE to calculate and manage paths specifically for native IP networks, expand PCEP's capabilities beyond its traditional use in MPLS and GMPLS networks. By implementing these extensions, IP network resources can be utilized more efficiently, facilitating the deployment of traffic engineering in native IP environments.</t> </abstract> </front> <middle> <section anchor="intro" numbered="true" toc="default"> <name>Introduction</name> <t>Generally, Multiprotocol Label Switching Traffic Engineering (MPLS-TE) requires the corresponding network devices to support the Resource ReSerVation Protocol(RSVP)<xref(RSVP) <xref target="RFC3209"format="default"/>/Labelformat="default"/> and the Label Distribution Protocol(LDP)<xref(LDP) <xref target="RFC5036" format="default"/>protocolsto ensuretheEnd-to-End (E2E) traffic performance. But in native IP network scenarios described in <xref target="RFC8735" format="default"/>, there will be no such signaling protocol to synchronize the actions among different network devices. It is feasible to use the central control mode described in <xref target="RFC8283" format="default"/> to correlate the forwarding behavior among different network devices. <!--[rfced] To avoid awkward hyphenation, may we update the text below as follows? Original: [RFC8821] describes the architecture and solution philosophy for the E2E traffic assurance in the Native IP network via multiple Border Gateway Protocol (BGP) sessions-based solution. Perhaps: [RFC8821] describes the architecture and solution philosophy for the E2E traffic assurance in the Native IP network via a solution based on multiple Border Gateway Protocol (BGP) sessions. --> <xref target="RFC8821" format="default"/> describes the architecture and solution philosophy for the E2E traffic assurance in the Native IP network via multiple Border Gateway Protocol (BGP) sessions-based solution. It requires only the PCE to send the instructions to thePCCs,Path Computation Clients (PCCs) to build multiple BGP sessions, distribute different prefixes on the established BGPsessionssessions, and assign the different paths to the BGP next hops.</t> <t>This document describes the corresponding Path Computation Element Communication Protocol (PCEP) extensions to transfer the key information about the BGP peer, peer prefix advertisement, andtheexplicit peer route on on-path routers.</t> </section> <section numbered="true" toc="default"> <name>ConventionsusedUsed inthis document</name> <t>The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",This Document</name> <t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xreftarget="RFC2119" format="default"/>target="RFC2119"/> <xreftarget="RFC8174" format="default"/>target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> <section numbered="true" toc="default"> <name>Use of RBNF</name> <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 certain important details; the normative specification of messages is found in the prose description. If there is any divergence between the RBNF and the prose, the prose is considered authoritative.</t> </section> <section numbered="true" toc="default"> <name>Experimental Status Consideration</name> <t>The procedures outlined in this document are experimental. The experiment aims to explore the use of PCE (and PCEP) forend-to-endE2E traffic assurance in Native IP networks through multiple BGP sessions. Additional implementation is necessary to gain a deeper understanding of the operational impact, scalability, and stability of the mechanism described. <!-- [rfced] This sentence implies that the status of this document could change in the future. May we update the text to state that a new document would be published in order to update the status? Original: Feedback from deployments will be crucial in determining whether this specification should advance from Experimental to the IETF Standards Track. Perhaps: Feedback from deployments will be crucial in determining whether a future document will be published to advance this specification from Experimental to the IETF Standards Track. --> Feedback from deployments will be crucial in determining whether this specification should advance from Experimental to the IETF Standards Track.</t> </section> </section> <section numbered="true" toc="default"> <name>Terminology</name> <t>This document uses the following terms defined in <xref target="RFC5440" format="default"/>: PCC, PCE, and PCEP.</t><t>The<t>Additionally, the following terminology is used in this document:</t><ul spacing="normal"> <li> <t>BPI: BGP<dl spacing="normal" newline="false"> <dt>BPI:</dt><dd>BGP PeerInfo</t> </li> <li> <t>CCDR: CentralInfo</dd> <dt>CCDR:</dt><dd>Centralized Control DynamicRouting</t> </li> <li> <t>CCI: CentralRouting</dd> <dt>CCI:</dt><dd>Central ControllerInstructions, definedInstructions (defined in <xref target="RFC9050"format="default"/></t> </li> <li> <t>E2E: End-to-End</t> </li> <li> <t>EPR: Explicitformat="default"/>)</dd> <dt>E2E:</dt><dd>End-to-End</dd> <dt>EPR:</dt><dd>Explicit PeerRoute</t> </li> <li> <t>NativeRoute</dd> <dt>Native IPnetwork: Networknetwork:</dt><dd>Network that forwards traffic based solely on the IP address, instead ofotheranother indicator, forexample MPLS etc.</t> </li> <li> <t>PCECC: PCEexample, MPLS, etc.</dd> <dt>PCECC:</dt><dd>PCE as a CentralController, definedController (defined in <xref target="RFC8283"format="default"/></t> </li> <li> <t>PPA: Peerformat="default"/>)</dd> <dt>PPA:</dt><dd>Peer PrefixAdvertisement</t> </li> <li> <t>PST: PathAdvertisement</dd> <dt>PST:</dt><dd>Path SetupType, definedType (defined in <xref target="RFC8408"format="default"/></t> </li> <li> <t>SRP: Statefulformat="default"/>)</dd> <dt>SRP:</dt><dd>Stateful PCE RequestParameters, definedParameter (defined in <xref target="RFC8231"format="default"/></t> </li> <li> <t>RR: Route Reflector</t> </li> </ul>format="default"/>)</dd> <dt>RR:</dt><dd>Route Reflector</dd> </dl> </section> <section numbered="true" toc="default"> <name>Capability Advertisement</name> <section numbered="true" toc="default"> <name>Open Message</name> <t>During the PCEP Initialization Phase, PCEP Speakers (PCE or PCC) advertise their support of Native IP extensions.</t> <t>This document defines a new Path Setup Type (PST) <xref target="RFC8408" format="default"/> for Native-IP, as follows: </t> <ul spacing="normal"><li> <t>PST<li>PST = 4: Path is a Native IP TE path as per <xref target="RFC8821"format="default"/>.</t> </li>format="default"/>.</li> </ul> <t>A PCEP speakerMUST<bcp14>MUST</bcp14> indicate its support of the function described 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> <!--[rfced] Does "their" refer to "PCECC-CAPABILITY sub-TLV"? If yes, may we update "their" to "its" for clarity? Original: [RFC9050] defined the PCECC-CAPABILITY sub-TLV to exchange information about their PCECC capability. Perhaps: [RFC9050] defined the PCECC-CAPABILITY sub-TLV to exchange information about its PCECC capability. --> <t><xref target="RFC9050" format="default"/> defined the PCECC-CAPABILITY sub-TLV to exchange information about their PCECC capability. A new flag 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 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 PCEMUST<bcp14>MUST</bcp14> set this flag to support this extension.</t> <t>If a PCEP speaker receives the PATH-SETUP-TYPE-CAPABILITY TLV with the newly definedpath setup type,PST, but without the N bit set in PCECC-CAPABILITY sub-TLV, itMUST:</t><bcp14>MUST</bcp14>:</t> <ul spacing="normal"> <li> <t>send a PCErr message with Error-Type=10 (Reception of an invalid object) and Error-Value=39 (PCECC NATIVE-IP-TE-CAPABILITY bit is notset).</t>set) and</t> </li> <li> <t>terminate the PCEPsession</t>session.</t> </li> </ul> <t>If a PCEP speaker receives the PATH-SETUP-TYPE-CAPABILITY TLV with the newly definedpath setup type,PST, but without the PCECC-CAPABILITY sub-TLV, itMUST:</t><bcp14>MUST</bcp14>:</t> <ul spacing="normal"> <li> <t>send a PCErr message withError-Type=10(ReceptionError-Type=10 (Reception of an invalid object) and Error-Value=33 (Missing PCECC Capabilitysub-TLV).</t>sub-TLV) and</t> </li> <li> <t>terminate the PCEPsession</t>session.</t> </li> </ul> <t>If one or both speakers (PCE and PCC) have not indicated the support for Native-IP, the PCEP extensions for the Native-IPMUST NOT<bcp14>MUST NOT</bcp14> be used. If a Native-IP operation is attempted when both speakers have not agreed on the OPEN messages, the receiver of the messageMUST:</t><bcp14>MUST</bcp14>:</t> <ul spacing="normal"> <li> <t>send a PCErr message with Error-Type=19 (Invalid Operation) andError-value=TBD1Error-value=29 (Attempted Native-IP operations when the capability was not advertised) and</t> </li> <li> <t>terminate the PCEP session.</t> </li> </ul> </section> </section> <section toc="default" numbered="true"> <name>PCEP Messages</name><t>PCECC<!--[rfced] To improve readability, may we update this sentence as follows? Please review and ensure that the suggested text does not alter the intended meaning. Original: The PCECC Native IP TE solution uses the existing PCE Label Switched Path (LSP) Initiate Request message (PCInitiate) [RFC8281], and PCE Report message (PCRpt) [RFC8231] to accomplish the multiple BGP sessions establishment, E2E Native-IP TE path deployment, and route prefixes advertisement among different BGP sessions. Perhaps: The PCECC Native IP TE solution uses the existing PCE Label Switched Path (LSP) Initiate Request message (PCInitiate) [RFC8281] and PCE Report message (PCRpt) [RFC8231] to establish multiple BGP sessions, deploy the E2E Native-IP TE path, and advertise route prefixes among different BGP sessions. --> <t>The PCECC Native IP TE solution uses the existing PCE Label Switched Path (LSP) Initiate Request message (PCInitiate) <xref target="RFC8281" format="default"/>, and PCE Report message (PCRpt) <xref target="RFC8231" format="default"/> to accomplish the multiple BGP sessions establishment, E2E Native-IP TE path deployment, and route prefixes advertisement 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> <t>The extended PCInitiate message described in <xref target="RFC9050" format="default"/> is used to download or remove thecentral controller's instructions (CCIs).Central Controller Instructions (CCI). <xref target="RFC9050" format="default"/> specifies an object called CCI for the encoding of the central controller's instructions. This document 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. Three new PCEP Objects (BGP Peer Info(BPI) Object,(BPI), Explicit Peer Route(EPR) Object,(EPR), and Peer Prefix Advertisement(PPA) Object)(PPA)) are defined in this document. Refer to <xref target="Obj-Def-Sec" format="default"/> for detailed object definitions. All PCEP procedures specified in <xref target="RFC9050" format="default"/> continue to apply unless specified otherwise.</t> <section anchor="SEC_PCInitiate" toc="default" numbered="true"> <name>The PCInitiate Message</name> <t>The PCInitiate Message defined in <xref target="RFC8281" format="default"/> and extended in <xref target="RFC9050" format="default"/> is further extended to support Native-IP CCI.</t> <t>The format of the extended PCInitiate message is as follows: </t><artwork<!-- [rfced] Please review the "type" attribute of each sourcecode element in the XML file to ensure correctness. If the current list of preferred values for "type" (https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types) does not contain an applicable type, then feel free to let us know. Also, it is acceptable to leave the "type" attribute not set. --> <sourcecode name=""type="" align="left" alt=""><![CDATA[type="rbnf"><![CDATA[ <PCInitiate Message> ::= <Common Header> <PCE-initiated-lsp-list>Where:]]></sourcecode> <t>Where:</t> <sourcecode name="" type="rbnf"><![CDATA[ <Common Header> is defined in[RFC5440]RFC 5440 <PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request> [<PCE-initiated-lsp-list>] <PCE-initiated-lsp-request> ::= (<PCE-initiated-lsp-instantiation>| <PCE-initiated-lsp-deletion>| <PCE-initiated-lsp-central-control>) <PCE-initiated-lsp-central-control> ::= <SRP> <LSP> <cci-list> <cci-list> ::= <CCI> [<BPI>|<EPR>|<PPA>] [<cci-list>]]]></artwork> <t>Where: </t>]]></sourcecode> <t>Where:</t> <ulempty="true"spacing="normal"> <li> <t><PCE-initiated-lsp-instantiation> and <PCE-initiated-lsp-deletion> are as per[RFC8281].</t><xref target="RFC8281"/>.</t> </li> <li> <t>The LSP and SRP objects are defined in[RFC8231].</t><xref target="RFC8231"/>.</t> </li> </ul> <t>When the PCInitiate message is used for Native IP instructions,i.e. Wheni.e., when the CCI Object-Type is 2, the SRP,LSPLSP, and CCI objectsMUST<bcp14>MUST</bcp14> be present. Error handling for missing SRP,LSPLSP, or CCI objectsMUST<bcp14>MUST</bcp14> be performed as specified in <xref target="RFC9050" format="default"/>. Additionally, exactly one object among the BPI, EPR, or PPA objectsMUST<bcp14>MUST</bcp14> be present. ThePLSP-IDPCEP-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="RFC8281" format="default"/>, and <xref target="RFC9050" format="default"/>. The Symbolic Path Name is used by the PCE/PCC to uniquely identify the E2E native IP TE path. The related Native-IP instructions with BPI,EPREPR, or PPA objects are identified by the same Symbolic Path Name.</t> <t>If none of the BPI,EPREPR, or PPA objects are present, the receiving PCCMUST<bcp14>MUST</bcp14> send a PCErr message with Error-type=6 (Mandatory Object missing) and Error-value=19 (Native IP object missing). <!--[rfced] May we make the following sentences more concise by removing "instance of"? Please review the suggested text and let us know if this change alters the intended meaning. Original: If there is more than one instance of BPI, EPR or PPA object present, the receiving PCC MUST send a PCErr message with Error-type=19 (Invalid Operation) and Error-value=22 (Only one BPI, EPR or PPA object can be included in this message). ... If there are more than one instance of BPI, EPR or PPA objects present, the receiving PCE MUST send a PCErr message with Error-type=19 (Invalid Operation) and Error-value=22 (Only one BPI, EPR or PPA object can be included in this message). Perhaps: If there is more than one BPI, EPR, or PPA object present, the receiving PCC MUST send a PCErr message with Error-type=19 (Invalid Operation) and Error-value=22 (Only one BPI, EPR, or PPA object can be included in this message). ... If there is more than one BPI, EPR, or PPA object present, the receiving PCE MUST send a PCErr message with Error-type=19 (Invalid Operation) and Error-value=22 (Only one BPI, EPR, or PPA object can be included in this message). --> If there is more than one instance of BPI, EPR, or PPA object present, the receiving PCC <bcp14>MUST</bcp14> send a PCErr message with Error-type=19 (Invalid Operation) and Error-value=22 (Only one BPI, EPR, or PPA object can be included in this message).</t> <t>When the PCInitiate message is not used for Native IP instructions,i.e. Wheni.e., when the CCI Object-Type is not equal to 2, the BPI,EPREPR, and PPA objectsSHOULD NOT<bcp14>SHOULD NOT</bcp14> be present. If present, theyMUST<bcp14>MUST</bcp14> be ignored by the receiver.</t> <t>To clean up the existing Native IP instructions, the SRP objectMUST<bcp14>MUST</bcp14> set the R (remove) bit.</t> </section> <section anchor="SEC_PCRpt" toc="default" numbered="true"> <name>The PCRpt Message</name> <t>The PCRpt message is used to acknowledge the Native-IP instructions received from the central controller (PCE) as well as during the State Synchronization phase.</t> <t>The format of the PCRpt message is as follows: </t><artwork<sourcecode name=""type="" align="left" alt=""><![CDATA[type="rbnf"><![CDATA[ <PCRpt Message> ::= <Common Header> <state-report-list>Where:]]></sourcecode> <t>Where:</t> <sourcecode name="" type="rbnf"><![CDATA[ <state-report-list> ::= <state-report>[<state-report-list>] <state-report> ::= (<lsp-state-report>| <central-control-report>) <lsp-state-report> ::= [<SRP>] <LSP> <path> <central-control-report> ::= [<SRP>] <LSP> <cci-list> <cci-list> ::= <CCI> [<BPI>|<EPR>|<PPA>] [<cci-list>]]]></artwork>]]></sourcecode> <t>Where:</t> <ulempty="true"spacing="normal"><li> <t>Where: <path><li><path> is as per[RFC8231] and the<xref target="RFC8231"/>.</li> <li>The LSP and SRP objects are also defined in[RFC8231].</t> </li><xref target="RFC8231"/>.</li> </ul> <!--[rfced] To avoid the repetition of "object", may we update the sentence below? Original: Furthermore, one, and only one, object among BPI, EPR or PPA object MUST be present. Perhaps: Furthermore, one and only one BPI, EPR, or PPA object MUST be present. --> <t>The error handling for missing CCI objects is as per <xref target="RFC9050" format="default"/>. Furthermore, one, and only one, object among BPI, EPR or PPA objectMUST<bcp14>MUST</bcp14> be present.</t> <t>If none of the BPI,EPREPR, or PPA objects are present, the receiving PCEMUST<bcp14>MUST</bcp14> send a PCErr message with Error-type=6 (Mandatory Object missing) and Error-value=19 (Native IP object missing). If there are more than one instance of BPI, EPR or PPA objects present, the receiving PCEMUST<bcp14>MUST</bcp14> send a PCErr message with Error-type=19 (Invalid Operation) and Error-value=22 (Only one BPI,EPREPR, or PPA object can be included in this message).</t> <t>When the PCInitiate message is not used for Native IP instructions,i.e. Wheni.e., when the CCI Object-Type is not equal to 2, the BPI,EPREPR, and PPA objectsSHOULD NOT<bcp14>SHOULD NOT</bcp14> be present. If present, theyMUST<bcp14>MUST</bcp14> be ignored by the receiver.</t> </section> </section> <section numbered="true" toc="default"> <name>PCECC Native IP TE Procedures</name> <t>The detailed procedures for the TE in the native IP environment are described in the following sections.</t> <section anchor="BGPSess" numbered="true" toc="default"> <name>BGP Session Establishment Procedures</name> <t>The PCInitiate and PCRpt message pair is used to exchange the configuration parameters for a BGP peer session. This pair of PCEP messages are exchanged between a PCE and each BGP peer (acting asPCC)the PCC), which needs to establish a BGP session. After the BGP peer session has been initiated via this pair of PCEP messages, the BGP session establishes and operates in a normal fashion. The BGP peers can be used for External BGP (EBGP) peers or Internal BGP (IBGP) peers. For IBGP connection topologies, the Route Reflector (RR) is required.</t> <t>The PCInitiate message is sent to the BGP router and/or RR (which are acting as the PCC).</t> <t>The RR topology for a single Autonomous System (AS) is shown inFigure 1.<xref target="fig-1"/>. The BGP routers R1, R3, and R7 are within a single AS. R1 and R7 are BGP RR clients, and R3 isaan RR. The PCInitiate message is sent to the BGP routers R1,R3R3, andR7 thatR7, which need to establish a BGP session.</t> <t>PCInitiate message creates anauto-configurationautoconfiguration function for these BGP peers by providing the indicated Peer AS and the Local/Peer IP Address.</t> <t>When the PCC receives the BPI and CCIobjectobjects (with the R bit set to 0 in the SRP object) in the PCInitiate message, the PCCSHOULD<bcp14>SHOULD</bcp14> try to establish the BGP session with the indicated Peer as per the AS and Local/Peer IP address.</t> <t>During the establishment procedure, the PCCMUST<bcp14>MUST</bcp14> reportto the PCEthe 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 corresponding SRP and CCI objects included.</t> <t>When the PCC receives this message with the R bit set to 1 in the SRP object in the PCInitiate message, the PCCMUST<bcp14>MUST</bcp14> clear the BGP configuration and tear down the BGP session that is indicated by the BPI object.</t> <t>When the PCCclearssuccessfully clears the specified BGP session configuration, itMUST<bcp14>MUST</bcp14> report the result via the PCRpt message, with the BPI objectincluded,and the corresponding SRP and CCIobjects.</t>objects included.</t> <figure anchor="fig-1"> <name>BGP Session Establishment Procedures (R3 acts as the RR)</name> <artwork name="" type=""align="left"align="center" alt=""><![CDATA[ +------------------+ +-----------> PCE <----------+ | +--------^---------+ | | | | | PCInitiate/PCRpt | | | | | +----v--+ | +---------------+ R3(RR)+-----------------+ | +-------+ | PCInitiate/PCRpt PCInitiate/PCRpt | | +v-+ +--+ +--+ +-v+ |R1+----------+R5+----------+R6+---------+R7| ++-+ +-++ +--+ +-++ | | | | +--+ +--+ | +------------+R2+----------+R4+-----------+ +--+ +--+Figure 1: BGP Session Establishment Procedures(R3 act as RR)]]></artwork><t/></figure> <t>The message peers, messagetype,types, message keyparametersparameters, and procedures in the abovefiguresfigure are shown below:</t> <figure anchor="fig-2"> <name>Message Information and Procedures</name> <artwork name="" type=""align="left"align="center" alt=""><![CDATA[ +-------+ +-------+ |PCC | | PCE | |R1 | +-------+ +------| | | | PCC +-------+ | | R3 | | (For R1/R3 BGP Session on R1) | +------| | |<-PCInitiate,CC-ID=X,Symbolic Path Name=Class A-| | | | |BPI Object(Peer AS, Local_IP=R1_A, Peer_IP=R3_A)| |PCC +--------+ | | |R7 | | |----PCRpt,CC-ID=X(Symbolic Path Name=Class A)-->| | | | |BPI Object(Peer AS, Local_IP=R1_A, Peer_IP=R3_A)| +--------+ | | | | (For R1/R3 BGP Session on R3) | | |<--PCInitiate,CC-ID=Y1,Symbolic Path Name=Class A-----| | | BPI Object(Peer AS, Local_IP=R3_A, Peer_IP=R1_A)| | |---PCRpt,CC-ID=Y1,Symbolic Path Name=Class A--------->| | | BPI Object(Peer AS, Local_IP=R3_A, Peer_IP=R1_A)| | | | | | (For R3/R7 BGP Session on R3) | | |<--PCInitiate,CC-ID=Y2,Symbolic Path Name=Class A-----| | | BPI Object(Peer AS, Local_IP=R3_A, Peer_IP=R7_A) | | |----PCRpt,CC-ID=Y2,Symbolic Path Name=Class A-------->| | | BPI Object(Peer AS, Local_IP=R3_A, Peer_IP=R7_A) | | | | (For R3/R7 BGP Session on R7) | |<--PCInitiate,CC-ID=Z,Symbolic Path Name=Class A--------------| | BPI Object(Peer AS, Local_IP=R7_A, Peer_IP=R3_A) | |---PCRpt,CC-ID=Z,Symbolic Path Name=Class A------------------>| | BPI Object(Peer AS, Local_IP=R7_A, Peer_IP=R3_A) |Figure 2: Message Information and Procedures]]></artwork> </figure> <t>The Local/Peer IP addressMUST<bcp14>MUST</bcp14> be dedicated to the usage of the native IP TEsolution,solution andMUST NOT<bcp14>MUST NOT</bcp14> be used by other BGP sessions that 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 sessions, the PCCMUST<bcp14>MUST</bcp14> report such an error situation via a PCErr message with:</t> <ulempty="true"spacing="normal"> <li> <t>Error-type=33 (Native IP TE failure) and Error-value=1 (Local IP is inuse),use) or</t> </li> <li> <t>Error-type=33 (Native IP TEfailure )andfailure) and Error-value=2 (Remote IP is in use).</t> </li><li></ul> <t>The detailed Error-Types and Error-Values are defined in <xref target="NewErrorTypeAndValue"format="default"/></t> </li> </ul>format="default"/>.</t> <t>If the established BGP session is broken, the PCCMUST<bcp14>MUST</bcp14> report such information via a PCRpt message with the status field set to "BGP session down" in the associated BPI Object. The error code field within the BPI objectSHOULD<bcp14>SHOULD</bcp14> indicate the reason that leads to the BGP session being down. In the future, when the BGP session is up again, the PCCMUST<bcp14>MUST</bcp14> report that as well via the PCRpt message with the status field set to "BGP Session Established".</t> </section> <section anchor="BGPEx" numbered="true" toc="default"> <name>Explicit Route Establishment Procedures</name> <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 pair. Such explicit routes operate the same as static routes installed by network management protocols(Network(e.g., Network Configuration Protocol(NETCONF)/YANG).(NETCONF) / YANG). The procedures of such explicit route addition and removalMUST<bcp14>MUST</bcp14> be controlled by the PCE in a specific order so that the pathways are established without loops.</t> <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, for the explicit route from R1 to R7, the PCInitiate message is sent to R1,R2R2, and R4, as shown inFigure 3.<xref target="fig-3"/>. For the explicit route from R7 to R1, the PCInitiate message is sent to R7,R4R4, and R2, as shown inFigure 5.</t><xref target="fig-5"/>.</t> <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 PCCSHOULD<bcp14>SHOULD</bcp14> install the explicit route to the peer in the RIB/FIB.</t> <t>When the PCCinstallssuccessfully installs the explicit route to the peer, itMUST<bcp14>MUST</bcp14> report the result via the PCRptmessages,message, with the EPR object 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 to 1 in the SRP object in the PCInitiate message, the PCCMUST<bcp14>MUST</bcp14> remove the explicit route to the peer that is indicated by the EPR object.</t> <t>When the PCC has removed the explicit route that is indicated by this object, itMUST<bcp14>MUST</bcp14> report the result via the PCRpt message, with the EPR objectincluded,and the corresponding SRP and CCIobject.</t>objects included.</t> <figure anchor="fig-3"> <name>Explicit Route Establish Procedures (from R1 to R7)</name> <artwork name="" type=""align="left"align="center" alt=""><![CDATA[ +------------------+ +----------> PCE + | +----^-----------^-+ | | | | | | | | +------+ | +---------------|-+R3(RR)+--|-------------+ PCInitiate/PCRpt | +------+ | | | | | | +v-+ +--+ | | +--+ +--+ |R1+------+R5+---+-----------|---+R6+----+R7| ++-+ +--+ | | +--+ +-++ | PCInitiate/PCRpt PCInitiate/PCRpt | | | | | | +--v--+ +--v-+ | +------------+- R2 +-----+ R4 +-----------+ +--+--+ +--+-+Figure 3: Explicit Route Establish Procedures(From R1 to R7)]]></artwork> </figure> <t>The message peers, messagetype,types, message keyparametersparameters, and procedures in the abovefiguresfigure are shown below:</t> <figure anchor="fig-4"> <name>Message Information and Procedures</name> <artwork name="" type=""align="left"align="center" alt=""><![CDATA[ +-------+ +-------+ |PCC | | PCE | |R4 | +-------+ +------| | | | PCC +-------+ | | R2 | | (EPR route on R4) | +------| | |<-PCInitiate,CC-ID=Z,Symbolic Path Name=Class A| | | | | EPR Object(Peer Address=R7_A, Next Hop=R7_A)| |PCC +--------+ | | |R1 | | |----PCRpt,CC-ID=Z,Symbolic Path Name=Class A-->| | | | | EPR Object(Peer Address=R7_A, Next Hop=R7_A)| +--------+ | | | | (EPR route on R2) | | |<--PCInitiate,CC-ID=Y,Symbolic Path Name=Class A-----| | | EPR Object(Peer Address=R7_A, Next Hop=R4_A) | | |----PCRpt,CC-ID=Y,Symbolic Path Name=Class A-------->| | | EPR Object(Peer Address=R7_A, Next Hop=R4_A) | | | | | | | (EPR route on R1) | |<--PCInitiate,CC-ID=X,Symbolic Path Name=Class A-------------| | EPR Object(Peer Address=R7_A, Next Hop=R2_A) | |---PCRpt,CC-ID=X1(Symbolic Path Name=Class A)--------------->| | EPR Object(Peer Address=R7_A, Next Hop=R2_A) |Figure 4: Message Information and Procedures]]></artwork> </figure> <figure anchor="fig-5"> <name>Explicit Route Establish Procedures (from R7 to R1)</name> <artwork name="" type=""align="left"align="center" alt=""><![CDATA[ +------------------+ + PCE <-----------+ +----^-----------^-+ | | | | | | | | +------+ | | +-----------------+R3(RR)+--|-------------+ | | +------+ | PCInitiate/PCRpt | | | | +--+ +--+ | | +--+ +-v+ |R1+------+R5+---+-----------|---+R6+----+R7| ++-+ +--+ | | +--+ +-++ | PCInitiate/PCRpt PCInitiate/PCRpt | | | | | | +--v--+ +--v-+ | +------------+- R2 +-----+ R4 +-----------+ +--+--+ +--+-+Figure 5: Explicit Route Establish Procedures(From R7 to R1)]]></artwork> </figure> <t>The message peers, messagetype,types, message keyparametersparameters, and procedures in the abovefiguresfigure are shown below:</t> <figure anchor="fig-6"> <name>Explicit Route Establish Procedures (from R7 to R1)</name> <artwork name="" type=""align="left"align="center" alt=""><![CDATA[ +-------+ +-------+ |PCC | | PCE | |R2 | +-------+ +------| | | | PCC +-------+ | | R4 | | (EPR route on R2) | +------| | |<-PCInitiate,CC-ID=X,Symbolic Path Name=Class A| | | | | EPR Object(Peer Address=R1_A, Next Hop=R1_A) | |PCC +--------+ | | |R7 | | |----PCRpt,CC-ID=X,Symbolic Path Name=Class A-->| | | | | EPR Object(Peer Address=R1_A, Next Hop=R1_A) | +--------+ | | | | (EPR route on R4) | | |<--PCInitiate,CC-ID=Y,Symbolic Path Name=Class A-----| | | EPR Object(Peer Address=R1_A, Next Hop=R2_A) | | |----PCRpt,CC-ID=Y,Symbolic Path Name=Class A-------->| | | EPR Object(Peer Address=R1_A, Next Hop=R2_A) | | | | | | | (EPR route on R7) | |<--PCInitiate,CC-ID=Z,Symbolic Path Name=Class A-------------| | EPR Object(Peer Address=R1_A, Next Hop=R4_A) | |---PCRpt,CC-ID=Z,Symbolic Path Name=Class A----------------->| | EPR Object(Peer Address=R1_A, Next Hop=R4_A) |Figure 6: Explicit Route Establish Procedures(From R7 to R1)]]></artwork> </figure> <t>To avoid the transient loop while deploying the explicit peer route, the EPR objectMUST<bcp14>MUST</bcp14> be sent to the PCCs in the reverse order of the E2E path. To remove the explicit peer route, the EPR objectMUST<bcp14>MUST</bcp14> 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 objects to the same node, with the same route priority and peer address value but a different next-hop address.</t> <t>The PCCMUST<bcp14>MUST</bcp14> verify that thenext hopnext-hop address is reachable. In case of failure, the PCCMUST<bcp14>MUST</bcp14> send the corresponding error via a PCErr message, with the error information: Error-type=33 (Native IP TEfailure),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 indicated in the BPI object in the PCC for the same path that is identified by Symbolic Path Name TLV, a PCErr messageMUST<bcp14>MUST</bcp14> be reported, with the errorinformation:information Error-type=33 (Native IP TEfailure), Error-value=4, EPR/BPIfailure) and Error-value=4 (EPR/BPI Peer InfoMismatch.mismatch). Note that the same error can be used in case no BPI is received at the PCC.</t> <t>If the PCE needs to update the path, itMUST<bcp14>MUST</bcp14> first instruct the new CCI with the updated EPR corresponding to the new next hop to use and then instruct the removal of the older CCI.</t> </section> <section anchor="BGPPrefix" numbered="true" toc="default"> <name>BGP Prefix Advertisement Procedures</name> <t>The detailed procedures for BGP prefix advertisement are shown below, using the PCInitiate and PCRpt message pair.</t> <t>The PCInitiate messageSHOULD<bcp14>SHOULD</bcp14> be sent to the PCC that acts as a BGP peer edge router only. In the example, it is sent to R1 andR7R7, respectively.</t> <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 PCCSHOULD<bcp14>SHOULD</bcp14> send the prefixes indicated in this object to the identified BGP peer via the corresponding BGP session <xref target="RFC4271" format="default"/>.</t> <t>When the PCC has successfully sent the prefixes to the appointed BGP peer, itMUST<bcp14>MUST</bcp14> report the result via the PCRpt messages, with the 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 to 1 in the SRP object in the PCInitiate message, the PCCMUST<bcp14>MUST</bcp14> withdraw theprefixesprefix advertisement to the peer indicated by this object.</t> <t>When the PCCwithdrawssuccessfully withdraws the prefixes that are indicated by this object, itMUST<bcp14>MUST</bcp14> report the result via the PCRpt message, with the PPA objectincluded,and the corresponding SRP and CCIobjects.</t>objects included.</t> <figure anchor="fig-7"> <name>BGP Prefix Advertisement Procedures</name> <artwork name="" type=""align="left"align="center" alt=""><![CDATA[ +------------------+ +----------> PCE <-----------+ | +------------------+ | | +--+ | +------------------+R3+-------------------+ PCInitiate/PCRpt +--+ PCInitiate/PCRpt | | +v-+ +--+ +--+ +-v+ |R1+----------+R5+----------+R6+---------+R7| ++-+ +--+ +--+ +-++ (BGP Router) (BGP Router) | | | | | +--+ +--+ | +------------+R2+----------+R4+-----------+ +--+ +--+Figure 7: BGP Prefix Advertisement Procedures]]></artwork> </figure> <t>The message peers, messagetype,types, message keyparametersparameters, and procedures in the abovefiguresfigure are shown below:</t> <figure anchor="fig-8"> <name>Message Information and Procedures</name> <artwork name="" type=""align="left"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) | | |Figure 8: Message Information and Procedures]]></artwork> </figure> <t>The AFI/SAFI for the corresponding BGP sessionSHOULD<bcp14>SHOULD</bcp14> match the Peer Prefix Advertisement Object-Type, i.e., AFI/SAFISHOULD<bcp14>SHOULD</bcp14> be 1/1 for the IPv4 prefix and 2/1 for the IPv6 prefix. In case of mismatch, anerror:error, i.e., Error-type=33 (Native IP TEfailure),failure) and Error-value=5 (BPI/PPAaddress family mismatch) MUSTAddress Family mismatch), <bcp14>MUST</bcp14> be reported via the PCErr message.</t> <t>When the peer info is not the same as the peer info that is indicated in the BPI object in the PCC for the same path that is identified by Symbolic Path Name TLV, anerror:error, i.e., Error-type=33 (Native IP TEfailure),failure) and Error-value=6 (PPA/BPIpeer info mismatch) MUSTPeer Info mismatch), <bcp14>MUST</bcp14> be reported via the PCErr message. Note that the same error can be used in case no BPI is received at the PCC.</t> </section> <section numbered="true" toc="default"> <name>Selection of the Raw Mode and Tunnel Mode Forwarding Strategy</name> <t>Normally, when the above procedures are finished, the user traffic will be forwarded via the appointed path, but the forwarding will be based solely on the destination of user traffic. <!--[rfced] How may we clarify "to the same destination"? Original: If there is traffic from different attached points to the same destination coming into the network, they could share the priority path which may not be the initial desire. Perhaps: If traffic is coming into the network from different attached points but to the same destination, they could share the priority path, which may not be the initial desire. --> If there is traffic from different attached points to the same destination coming into the network, they could share the priority path, which may not be the initial desire. For example, as illustrated inFigure 1,<xref target="fig-1"/>, the initial aim is to ensuretrafficthat traffic enters the network via R1 and exits the network at R7 via R5-R6-R7. If some traffic enters the network via the R2 router, passes throughR5R5, and exits at R7, they may share the 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 mode forwarding strategy. Such a mode canachieveonly achieve the moderate traffic path control effect. To achieve the strict traffic path control effect, the entry pointMUST<bcp14>MUST</bcp14> tunnel the user traffic from the 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"/>. <!--[rfced] We don't see the term "IPinIP" in RFC 2003. Should this be updated as "IP in IP"? Note that other RFCs generally use "IP-in-IP" when referring to tunnels. We also see "IPnIP" in Table 8 - is this term the same as "IPinIP" or different? Please let us know if/how these terms may be updated for consistency. Original: Section 6.4 For simplicity, the IPinIP tunnel type [RFC2003] is used between the BGP peers by default. Section 7.2 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). Table 8 7 | T (IPnIP) bit | --> 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> <t>The selection of Raw mode and Tunnel mode forwarding strategies are controlled via the"T"T bit in the BPIObject thatObject, which is defined in <xref target="BPI_Object" format="default"/></t> </section> <section numbered="true" toc="default"><name>Clean Up</name> <t>To<name>Cleanup</name> <!--[rfced] Per use elsewhere throughout the document, should "R flag" be updated to "R bit"? Original: To remove the Native-IP state from the PCC, the PCE MUST send explicit CCI cleanup instructions for PPA, EPR and BPI objects respectively with the R flag set in the SRP object. Perhaps: To remove the Native-IP state from the PCC, the PCE MUST send explicit CCI cleanup instructions for PPA, EPR, and BPI objects, respectively, with the R bit set in the SRP object. --> <t>To remove the Native-IP state from the PCC, the PCE <bcp14>MUST</bcp14> send explicit CCI cleanup instructions for PPA, EPR, and BPI objects, respectively, with the R flag set in the SRP object. If the PCC receives a PCInitiate message but does not recognize the Native-IP information in the CCI, the PCCMUST<bcp14>MUST</bcp14> generate a PCErr message with Error-Type=19 (Invalidoperation)Operation) andError-value=TBD2Error-value=30 (Unknown Native-IP Info) andMUST<bcp14>MUST</bcp14> include the SRP object to specify the error is for the corresponding cleanup (via a PCInitiate message).</t> </section> <section numbered="true" toc="default"> <name>Other Procedures</name> <t>The handling of the state synchronization, redundant PCEs,re-delegationredelegation, andclean upcleanup is the same as other CCIs as specified in <xref target="RFC9050" format="default"/>.</t> </section> </section> <section anchor="Obj-Def-Sec" numbered="true" toc="default"> <name>New PCEP Objects</name> <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" format="default"/>.</t> <section anchor="CCI" numbered="true" toc="default"> <name>CCI Object</name> <t>The Central Control Instructions (CCI) Object (defined in <xref target="RFC9050" format="default"/>) is used by the PCE to specify the forwarding instructions. This document defines another object type for Native-IP procedures.</t><t>CCI<t>The CCI Object-Type is 2 forNative-IPNative-IP, asbelow:follows: </t> <figure anchor="fig-9"> <name>CCI Object for Native IP</name> <artwork name="" type=""align="left"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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CC-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags | +---------------------------------------------------------------+ | | // Optional TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 9: CCI Object for Native IP]]></artwork>]]></artwork> </figure> <t>ThefieldCC-ID field is as described in <xref target="RFC9050" format="default"/>. The following fields are defined for CCI Object-Type2 </t>2.</t> <dl newline="false" spacing="normal"> <dt>Reserved:</dt> <dd>2bytes, is setbytes. Set to zero while sending and ignored on receipt.</dd> <dt>Flags:</dt> <dd>2bytes, is usedbytes. Used to carry any additional information about the Native-IP CCI. Currently, no flag bits are defined. Unassigned flags are set to zero while sending and ignored on receipt.</dd> </dl> <t>Optional TLVs may be included within the CCI object body. The Symbolic Path Name TLV <xref target="RFC8231" format="default"/>MUST<bcp14>MUST</bcp14> be included in the CCI Object-Type 2 to identify the E2E TE path in the Native IP environment.</t> </section> <section anchor="BPI_Object" numbered="true" toc="default"> <name>BGP Peer Info Object</name> <t>The BGP Peer Info (BPI) object is used to specify the information about the peer with which the PCCwantwants to establish the BGP session. This 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 RR is used between the source and destination routers, then such information is sent to the source router,RRRR, and destinationrouterrouter, respectively.</t> <t>By default, the Local/Peer IP addressMUST<bcp14>MUST</bcp14> be a unicast address and dedicated to the usage of the native IP TEsolution,solution andMUST NOT<bcp14>MUST NOT</bcp14> be used by other BGP sessions that are established by manual or other configuration mechanisms.</t><t>BGP<t>The BGP Peer Info Object-Class is46</t> <t>BGP46.</t> <t>The BGP Peer Info Object-Type is 1 for IPv4 and 2 forIPv6</t>IPv6.</t> <t>The format of the BGP Peer Info object body for IPv4 (Object-Type=1) is as follows:</t> <figure anchor="fig-10"> <name>BGP Peer Info Object Body Format for IPv4</name> <artwork name="" type=""align="left"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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer AS Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ETTL | Status | Error Code | Flag |T| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Optional TLVs // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 10: BGP Peer Info Object Body Format for IPv4]]></artwork><t/></figure> <t>The format of the BGP Peer Info object body for IPv6 (Object-Type=2) is as follows:</t> <figure anchor="fig-11"> <name>BGP Peer Info Object Body Format for IPv6</name> <artwork name="" type=""align="left"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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer AS Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ETTL | Status | Error Code | Flag |T| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Local IP Address (16 bytes) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Peer IP Address (16 bytes) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Optional TLVs // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 11: BGP Peer Info Object Body Format for IPv6]]></artwork><ul empty="true" spacing="normal"> <li> <t>Peer</figure> <dl spacing="normal" newline="false"> <dt>Peer ASNumber: 4 bytes, to indicateNumber:</dt><dd>4 bytes. Indicates the AS number of the Remote Peer. Note that if 2-byte AS numbers are in use, the low-order bits (16 through 31)isare used, and the high-order bits (0 through 15)isare set tozero.</t> </li> <li> <t>ETTL: 1 byte,zero.</dd> <dt>ETTL:</dt><dd>1 byte. EBGP Time ToLive, to indicateLive. Indicates the multi-hop count for the EBGP session. It should be 0 and ignored when Local AS and Peer AS are thesame.</t> </li> <li> <t>Status: 1 byte, Indicatesame.</dd> <dt>Status:</dt><dd><t>1 byte. Indicates the BGP session status between the peers. Its values are defined below:</t></li> <li> <ul spacing="normal"> <li> <t>0: Reserved</t> </li> <li> <t>1: BGP<dl spacing="normal" newline="false"> <dt>0:</dt><dd>Reserved</dd> <dt>1:</dt><dd>BGP SessionEstablished</t> </li> <li> <t>2: BGPEstablished</dd> <dt>2:</dt><dd>BGP Session Establishment InProgress</t> </li> <li> <t>3: BGPProgress</dd> <dt>3:</dt><dd>BGP SessionDown</t> </li> <li> <t>4-255: Reserved</t> </li> </ul> </li> <li> <t>Error Code: 1 byte, IndicateDown</dd> <dt>4-255:</dt><dd>Reserved</dd> </dl> </dd> <dt>Error Code:</dt><dd><t>1 byte. Indicates the reason that the BGP session can't be established.</t></li> <li> <ul spacing="normal"> <li> <t>0: Unspecific</t> </li> <li> <t>1: ASes<dl spacing="normal" newline="false"> <dt>0:</dt><dd>Unspecific</dd> <dt>1:</dt><dd>ASes do not match, BGP SessionFailure</t> </li> <li> <t>2: PeerFailure</dd> <dt>2:</dt><dd>Peer IP can't be reached, BGP SessionFailure</t> </li> <li> <t>3-255: Reserved</t> </li> </ul> </li> <li> <t>Flag: 1Failure</dd> <dt>3-255:</dt><dd>Reserved</dd> </dl> </dd> <dt>Flag:</dt><dd><t>1 byte.</t></li> <li> <ul spacing="normal"> <li><t>Currently, only bit 7 (T bit) is defined. When the T bit is set, the trafficSHOULD<bcp14>SHOULD</bcp14> be sent in the IPinIP tunnel(Tunnel(the tunnel source is the Local IP Address, and the tunnel destination is the Peer IP Address). When the T bit is cleared, the traffic is sent via its original source and destination address. The Tunnelmode(Tmode (i.e., the 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(i.e., the 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</dd> <dt>Local IP Address(4/16bytes): Unicastbytes):</dt><dd>Unicast IP address of the local router, used to peer with another end router. When the Object-Type is 1, the length is 4 bytes; when the Object-Type is 2, the length is 16bytes.</t> </li> <li> <t>Peerbytes.</dd> <dt>Peer IP Address(4/16bytes): Unicastbytes):</dt><dd>Unicast IP address of the peer router, used to peer with the local router. When the Object-Type is 1, the length is 4 bytes; when the Object-Type is 2, the length is 16bytes;</t> </li> <li> <t>Optional TLVs: TLVsbytes.</dd> <dt>Optional TLVs:</dt><dd>TLVs that are associated with thisobject,object; can be used to convey other necessary information for dynamic BGP session establishment. No TLVs are currentlydefined.</t> </li> </ul>defined.</dd> </dl> <t>When the PCC receives a BPI object, with Object-Type=1, itSHOULD<bcp14>SHOULD</bcp14> try to establish a BGP session with the peer in AFI/SAFI=1/1.</t> <t>When the PCC receives a BPIobjectobject, with Object-Type=2, itSHOULD<bcp14>SHOULD</bcp14> try to establish a BGP session with the peer in AFI/SAFI=2/1.</t> </section> <section numbered="true" toc="default"> <name>Explicit Peer Route Object</name> <t>The Explicit Peer Route (EPR) object is defined to specify the explicit 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 devices on the path thatisare calculated by the PCE. Although the object is namedas"Explicit Peer Route", it can be seen that the routes it installs are simply host routes. The use of this object to install host routes for any purpose other than reaching the corresponding peer address on each device that is on the E2E Native-IP TE path is outside the scope of this specification.</t> <t>By default, the path established by this objectMUST<bcp14>MUST</bcp14> have higher priority than the other paths calculated by the dynamic IGPprotocol,protocol andMUST<bcp14>MUST</bcp14> have lower priority than the static route configured bymanual or NETCONFmanual, NETCONF, or any other static means.</t><t>Explicit<t>The Explicit Peer Route Object-Class is 47.</t><t>Explicit<t>The Explicit Peer Route Object-Type is 1 for IPv4 and 2 forIPv6</t>IPv6.</t> <t>The format of the Explicit Peer Route object body for IPv4 (Object-Type=1) is as follows:</t> <figure anchor="fig-12"> <name>Explicit Peer Route Object Body Format for IPv4</name> <artwork name="" type=""align="left"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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Priority | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Hop IPv4 Address to the Peer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Optional TLVs // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 12: Explicit Peer Route Object Body Format for IPv4]]></artwork><t/></figure> <t>The format of the Explicit Peer Route object body for IPv6 (Object-Type=2) is as follows:</t> <figure anchor="fig-13"> <name>Explicit Peer Route Object Body Format for IPv6</name> <artwork name="" type=""align="left"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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Priority | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Peer IPv6 Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Next Hop IPv6 Address to the Peer | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Optional TLVs // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 13: Explicit Peer Route Object Body Format for IPv6]]></artwork><ul empty="true"</figure> <dl newline="false" spacing="normal"><li> <t>Route Priority: 2 bytes; the<dt>Route Priority:</dt><dd>2 bytes. The priority of this explicit route. The higher prioritySHOULD<bcp14>SHOULD</bcp14> be preferred by the device. This field is used to indicate the preferred path at eachhop.</t> </li> <li> <t>Reserved: is sethop.</dd> <dt>Reserved:</dt><dd>Set to zero whilesending,sending and ignored onreceipt.</t> </li> <li> <t>Peerreceipt.</dd> <dt>Peer (IPv4/IPv6)Address: Peer AddressAddress:</dt><dd>Peer address for the BGP session (4/16bytes).</t> </li> <li> <t>Nextbytes).</dd> <dt>Next Hop (IPv4/IPv6) Address to thePeer: To indicatePeer:</dt><dd>Indicates thenext hopnext-hop address (4/16 bytes) to the corresponding peeraddress.</t> </li> <li> <t>Optional TLVs: TLVsaddress.</dd> <dt>Optional TLVs:</dt><dd>TLVs that are associated with thisobject,object; can be used to convey other necessary information for explicit peer path establishment. No TLVs are currentlydefined.</t> </li> </ul>defined.</dd> </dl> </section> <section numbered="true" toc="default"> <name>Peer Prefix Advertisement Object</name> <t>The Peer Prefix Advertisement (PPA) object is defined to specify the IP prefixes that are advertised to the corresponding peer. This objectneedsonly needs to be included and sent to the source/destination router of the E2E path.</t> <t>The prefix information included in this objectMUST<bcp14>MUST</bcp14> only be advertised to the indicatedpeer,peer andSHOULD NOT<bcp14>SHOULD NOT</bcp14> be advertised to other BGP peers.</t><t>Peer<t>The Peer Prefix Advertisement Object-Class is48</t> <t>Peer48.</t> <t>The Peer Prefix Advertisement Object-Type is 1 for IPv4 and 2 forIPv6</t>IPv6.</t> <t>The format of the Peer Prefix Advertisement object body for IPv4 is as follows:</t> <figure anchor="fig-14"> <name>Peer Prefix Advertisement Object Body Format for IPv4</name> <artwork name="" type=""align="left"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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | No. of Prefix | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Prefix #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Prefix #1 Len | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : | | : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Prefix #n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Prefix #n Len | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Optional TLVs // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 14:]]></artwork> </figure> <!--[rfced] FYI - To match Sections 7.2 and 7.3, we have updated the single sentence preceding Figures 14 and 15 in Section 7.4 to be two sentences, one preceding each figure, respectively. Please review and let us know of any objections. Original: The format of the Peer Prefix Advertisement object body is as follows: Current: The format of the Peer Prefix Advertisement object body for IPv4 is as follows: ... The format of the Peer Prefix Advertisement object body for IPv6 is as follows: --> <t>The format of the Peer Prefix Advertisement object body for IPv6 is as follows:</t> <figure anchor="fig-15"> <name>Peer Prefix Advertisement Object Body Format forIPv4]]></artwork>IPv6</name> <artwork name="" type=""align="left"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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Peer IPv6 Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | No. of Prefix | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Prefix #1 | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Prefix #1 Len | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : | | : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Prefix #n | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Prefix #n Len | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Optional TLVs // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 15: Peer Prefix Advertisement Object Body Format for IPv6]]></artwork> <ul empty="true" spacing="normal"> <li> <t>Common Fields:</t> </li> <li> <ul empty="true"]]></artwork> </figure> <dl newline="true"> <dt>Common Fields:</dt> <dd> <dl newline="false" spacing="normal"><li> <t>No.<dt>No. ofPrefix: 1Prefix:</dt><dd>1 byte. Identifies the number of prefixes that are advertised to the peer in the PPAobject.</t> </li> <li> <t>Reserved: 3object.</dd> <dt>Reserved:</dt><dd>3 bytes. Ought to be set to zero while sending andbeignored onreceipt.</t> </li> <li> <t>Prefix Len: 1receipt.</dd> <dt>Prefix Len:</dt><dd>1 byte. Identifies the length of theprefix.</t> </li> <li> <t>Optional TLVs: TLVsprefix.</dd> <dt>Optional TLVs:</dt><dd>TLVs that are associated with thisobject,object; can be used to convey other necessary information for prefix advertisement. No TLVs are currentlydefined.</t> </li> </ul> </li> <li> <t>For IPv4:</t> </li> <li> <ul empty="true"defined.</dd> </dl> </dd> <dt>For IPv4:</dt> <dd> <dl newline="false" spacing="normal"><li> <t>Peer<dt>Peer IPv4Address: 4Address:</dt><dd>4 bytes. Identifies the peer IPv4 address that the associated prefixes will be sentto.</t> </li> <li> <t>IPv4 Prefix: 4to.</dd> <dt>IPv4 Prefix:</dt><dd>4 bytes. Identifies the prefix that will be sent to the peer identified by the Peer IPv4Address.</t> </li> </ul> </li> <li> <t>For IPv6:</t> <ul empty="true"Address.</dd> </dl> </dd> <dt>For IPv6:</dt> <dd> <dl newline="false" spacing="normal"><li> <t>Peer<dt>Peer IPv6Address: 16Address:</dt><dd>16 bytes. Identifies the peer IPv6 address that the associated prefixes will be sentto.</t> </li> <li> <t>IPv6 Prefix: Identifiesto.</dd> <dt>IPv6 Prefix:</dt><dd>Identifies the prefix that will be sent to the peer identified by the Peer IPv6Address.</t> </li> </ul>Address.</dd> </dl> </dd> </dl> <t>If in thefuture,future a requirement is identified to advertise IPv4 prefixestowardtowards an IPv6 peeringaddress,address or IPv6 prefixes towards an IPv4 peering address, then a new Peer Prefix AdvertisementObject-TypesObject-Type can be defined for these purposes.</t></li> </ul></section> </section> <section anchor="NewErrorTypeAndValue" numbered="true" toc="default"> <name>NewError-TypesError-Type and Error-Values Defined</name> <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 Error-value that provides additional information about the error. An additional Error-Type and several Error-values are defined to represent the errors related to the newly defined objects that are related to Native IP TE procedures.</t><artwork name="" type="" align="left" alt=""><![CDATA[ +============+==========+=====================================+ |<!-- [rfced] Table 1: Rather than have two tables with the same information, may we point readers to Table 5 in the IANA Considerations section as shown below? Current (Section 8): An additional Error-Type| Meaning | Error-value | +=======+===============+=====================================+ | 33 |and several Error-values are defined to represent the errors related to the newly defined objects that are related to Native IP TEfailure | | | | +-------+---------------+-------------------------------------+ | | |0:Unassigned | +-------+---------------+-------------------------------------+ | | |1:Local IP is in use | +-------+---------------+-------------------------------------+ | | |2:Remoteprocedures. Perhaps: An additional Error-Type and several Error-values are defined to represent the errors related to the newly defined objects that are related to Native IPis 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 | MandatoryTE procedures. See Table 5 (Section 13.4) for the newly defined Error-Type and Error-values. --> <table> <name>Newly Defined Error-Type and Error-Values</name> <thead> <tr> <th>Error-Type</th> <th>Meaning</th> <th>Error-value</th> </tr> </thead> <tbody> <tr> <td>6</td> <td>Mandatory Objectmissing | | | | +-------+---------------+-------------------------------------+ | | |19:Nativemissing</td> <td>19: Native IP objectmissing | +-------+---------------+-------------------------------------+ | 10 | Receptionmissing</td> </tr> <tr> <td>10</td> <td>Reception of an invalidobject | | | | +-------+---------------+-------------------------------------+ | | |39:PCECCobject</td> <td>39: PCECC NATIVE-IP-TE-CAPABILITY bit| | | |isis notset | +-------+---------------+-------------------------------------+ | 19 | Invalid Operation | | | | +-------+---------------+-------------------------------------+ | | |22:Onlyset</td> </tr> <tr> <td rowspan="3">19</td> <td rowspan="3">Invalid Operation</td> <td> 22: Only one BPI,EPREPR, or PPA object| | | |cancan be included in thismessage | +-------+---------------+-------------------------------------+ | | |TBD1:Attemptedmessage</td> </tr> <tr> <td>29: Attempted Native-IP operations| | | |whenwhen the capability was not| | | | advertised | +-------+---------------+-------------------------------------+ | | |TBD2:Unknownadvertised</td> </tr> <tr> <td>30: Unknown Native-IP Info</td> </tr> <tr> <td rowspan="6">33</td> <td rowspan="6">Native IP TE failure</td> <td>1: Local IP is in use</td> </tr> <tr> <td>2: Remote IP is in use</td> </tr><tr> <td>3: Explicit Peer Route Error</td> </tr><tr> <td>4: EPR/BPI Peer Info| +-------+---------------+-------------------------------------+ Figure 16: Newly defined Error-Type and Error-Value ]]></artwork>mismatch</td> </tr><tr> <td>5: BPI/PPA Address Family mismatch</td> </tr><tr> <td>6: PPA/BPI Peer Info mismatch</td> </tr> </tbody> </table> </section> <section anchor="BGP_Considerations" numbered="true" toc="default"> <name>BGP Considerations</name> <t>This document definestheprocedures and objects to create the BGP sessions and to advertise the associated prefixes dynamically. Only the key information, for example, peer IP addresses, andpeerPeer AS numbers are exchanged via the PCEP protocol. Other parameters that are needed for the BGP session setupSHOULD<bcp14>SHOULD</bcp14> be derived from their default values.</t> <t>When the PCE sends out the PCInitiate message with the BPI object embedded to establish the BGP session between the PCC peers, the PCCSHOULD<bcp14>SHOULD</bcp14> report the BGP session status. For instance, the PCC could respond with "BGP Session Establishment In Progress" initiallyandand, on sessionestablishmentestablishment, send another PCRpt message with the state updated to "BGP Session Established". If there is any error during the BGP session establishment, the PCCSHOULD<bcp14>SHOULD</bcp14> indicate the reason with the appropriate status value set in the BPI object.</t> <t>Upon receiving such key information, the BGP module on the PCCSHOULD<bcp14>SHOULD</bcp14> try to accomplish the task appointed by the PCEP protocol and report the successful status to the PCEP modules after the session is set up.</t> <t>There is no influence on the current implementation of the BGP Finite State Machine (FSM).ThePCEP focuses only on the success and failure status of the BGP session and acts upon such information accordingly.</t> <t>The error-handling procedures related to incorrect BGP parameters are specified in Sections <xref target="BGPSess"format="default"/>,format="counter"/>, <xref target="BGPEx"format="default"/>,format="counter"/>, and <xref target="BGPPrefix"format="default"/>.</t>format="counter"/>.</t> </section> <section numbered="true" toc="default"> <name>Deployment Considerations</name> <t>The information transferred in this document is mainly used for the BGP session setup, explicit routedeploymentdeployment, andtheprefix distribution. The planning,allocationallocation, and distribution of the peer addresses within IGPneedsneed to be accomplished inadvanceadvance, and they are out of the scope of this document.</t> <!--[rfced] To have a 1:1 matchup between the acronym and its expansion, may we update "LSP-DB" as follows, i.e., remove "State" from the expansion? Original: ...treat the three newly defined objects (BPI, EPR and PPA) associated with the same symbolic path name as the attribute of the same path in the LSP-DB (LSP State Database). Perhaps: ...treat the three newly defined objects (BPI, EPR, and PPA) associated with the same symbolic path name as the attribute of the same path in the LSP Database (LSP-DB). --> <t>The communication of PCE and PCC described in this documentMUST<bcp14>MUST</bcp14> follow the state synchronization procedures described in <xref target="RFC8232" format="default"/>, i.e., treat the three newly defined objects (BPI,EPREPR, and PPA) associated with the same symbolic path name as the attribute of the same path in theLSP-DB (LSPLSP StateDatabase).</t>Database (LSP-DB).</t> <t>When the PCE detects that one or some of the PCCs are out of its control, itMUST<bcp14>MUST</bcp14> recompute and redeploy the traffic engineering path for native IP on the currently active PCCs. The PCEMUST<bcp14>MUST</bcp14> ensure the avoidance of the possible transient loop in such node failure when it deploys the explicit peer route on the PCCs.</t> <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="default"/>.</t> <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 result in automatic and immediate disruption for the services. Similarly, as per <xref target="RFC9050" format="default"/>, the central controller instructions are not removed immediately upon PCE failure. Instead, they could bere-delegatedredelegated to the new PCE before the expiration of thistimer,timer or be cleaned up on the expiration of this timer. This allows for networkclean upcleanup without manual intervention. The PCC supports the removal of CCI as one of the behaviors applied on the expiration of the State Timeout Interval timer.</t> </section> <section numbered="true" toc="default"> <name>Manageability Considerations</name> <section numbered="true" toc="default"> <name>Control of Function and Policy</name> <t>A PCE or PCC implementationSHOULD<bcp14>SHOULD</bcp14> allow the PCECC Native-IP capability to be enabled/disabled as part of the global configuration.</t> </section> <section numbered="true" toc="default"> <name>Information and Data Models</name> <t><xref target="RFC7420" format="default"/> describes the PCEP MIB; this MIB could be extended to get the PCECC Native-IP capability status. The PCEP YANG module <xref target="I-D.ietf-pce-pcep-yang" format="default"/>modulecould be extended to enable/disable the PCECC Native-IP capability.</t> </section> <section numbered="true" toc="default"> <name>Liveness Detection and Monitoring</name> <!--[rfced] Is the intended meaning that the mechanisms in this document and the mechanisms listed in RFC 5440 do not imply any new liveness detection and monitoring? If so, may we rephrase the text as shown below for clarity? Original: Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440]. Perhaps: Mechanisms defined in this document, and those already listed in [RFC5440], do not imply any new liveness detection and monitoring requirements. --> <t>Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in <xref target="RFC5440" format="default"/>. The operator relies on existing IP liveness detection and monitoring.</t> </section> <section numbered="true" toc="default"> <name>Verify Correct Operations</name> <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"/>format="default"/>, and <xref target="RFC9050" format="default"/>. Further, the operator needs to be able to verify the status of BGP sessions and prefix advertisements.</t> </section> <section numbered="true" toc="default"> <name>Requirements on Other Protocols</name> <t>Mechanisms defined in this document require the interaction with BGP. <xref target="BGP_Considerations" format="default"/> describes in detail the considerations regarding the BGP. During the BGP session establishment, the Local/Peer IP addressMUST<bcp14>MUST</bcp14> be dedicated to the usage of the native IP TEsolution,solution andMUST NOT<bcp14>MUST NOT</bcp14> be used by other BGP sessions that are established manually or in other ways.</t> </section> <section numbered="true" toc="default"> <name>Impact on Network Operations</name> <t><xref target="RFC8821" format="default"/> describes the various deployment considerations in CCDR architecture and their impact on network operations.</t> </section> </section> <section numbered="true" toc="default"> <name>Security Considerations</name> <t>In this setup, the BGP sessions, prefix advertisement, and explicit peer route establishment are all controlled by the PCE. See <xref target="RFC4271" format="default"/> forsecurity consideration ofclassical BGPimplementation,implementation security considerations and <xref target="RFC4272" format="default"/> for classical BGP vulnerabilities analysis. Security considerations in <xref target="RFC5440"format="default"/>forformat="default"/> for the basic PCEP protocol, <xref target="RFC8231" format="default"/> for PCEP extension for statefulPCEPCE, and <xref target="RFC8281" format="default"/> for PCE-Initiated LSP setupSHOULD<bcp14>SHOULD</bcp14> be considered. To prevent a bogus PCE from sending harmful messages to the network nodes, the network devicesSHOULD<bcp14>SHOULD</bcp14> authenticate the PCE and ensure a secure communication channel between them. Thus, the mechanisms described in <xref target="RFC8253" format="default"/> for the usage of TLS for PCEP and <xref target="RFC9050" format="default"/> for protection against malicious PCEsSHOULD<bcp14>SHOULD</bcp14> be used.</t><t>If<!--[rfced] Does "it" refer to a suitable default value? If so, may we clarify the text as follows? Original: If suitable default values as discussed in Section 9 aren't enough and securing the BGP transport is required(for example, the TCP-AO [RFC5925], it can be provided through the addition of optional TLVs to the BGP Peer Info object that conveys the necessary additional information (for example, a key chain [RFC8177]name). Perhaps: If the suitable default values discussed in Section 9 aren't enough and securing the BGP transport is required (for example, by using TCP-AO [RFC5925]), 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 example, a key chain [RFC8177] name). --> <t>If the suitable default values discussed in <xref target="BGP_Considerations" format="default"/> aren't enough and securing the BGP transport isrequired(forrequired (for example, theTCP-AOTCP Authentication Option (TCP-AO) <xref target="RFC5925"format="default"/>,format="default"/>), it can be provided through the addition of optional TLVs to the BGP Peer Info object that conveys the necessary additional information (for example, a key chain <xref target="RFC8177"format="default"/>name).</t>format="default"/> name).</t> </section> <section numbered="true" toc="default"> <name>IANA Considerations</name> <section numbered="true" toc="default"><name>Path<name>PCEP Path SetupType Registry</name>Types</name> <t><xref target="RFC8408" format="default"/> createda sub-registrythe "PCEP Path Setup Types" registry within the "Path Computation Element Protocol (PCEP) Numbers" registrycalled "PCEP Path Setup Types".group. IANAis requested to allocatehas allocated a new code point within thissub-registry,registry, as follows:</t><artwork name="" type="" align="left" alt=""><![CDATA[ Value Description Reference 4 Native<table> <name>PCEP Path Setup Types Registry</name> <thead> <tr> <th>Value</th> <th>Description</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>4</td> <td>Native IP TEPath This document ]]></artwork>Path</td> <td>RFC 9757</td> </tr> </tbody> </table> </section> <section numbered="true" toc="default"> <name>PCECC-CAPABILITYsub-TLV'sSub-TLV Flagfield</name> <t>Editorial Note (To be removed by RFC Editor): This experimental track document is allocating a code point in the registry under the standards action registry which is not allowed. <xref target="RFCYYY1" format="default"/> updates the registration policy to IETF review allowing for this allocation. Note that an early allocation was made when the document was being progressed in the standards track. At the time of publication, please remove this note and the reference to <xref target="RFCYYY1" format="default"/>.</t>Field</name> <t><xref target="RFC9050" format="default"/> createda sub-registrythe "PCECC-CAPABILITY sub-TLV" registry within the "Path Computation Element Protocol (PCEP) Numbers" registry group to manage the value of the PCECC-CAPABILITY sub-TLV's 32-bit Flag field. IANAis requested to allocatehas allocated a new bit position within this registry, as follows:</t><artwork name="" type="" align="left" alt=""><![CDATA[ Bit Name Reference 30 NATIVE IP This document ]]></artwork><table> <name>PCECC-CAPABILITY Sub-TLV Registry</name> <thead> <tr> <th>Bit</th> <th>Name</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>30</td> <td>NATIVE IP</td> <td>RFC 9757</td> </tr> </tbody> </table> </section> <section numbered="true" toc="default"> <name>PCEPObject</name>Objects</name> <t>IANAis requested to allocatehas allocated newcodepointscode points in the "PCEP Objects"sub-registryregistry, as follows:</t><artwork name="" type="" align="left" alt=""><![CDATA[ Object-Class Value Name Reference 44 CCI Object This document Object-Type 2:<!-- [rfced] We have included a clarification about the IANA text below. In addition to reviewing it, please review all of the IANA-related updates carefully and let us know if any further updates are needed. ) FYI: In Table 4, we have added "Object-Type" to each name and have added "0: Reserved" accordingly to match the "PCEP Objects" registry (see <https://www.iana.org/assignments/pcep/>). --> <table> <name>PCEP Objects Registry</name> <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: NativeIP 46 BGPIP</td> <td>RFC 9757</td> </tr> <tr> <td rowspan="3">46</td> <td rowspan="3">BGP Peer InfoThis document Object-Type 1:Object-Type</td> <td>0: Reserved</td> <td>RFC 9757</td> </tr><tr> <td>1: IPv4address 2:address</td> <td></td> </tr><tr> <td>2: IPv6address 47 Explicitaddress</td> <td></td> </tr> <tr> <td rowspan="3">47</td> <td rowspan="3">Explicit Peer RouteThis document Object-Type 1:Object-Type</td> <td>0: Reserved</td> <td>RFC 9757</td> </tr><tr> <td>1: IPv4address 2:address</td> <td></td> </tr><tr> <td>2: IPv6address 48 Peeraddress</td> <td></td> </tr> <tr> <td rowspan="3">48</td> <td rowspan="3">Peer Prefix AdvertisementThis document Object-Type 1:Object-Type</td> <td>0: Reserved</td> <td>RFC 9757</td> </tr><tr> <td>1: IPv4address 2:address</td> <td></td> </tr><tr> <td>2: IPv6address ]]></artwork>address</td> <td></td> </tr> </tbody> </table> </section> <section numbered="true" toc="default"> <name>PCEP-ErrorObject</name>Objects</name> <t>IANAis requested to allocatehas allocated a newerror typesError-Type anderror values withinseveral Error-values in the "PCEP-ERROR Object Error Types and Values"sub-registry of the PCEP Numbersregistryforwithin thefollowing errors:</t> <artwork name="" type="" align="left" alt=""><![CDATA[ Error-Type Meaning Error-value 6 Mandatory"Path Computation Element Protocol (PCEP) Numbers" registry group, as follows:</t> <table> <name>PCEP-ERROR Objectmissing 19:NativeError Types and Values Registry</name> <thead> <tr> <th>Error-Type</th> <th>Meaning</th> <th>Error-value</th> </tr> </thead> <tbody> <tr> <td>6</td> <td>Mandatory Object missing</td> <td>19: Native IP objectmissing 10 Receptionmissing</td> </tr> <tr> <td>10</td> <td>Reception of an invalidobject 39:PCECCobject</td> <td>39: PCECC NATIVE-IP-TE-CAPABILITY bit is notset 19 Invalid Operation 22:Onlyset</td> </tr> <tr> <td rowspan="3">19</td> <td rowspan="3">Invalid Operation</td> <td> 22: Only one BPI,EPREPR, or PPA object can be included in thismessage TBD1:Attemptedmessage</td> </tr> <tr> <td>29: Attempted Native-IP operations when the capability was notadvertised TBD2:Unknownadvertised</td> </tr> <tr> <td>30: Unknown Native-IPInfo 33 NativeInfo</td> </tr> <tr> <td rowspan="7">33</td> <td rowspan="7">Native IP TEfailure 1:Localfailure</td> <td>0: Unassigned</td> </tr> <tr> <td>1: Local IP is inuse 2:Remoteuse</td> </tr><tr> <td>2: Remote IP is inuse 3:Explicituse</td> </tr><tr> <td>3: Explicit Peer RouteError 4:EPR/BPIError</td> </tr><tr> <td>4: EPR/BPI Peer Infomismatch 5:BPI/PPAmismatch</td> </tr><tr> <td>5: BPI/PPA Address Familymismatch 6:PPA/BPImismatch</td> </tr><tr> <td>6: PPA/BPI Peer Infomismatch ]]></artwork>mismatch</td> </tr> </tbody> </table> <t>The reference fortheeach newError-type/valueError-Type/Error-value should be set to this document.</t> </section> <section numbered="true" toc="default"> <name>CCI Object Flag Field</name> <t>IANAis requested to create a new sub-registryhas created the "CCI Object Flag Field for Native-IP" registry to manage the16-bits16-bit Flag field of the new CCIObject called "CCI Object Flag Field for Native-IP".Object. New values are to be assigned by IETFreviewReview <xref target="RFC8126" format="default"/>. Each bit should be tracked with the following qualities:</t> <ulempty="true"spacing="normal"><li> <t>bit<li>bit number (counting from bit 0 as the most significantbit,bit and bit 15 as thelestleast significantbit)</t> </li> <li> <t>capability description</t> </li> <li> <t>defining RFC</t> </li>bit)</li> <li>capability description</li> <li>defining RFC</li> </ul> <t>Currently, no flags are assigned.</t> </section> <section numbered="true" toc="default"> <name>BPI Object StatusCode</name>Codes</name> <t>IANAis requested to create a new sub-registryhas created the "BPI Object Status Code Field" registry within the "Path Computation Element Protocol (PCEP)Numbers".Numbers" registry group. New values are assigned by IETFreviewReview <xref target="RFC8126" format="default"/>. Each value should be tracked with the following qualities: value, meaning, and defining RFC. The following values are defined in this document:</t><artwork name="" type="" align="left" alt=""><![CDATA[ Value Meaning Reference 0 Reserved This document 1 BGP<table> <name>BPI Object Status Code Field Registry</name> <thead> <tr> <th>Value</th> <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>BGP SessionEstablished This document 2 BGPEstablished</td> <td>RFC 9757</td> </tr> <tr> <td>2</td> <td>BGP Session Establishment InProgress This document 3 BGPProgress</td> <td>RFC 9757</td> </tr> <tr> <td>3</td> <td>BGP SessionDown This document 4-255 Unassigned This document ]]></artwork>Down</td> <td>RFC 9757</td> </tr> <tr> <td>4-255</td> <td>Unassigned</td> <td>RFC 9757</td> </tr> </tbody> </table> </section> <section numbered="true" toc="default"> <name>BPI Object ErrorCode</name>Codes</name> <t>IANAis requested to create a new sub-registryhas created the "BPI Object Error Code Field" registry within the "Path Computation Element Protocol (PCEP)Numbers".Numbers" registry group. New values are assigned by IETFreviewReview <xref target="RFC8126" format="default"/>. Each value should be tracked with the following qualities: value, meaning, and defining RFC. The following values are defined in this document:</t><artwork name="" type="" align="left" alt=""><![CDATA[ Value Meaning Reference 0 Reserved This document 1 ASes does<table> <name>BPI Object Error Code Field Registry</name> <thead> <tr> <th>Value</th> <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 notmatch,match - BGP SessionFailure This document 2 PeerFailure</td> <td>RFC 9757</td> </tr> <tr> <td>2</td> <td>Peer IP can't bereached,reached - BGP SessionFailure This document 3-255 Unassigned This document ]]></artwork>Failure</td> <td>RFC 9757</td> </tr> <tr> <td>3-255</td> <td>Unassigned</td> <td>RFC 9757</td> </tr> </tbody> </table> </section> <section numbered="true" toc="default"> <name>BPI Object Flag Field</name> <t>IANAis requested to create a new sub-registryhas created the "BPI Object Flag Field" registry within the "Path Computation Element Protocol (PCEP)Numbers".Numbers" registry group. New values are to be assigned by IETFreviewReview <xref target="RFC8126" format="default"/>. Each bit should be tracked with the following qualities:</t> <ulempty="true"spacing="normal"> <li> <t>bit number (counting from bit 0 as the most significant bit)</t> </li> <li> <t>capability description</t> </li> <li> <t>defining RFC</t> </li> </ul> <t>The following values are defined in this document:</t><artwork name="" type="" align="left" alt=""><![CDATA[ Bit Meaning Reference 0-6 Unassigned 7 T<table> <name>BPI Object Flag Field Registry</name> <thead> <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 (IPnIP)bit This document ]]></artwork>bit</td> <td>RFC 9757</td> </tr> </tbody> </table> </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> <back> <displayreference target="I-D.ietf-pce-pcep-yang" to="YANG-PCEP"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2003.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5511.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5925.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7420.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8231.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8232.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8253.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8281.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8408.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9050.xml"/><!-- [rfced] [I-D.ietf-pce-iana-update] IESG state: I-D Exists as of 09/04/24; companion<!--[rfced] *AD - Per the following note left in the document by the authors, we have removed the normative reference [I-D.ietf-pce-iana-update]. Please review and approve of this update. Original: Editorial Note (To be removed by RFCYYY1--> <reference anchor="RFCYYY1" target="https://www.rfc-editor.org/info/rfcYYY1"> <front> <title>UpdateEditor): This experimental track document is allocating a code point in the registry under the standards action registry which is not allowed. [I-D.ietf-pce-iana-update] updates the registration policy to IETF review allowing for this allocation. Note that an early allocation was made when theIANA PCEP Registration Proceduresdocument was being progressed in the standards track. At the time of publication, please remove this note andAllowing Experimental 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>the reference to [I-D.ietf-pce-iana-update]. --> </references> <references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3209.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4272.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5036.xml"/> <!-- [rfced] The following reference is not cited in the text. Please let us know where it should be cited; otherwise, it will be deleted from the references section. [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-editor.org/info/rfc7942>. --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7942.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8177.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8283.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8735.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8821.xml"/> <!--[rfced][I-D.ietf-pce-pcep-yang] IESG state:Publication requestedIESG Evaluation::Revised I-D Needed as of09/04/241/9/25 --> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-pce-pcep-yang.xml"/> </references> </references> <section numbered="false" toc="default"> <name>Acknowledgements</name> <t>Thanks to <contact fullname="Mike Koldychev"/>, <contact fullname="Susan 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="Dhruv Dhody"/> has contributed to this document.</t> </section> <!-- [rfced] FYI - We have added expansions for the following abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. Path Computation Client (PCC) PCEP-specific LSP identifiers (PLSP-ID) TCP Authentication Option (TCP-AO) --> <!-- [rfced] Terminology a) Throughout the text, the following terminology appears to be used inconsistently. Please review these occurrences and let us know if/how they may be made consistent. Local/Peer IP Address vs. Local/Peer IP address Native IP vs. Native-IP vs. native IP vs. NATIVE IP [Note: These differences are also found within the IANA registries.] Peer IPv4 Address vs. peer IPv4 address Peer IPv6 Address vs. peer IPv6 address b) May we update the following terms to the form on the right in the running text for consistency? central controller instructions > Central Controller Instructions (per RFC 9050) code point > codepoint (per RFC 9050 and to match the companion document) Error-type > Error-Type Error-Value > Error-value Object type, object type > Object-Type PCE-Initiated > PCE-initiated (per RFC 8281) PCEP Speakers > PCEP speakers PCInitiate Message > PCInitiate message state synchronization > State Synchronization (per RFCs 8232 and 9050) Symbolic Path Name > symbolic path name (per RFC 8232) Remote Peer > remote peer (per RFC 8232) PCEP Object > PCEP object BPI Object > BPI object CCI Object > CCI object c) We note three instances of "PCEP protocol". Since this reads as "Path Computation Element Communication Protocol protocol" when expanded, may we remove "protocol" when it occurs after "PCEP"? d) FYI: We note "Central Control Dynamic Routing" vs. "Centralized Control Dynamic Routing" for the expansion of "CCDR". We have updated the text to reflect the latter form per use in RFCs 8735 and 8821. Central Control Dynamic Routing > Centralized Control Dynamic Routing --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. For example, please consider whether the following should be updated: - traditional - native --> </back> </rfc>