idnits 2.17.00 (12 Aug 2021) /tmp/idnits24327/draft-pkaneria-lsr-multi-tlv-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7356]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (21 January 2022) is 113 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: 1 error (**), 0 flaws (~~), 0 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LSR Working Group P. Kaneriya 3 Internet-Draft Tony. Li 4 Intended status: Standards Track Antoni. Przygienda 5 Expires: 25 July 2022 S. Hegde 6 C. Bowers 7 Juniper Networks 8 L. Ginsberg 9 Cisco Systems 10 21 January 2022 12 Multiple TLV Instances in IS-IS 13 draft-pkaneria-lsr-multi-tlv-00 15 Abstract 17 Emerging technologies are adding information into IS-IS TLVs at a 18 steady pace while deployment scales are simultaneously increasing. 19 This causes the contents of many critical TLVs to exceed the 20 currently supported limit of 255 octets. Extensions such as 21 [RFC7356] require significant IS-IS changes that could help address 22 the problem, but a less drastic solution would be beneficial. This 23 document codifies the common mechanism of extending the TLV space 24 through multiple TLV instances. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 25 July 2022. 43 Copyright Notice 45 Copyright (c) 2022 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 61 3. Procedure for Advertising Multiple TLV Instances . . . . . . 3 62 4. Procedure for Receiving Multiple TLV Instances . . . . . . . 4 63 5. Operational Considerations . . . . . . . . . . . . . . . . . 4 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 68 8.2. Informative References . . . . . . . . . . . . . . . . . 5 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 The continued growth of the Internet has resulted in a commensurate 74 growth in the scale of service provider networks and the amount of 75 information carried in IS-IS [ISO10589] Type-Length-Value (TLV) 76 tuples. Simultaneously, new traffic engineering technologies are 77 defining new attributes, further adding to the scaling pressures. 78 The original TLV definition allows for 255 octets of payload, which 79 is becoming increasingly inadequate. 81 Some TLV definitions have addressed this by explicitly stating that a 82 TLV may appear multiple times inside of an LSP. However, this has 83 not been done for many legacy TLVs, leaving the situation ambiguous. 84 The intent of this document is to clarify the situation by explicitly 85 defining the use of multiple instances of TLVs as the mechanism for 86 scaling TLV contents, except where explicitly prohibited. 88 Today, as an example, the Extended IS Reachability TLV (22) [RFC5305] 89 and MT Intermediate Systems TLV (222) [RFC5120] are TLVs where 90 existing standards do not specify the behavior expected when multiple 91 copies of the TLV are present and no other mechanism for expanding 92 the information carrying capacity of the TLV has been specified. 94 [RFC7356] has proposed a 16 bit length field for TLVs in flooding 95 scoped Protocol Data Units (PDUs), but does nothing to address legacy 96 implementations that do not yet implement the full breadth and scope 97 of that RFC. 99 2. Requirements Language 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in BCP 104 14 [RFC2119] [RFC8174] when, and only when, they appear in all 105 capitals, as shown here. 107 3. Procedure for Advertising Multiple TLV Instances 109 If the TLV contains information that specifies the applicability of 110 its contents (i.e., a key), the key information MUST be replicated in 111 additional TLV instances so that all contents specific to that key 112 can be identified. This allows more sub-TLVs to be advertised for 113 the same key information. The specification of the key for a given 114 TLV is out of scope for this document. 116 This should be applied recursively. If a TLV is structured with sub- 117 TLVs and sub-sub-TLVs, then replication of key information allows for 118 the advertisement of additional sub-TLVs and sub-sub-TLVs for that 119 key. 121 Note: If the fixed portion of a TLV includes information that is NOT 122 part of the key and the non-key elements of the fixed portion of the 123 TLV (metric and other bits in the control octet in the example below) 124 differ, the values in the first TLV present in the lowest numbered 125 LSP MUST be used. 127 As an example, consider the Extended IP Reachability TLV (type 135). 128 A prefix in this TLV is specified by: 130 * 4 octets of metric information 132 * 1 octet of control information which includes 6 bits specifying 133 the prefix length 135 * 0-4 octets of IPv4 prefix 137 followed by up to 250 octets of sub-TLV information. 139 The key consists of the 6 bits of prefix length and the 0-4 octets of 140 IPv4 prefix. 142 If this is insufficient sub-TLV space, then the node MAY advertise 143 additional instances of the Extended IS Reachability TLV. The key 144 information MUST be replicated identically and the additional sub-TLV 145 space may be populated with additional information. The complete 146 information for a given key in such cases is the joined set of all 147 the carried information under the key in all the TLV instances. 149 4. Procedure for Receiving Multiple TLV Instances 151 A node that receives multiple TLV instances MUST accept all of the 152 information in all of the instances. The order of arrival and 153 placement of the TLV instances in LSP fragments MUST NOT change the 154 behavior of the node once all the fragments have been received. 156 The contents of multiple TLV instances of the same type should be 157 processed as if they were concatenated. If the internals of the TLV 158 contain key information, then replication of the key information 159 should be taken to indicate that subsequent data should be processed 160 as if the subsequent data were concatenated. 162 Specifically, if a TLV is structured with sub-TLVs and key 163 information is replicated, then the sub-TLVs should be processed as 164 if they were concatenated. 166 This process should be applied recursively. If a TLV is structured 167 with sub-TLVs and sub-sub-TLVs with replicated key information at all 168 levels, then sub-sub-TLVs should be processed as if they were 169 concatenated. 171 For example, suppose that a node received an LSP with multiple 172 instances of the Extended IS Reachability TLV. The first instance 173 contained key information K with sub-TLVs A, B, and C. The second 174 instance contained key information K with sub-TLVs D, E, and F. The 175 receiving node should then process this as having key information K 176 and sub-TLVs A, B, C, D, E, F, or, because ordering is irrelevant, 177 sub-TLVs D, E, F, A, B, C. 179 5. Operational Considerations 181 The generation of multiple TLVs for a given object is triggered by 182 more information than will fit into a single TLV. If multiple TLVs 183 are advertised in the presence of nodes which do not support multiple 184 TLVs, operation of routing in the network is likely to be 185 compromised. 187 6. IANA Considerations 189 This document makes no requests of IANA. 191 7. Security Considerations 193 This document creates no new security issues for IS-IS. Additional 194 instances of existing TLVs expose no new information. 196 Security concerns for IS-IS are addressed in [ISO10589], [RFC5304], 197 and [RFC5310]. 199 8. References 201 8.1. Normative References 203 [ISO10589] ISO, "Intermediate system to Intermediate system routing 204 information exchange protocol for use in conjunction with 205 the Protocol for providing the Connectionless-mode Network 206 Service (ISO 8473)", August 1987, . 208 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 209 Requirement Levels", BCP 14, RFC 2119, 210 DOI 10.17487/RFC2119, March 1997, 211 . 213 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 214 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 215 2008, . 217 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 218 and M. Fanto, "IS-IS Generic Cryptographic 219 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 220 2009, . 222 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 223 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 224 May 2017, . 226 8.2. Informative References 228 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 229 Topology (MT) Routing in Intermediate System to 230 Intermediate Systems (IS-ISs)", RFC 5120, 231 DOI 10.17487/RFC5120, February 2008, 232 . 234 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 235 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 236 2008, . 238 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 239 Scope Link State PDUs (LSPs)", RFC 7356, 240 DOI 10.17487/RFC7356, September 2014, 241 . 243 Authors' Addresses 245 Parag Kaneriya 246 Juniper Networks 247 Elnath-Exora Business Park Survey 248 Bangalore 560103 249 Karnataka 250 India 252 Email: pkaneria@juniper.net 254 Tony Li, 255 Juniper Networks 256 1133 Innovation Way 257 Sunnyvale, California 94089 258 United States of America 260 Email: tony.li@tony.li 262 Antoni Przygienda, 263 Juniper Networks 264 1133 Innovation Way 265 Sunnyvale, California 94089 266 United States of America 268 Email: prz@juniper.net 270 Shraddha Hegde 271 Juniper Networks 272 Elnath-Exora Business Park Survey 273 Bangalore 560103 274 Karnataka 275 India 277 Email: shraddha@juniper.net 278 Chris Bowers 279 Juniper Networks 280 1133 Innovation Way 281 Sunnyvale, California 94089 282 United States of America 284 Email: cbower@juniper.net 286 Les Ginsberg 287 Cisco Systems 288 821 Alder Drive 289 Milpitas, CA 95035 290 United States of America 292 Email: ginsberg@cisco.com