idnits 2.17.1 draft-ietf-rift-kv-registry-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 document seems to lack an Introduction section. ** The abstract seems to contain references ([RIFT]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (20 September 2021) is 946 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) == Outdated reference: A later version (-21) exists of draft-ietf-rift-rift-13 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RIFT J. Head, Ed. 3 Internet-Draft T. Przygienda 4 Intended status: Standards Track Juniper Networks 5 Expires: 24 March 2022 20 September 2021 7 RIFT Keys Structure and Well-Known Registry in Key Value TIE 8 draft-ietf-rift-kv-registry-00 10 Abstract 12 Routing in Fat-Trees RIFT [RIFT] allows for key/value pairs to be 13 advertised within Key-Value Topology Information Elements (KV TIEs). 14 The data contained within these KV TIEs can be used for any 15 imaginable purpose. This document defines the various Key Types 16 (i.e. Well-Known, OUI, and Experimental) and a method to structure 17 corresponding values. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 24 March 2022. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Description . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Key-Value Pair Structure . . . . . . . . . . . . . . . . . . 2 60 2.1. Well-Known Key Type . . . . . . . . . . . . . . . . . . . 3 61 2.2. OUI Key Type . . . . . . . . . . . . . . . . . . . . . . 4 62 2.3. Experimental Key Type . . . . . . . . . . . . . . . . . . 4 63 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. Key Type Registry . . . . . . . . . . . . . . . . . . . . 5 65 3.1.1. Requested Entries . . . . . . . . . . . . . . . . . . 5 66 3.2. Experimental Key Type . . . . . . . . . . . . . . . . . . 5 67 3.2.1. Requested Entries . . . . . . . . . . . . . . . . . . 5 68 3.3. Well-Known Key Type . . . . . . . . . . . . . . . . . . . 5 69 3.3.1. Requested Entries . . . . . . . . . . . . . . . . . . 6 70 3.4. OUI Key Type . . . . . . . . . . . . . . . . . . . . . . 6 71 3.4.1. Requested Entries . . . . . . . . . . . . . . . . . . 6 72 4. Operational Considerations . . . . . . . . . . . . . . . . . 6 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 75 7. Normative References . . . . . . . . . . . . . . . . . . . . 7 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 78 1. Description 80 Routing in Fat-Trees (RIFT [RIFT]) allows for key/value pairs to be 81 advertised within Key-Value Topology Information Elements (KV TIEs). 82 There are no restrictions placed on the type of data that is 83 contained in KV TIEs nor what the data is used for. 85 This document defines a Key Type Registry to maintain Well-Known and 86 vendor specific Key Types in order to simplify interoperability 87 between implementations and eliminate the risk of collision for 88 future implementations. An Experimental Key Type is additionally 89 defined. 91 2. Key-Value Pair Structure 93 Figure 1 illustrates the generic Key-Value Pair structure. 95 0 1 2 3 96 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 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 | Key-Type | Key Identifier | 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 | Values (variable) | 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 Figure 1: Generic Key-Value Structure 105 where: 107 Key-Type: 108 A 1-byte value that identifies the Key Type. It MUST be a 109 reserved value from the Key Value Type Registry that is defined 110 later in this document. 112 Key Identifier: 113 A 3-byte value that identifies the specific Key and describes 114 the structure of the contained values. 116 Values: 117 A variable length value that contains data associated with the 118 Key. It SHOULD contain 1 or more elements. Whether the 119 collection of elements allows duplicates and/or is ordered is 120 governed by the particular key identifier. 122 2.1. Well-Known Key Type 124 This section reserves a value in the Key Type Registry to indicate 125 Well-Known Key Types that all implementations SHOULD support. 127 As shown in Figure 2, the Key-Type will be used to identify that the 128 Key Type is Well-Known. The Key Identifier will be used to identify 129 the specific Key and describe the structure of the contained values. 131 0 1 2 3 132 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 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | TBD2 | Well-Known Key Identifier | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Well-Known Values (variable) | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 Figure 2: Well-Known Key Type 141 2.2. OUI Key Type 143 This section reserves a value in the Key Type Registry to indicate an 144 OUI (vendor-specific) Key Type that any implementation MAY support. 146 As shown in Figure 3, the Key-Type will be used to identify the Key 147 Type as OUI. The Key Identifier MUST use an organization's reserved 148 OUI space to indicate the Key and value structure. 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | TBD3 | Organizationally Unique Identifier | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Vendor Specific Values (variable) | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 Figure 3: OUI Key Type 160 2.3. Experimental Key Type 162 This section reserves a value in the Key Type Registry to indicate an 163 Experimental Key Type. 165 As shown in Figure 4, the Key-Type will be used to identify the Key 166 Type as Experimental. The Key Identifier will be used to identify 167 the specific experimental Key and describe the structure of the 168 contained values. 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | TBD1 | Experimental Key Identifier | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Experimental Values (variable) | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 Figure 4: Experimental Key Type 180 3. IANA Considerations 182 This section requests that IANA help govern Key Types via the usual 183 IANA registry procedures as per [RFC8126]. 185 All values not suggested are available for assignment. The 186 allocation of new values MUST be done via "Expert Review" procedures. 188 3.1. Key Type Registry 190 This section defines the Key Type Registry that is used to identify a 191 specific Key Type. It also suggests values for Experimental, Well- 192 Known, and OUI Key Types. 194 The range of valid values is 1 - 255. 196 0 is an illegal value and MUST NOT be allocated to or used by any 197 implementation. It MUST be ignored on reception. 199 3.1.1. Requested Entries 201 +==============+=======+=========================================+ 202 | Key Type | Value | Description | 203 +==============+=======+=========================================+ 204 | Experimental | TBD1 | Indicates that the Key is Experimental. | 205 +--------------+-------+-----------------------------------------+ 206 | Well-Known | TBD2 | Indicates that the Key is Well-Known. | 207 +--------------+-------+-----------------------------------------+ 208 | OUI | TBD3 | Indicates that the Key is OUI. | 209 +--------------+-------+-----------------------------------------+ 211 Table 1 213 3.2. Experimental Key Type 215 This value indicates that a specific key is Experimental. 217 The range of valid values is 1 - 16777215 (2^24-1). 219 0 is an illegal value and MUST NOT be allocated to or used by any 220 implementation. It MUST be ignored on reception. 222 3.2.1. Requested Entries 224 +==================+============+==============+ 225 | Experimental Key | Identifier | Description | 226 +==================+============+==============+ 227 | Illegal | 0 | Not allowed. | 228 +------------------+------------+--------------+ 230 Table 2 232 3.3. Well-Known Key Type 234 This value indicates that a specific key is Well-Known. 236 The range of valid values is 1 - 16777215 (2^24-1). 238 0 is an illegal value and MUST NOT be allocated to or used by any 239 implementation. It MUST be ignored on reception. 241 3.3.1. Requested Entries 243 +============================+============+================+ 244 | Well-Known Key | Identifier | Description | 245 +============================+============+================+ 246 | Illegal | 0 | Not allowed. | 247 +----------------------------+------------+----------------+ 248 | MAC/IP Binding | TBD1 | To be defined. | 249 +----------------------------+------------+----------------+ 250 | FAM Security Roll-Over Key | TBD2 | To be defined. | 251 +----------------------------+------------+----------------+ 253 Table 3 255 3.4. OUI Key Type 257 This value indicates a specific OUI Key using an organization's 258 reserved OUI space. 260 The range of valid values is 1 - 16777215 (2^24-1). 262 0 is an illegal value and MUST NOT be allocated to or used by any 263 implementation. It MUST be ignored on reception. 265 3.4.1. Requested Entries 267 +=========+============+==============+ 268 | OUI Key | Identifier | Description | 269 +=========+============+==============+ 270 | Illegal | 0 | Not allowed. | 271 +---------+------------+--------------+ 273 Table 4 275 4. Operational Considerations 277 While no restrictions are placed on Key-Value data or what it is used 278 for, it is RECOMMENDED that a serialized Thrift model be used for 279 simpler interoperability. RIFT Auto-EVPN [RIFT-AUTO-EVPN] is an 280 example of this type of implementation. 282 Key-Value elements SHOULD NOT be used to carry topology information 283 used by RIFT itself to perform distributed computations. 285 In cases where Key-Value TIEs are flooded from north to south, 286 policies SHOULD be implemented in order to avoid network-wide 287 flooding. 289 For networks with more than one ToF node, it is RECOMMENDED that 290 those ToF nodes contain identical Key-Value TIE information when 291 being distributed from north to south as the Key-Value tie breaking 292 rules in RIFT [RIFT] ultimately mention that only one Key-Value TIE 293 can be selected from multiple northbound neighbors. If this is not 294 considered, nodes receiving varying Key-Value TIEs might select a 295 suboptimal Key-Value TIE. 297 5. Security Considerations 299 This document introduces no new security concerns to RIFT or other 300 specifications referenced in this document given that the TIEs that 301 carry KV pairs are already extensively secured by the RIFT [RIFT] 302 specification itself. 304 6. Acknowledgements 306 To be provided. 308 7. Normative References 310 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 311 Requirement Levels", BCP 14, RFC 2119, 312 DOI 10.17487/RFC2119, March 1997, 313 . 315 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 316 Writing an IANA Considerations Section in RFCs", June 317 2017, . 319 [RIFT] Przygienda, T., Sharma, A., Thubert, P., Rijsman, B., and 320 D. Afanasiev, "RIFT: Routing in Fat Trees", Work in 321 Progress, draft-ietf-rift-rift-13, July 2021. 323 [RIFT-AUTO-EVPN] 324 Head, J., Przygienda, T., and W. Lin, "RIFT Auto-EVPN", 325 Work in Progress, draft-head-rift-auto-evpn-01, July 2021. 327 Authors' Addresses 328 Jordan Head (editor) 329 Juniper Networks 330 1137 Innovation Way 331 Sunnyvale, CA 332 United States of America 334 Email: jhead@juniper.net 336 Tony Przygienda 337 Juniper Networks 338 1137 Innovation Way 339 Sunnyvale, CA 340 United States of America 342 Email: prz@juniper.net