idnits 2.17.1 draft-ietf-rift-kv-registry-01.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 (24 June 2022) is 670 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-15 -- Unexpected draft version: The latest known version of draft-head-rift-auto-evpn is -01, but you're referring to -02. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). 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: 26 December 2022 24 June 2022 7 RIFT Key/Value Structure and Registry 8 draft-ietf-rift-kv-registry-01 10 Abstract 12 The Routing in Fat-Trees RIFT [RIFT] protocol allows for key/value 13 pairs to be advertised within Key-Value Topology Information Elements 14 (KV-TIEs). The data contained within these KV-TIEs can be used for 15 any 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 26 December 2022. 42 Copyright Notice 44 Copyright (c) 2022 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 Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised BSD License. 56 Table of Contents 58 1. Description . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Key Structure . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2.1. Experimental Key-Type . . . . . . . . . . . . . . . . . . 3 61 2.2. Well-Known Key-Type . . . . . . . . . . . . . . . . . . . 4 62 2.3. OUI Key-Type . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Operational Considerations . . . . . . . . . . . . . . . . . 5 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 4.1. RIFT Key-Type Registry . . . . . . . . . . . . . . . . . 6 66 4.1.1. RIFT Key-Type Registry Requested Entries . . . . . . 6 67 4.2. RIFT Well-Known Key-Type Registry . . . . . . . . . . . . 6 68 4.2.1. RIFT Well-Known Key-Type Registry Requested 69 Entries . . . . . . . . . . . . . . . . . . . . . . . 7 70 4.3. Expert Review Guidance . . . . . . . . . . . . . . . . . 7 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 73 7. Normative References . . . . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Description 78 The Routing in Fat-Trees RIFT [RIFT] protocol allows for key/value 79 pairs to be advertised within Key-Value Topology Information Elements 80 (KV-TIEs). There are no restrictions placed on the type of data that 81 is contained in KV-TIEs nor what the data is used for. 83 For example, it might be beneficial to advertise overlay protocol 84 state from leaf nodes to the Top-of-Fabric (ToF) nodes. This would 85 make it possible to view critical state of a fabric-wide service from 86 a single ToF node rather than retrieving and reconciling the same 87 state from multiple leaf nodes. 89 2. Key Structure 91 This section describes the generic Key structure and semantics, 92 Figure 1 further illustrates these components. 94 0 1 2 3 95 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 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | Key-Type | Key Identifier | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | Values (variable) | 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 Figure 1: Generic Key-Value Structure 104 *where:* 106 *Key-Type:* 107 A 1-byte value that identifies the Key-Type. It MUST be a 108 reserved value from the RIFT Key-Type Registry that is defined 109 later in this document. 111 The range of valid values is 1 - 255 (2^8-1). 113 0 is an illegal value and MUST NOT be allocated to or used by 114 any implementation. It MUST be ignored on receipt. 116 *Key Identifier:* 117 A 3-byte value that identifies the specific key and describes 118 the structure of the contained values. 120 The range of valid values is 1 - 16777215 (2^24-1). 122 0 is an illegal value and MUST NOT be allocated to or used by 123 any implementation. It MUST be ignored on receipt. 125 *Values:* 126 A variable length value that contains data associated with the 127 Key Identifier. It SHOULD contain 1 or more elements. Whether 128 the collection of elements allows duplicates and/or is ordered 129 is governed by the particular Key Identifier's specification. 131 2.1. Experimental Key-Type 133 This section reserves a value in the RIFT Key-Type Registry to 134 indicate an Experimental Key-Type. 136 As shown in Figure 2, the Key-Type will be used to identify the Key- 137 Type as Experimental. The Key Identifier will be used to identify 138 the specific key and describe the structure of the contained values. 140 0 1 2 3 141 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 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | 1 | Experimental Key Identifier | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Experimental Values (variable) | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 Figure 2: Experimental Key-Type 150 2.2. Well-Known Key-Type 152 This section reserves a value in the RIFT Key-Type Registry to 153 indicate Well-Known Key-Types that all implementations SHOULD 154 support. 156 As shown in Figure 3, the Key-Type will be used to identify the Key- 157 Type as Well-Known. The Key Identifier will be used to identify the 158 specific key and describe the structure of the contained values. 160 0 1 2 3 161 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 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | 2 | Well-Known Key Identifier | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Well-Known Values (variable) | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 Figure 3: Well-Known Key-Type 170 2.3. OUI Key-Type 172 This section reserves a value in the RIFT Key-Type Registry to 173 indicate an OUI (vendor-specific) Key-Type that any implementation 174 MAY support. 176 As shown in Figure 4, the Key-Type will be used to identify the Key- 177 Type as OUI. The Key Identifier MUST use the implementing 178 organization's reserved OUI space to indicate the key and value 179 structure. 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | 3 | OUI Key Identifier | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Vendor Specific Values (variable) | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 Figure 4: OUI Key-Type 191 3. Operational Considerations 193 While no restrictions are placed on Key-Value data or what it is used 194 for, it is RECOMMENDED that a serialized Thrift model be used for 195 simpler interoperability. [RIFT-AUTO-EVPN] is an example of this 196 type of implementation. 198 Key-Value elements SHOULD NOT be used to carry topology information 199 used by RIFT itself to perform distributed computations. 201 In cases where KV-TIEs are flooded from north to south, policies 202 SHOULD be implemented in order to avoid network-wide flooding. 204 For networks with more than one ToF node, it is RECOMMENDED that 205 those ToF nodes contain identical KV-TIE information when being 206 distributed from north to south. RIFT [RIFT] requires that only one 207 KV-TIE is selected when identical keys are received from multiple 208 northbound neighbors. If this is not considered then the tie- 209 breaking rules may cause a node to select a suboptimal KV-TIE. 210 Consider a case where failure conditions cause the ToF nodes to 211 become split-brained. While the Key-Type and Key Identifier will be 212 identical, the value(s) contained within may differ. The node(s) 213 receiving these differing KV-TIEs will select the one from the ToF 214 node with the highest System ID, potentially leading to unintended 215 effects. 217 4. IANA Considerations 219 This section requests that IANA create two new registries the "RIFT 220 Key-Type" and "RIFT Well-Known Key-Type" registries in accordance 221 with [RFC8126]. 223 Experts reviewing requests for new values to either registry MUST 224 consider the items in the Expert Review Guidance (Section 4.3) 225 section. 227 The following sections detail each registry's requirements and 228 suggested values. 230 4.1. RIFT Key-Type Registry 232 This section requests that IANA create and help govern the following 233 registry: 235 *Registry Name:* 236 RIFT Key-Type Registry 238 *Registration Procedures:* 239 Expert Review 241 *Description:* 242 Key-Type registry for the RIFT protocol. 244 *Reference:* 245 This document. 247 4.1.1. RIFT Key-Type Registry Requested Entries 249 This section requests that IANA register the following suggested 250 values to the "RIFT Key-Type Registry". 252 +=======+==============+=============================+===========+ 253 | Value | Key-Type | Description | Status/ | 254 | | | | Reference | 255 +=======+==============+=============================+===========+ 256 | 0 | Illegal | Not allowed. | This | 257 | | | | document | 258 +-------+--------------+-----------------------------+-----------+ 259 | 1 | Experimental | Indicates that the Key-Type | This | 260 | | | is Experimental. | document. | 261 +-------+--------------+-----------------------------+-----------+ 262 | 2 | Well-Known | Indicates that the Key-Type | This | 263 | | | is Well-Known. | document. | 264 +-------+--------------+-----------------------------+-----------+ 265 | 3 | OUI | Indicates that the Key-Type | This | 266 | | | is OUI (vendor specific). | document. | 267 +-------+--------------+-----------------------------+-----------+ 269 Table 1 271 4.2. RIFT Well-Known Key-Type Registry 273 This section requests that IANA create and help govern the following 274 registry: 276 *Registry Name:* 277 RIFT Well-Known Key-Type Registry 279 *Registration Procedures:* 280 Expert Review 282 *Description:* 283 Well-Known Key-Type (2) registry for the RIFT protocol. 285 *Reference:* 286 This document. 288 4.2.1. RIFT Well-Known Key-Type Registry Requested Entries 290 This section requests that IANA register the following suggested 291 values to the "RIFT Well-Known Key-Type Registry". 293 +=======+================+================+==================+ 294 | Value | Key-Identifier | Description | Status/Reference | 295 +=======+================+================+==================+ 296 | 0 | Illegal | Not allowed. | This document. | 297 +-------+----------------+----------------+------------------+ 298 | 1 | MAC/IP Binding | To be defined. | To be defined. | 299 +-------+----------------+----------------+------------------+ 300 | 2 | FAM Security | To be defined. | To be defined. | 301 | | Roll-Over Key | | | 302 +-------+----------------+----------------+------------------+ 304 Table 2 306 4.3. Expert Review Guidance 308 Experts reviewing requests for values from the RIFT Key-Type Registry 309 or the the the Well-Known RIFT Key-Type Registry are responsible for 310 the following: 312 1. Determining the existence of a specification that clearly defines 313 the purpose supporting the request and MUST contain all required 314 fields for given registry. 316 The document MUST also be permenent and publically available. 318 2. Ensuring that any requests are made available to the RIFT working 319 group for review should the work originate from outside of the 320 RIFT Working Group. 322 3. Ensuring that any work produce outside of the IETF does not 323 conflict with any work that is already published or actively 324 pursuing being published. 326 5. Security Considerations 328 This document introduces no new security concerns to RIFT or other 329 specifications referenced in this document given that the Key-Value 330 TIEs are already extensively secured by the RIFT [RIFT] protocol 331 specification itself. 333 6. Acknowledgements 335 To be provided. 337 7. Normative References 339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 340 Requirement Levels", BCP 14, RFC 2119, 341 DOI 10.17487/RFC2119, March 1997, 342 . 344 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 345 Writing an IANA Considerations Section in RFCs", June 346 2017, . 348 [RIFT] Przygienda, T., Sharma, A., Thubert, P., Rijsman, B., and 349 D. Afanasiev, "RIFT: Routing in Fat Trees", Work in 350 Progress, draft-ietf-rift-rift-15, July 2021. 352 [RIFT-AUTO-EVPN] 353 Head, J., Przygienda, T., and W. Lin, "RIFT Auto-EVPN", 354 Work in Progress, draft-head-rift-auto-evpn-02, March 355 2022. 357 Authors' Addresses 359 Jordan Head (editor) 360 Juniper Networks 361 1137 Innovation Way 362 Sunnyvale, CA 363 United States of America 364 Email: jhead@juniper.net 365 Tony Przygienda 366 Juniper Networks 367 1137 Innovation Way 368 Sunnyvale, CA 369 United States of America 370 Email: prz@juniper.net