<?xml version='1.0' encoding='utf-8'?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
    please see http://xml.resource.org/authoring/README.html. -->
<rfc
      xmlns:xi="http://www.w3.org/2001/XInclude"
      category="std"
      docName="draft-xpbs-pce-topology-filter-00"
      ipr="trust200902"
      obsoletes=""
      updates=""
      submissionType="IETF"
      xml:lang="en"
      tocInclude="true"
      tocDepth="4"
      symRefs="true"
      sortRefs="true"
      version="3">

	   
 <!-- ***** FRONT MATTER ***** -->
 <front>

   <title abbrev="PCEP Extensions for Topology Filter">PCEP Extensions for Topology Filter</title>
   <seriesInfo name="Internet-Draft" value="draft-xpbs-pce-topology-filter-00"/>
	
	<author fullname="Quan Xiong" initials="Q" surname="Xiong">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <country>China</country>
        </postal>

        <phone></phone>

        <email>xiong.quan@zte.com.cn</email>
      </address>
    </author>
	
   	<author fullname="Shaofu Peng" initials="S" surname="Peng">
      <organization>ZTE Corporation</organization>

      <address>
        <postal>
          <street>No.50 Software Avenue</street>
          
          <city>Nanjing</city>
          
          <region>Jiangsu</region>
  
          <code>210012</code>

          <country>China</country>
        </postal>

        <phone></phone>

        <email>peng.shaofu@zte.com.cn</email>
      </address>
    </author>
	
   	<author fullname="Vishnu Pavan Beeram" initials="V" surname="Beeram">
      <organization>Juniper Networks</organization>

      <address>
        <postal>
          <street></street>
          
          <city></city>
          
          <region></region>
  
          <code></code>

          <country></country>
        </postal>

        <phone></phone>

        <email>vbeeram@juniper.net</email>
      </address>
    </author>

   	<author fullname="Tarek Saad" initials="T" surname="Saad">
      <organization>Juniper Networks</organization>

      <address>
        <postal>
          <street></street>
          
          <city></city>
          
          <region></region>
  
          <code></code>

          <country></country>
        </postal>

        <phone></phone>

        <email>tsaad@juniper.net</email>
      </address>
    </author>	
	
    <author fullname="Mike Koldychev" initials="M" surname="Koldychev">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street></street>
          
          <city></city>
          
          <region></region>
  
          <code></code>

          <country>Canada</country>
        </postal>

        <phone></phone>

        <email>mkoldych@cisco.com</email>
      </address>
    </author>

	
	
   <date year="2021"/>
   <area>Routing</area>
   <workgroup>PCE</workgroup>
   <keyword>topology</keyword>
   <abstract>
      <t>This document proposes a set of extensions for PCEP to support the
	  topology filter during path computation.</t>
    </abstract>
  </front>
  
  <!-- ***** MIDDLE MATTER ***** -->
  
  <middle>
  
    <section numbered="true" toc="default">  <name>Introduction</name>
	
	<t><xref target="RFC5440"></xref> describes the Path Computation Element 
    Protocol (PCEP) which is used between a Path Computation Element (PCE) 
    and a Path Computation Client (PCC) (or other PCE) to enable computation 
    of Multi-protocol Label Switching (MPLS) for Traffic Engineering Label 
    Switched Path (TE LSP). PCEP Extensions for the Stateful PCE Model <xref target="RFC8231"></xref> 
	describes a set of extensions to PCEP to enable active control of MPLS-TE and 
	Generalized MPLS (GMPLS) tunnels. As depicted in <xref target="RFC4655"></xref>, a PCE MUST be able
	to compute the path of a TE LSP by operating on the TED and considering 
	bandwidth and other constraints applicable to the TE LSP service request.</t> 
	 
	<t>A PCE always perform path computation based on the network topology 
	information collected through BGP-LS <xref target="RFC7752"></xref>. BGP-LS can get multiple 
	link-state data from multiple IGP instance, or multiple virtual topologies 
	from a single IGP instance. It is necessary to restrict the PCE to a 
	sub-topology during path computation. The PCE MUST take the topology
    constraint into consideration during path computation. </t>
	
	<t>The sub-topology may be considered as a TE topology or a specific 
	IGP domain. As defined in draft-bestbar-teas-yang-topology-filter, 
	a topology filter is a data construct that can be applied on either 
	a native topology or a user specified topology. The topology filter 
	can be viewed as a set of filtering rules to construct the sub-topology.
	The topology filter specifies the topology reference or a set of 
	include-any, include-all and exclude filtering rules.</t> 
	
	<t>This document proposes a set of extensions for PCEP to support the
	topology filter during path computation.</t>
	  
      <section numbered="true" toc="default"> <name>Terminology</name>
        <t>The terminology is defined as <xref target="RFC5440"></xref>, <xref target="RFC7752"></xref>
		and <xref target="RFC8795"></xref>.</t> 
      </section>
	  
      <section numbered="true" toc="default"> <name>Requirements Language</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
       "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
       document are to be interpreted as described in <xref target="RFC2119" 
	   format="default">RFC 2119</xref>.</t>
      </section>
	  
    </section>
   <section numbered="true" toc="default"> <name>Topology Filter</name>
   
    <t>As defined in draft-bestbar-teas-yang-topology-filter, 
	a topology filter is a data construct that can be applied on either 
	a native topology or a user specified topology. The topology filter 
	can be viewed as a set of filtering rules to construct the sub-topology.
	The topology filter specifies the topology reference or a set of 
	include-any, include-all and exclude filtering rules.</t>
   
   <section numbered="true" toc="default"> <name>Topology Reference</name>
	
	<t>The topology reference indicates the topology on which the existing 
	referenced filtering rules need to be applied. The referenced topology
    could be a predefined TE topology or a specific IGP domain.</t>
	
	<t>As defined in RFC7752, the IGP domain has a unique IGP representation 
	by using the combination of Area-ID, Router-ID, Protocol-ID, Multi-Topology 
	ID, and Instance-ID. This document defines TOPOLOGY object and new TLVs for 
	the topology filiter such as Source Protocol TLV, Multi-Topology ID, Area-ID 
	and Algorithm TLV.</t>
	</section>
	
   <section numbered="true" toc="default"> <name>Filters</name>
   <t>The topology filters carries a list of filters. Each filter specifies a 
   set of include-any, include-all and exclude filtering rules that can be 
   applied on the native topology. The filtering rules specify the a set
   of constraints on the topology, that are to be used to compute path at PCE.
   This document proposes a set of extensions for IRO and XRO objext and 
   defines new subobjects such as Link ID, Link affinity and Source Protocol.</t>  
   </section>
	
   </section>
	
	
    <section numbered="true" toc="default"> <name>PCEP Extensions</name>
	
    <section numbered="true" toc="default"> <name>TOPOLOGY Object</name>
	<t>This document defines a new TOPOLOGY object to carry the topology
	filter.</t>
	
   <t>The TOPOLOGY object is optional and specifies the sub-topology
   to be taken into account by the PCE during path computation. The 
   TOPOLOGY object can be carried within a PCReq message, or a PCRep
   message in case of unsuccessful path computation. </t>
	
    <t>TOPOLOGY Object-Class is TBD1.</t>

    <t>TOPOLOGY Object-Type is TBD2.</t>
	
	<t>The format of the TOPOLOGY object body is:</t>
	
	<figure title="TOPOLOGY Body Object Format">
        <artwork align="left" name="" type="" 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Reserved                        |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                      Optional TLVs                          //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	 ]]></artwork>
      </figure>
	  
	<t>Reserved (24 bits):  This field MUST be set to zero on transmission
      and MUST be ignored on receipt.</t>
	<t>Flags (8 bits):  No flags are currently defined.  Unassigned flags
      MUST be set to zero on transmission and MUST be ignored on
      receipt.</t>
	<t>The format of optional TLVs is defined in RFC5440 and may be used 
	to carry topology filter information as defined in section.</t>
	
	<section numbered="true" toc="default"> <name>Source Protocol TLV</name>

	<t>The Source Protocol TLV is optional and is defined to carry the
    protocol ID and Instance ID.</t>

   <t>The format of the Source Protocol TLV is:</t>
   
   <figure title="Source Protocol TLV" align="center">
     <artwork align="left"><![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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Type=TBD3             |            Length=12          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Protocol-ID  |                  Reserved                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Instance-ID                          |
    |                           (64 bits)                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             
    ]]></artwork>
   </figure>
   
   <t>The code point for the TLV type is TBD3. The TLV length is 12 octets.</t>
   
   <t>Protocol-ID (8 bits): defined in <xref target="RFC7752"></xref> section 3.2.
   IS-IS <xref target="RFC8202"></xref> and OSPF <xref target="RFC6549"></xref>
   MAY run multiple routing protocol instances identified by the Protocol-ID 
   over the same link.  </t>
   
   <t>Reserved (24 bits): This field MUST be set to zero on transmission
   and MUST be ignored on receipt.</t>
   
   <t>Instance-ID (64 bits): defined in <xref target="RFC7752"></xref> section 3.2.</t>
 
   </section>
	  
   <section numbered="true" toc="default"> <name>Multi-topology TLV</name>
	
   <t>The Multi-topology TLV is optional and is defined to carry the
   multi-topology ID.</t>

   <t>The format of the Multi-topology TLV is :</t>
  
  
  <figure title="Multi-topology TLV" align="center">
     <artwork align="center"><![CDATA[
	 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Type=TBD4             |            Length=4           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R R R R|   Multi-Topology ID   |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             
    ]]></artwork>
   </figure> 
   
   <t>The code point for the sub-TLV type is TBD4. The sub-TLV length is 4 octets.</t>
   
   <t>Multi-Topology ID (12 bits): Semantics of the IS-IS MT-ID are defined
   in Section 7.2 of <xref target="RFC5120"></xref>. Semantics of the OSPF MT-ID are defined
   in Section 3.7 of <xref target="RFC4915"></xref>. As defined in section 3.2.1.5 
   of <xref target="RFC7752"></xref>, if the value is derived from OSPF, then
   the upper 9 bits MUST be set to 0.  Bits R are reserved and SHOULD be
   set to 0 when originated and ignored on receipt.</t>
   
   <t>Reserved (16 bits): This field MUST be set to zero on transmission
   and MUST be ignored on receipt.</t>
   
   </section>
	
   <section numbered="true" toc="default"> <name>Area TLV</name>
   	<t>The Area TLV is optional and is defined to carry the
    Area ID.</t>

	<t>The format of the Area TLV is :</t>
	
	<figure title="Area TLV" align="center">
     <artwork align="left"><![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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Type=TBD5        |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                 Area ID (variable)                         //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             
    ]]></artwork>
   </figure>
   
    <t>The code point for the TLV type is TBD3. The TLV length is variable.</t>
    <t>Area-ID: Area identifier as defined in RFC7752.</t>
   
   
   </section>
   
   <section numbered="true" toc="default"> <name>Algorithm TLV</name>
   
    <t>The Algorithm TLV is optional and is defined to carry the
    Algorithm ID.</t>

   <t>The Algorithm TLV MAY be inserted so as to provide the Flex-algo 
   plane information for the computed path. The format of the TLV is 
   defined in draft-tokar-pce-sid-algo-04 section 3.4.</t>
   
   </section>
   </section>
   
   <section numbered="true" toc="default"> <name>IRO Object</name>
	
	<t>As per [RFC5440], IRO can be used to specify that the computed path
   needs to traverse a set of specified network elements or abstract
   nodes. This document proposed a set of extensions for topology filter.</t>
   
   <section numbered="true" toc="default"> <name>Link ID</name>
   <t>The Link ID is used to include the link that is used 
   during the path calculation.</t> 
   
   <t>The Link ID subobject is defined:</t>
   
	<figure title="Link ID subobject in IRO">
        <artwork align="left" name="" type="" 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type=TBD6   |     Length    |         Reserved              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Link ID (4 bytes)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   	 ]]></artwork>
      </figure>
   <t>The code point for the TLV type is TBD6. The TLV length is 12 octets.</t>
   
   <t>Link ID (32bits ): defined in IS-IS RFC5307 and OSPF RFC3630.</t>
   
   </section>
   
   <section numbered="true" toc="default"> <name>Admin Group</name>
   
   <t>The Admin Group is used to include the links that is used 
   during the path calculation.</t> 
   
   <figure title="Admin Group subobject in IRO" align="center">
     <artwork align="left"><![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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type=TBD7   |     Length    |         Reserved              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Extended Admin Group                     |
   +-                                                             -+
   |                            ...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ]]></artwork>
   </figure>
   
    <t>The code point for the TLV type is TBD7. The TLV length is variable.</t>
    <t>Extended Administrative Group: Extended Administrative Group as
      defined in [RFC7308].</t>  
	</section>
	
  <section numbered="true" toc="default"> <name>Source Protocol</name>
	
  <t>The format of the Source Protocol subobject is:</t>
   
   <figure title="Source Protocol subobject in IRO" align="center">
     <artwork align="left"><![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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Type=TBD8    |     Length    |   Reserved    | Protocol-ID   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Instance-ID                          |
    |                           (64 bits)                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             
    ]]></artwork>
   </figure>
   
   <t>The code point for the TLV type is TBD8. The TLV length is 12 octets.</t>
   
   <t>Protocol-ID (8 bits): defined in <xref target="RFC7752"></xref> section 3.2.
   IS-IS <xref target="RFC8202"></xref> and OSPF <xref target="RFC6549"></xref>
   MAY run multiple routing protocol instances identified by the Protocol-ID 
   over the same link.  </t>
   
   <t>Reserved (24 bits): This field MUST be set to zero on transmission
   and MUST be ignored on receipt.</t>
   
   <t>Instance-ID (64 bits): defined in <xref target="RFC7752"></xref> section 3.2.</t>
   </section>
  </section> 
  
    <section numbered="true" toc="default"> <name>XRO Object</name>
	
	<t> As per [RFC5521], XRO is an optional object used to specify 
	exclusion of certain abstract nodes or resources from the whole path.
	This document proposed a set of extensions for topology filter.</t>
   
   <section numbered="true" toc="default"> <name>Link ID</name>
   
     <t>The Link ID is used to exclude the link that is used 
   during the path calculation.</t> 
   
   <t>The Link ID subobject is defined:</t>
   
	<figure title="Link ID subobject in XRO">
        <artwork align="left" name="" type="" 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type=TBD9   |     Length    |         Reserved              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Link ID (4 bytes)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   	 ]]></artwork>
      </figure>
   <t>The code point for the TLV type is TBD9. The TLV length is 12 octets.</t>
   
   <t>Link ID (32bits ): defined in IS-IS RFC5307 and OSPF RFC3630.</t>
   
   </section>
   
   <section numbered="true" toc="default"> <name>Admin Group</name>
   
   <t>The Admin Group is used to exclude the links that is used 
   during the path calculation.</t> 
   
   <figure title="Admin Group subobject in XRO" align="center">
     <artwork align="left"><![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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type=TBD10  |     Length    |         Reserved              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Extended Admin Group                     |
   +-                                                             -+
   |                            ...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ]]></artwork>
   </figure>
   
    <t>The code point for the TLV type is TBD10. The TLV length is variable.</t>
    <t>Extended Administrative Group: Extended Administrative Group as
      defined in [RFC7308].</t>  
	</section>
	
  <section numbered="true" toc="default"> <name>Source Protocol</name>
	
  <t>The format of the Source Protocol subobject is:</t>
   
   <figure title="Source Protocol subobject in XRO" align="center">
     <artwork align="left"><![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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type=TBD11  |     Length    |   Reserved    | Protocol-ID   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Instance-ID                          |
    |                           (64 bits)                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             
    ]]></artwork>
   </figure>
   
   <t>The code point for the TLV type is TBD11. The TLV length is 12 octets.</t>
   
   <t>Protocol-ID (8 bits): defined in <xref target="RFC7752"></xref> section 3.2.
   IS-IS <xref target="RFC8202"></xref> and OSPF <xref target="RFC6549"></xref>
   MAY run multiple routing protocol instances identified by the Protocol-ID 
   over the same link.  </t>
   
   <t>Reserved (24 bits): This field MUST be set to zero on transmission
   and MUST be ignored on receipt.</t>
   
   <t>Instance-ID (64 bits): defined in <xref target="RFC7752"></xref> section 3.2.</t>
   </section>
  </section>
	 
	<section numbered="true" toc="default"> <name>Procedures</name>
	
	<t>A PCC MAY insert a TOPOLOGY object to indicate the sub-topology of 
	an IGP domain that MUST be considered by the PCE. The PCE will perform
	path computation based on the sub-topology identified by the topology
	filter rules that can be applied on either the native topology or a user 
	specified topology. The absence of the TLVs related topology reference
	indicates that the filtering rules are to be applied on the native topology.</t>
	
   </section>
	</section>

   <section numbered="true" toc="default"> <name>Acknowledgements</name>
   <t>TBA</t>
   </section>
	
   <section numbered="true" toc="default"> <name>IANA Considerations</name>
	<section numbered="true" toc="default"> <name>TOPOLOGY Object</name>
	<t>IANA is requested to make allocations for Topology Object from the registry, as follows: </t>
	  <table anchor="table_1" align="center">
          <name>TLVs for Topology Object</name>
          <thead>
            <tr>
              <th align="center">Type</th>
              <th align="center">TLV</th>
              <th align="center">Reference</th>			  
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">TBD1</td>
              <td align="center">Source Protocol TLV</td>
              <td align="center">[this document]</td>			  
            </tr>
            <tr>
              <td align="center">TBD2</td>			
              <td align="center">Multi-topology TLV</td>
              <td align="center">[this document]</td>
            </tr>
            <tr>
              <td align="center">TBD3</td>
              <td align="center">Area TLV</td>
              <td align="center">[this document]</td>
            </tr>
			 <tr>
              <td align="center">TBD4</td>
              <td align="center">Algorithm TLV</td>
              <td align="center">draft-tokar-pce-sid-algo</td>
            </tr>
          </tbody>
        </table>
    </section> 
    <section numbered="true" toc="default"> <name>IRO Object</name>
	<t>IANA is requested to make allocations for IRO Object from the registry, as follows: </t>
	
		  <table anchor="table_2" align="center">
          <name>Subobjects for IRO Object</name>
          <thead>
            <tr>
              <th align="center">Type</th>
              <th align="center">Subobject</th>
              <th align="center">Reference</th>			  
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">TBD5</td>
              <td align="center">Link ID</td>
              <td align="center">[this document]</td>			  
            </tr>
            <tr>
              <td align="center">TBD6</td>			
              <td align="center">Admin Group</td>
              <td align="center">[this document]</td>
            </tr>
            <tr>
              <td align="center">TBD7</td>
              <td align="center">Source Protocol</td>
              <td align="center">[this document]</td>
            </tr>
          </tbody>
        </table>
	</section>
	
    <section numbered="true" toc="default"> <name>XRO Object</name>
    <t>IANA is requested to make allocations for XRO Object from the registry, as follows: </t>
	
	 <table anchor="table_3" align="center">
          <name>Subobjects for XRO Object</name>
          <thead>
            <tr>
              <th align="center">Type</th>
              <th align="center">Subobject</th>
              <th align="center">Reference</th>			  
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">TBD8</td>
              <td align="center">Link ID</td>
              <td align="center">[this document]</td>			  
            </tr>
            <tr>
              <td align="center">TBD9</td>			
              <td align="center">Admin Group</td>
              <td align="center">[this document]</td>
            </tr>
            <tr>
              <td align="center">TBD10</td>
              <td align="center">Source Protocol</td>
              <td align="center">[this document]</td>
            </tr>
          </tbody>
        </table>
	</section>
   </section>
   
   <section  numbered="true" toc="default"> <name>Security Considerations</name>
   <t>TBA</t>
   </section>
  </middle>
  
  <!--  *****BACK MATTER ***** -->

 <back>
   <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
		<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <seriesInfo name="DOI" value="10.17487/RFC2119"/>
            <seriesInfo name="RFC" value="2119"/>
            <seriesInfo name="BCP" value="14"/>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization/>
            </author>
            <date year="1997" month="March"/>
          </front>
        </reference>
		<reference anchor="RFC5440" target="https://www.rfc-editor.org/info/RFC5440">
		<front>
            <title>Path Computation Element (PCE) Communication Protocol (PCEP)</title>
			<author>
              <organization/>
            </author>
			<date year="2009" month="March"/>
          </front>
        </reference>
		<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/RFC8174">
		<front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
			<author>
              <organization/>
            </author>
			<date year="2017" month="May"/>
          </front>
        </reference>
		<reference anchor="RFC8231" target="https://www.rfc-editor.org/info/RFC8231">
		<front>
            <title>Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE</title>
			<author>
              <organization/>
            </author>
			<date year="2017" month="September"/>			
          </front>
        </reference>
		<reference anchor="RFC7752" target="https://www.rfc-editor.org/info/RFC7752">
		<front>
            <title>North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP</title>
			<author>
              <organization/>
            </author>
			<date year="2016" month="March"/>
          </front>
        </reference>
		<reference anchor="RFC5120" target="https://www.rfc-editor.org/info/RFC5120">
		<front>
            <title>M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)</title>
			<author>
              <organization/>
            </author>
			<date year="2008" month="February"/>
          </front>
        </reference>
		<reference anchor="RFC4915" target="https://www.rfc-editor.org/info/RFC4915">
		<front>
            <title>Multi-Topology (MT) Routing in OSPF</title>
			<author>
              <organization/>
            </author>
			<date year="2007" month="June"/>
          </front>
        </reference>
		<reference anchor="RFC4655" target="https://www.rfc-editor.org/info/RFC4655">
		<front>
            <title>A Path Computation Element (PCE)-Based Architecture</title>
			<author>
              <organization/>
            </author>
			<date year="2006" month="August"/>
          </front>
        </reference>		
        <reference anchor="RFC6549" target="https://www.rfc-editor.org/info/RFC6549">
		<front>
            <title>OSPFv2 Multi-Instance Extensions</title>
			<author>
              <organization/>
            </author>
			<date year="2012" month="March"/>
          </front>
        </reference>
        <reference anchor="RFC8795" target="https://www.rfc-editor.org/info/RFC8795">
		<front>
            <title>YANG Data Model for Traffic Engineering (TE) Topologies</title>
			<author>
              <organization/>
            </author>
			<date year="2020" month="August"/>
          </front>
        </reference>
        <reference anchor="RFC8202" target="https://www.rfc-editor.org/info/RFC8202">
		<front>
            <title>IS-IS Multi-Instance</title>
			<author>
              <organization/>
            </author>
			<date year="2017" month="June"/>
          </front>
        </reference>
        <reference anchor="draft-ietf-lsr-flex-algo" target="https://www.rfc-editor.org/info/draft-ietf-lsr-flex-algo">
		<front>
            <title>IGP Flexible Algorithm</title>
			<author>
              <organization/>
            </author>
			<date year="2021" month="July"/>
          </front>
        </reference>		
	</references>

    </references>
 </back>
</rfc>
