<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?> 
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-wang-lsr-isis-mfi-00"
     ipr="trust200902">
  <front>
    <title abbrev="draft-wang-lsr-isis-mfi-00"> 
	IS-IS Multi-Flooding Instances</title>

    <author fullname="Yali Wang" initials="Y." surname="Wang">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>156 Beiqing Rd., Haidian District</street>

          <city>Beijing</city>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>wangyali11@huawei.com</email>

        <uri/>
      </address>
    </author>
	
	
	<author fullname="Aijun Wang" initials="A." surname="Wang">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street>Beiqijia Town, Changping District</street>

          <city>Beijing</city>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>wangaj3@chinatelecom.cn</email>

        <uri/>
      </address>
    </author>

	<author fullname="Zhibo Hu" initials="Z." surname="Hu">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>156 Beiqing Rd., Haidian District</street>

          <city>Beijing</city>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>huzhibo@huawei.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Tianran Zhou" initials="T." surname="Zhou">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>156 Beiqing Rd., Haidian District</street>

          <city>Beijing</city>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>zhoutianran@huawei.com</email>

        <uri/>
      </address>
    </author>
	
    <date day="20" month="February" year="2021"/>

    <workgroup>Link State Routing Working Group</workgroup>

    <abstract>
		<t>This document proposes a new IS-IS flooding mechanism which separates multiple flooding instances for dissemination of routing information and other types of application-specific information to minimizes the impact of non-routing information flooding on the routing convergence and stability. Due to different flooding information has different requirements on the flooding rate, these multi-flooding instances should be given various priorities and flooding parameters. An encoding format for IS-IS Multi-Flooding Instance Identifier (MFI-ID) TLV and Update Process are specified in this document.</t>
    </abstract>

    <note title="Requirements Language">
		<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">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">	
		<t><xref target="ISO10589"></xref> specifies the IS-IS protocol, in which each Intermediate System (IS) (router) advertises one or more IS-IS Link State Protocol Data Units (LSPs) with routing topology and Traffic Engineering (TE) information. As the one-octet LSP Number field, there are limited 256 numbers of LSPs that may be assigned. However, with the increasing amount of Topology information and TE information proposed to be advertised, for example, advertisement of Virtual Transport Networks (VTN) Topology, VTN Resource and VTN specific Data Plane Identifiers <xref target="I-D.dong-lsr-sr-enhanced-vpn"></xref>, there will be huge consumption of LSPs. In addition, with the increasing use the same mechanism for advertisement of application-specific information, therefore, a mechanism should be defined for advertisement of application-specific information that minimizes the impact on the operation of the IS-IS protocol.</t>
		
		<t>This document proposes a new IS-IS flooding mechanism which separates multiple flooding instances for dissemination of routing information and other types of application-specific information in a single IS-IS protocol instance. This document therefore defines an encoding format for IS-IS Multi-Flooding Instances Identifier (MFIs-ID) TLV and MFIs Update Process.</t>
				
		<t>For dissemination of generic information (GENINFO) not directly related to the operation of the IS-IS protocol within the domain, <xref target="RFC6823"></xref> defines a GENINFO TLV aand specifies that the advertisement of GENINFO must occur in a non-zero instance of IS-IS protocol as defined in <xref target="RFC8202"></xref> for minimizing the impact of advertisement of GENINFO on the operation of routing. This document also recommends the use of GENINFO TLV in a specific MFI for advertisement of GENINFO in the zero IS-IS instance, which can isolate the impact of non-routing information on the standard IS-IS operation.</t>	
		
		<t>Instead of using non-zero IS-IS instances, the advertisement of non-routing information in MFIs is implemented in the zero IS-IS instance, which simplifies the deployment. MFIs mechanism has a lower cost to maintain neighbor because that all the MFIs share the standard IS-IS instance neighbor. In addition, MFIs can be configured with customized MFIs-specific flooding parameters (including the retransmission interval, refresh timer, maximum age, etc.).</t>
		
		<t>Similarly, OSPF Multi-Flooding Instances will be proposed in the future work.</t>
    </section>


	<section title="IS-IS Multi-Flooding Instances">
		<t>An existing protocol limitation is that a given IS-IS instance in a single level supports a single update process operating on a single Link State Database (LSDB). This document defines an extension to IS-IS to allow one standard instance of the protocol to support multiple update process operations. This extension is referred to as "IS-IS Multi-Flooding Instances" (IS-IS MFIs).</t>
		
		<t>Each update process is associated with a unique MFI. The behavior of the standard update process is not changed in any way by the extensions defined in this document. MFI-specific prioritization for processing PDUs and MFI-specific flooding parameters should be defined so as to allow different MFIs to consume network-wide resources at different rates. The use of MFIs can enhance the ability to isolate the resources associated with the standard update process and other application-specific update process.</t>
		
		<section title="Multi-Flooding Instance Identifier">
			<t>A Multi-Flooding Instance Identifier (MFI-ID) is introduced to uniquely identify an IS-IS Multi-Flooding Instance and the associated update process. The protocol extension includes a new TLV (i.e. MFI-ID TLV) in each IS-IS PDU originated by an Intermediate System. It is recommended that the MFI-ID TLV be the first TLV in the PDU, which allows determination of the association of a PDU with a particular MFI more quickly. Each IS-IS PDU is associated with only one IS-IS MFI.</t>
			
			<t>The MFI-ID TLV is carried in Link State PDUs (LSPs) and Sequence Number PDUs (SNPs). MFI-IDs MUST be unique within the same routing domain. The following format is used for the MFI-ID TLV:</t>
			<t><figure align="center">
			<artwork><![CDATA[
                                  No. of octets   
+---------------+---------------+
|      Type     |      Length   |      2
+---------------+---------------+
|            MFI-ID             |      2
+-------------------------------+ 
]]></artwork>
			</figure></t>
			
			<t>MFI-ID#0 is reserved for the routing flooding instance supported by legacy systems. IS-IS LSPs and SNPs do not carry the MFI-ID TLV, which indicates these PDUs are associated with the routing flooding instance in the zero IS-IS instance.</t>	
		</section>
		
		<section title="Update Process Operation">
			<t>In this document, MFIs can be created in a single IS-IS instance. Different application information can be advertised to all the other Intermediate systems in the corresponding MFI.</t>
			
			<t>The Update Process in an Intermediate system shall generate one or more new Link State PDUs. Each Level 1/Level 2 Link State PDU associated with a specific MFI carries application information belonging to the specific MFI. And Level 1/Level 2 PSNP and Level 1/Level 2 CSNP containing information about LSPs that transmitted in a specific MFI are generated to synchronize the LSDB corresponding to the specific MFI.</t>
			
			<t>In each MFI, update parameters can be customized differently. As specified in <xref target="ISO10589"></xref>, parameters include the LSP MaxAge, LSP Refresh time, LSP retransmission interval, Maximum LSP Generation interval, Minimum LSP Generation interval, Minimum LSP transmission interval, PSNP sending interval, and CSNP sending interval. Note that besides of different update parameters, any other elements in these MFI-specific Update Process are same as the standard IS-IS Update Process including Input and Output, Event driven LSP Generation, action on receipt of a link state PDU, etc.</t>
		</section>
		
		<section title="Interoperability Considerations">
			<t>In the scenario where some routers that do not support MFI are deployed in the same routing domain, it is recommended that all MFIs in an IS-IS protocol instance share one LSP Number space. The total number of LSPs in all MFIs cannot exceed 256. This implementation mode of MFI can coexist with routers that do not support MFI. If routers that do not support MFI receive the LSPs and SNPs encoding MFI-ID TLV, then routers SHOULD ignore the MFI-ID TLV and continues processing other TLVs.</t>
			
			<t>In the scenario where all routers in the entire routing domain support MFI, it is recommended that each MFI can has its separate LSP Number space. Each MFI can have a maximum of 256 LSPs. Both LSP ID and MFI are used to uniquely identify an LSP.</t>

			<t>Note that the MFI mechanism does not affect neighbor relationship establishment, shortest-path-first (SPF) algorithm and TE routing calculation, but only affects IS-IS LSDB synchronization.</t>
		</section>
		
	</section>
	
	<section title="IS-IS Non-routing MFIs Omission of Routing Calculation">
		<t>IS-IS standard routing related TLVs and TE related extended TLVs, for example, IS Neighbors TLV and IP Reachability, are not included in Non-routing Multi-flooding Instances.</t>
	</section>
	
	<section title="Applicability of IS-IS Multi-Flooding Instances">
		<t>In addition to IS-IS route flooding, more and more application information and node capabilities that are not directly related to IS-IS operations need to be advertised in the entire routing domain through the IS-IS flooding mechanism. For example, the advertisement of supported In-situ Flow Information Telemetry (IFIT) capabilities at node and/or link granularity <xref target="I-D.wang-lsr-igp-extensions-ifit"></xref>.</t>
	</section>

    <section anchor="IANA" title="IANA Considerations">
        <t>IANA is requested to allocate values for the following new TLV.</t>

        <texttable align="center">
          <ttcol>Type</ttcol>

          <ttcol>Description</ttcol>

          <c>TBA</c>

          <c>MFI-ID TLV</c>
		  
        </texttable>
    </section>
	
	<section anchor="Security" title="Security Considerations">
      <t>It does not introduce any new security risks to IS-IS.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>TBD</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <reference anchor="ISO10589"
                 target="https://www.iso.org/standard/30932.html">
        <front>
          <title>International Organization for Standardization, "Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, November 2002.</title>
          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>
	  
	</references>

    <references title="Informative References">
		<reference anchor="RFC6823"
                 target="https://www.rfc-editor.org/info/rfc6823">
        <front>
          <title>Advertising Generic Information in IS-IS</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
		</reference>
	  
		<reference anchor="RFC8202"
                 target="https://www.rfc-editor.org/info/rfc8202">
        <front>
          <title>IS-IS Multi-Instance</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
		</reference>
		
		<reference anchor="I-D.wang-lsr-igp-extensions-ifit"
                 target="https://datatracker.ietf.org/doc/draft-wang-lsr-igp-extensions-ifit/">
        <front>
          <title>IGP Extensions for In-situ Flow Information Telemetry (IFIT) Capability Advertisement</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
		</reference>	 
		
		<reference anchor="I-D.dong-lsr-sr-enhanced-vpn"
                 target="https://datatracker.ietf.org/doc/draft-dong-lsr-sr-enhanced-vpn/">
        <front>
          <title>IGP Extensions for Segment Routing based Enhanced VPN</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
		</reference>	    
    </references>
	
  </back>
</rfc>
