idnits 2.17.00 (12 Aug 2021) /tmp/idnits63208/draft-wang-lsr-isis-mfi-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 21, 2021) is 447 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Link State Routing Working Group Y. Wang 3 Internet-Draft Huawei 4 Intended status: Standards Track A. Wang 5 Expires: August 25, 2021 China Telecom 6 Z. Hu 7 T. Zhou 8 Huawei 9 February 21, 2021 11 IS-IS Multi-Flooding Instances 12 draft-wang-lsr-isis-mfi-00 14 Abstract 16 This document proposes a new IS-IS flooding mechanism which separates 17 multiple flooding instances for dissemination of routing information 18 and other types of application-specific information to minimizes the 19 impact of non-routing information flooding on the routing convergence 20 and stability. Due to different flooding information has different 21 requirements on the flooding rate, these multi-flooding instances 22 should be given various priorities and flooding parameters. An 23 encoding format for IS-IS Multi-Flooding Instance Identifier (MFI-ID) 24 TLV and Update Process are specified in this document. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on August 25, 2021. 49 Copyright Notice 51 Copyright (c) 2021 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. IS-IS Multi-Flooding Instances . . . . . . . . . . . . . . . 3 68 2.1. Multi-Flooding Instance Identifier . . . . . . . . . . . 4 69 2.2. Update Process Operation . . . . . . . . . . . . . . . . 4 70 2.3. Interoperability Considerations . . . . . . . . . . . . . 5 71 3. IS-IS Non-routing MFIs Omission of Routing Calculation . . . 5 72 4. Applicability of IS-IS Multi-Flooding Instances . . . . . . . 5 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 78 8.2. Informative References . . . . . . . . . . . . . . . . . 6 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 81 1. Introduction 83 [ISO10589] specifies the IS-IS protocol, in which each Intermediate 84 System (IS) (router) advertises one or more IS-IS Link State Protocol 85 Data Units (LSPs) with routing topology and Traffic Engineering (TE) 86 information. As the one-octet LSP Number field, there are limited 87 256 numbers of LSPs that may be assigned. However, with the 88 increasing amount of Topology information and TE information proposed 89 to be advertised, for example, advertisement of Virtual Transport 90 Networks (VTN) Topology, VTN Resource and VTN specific Data Plane 91 Identifiers [I-D.dong-lsr-sr-enhanced-vpn], there will be huge 92 consumption of LSPs. In addition, with the increasing use the same 93 mechanism for advertisement of application-specific information, 94 therefore, a mechanism should be defined for advertisement of 95 application-specific information that minimizes the impact on the 96 operation of the IS-IS protocol. 98 This document proposes a new IS-IS flooding mechanism which separates 99 multiple flooding instances for dissemination of routing information 100 and other types of application-specific information in a single IS-IS 101 protocol instance. This document therefore defines an encoding 102 format for IS-IS Multi-Flooding Instances Identifier (MFIs-ID) TLV 103 and MFIs Update Process. 105 For dissemination of generic information (GENINFO) not directly 106 related to the operation of the IS-IS protocol within the domain, 107 [RFC6823] defines a GENINFO TLV aand specifies that the advertisement 108 of GENINFO must occur in a non-zero instance of IS-IS protocol as 109 defined in [RFC8202] for minimizing the impact of advertisement of 110 GENINFO on the operation of routing. This document also recommends 111 the use of GENINFO TLV in a specific MFI for advertisement of GENINFO 112 in the zero IS-IS instance, which can isolate the impact of non- 113 routing information on the standard IS-IS operation. 115 Instead of using non-zero IS-IS instances, the advertisement of non- 116 routing information in MFIs is implemented in the zero IS-IS 117 instance, which simplifies the deployment. MFIs mechanism has a 118 lower cost to maintain neighbor because that all the MFIs share the 119 standard IS-IS instance neighbor. In addition, MFIs can be 120 configured with customized MFIs-specific flooding parameters 121 (including the retransmission interval, refresh timer, maximum age, 122 etc.). 124 Similarly, OSPF Multi-Flooding Instances will be proposed in the 125 future work. 127 2. IS-IS Multi-Flooding Instances 129 An existing protocol limitation is that a given IS-IS instance in a 130 single level supports a single update process operating on a single 131 Link State Database (LSDB). This document defines an extension to 132 IS-IS to allow one standard instance of the protocol to support 133 multiple update process operations. This extension is referred to as 134 "IS-IS Multi-Flooding Instances" (IS-IS MFIs). 136 Each update process is associated with a unique MFI. The behavior of 137 the standard update process is not changed in any way by the 138 extensions defined in this document. MFI-specific prioritization for 139 processing PDUs and MFI-specific flooding parameters should be 140 defined so as to allow different MFIs to consume network-wide 141 resources at different rates. The use of MFIs can enhance the 142 ability to isolate the resources associated with the standard update 143 process and other application-specific update process. 145 2.1. Multi-Flooding Instance Identifier 147 A Multi-Flooding Instance Identifier (MFI-ID) is introduced to 148 uniquely identify an IS-IS Multi-Flooding Instance and the associated 149 update process. The protocol extension includes a new TLV (i.e. 150 MFI-ID TLV) in each IS-IS PDU originated by an Intermediate System. 151 It is recommended that the MFI-ID TLV be the first TLV in the PDU, 152 which allows determination of the association of a PDU with a 153 particular MFI more quickly. Each IS-IS PDU is associated with only 154 one IS-IS MFI. 156 The MFI-ID TLV is carried in Link State PDUs (LSPs) and Sequence 157 Number PDUs (SNPs). MFI-IDs MUST be unique within the same routing 158 domain. The following format is used for the MFI-ID TLV: 160 No. of octets 161 +---------------+---------------+ 162 | Type | Length | 2 163 +---------------+---------------+ 164 | MFI-ID | 2 165 +-------------------------------+ 167 MFI-ID#0 is reserved for the routing flooding instance supported by 168 legacy systems. IS-IS LSPs and SNPs do not carry the MFI-ID TLV, 169 which indicates these PDUs are associated with the routing flooding 170 instance in the zero IS-IS instance. 172 2.2. Update Process Operation 174 In this document, MFIs can be created in a single IS-IS instance. 175 Different application information can be advertised to all the other 176 Intermediate systems in the corresponding MFI. 178 The Update Process in an Intermediate system shall generate one or 179 more new Link State PDUs. Each Level 1/Level 2 Link State PDU 180 associated with a specific MFI carries application information 181 belonging to the specific MFI. And Level 1/Level 2 PSNP and Level 1/ 182 Level 2 CSNP containing information about LSPs that transmitted in a 183 specific MFI are generated to synchronize the LSDB corresponding to 184 the specific MFI. 186 In each MFI, update parameters can be customized differently. As 187 specified in [ISO10589], parameters include the LSP MaxAge, LSP 188 Refresh time, LSP retransmission interval, Maximum LSP Generation 189 interval, Minimum LSP Generation interval, Minimum LSP transmission 190 interval, PSNP sending interval, and CSNP sending interval. Note 191 that besides of different update parameters, any other elements in 192 these MFI-specific Update Process are same as the standard IS-IS 193 Update Process including Input and Output, Event driven LSP 194 Generation, action on receipt of a link state PDU, etc. 196 2.3. Interoperability Considerations 198 In the scenario where some routers that do not support MFI are 199 deployed in the same routing domain, it is recommended that all MFIs 200 in an IS-IS protocol instance share one LSP Number space. The total 201 number of LSPs in all MFIs cannot exceed 256. This implementation 202 mode of MFI can coexist with routers that do not support MFI. If 203 routers that do not support MFI receive the LSPs and SNPs encoding 204 MFI-ID TLV, then routers SHOULD ignore the MFI-ID TLV and continues 205 processing other TLVs. 207 In the scenario where all routers in the entire routing domain 208 support MFI, it is recommended that each MFI can has its separate LSP 209 Number space. Each MFI can have a maximum of 256 LSPs. Both LSP ID 210 and MFI are used to uniquely identify an LSP. 212 Note that the MFI mechanism does not affect neighbor relationship 213 establishment, shortest-path-first (SPF) algorithm and TE routing 214 calculation, but only affects IS-IS LSDB synchronization. 216 3. IS-IS Non-routing MFIs Omission of Routing Calculation 218 IS-IS standard routing related TLVs and TE related extended TLVs, for 219 example, IS Neighbors TLV and IP Reachability, are not included in 220 Non-routing Multi-flooding Instances. 222 4. Applicability of IS-IS Multi-Flooding Instances 224 In addition to IS-IS route flooding, more and more application 225 information and node capabilities that are not directly related to 226 IS-IS operations need to be advertised in the entire routing domain 227 through the IS-IS flooding mechanism. For example, the advertisement 228 of supported In-situ Flow Information Telemetry (IFIT) capabilities 229 at node and/or link granularity [I-D.wang-lsr-igp-extensions-ifit]. 231 5. IANA Considerations 233 IANA is requested to allocate values for the following new TLV. 235 +------+-------------+ 236 | Type | Description | 237 +------+-------------+ 238 | TBA | MFI-ID TLV | 239 +------+-------------+ 241 6. Security Considerations 243 It does not introduce any new security risks to IS-IS. 245 7. Acknowledgements 247 TBD 249 8. References 251 8.1. Normative References 253 [ISO10589] 254 "International Organization for Standardization, 255 "Information technology -- Telecommunications and 256 information exchange between systems -- Intermediate 257 System to Intermediate System intra-domain routing 258 information exchange protocol for use in conjunction with 259 the protocol for providing the connectionless-mode network 260 service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, 261 November 2002.", 262 . 264 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, 266 DOI 10.17487/RFC2119, March 1997, 267 . 269 8.2. Informative References 271 [I-D.dong-lsr-sr-enhanced-vpn] 272 "IGP Extensions for Segment Routing based Enhanced VPN", 273 . 276 [I-D.wang-lsr-igp-extensions-ifit] 277 "IGP Extensions for In-situ Flow Information Telemetry 278 (IFIT) Capability Advertisement", 279 . 282 [RFC6823] "Advertising Generic Information in IS-IS", 283 . 285 [RFC8202] "IS-IS Multi-Instance", 286 . 288 Authors' Addresses 290 Yali Wang 291 Huawei 292 156 Beiqing Rd., Haidian District 293 Beijing 294 China 296 Email: wangyali11@huawei.com 298 Aijun Wang 299 China Telecom 300 Beiqijia Town, Changping District 301 Beijing 302 China 304 Email: wangaj3@chinatelecom.cn 306 Zhibo Hu 307 Huawei 308 156 Beiqing Rd., Haidian District 309 Beijing 310 China 312 Email: huzhibo@huawei.com 314 Tianran Zhou 315 Huawei 316 156 Beiqing Rd., Haidian District 317 Beijing 318 China 320 Email: zhoutianran@huawei.com