Internet-Draft | draft-ietf-head-rift-kv-registry | February 2021 |
Head & Przygienda | Expires 26 August 2021 | [Page] |
Routing in Fat-Trees RIFT [RIFT] allows for key/value pairs to be advertised within Key-Value Topology Information Elements (KV TIEs). The data contained within these KV TIEs can be used for any imaginable purpose. This document defines the various Key Types (i.e. Well-Known, OUI, and Experimental) and a method to structure corresponding values.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 26 August 2021.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
Routing in Fat-Trees (RIFT [RIFT]) allows for key/value pairs to be advertised within Key-Value Topology Information Elements (KV TIEs). There are no restrictions placed on the type of data that is contained in KV TIEs nor what the data is used for. It could contain a simple string or even Thrift encoded data. However, the KV elements SHOULD NOT be used to carry topology information used by RIFT itself to perform distributed computations.¶
This document defines a Key Type Registry to maintain Well-Known and vendor specific Key Types in order to simplify interoperability between implementations and eliminate the risk of collision for future implementations. An Experimental Key Type is additionally defined.¶
Figure 1 illustrates the generic Key-Value Pair structure.¶
where:¶
This section reserves a value in the Key Type Registry to indicate Well-Known Key Types that all implementations SHOULD support.¶
As shown in Figure 2, the Key-Type will be used to identify that the Key Type is Well-Known. The Key Identifier will be used to identify the specific Key and describe the structure of the contained values.¶
This section reserves a value in the Key Type Registry to indicate an OUI (vendor-specific) Key Type that any implementation MAY support.¶
As shown in Figure 3, the Key-Type will be used to identify the Key Type as OUI. The Key Identifier MUST use an organization's reserved OUI space to indicate the Key and value structure.¶
This section reserves a value in the Key Type Registry to indicate an Experimental Key Type.¶
As shown in Figure 4, the Key-Type will be used to identify the Key Type as Experimental. The Key Identifier will be used to identify the specific experimental Key and describe the structure of the contained values.¶
This section requests that IANA help govern Key Types via the usual IANA registry procedures as per [RFC8126].¶
All values not suggested are available for assignment. The allocation of new values MUST be done via "Expert Review" procedures.¶
This section defines the Key Type Registry that is used to identify a specific Key Type. It also suggests values for Experimental, Well-Known, and OUI Key Types.¶
The range of valid values is 1 - 255.¶
0 is an illegal value and MUST NOT be allocated to or used by any implementation. It MUST be ignored on reception.¶
Key Type | Value | Description |
---|---|---|
Experimental | TBD1 | Indicates that the Key is Experimental. |
Well-Known | TBD2 | Indicates that the Key is Well-Known. |
OUI | TBD3 | Indicates that the Key is OUI. |
This value indicates that a specific key is Experimental.¶
The range of valid values is 1 - 16777215 (2^24-1).¶
0 is an illegal value and MUST NOT be allocated to or used by any implementation. It MUST be ignored on reception.¶
Experimental Key | Identifier | Description |
---|---|---|
Illegal | 0 | Not allowed. |
This value indicates that a specific key is Well-Known.¶
The range of valid values is 1 - 16777215 (2^24-1).¶
0 is an illegal value and MUST not be allocated to or used by any implementation. It MUST be ignored on reception.¶
Well-Known Key | Identifier | Description |
---|---|---|
Illegal | 0 | Not allowed. |
MAC/IP Binding | TBD1 | To be defined. |
FAM Security Roll-Over Key | TBD2 | To be defined. |
This value indicates a specific OUI Key using an organization's reserved OUI space.¶
The range of valid values is 1 - 16777215 (2^24-1).¶
0 is an illegal value and MUST NOT be allocated to or used by any implementation. It MUST be ignored on reception.¶
OUI Key | Identifier | Description |
---|---|---|
Illegal | 0 | Not allowed. |
This document introduces no new security concerns to RIFT or other specifications referenced in this document given that the TIEs that carry KV pairs are already extensively secured by the RIFT [RIFT] specification itself.¶
To be provided.¶