idnits 2.17.1 draft-rift-head-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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 0 is an illegal value and MUST not be allocated to or used by any implementation. It MUST be ignored on reception. -- The document date (22 February 2021) is 1158 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-12 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Head 3 Internet-Draft A. Przygienda 4 Intended status: Standards Track Juniper Networks 5 Expires: 26 August 2021 22 February 2021 7 RIFT Keys Structure and Well-Known Registry in Key Value TIE 8 draft-rift-head-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 26 August 2021. 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 . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . 6 68 3.3. Well-Known Key Type . . . . . . . . . . . . . . . . . . . 6 69 3.3.1. Requested Entries . . . . . . . . . . . . . . . . . . 6 70 3.4. OUI Key Type . . . . . . . . . . . . . . . . . . . . . . 6 71 3.4.1. Requested Entries . . . . . . . . . . . . . . . . . . 7 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 74 6. Normative References . . . . . . . . . . . . . . . . . . . . 7 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 77 1. Description 79 Routing in Fat-Trees (RIFT [RIFT]) allows for key/value pairs to be 80 advertised within Key-Value Topology Information Elements (KV TIEs). 81 There are no restrictions placed on the type of data that is 82 contained in KV TIEs nor what the data is used for. It could contain 83 a simple string or even Thrift encoded data. However, the KV 84 elements SHOULD NOT be used to carry topology information used by 85 RIFT itself to perform distributed computations. 87 This document defines a Key Type Registry to maintain Well-Known and 88 vendor specific Key Types in order to simplify interoperability 89 between implementations and eliminate the risk of collision for 90 future implementations. An Experimental Key Type is additionally 91 defined. 93 2. Key-Value Pair Structure 95 Figure 1 illustrates the generic Key-Value Pair structure. 97 0 1 2 3 98 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 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 | Key-Type | Key Identifier | 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | Values (variable) | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 Figure 1: Generic Key-Value Structure 107 where: 109 Key-Type: 110 A 1-byte value that identifies the Key Type. It MUST be a 111 reserved value from the Key Value Type Registry that is defined 112 later in this document. 114 Key Identifier: 115 A 3-byte value that identifies the specific Key and describes 116 the structure of the contained values. 118 Values: 119 A variable length value that contains data associated with the 120 Key. It SHOULD contain 1 or more elements. Whether the 121 collection of elements allows duplicates and/or is ordered is 122 governed by the particular key identifier. 124 2.1. Well-Known Key Type 126 This section reserves a value in the Key Type Registry to indicate 127 Well-Known Key Types that all implementations SHOULD support. 129 As shown in Figure 2, the Key-Type will be used to identify that the 130 Key Type is Well-Known. The Key Identifier will be used to identify 131 the specific Key and describe the structure of the contained values. 133 0 1 2 3 134 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 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | TBD2 | Well-Known Key Identifier | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Well-Known Values (variable) | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 Figure 2: Well-Known Key Type 143 2.2. OUI Key Type 145 This section reserves a value in the Key Type Registry to indicate an 146 OUI (vendor-specific) Key Type that any implementation MAY support. 148 As shown in Figure 3, the Key-Type will be used to identify the Key 149 Type as OUI. The Key Identifier MUST use an organization's reserved 150 OUI space to indicate the Key and value structure. 152 0 1 2 3 153 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 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | TBD3 | Organizationally Unique Identifier | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Vendor Specific Values (variable) | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 Figure 3: OUI Key Type 162 2.3. Experimental Key Type 164 This section reserves a value in the Key Type Registry to indicate an 165 Experimental Key Type. 167 As shown in Figure 4, the Key-Type will be used to identify the Key 168 Type as Experimental. The Key Identifier will be used to identify 169 the specific experimental Key and describe the structure of the 170 contained values. 172 0 1 2 3 173 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 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | TBD1 | Experimental Key Identifier | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Experimental Values (variable) | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 Figure 4: Experimental Key Type 182 3. IANA Considerations 184 This section requests that IANA help govern Key Types via the usual 185 IANA registry procedures as per [RFC8126]. 187 All values not suggested are available for assignment. The 188 allocation of new values MUST be done via "Expert Review" procedures. 190 3.1. Key Type Registry 192 This section defines the Key Type Registry that is used to identify a 193 specific Key Type. It also suggests values for Experimental, Well- 194 Known, and OUI Key Types. 196 The range of valid values is 1 - 255. 198 0 is an illegal value and MUST NOT be allocated to or used by any 199 implementation. It MUST be ignored on reception. 201 3.1.1. Requested Entries 203 +==============+=======+=========================================+ 204 | Key Type | Value | Description | 205 +==============+=======+=========================================+ 206 | Experimental | TBD1 | Indicates that the Key is Experimental. | 207 +--------------+-------+-----------------------------------------+ 208 | Well-Known | TBD2 | Indicates that the Key is Well-Known. | 209 +--------------+-------+-----------------------------------------+ 210 | OUI | TBD3 | Indicates that the Key is OUI. | 211 +--------------+-------+-----------------------------------------+ 213 Table 1 215 3.2. Experimental Key Type 217 This value indicates that a specific key is Experimental. 219 The range of valid values is 1 - 16777215 (2^24-1). 221 0 is an illegal value and MUST NOT be allocated to or used by any 222 implementation. It MUST be ignored on reception. 224 3.2.1. Requested Entries 226 +==================+============+==============+ 227 | Experimental Key | Identifier | Description | 228 +==================+============+==============+ 229 | Illegal | 0 | Not allowed. | 230 +------------------+------------+--------------+ 232 Table 2 234 3.3. Well-Known Key Type 236 This value indicates that a specific key is Well-Known. 238 The range of valid values is 1 - 16777215 (2^24-1). 240 0 is an illegal value and MUST not be allocated to or used by any 241 implementation. It MUST be ignored on reception. 243 3.3.1. Requested Entries 245 +============================+============+================+ 246 | Well-Known Key | Identifier | Description | 247 +============================+============+================+ 248 | Illegal | 0 | Not allowed. | 249 +----------------------------+------------+----------------+ 250 | MAC/IP Binding | TBD1 | To be defined. | 251 +----------------------------+------------+----------------+ 252 | FAM Security Roll-Over Key | TBD2 | To be defined. | 253 +----------------------------+------------+----------------+ 255 Table 3 257 3.4. OUI Key Type 259 This value indicates a specific OUI Key using an organization's 260 reserved OUI space. 262 The range of valid values is 1 - 16777215 (2^24-1). 264 0 is an illegal value and MUST NOT be allocated to or used by any 265 implementation. It MUST be ignored on reception. 267 3.4.1. Requested Entries 269 +=========+============+==============+ 270 | OUI Key | Identifier | Description | 271 +=========+============+==============+ 272 | Illegal | 0 | Not allowed. | 273 +---------+------------+--------------+ 275 Table 4 277 4. Security Considerations 279 This document introduces no new security concerns to RIFT or other 280 specifications referenced in this document given that the TIEs that 281 carry KV pairs are already extensively secured by the RIFT [RIFT] 282 specification itself. 284 5. Acknowledgements 286 To be provided. 288 6. Normative References 290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, 292 DOI 10.17487/RFC2119, March 1997, 293 . 295 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 296 Writing an IANA Considerations Section in RFCs", June 297 2017, . 299 [RIFT] Przygienda, T., Sharma, A., Thubert, P., Rijsman, B., and 300 D. Afanasiev, "RIFT: Routing in Fat Trees", Work in 301 Progress, draft-ietf-rift-rift-12, May 2020. 303 Authors' Addresses 305 Jordan Head 306 Juniper Networks 307 1137 Innovation Way 308 Sunnyvale, CA 309 United States of America 311 Email: jhead@juniper.net 312 Tony Przygienda 313 Juniper Networks 314 1137 Innovation Way 315 Sunnyvale, CA 316 United States of America 318 Email: prz@juniper.net