Link State Routing Working Group Y. Wang Internet-Draft Huawei Intended status: Standards Track A. Wang Expires: August 25, 2021 China Telecom Z. Hu T. Zhou Huawei February 21, 2021 IS-IS Multi-Flooding Instances draft-wang-lsr-isis-mfi-00 Abstract 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. Requirements Language 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 RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 25, 2021. Wang, et al. Expires August 25, 2021 [Page 1] Internet-Draft draft-wang-lsr-isis-mfi-00 February 2021 Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. IS-IS Multi-Flooding Instances . . . . . . . . . . . . . . . 3 2.1. Multi-Flooding Instance Identifier . . . . . . . . . . . 4 2.2. Update Process Operation . . . . . . . . . . . . . . . . 4 2.3. Interoperability Considerations . . . . . . . . . . . . . 5 3. IS-IS Non-routing MFIs Omission of Routing Calculation . . . 5 4. Applicability of IS-IS Multi-Flooding Instances . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction [ISO10589] 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 [I-D.dong-lsr-sr-enhanced-vpn], 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. Wang, et al. Expires August 25, 2021 [Page 2] Internet-Draft draft-wang-lsr-isis-mfi-00 February 2021 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. For dissemination of generic information (GENINFO) not directly related to the operation of the IS-IS protocol within the domain, [RFC6823] 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 [RFC8202] 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. 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.). Similarly, OSPF Multi-Flooding Instances will be proposed in the future work. 2. IS-IS Multi-Flooding Instances 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). 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. Wang, et al. Expires August 25, 2021 [Page 3] Internet-Draft draft-wang-lsr-isis-mfi-00 February 2021 2.1. Multi-Flooding Instance Identifier 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. 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: No. of octets +---------------+---------------+ | Type | Length | 2 +---------------+---------------+ | MFI-ID | 2 +-------------------------------+ 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. 2.2. Update Process Operation 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. 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. In each MFI, update parameters can be customized differently. As specified in [ISO10589], 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 Wang, et al. Expires August 25, 2021 [Page 4] Internet-Draft draft-wang-lsr-isis-mfi-00 February 2021 Update Process including Input and Output, Event driven LSP Generation, action on receipt of a link state PDU, etc. 2.3. Interoperability Considerations 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. 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. 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. 3. IS-IS Non-routing MFIs Omission of Routing Calculation 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. 4. Applicability of IS-IS Multi-Flooding Instances 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 [I-D.wang-lsr-igp-extensions-ifit]. 5. IANA Considerations IANA is requested to allocate values for the following new TLV. +------+-------------+ | Type | Description | +------+-------------+ | TBA | MFI-ID TLV | +------+-------------+ Wang, et al. Expires August 25, 2021 [Page 5] Internet-Draft draft-wang-lsr-isis-mfi-00 February 2021 6. Security Considerations It does not introduce any new security risks to IS-IS. 7. Acknowledgements TBD 8. References 8.1. Normative References [ISO10589] "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.", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 8.2. Informative References [I-D.dong-lsr-sr-enhanced-vpn] "IGP Extensions for Segment Routing based Enhanced VPN", . [I-D.wang-lsr-igp-extensions-ifit] "IGP Extensions for In-situ Flow Information Telemetry (IFIT) Capability Advertisement", . [RFC6823] "Advertising Generic Information in IS-IS", . [RFC8202] "IS-IS Multi-Instance", . Wang, et al. Expires August 25, 2021 [Page 6] Internet-Draft draft-wang-lsr-isis-mfi-00 February 2021 Authors' Addresses Yali Wang Huawei 156 Beiqing Rd., Haidian District Beijing China Email: wangyali11@huawei.com Aijun Wang China Telecom Beiqijia Town, Changping District Beijing China Email: wangaj3@chinatelecom.cn Zhibo Hu Huawei 156 Beiqing Rd., Haidian District Beijing China Email: huzhibo@huawei.com Tianran Zhou Huawei 156 Beiqing Rd., Haidian District Beijing China Email: zhoutianran@huawei.com Wang, et al. Expires August 25, 2021 [Page 7]