<?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> <authorfullname="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> <authorfullname="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="March" 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 innativeNative IP networks through a PCE-based central control mechanism known as Centralized Control Dynamic Routing (CCDR). These extensions empower a PCE to calculate and manage paths specifically fornativeNative IP networks,expandthereby expanding PCEP's capabilities beyond itstraditionalpast use in MPLS and GMPLS networks. By implementing these extensions, IP network resources can be utilized more efficiently, facilitating the deployment of traffic engineering innativeNative 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 innativeNative 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. <xref target="RFC8821" format="default"/> 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-based solution.sessions. 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. 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, PCEPSpeakersspeakers (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"/> forNative-IP,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> <t><xref target="RFC9050" format="default"/> defined the PCECC-CAPABILITY sub-TLV to exchange information abouttheirthe PCEP speakers' 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) andError-Value=39Error-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) andError-Value=33Error-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 forNative-IP,Native IP, the PCEP extensions for theNative-IP MUST NOTNative IP <bcp14>MUST NOT</bcp14> be used. If aNative-IPNative 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 (AttemptedNative-IPNative 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<t>The PCECC Native IP TE solution uses the existing PCE Label Switched Path (LSP) Initiate Request message (PCInitiate) <xref target="RFC8281"format="default"/>,format="default"/> and PCE Report message (PCRpt) <xref target="RFC8231" format="default"/> toaccomplish theestablish multiple BGPsessions establishment,sessions, deploy the E2ENative-IPNative IP TEpath deployment,path, and advertise route prefixesadvertisementamong different BGP sessions. A new PST forNative-IPNative 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 PCEPObjectsobjects (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 PCInitiateMessagemessage defined in <xref target="RFC8281" format="default"/> and extended in <xref target="RFC9050" format="default"/> is further extended to supportNative-IPNative IP CCI.</t> <t>The format of the extended PCInitiate message is as follows: </t><artwork<sourcecode name=""type="" align="left" alt=""><![CDATA[type="abnf"><![CDATA[ <PCInitiate Message> ::= <Common Header> <PCE-initiated-lsp-list>Where:]]></sourcecode> <t>Where:</t> <sourcecode name="" type="abnf"><![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 E2EnativeNative IP TE path. The relatedNative-IPNative 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 withError-type=6Error-Type=6 (Mandatory Object missing) and Error-value=19 (Native IP object missing). If there is more than oneinstance ofBPI,EPREPR, or PPA object present, the receiving PCCMUST<bcp14>MUST</bcp14> send a PCErr message withError-type=19Error-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> <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 theNative-IPNative 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="abnf"><![CDATA[ <PCRpt Message> ::= <Common Header> <state-report-list>Where:]]></sourcecode> <t>Where:</t> <sourcecode name="" type="abnf"><![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> <t>The error handling for missing CCI objects is as per <xref target="RFC9050" format="default"/>. Furthermore,one,one and onlyone, object amongone BPI,EPREPR, 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 withError-type=6Error-Type=6 (Mandatory Object missing) and Error-value=19 (Native IP object missing). If thereareis more than oneinstance ofBPI,EPREPR, or PPAobjectsobject present, the receiving PCEMUST<bcp14>MUST</bcp14> send a PCErr message withError-type=19Error-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 thenativeNative 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 IPaddress.</t>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 IPaddress MUSTAddress <bcp14>MUST</bcp14> be dedicated to the usage of thenativeNative 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<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<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 andError-ValuesError-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 BPIObject.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=33Error-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: Error-type=33information 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-type=33error, 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-type=33error, 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. Ifthere istraffic is coming into the network from different attached points but to the samedestination coming into the network,destination, they could share the prioritypathpath, 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"/>. Such forwarding behavior is called the Tunnel mode forwarding strategy. For simplicity, theIPinIPIP-in-IP tunnel type <xref target="RFC2003" format="default"/> is used between the BGP peers by default.</t> <t>The selection of Raw mode and Tunnel mode forwarding strategies are 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><name>Cleanup</name> <t>To remove theNative-IPNative IP state from the PCC, the PCEMUST<bcp14>MUST</bcp14> send explicit CCI cleanup instructions for PPA,EPREPR, and BPIobjects respectivelyobjects, respectively, with the Rflagbit set in the SRP object. If the PCC receives a PCInitiate message but does not recognize theNative-IPNative 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 (UnknownNative-IPNative 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 thestate synchronization,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 CCIObject typeObject-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 anotherobject typeObject-Type forNative-IPNative 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 theNative-IPNative 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 IPaddress MUSTAddress <bcp14>MUST</bcp14> be a unicast address and dedicated to the usage of thenativeNative 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 theIPinIPIP-in-IP tunnel (the tunnel(Tunnelsource 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 E2ENative-IPNative 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 E2ENative-IPNative 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> <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 thepeerPeer IPv4addressAddress 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 thepeerPeer IPv6addressAddress 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 TEprocedures.</t> <artwork name="" type="" align="left" alt=""><![CDATA[ +============+==========+=====================================+ | Error-Type | Meaning | Error-value | +=======+===============+=====================================+ | 33 | Native IP TE failure | | | | +-------+---------------+-------------------------------------+ | | |0:Unassigned | +-------+---------------+-------------------------------------+ | | |1:Local IP is in use | +-------+---------------+-------------------------------------+ | | |2:Remote IP is in use | +-------+---------------+-------------------------------------+ | | |3:Explicit Peer Route Error | +-------+---------------+-------------------------------------+ | | |4:EPR/BPI Peer Info mismatch | +-------+---------------+-------------------------------------+ | | |5:BPI/PPA Address Family mismatch | +-------+---------------+-------------------------------------+ | | |6:PPA/BPI Peer Info mismatch | +-------+---------------+-------------------------------------+ | 6 | Mandatory Object missing | | | | +-------+---------------+-------------------------------------+ | | |19:Native IP object missing | +-------+---------------+-------------------------------------+ | 10 | Reception of an invalid object | | | | +-------+---------------+-------------------------------------+ | | |39:PCECC NATIVE-IP-TE-CAPABILITY bit | | | |is not set | +-------+---------------+-------------------------------------+ | 19 | Invalid Operation | | | | +-------+---------------+-------------------------------------+ | | |22:Only one BPI, EPR or PPA object | | | |can be included in this message | +-------+---------------+-------------------------------------+ | | |TBD1:Attempted Native-IP operations | | | |whenprocedures. See <xref target="err-type-value-reg"/> for thecapability was not | | | | advertised | +-------+---------------+-------------------------------------+ | | |TBD2:Unknown Native-IP Info | +-------+---------------+-------------------------------------+ Figure 16: Newlynewly defined Error-Type andError-Value ]]></artwork>Error-values.</t> </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,peerPeer IPaddresses,Addresses, andpeerPeer AS numbers are exchanged via thePCEP protocol.PCEP. 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 PCEPprotocoland 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> <t>The communication of PCE and PCC described in this documentMUST<bcp14>MUST</bcp14> follow thestate synchronizationState Synchronization procedures described in <xref target="RFC8232" format="default"/>, i.e., treat the three newly defined objects (BPI,EPREPR, and PPA) associated with the samesymbolic path nameSymbolic Path Name as the attribute of the same path in theLSP-DB (LSP State Database).</t>LSP 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 fornativeNative 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 thecentral controller instructionsCentral 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"/>, thecentral controller instructionsCentral 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 PCECCNative-IPNative 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 PCECCNative-IPNative IP capability status. The PCEP YANG module <xref target="I-D.ietf-pce-pcep-yang" format="default"/>modulecould be extended to enable/disable the PCECCNative-IPNative IP capability.</t> </section> <section numbered="true" toc="default"> <name>Liveness Detection and Monitoring</name> <t>Mechanisms defined in this document do not imply any new liveness detection and monitoring requirementsin addition tobeyond 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 IPaddress MUSTAddress <bcp14>MUST</bcp14> be dedicated to the usage of thenativeNative 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 basicPCEP protocol,PCEP, <xref target="RFC8231" format="default"/> for PCEP extension for statefulPCEPCE, and <xref target="RFC8281" format="default"/> forPCE-InitiatedPCE-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>Ifsuitablethe default valuesasdiscussed in <xref target="BGP_Considerations" format="default"/> aren't enough and securing the BGP transport isrequired(forrequired (for example,the TCP-AOby using TCP Authentication Option (TCP-AO) <xref target="RFC5925"format="default"/>, itformat="default"/>), 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 <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 newcode pointcodepoint 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 new codepoints 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:<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>RFC 9757</td> </tr> <tr> <td>2: IPv6address 47 Explicitaddress</td> <td>RFC 9757</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>RFC 9757</td> </tr> <tr> <td>2: IPv6address 48 Peeraddress</td> <td>RFC 9757</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>RFC 9757</td> </tr> <tr> <td>2: IPv6address ]]></artwork>address</td> <td>RFC 9757</td> </tr> </tbody> </table> </section> <section numbered="true"toc="default">toc="default" anchor="pcep-err-ob"> <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 anchor="err-type-value-reg"> <name>PCEP-ERROR Objectmissing 19:NativeError Types and Values Registry</name> <thead> <tr> <th>Error-Type</th> <th>Meaning</th> <th>Error-value</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>6</td> <td>Mandatory Object missing</td> <td>19: Native IP objectmissing 10 Receptionmissing</td> <td>RFC 9757</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> <td>RFC 9757</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:Attempted Native-IPmessage</td> <td>RFC 9757</td> </tr> <tr> <td>29: Attempted Native IP operations when the capability was notadvertised TBD2:Unknown Native-IP Info 33advertised</td> <td>RFC 9757</td> </tr> <tr> <td>30: Unknown Native IP Info</td> <td>RFC 9757</td> </tr> <tr> <td rowspan="7">33</td> <td rowspan="7">Native IP TEfailure 1:Localfailure</td> <td>0: Unassigned</td> <td>RFC 9757</td> </tr> <tr> <td>1: Local IP is inuse 2:Remoteuse</td> <td>RFC9757</td> </tr> <tr> <td>2: Remote IP is inuse 3:Explicituse</td> <td>RFC 9757</td> </tr> <tr> <td>3: Explicit Peer RouteError 4:EPR/BPIError</td> <td>RFC 9757</td> </tr> <tr> <td>4: EPR/BPI Peer Infomismatch 5:BPI/PPAmismatch</td> <td>RFC 9757</td> </tr> <tr> <td>5: BPI/PPA Address Familymismatch 6:PPA/BPImismatch</td> <td>RFC 9757</td> </tr> <tr> <td>6: PPA/BPI Peer Infomismatch ]]></artwork>mismatch</td> <td>RFC 9757</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 (IPnIP) bit This document ]]></artwork> </section> </section> <section numbered="true" toc="default"> <name>Contributor</name> <t>Dhruv Dhody has contributed to this document.</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 (IP-in-IP) bit</td> <td>RFC 9757</td> </tr> </tbody> </table> </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 document RFC YYY1--> <reference anchor="RFCYYY1" target="https://www.rfc-editor.org/info/rfcYYY1"> <front> <title>Update to the IANA PCEP Registration Procedures and Allowing 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></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"/> <xi:includehref="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7942.xml"/> <xi:includehref="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 requested as of 09/04/24 --><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="Ren Tan"/> and <contact fullname="Dhruv Dhody"/> have contributed to this document.</t> </section> </back> </rfc>