< draft-head-rift-kv-registry-00.txt		draft-head-rift-kv-registry-01.txt >
	Network Working Group J. Head		RIFT J. Head, Ed.
	Internet-Draft A. Przygienda		Internet-Draft T. Przygienda
	Intended status: Standards Track Juniper Networks		Intended status: Standards Track Juniper Networks
	Expires: 26 August 2021 22 February 2021		Expires: 10 January 2022 9 July 2021
	RIFT Keys Structure and Well-Known Registry in Key Value TIE		RIFT Keys Structure and Well-Known Registry in Key Value TIE
	draft-head-rift-kv-registry-00		draft-head-rift-kv-registry-01
	Abstract		Abstract
	Routing in Fat-Trees RIFT [RIFT] allows for key/value pairs to be		Routing in Fat-Trees RIFT [RIFT] allows for key/value pairs to be
	advertised within Key-Value Topology Information Elements (KV TIEs).		advertised within Key-Value Topology Information Elements (KV TIEs).
	The data contained within these KV TIEs can be used for any		The data contained within these KV TIEs can be used for any
	imaginable purpose. This document defines the various Key Types		imaginable purpose. This document defines the various Key Types
	(i.e. Well-Known, OUI, and Experimental) and a method to structure		(i.e. Well-Known, OUI, and Experimental) and a method to structure
	corresponding values.		corresponding values.
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 26 August 2021.		This Internet-Draft will expire on 10 January 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Description . . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Description . . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Key-Value Pair Structure . . . . . . . . . . . . . . . . . . 3		2. Key-Value Pair Structure . . . . . . . . . . . . . . . . . . 2
	2.1. Well-Known Key Type . . . . . . . . . . . . . . . . . . . 3		2.1. Well-Known Key Type . . . . . . . . . . . . . . . . . . . 3
	2.2. OUI Key Type . . . . . . . . . . . . . . . . . . . . . . 4		2.2. OUI Key Type . . . . . . . . . . . . . . . . . . . . . . 4
	2.3. Experimental Key Type . . . . . . . . . . . . . . . . . . 4		2.3. Experimental Key Type . . . . . . . . . . . . . . . . . . 4
	3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Key Type Registry . . . . . . . . . . . . . . . . . . . . 5		3.1. Key Type Registry . . . . . . . . . . . . . . . . . . . . 5
	3.1.1. Requested Entries . . . . . . . . . . . . . . . . . . 5		3.1.1. Requested Entries . . . . . . . . . . . . . . . . . . 5
	3.2. Experimental Key Type . . . . . . . . . . . . . . . . . . 5		3.2. Experimental Key Type . . . . . . . . . . . . . . . . . . 5
	3.2.1. Requested Entries . . . . . . . . . . . . . . . . . . 6		3.2.1. Requested Entries . . . . . . . . . . . . . . . . . . 5
	3.3. Well-Known Key Type . . . . . . . . . . . . . . . . . . . 6		3.3. Well-Known Key Type . . . . . . . . . . . . . . . . . . . 5
	3.3.1. Requested Entries . . . . . . . . . . . . . . . . . . 6		3.3.1. Requested Entries . . . . . . . . . . . . . . . . . . 6
	3.4. OUI Key Type . . . . . . . . . . . . . . . . . . . . . . 6		3.4. OUI Key Type . . . . . . . . . . . . . . . . . . . . . . 6
	3.4.1. Requested Entries . . . . . . . . . . . . . . . . . . 7		3.4.1. Requested Entries . . . . . . . . . . . . . . . . . . 6
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 7		4. Operational Considerations . . . . . . . . . . . . . . . . . 6
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7		5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	6. Normative References . . . . . . . . . . . . . . . . . . . . 7		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
			7. Normative References . . . . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Description		1. Description
	Routing in Fat-Trees (RIFT [RIFT]) allows for key/value pairs to be		Routing in Fat-Trees (RIFT [RIFT]) allows for key/value pairs to be
	advertised within Key-Value Topology Information Elements (KV TIEs).		advertised within Key-Value Topology Information Elements (KV TIEs).
	There are no restrictions placed on the type of data that is		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		contained in KV TIEs nor what the data is used for.
	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		This document defines a Key Type Registry to maintain Well-Known and
	vendor specific Key Types in order to simplify interoperability		vendor specific Key Types in order to simplify interoperability
	between implementations and eliminate the risk of collision for		between implementations and eliminate the risk of collision for
	future implementations. An Experimental Key Type is additionally		future implementations. An Experimental Key Type is additionally
	defined.		defined.
	2. Key-Value Pair Structure		2. Key-Value Pair Structure
	Figure 1 illustrates the generic Key-Value Pair structure.		Figure 1 illustrates the generic Key-Value Pair structure.
	skipping to change at page 6, line 26 ¶		skipping to change at page 6, line 7 ¶
	+------------------+------------+--------------+		+------------------+------------+--------------+
	Table 2		Table 2
	3.3. Well-Known Key Type		3.3. Well-Known Key Type
	This value indicates that a specific key is Well-Known.		This value indicates that a specific key is Well-Known.
	The range of valid values is 1 - 16777215 (2^24-1).		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		0 is an illegal value and MUST NOT be allocated to or used by any
	implementation. It MUST be ignored on reception.		implementation. It MUST be ignored on reception.
	3.3.1. Requested Entries		3.3.1. Requested Entries
	+============================+============+================+		+============================+============+================+
	| Well-Known Key | Identifier | Description |		| Well-Known Key | Identifier | Description |
	+============================+============+================+		+============================+============+================+
	| Illegal | 0 | Not allowed. |		| Illegal | 0 | Not allowed. |
	+----------------------------+------------+----------------+		+----------------------------+------------+----------------+
	| MAC/IP Binding | TBD1 | To be defined. |		| MAC/IP Binding | TBD1 | To be defined. |
	skipping to change at page 7, line 15 ¶		skipping to change at page 6, line 44 ¶
	3.4.1. Requested Entries		3.4.1. Requested Entries
	+=========+============+==============+		+=========+============+==============+
	| OUI Key | Identifier | Description |		| OUI Key | Identifier | Description |
	+=========+============+==============+		+=========+============+==============+
	| Illegal | 0 | Not allowed. |		| Illegal | 0 | Not allowed. |
	+---------+------------+--------------+		+---------+------------+--------------+
	Table 4		Table 4
	4. Security Considerations		4. Operational Considerations
			While no restrictions are placed on Key-Value data or what it is used
			for, it is RECOMMENDED that a serialized Thrift model be used for
			simpler interoperability. RIFT Auto-EVPN [RIFT-AUTO-EVPN] is an
			example of this type of implementation.
			Key-Value elements SHOULD NOT be used to carry topology information
			used by RIFT itself to perform distributed computations.
			In cases where Key-Value TIEs are flooded from north to south,
			policies SHOULD be implemented in order to avoid network-wide
			flooding.
			For networks with more than one ToF node, it is RECOMMENDED that
			those ToF nodes contain identical Key-Value TIE information when
			being distributed from north to south as the Key-Value tie breaking
			rules in RIFT [RIFT] ultimately mention that only one Key-Value TIE
			can be selected from multiple northbound neighbors. If this is not
			considered, nodes receiving varying Key-Value TIEs might select a
			suboptimal Key-Value TIE.
			5. Security Considerations
	This document introduces no new security concerns to RIFT or other		This document introduces no new security concerns to RIFT or other
	specifications referenced in this document given that the TIEs that		specifications referenced in this document given that the TIEs that
	carry KV pairs are already extensively secured by the RIFT [RIFT]		carry KV pairs are already extensively secured by the RIFT [RIFT]
	specification itself.		specification itself.
	5. Acknowledgements		6. Acknowledgements
	To be provided.		To be provided.
	6. Normative References		7. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", June		Writing an IANA Considerations Section in RFCs", June
	2017, <https://www.rfc-editor.org/info/rfc8126>.		2017, <https://www.rfc-editor.org/info/rfc8126>.
	[RIFT] Przygienda, T., Sharma, A., Thubert, P., Rijsman, B., and		[RIFT] Przygienda, T., Sharma, A., Thubert, P., Rijsman, B., and
	D. Afanasiev, "RIFT: Routing in Fat Trees", Work in		D. Afanasiev, "RIFT: Routing in Fat Trees", Work in
	Progress, draft-ietf-rift-rift-12, May 2020.		Progress, draft-ietf-rift-rift-13, July 2021.
	Authors' Addresses		[RIFT-AUTO-EVPN]
			Head, J., Przygienda, T., and W. Lin, "RIFT Auto-EVPN",
			Work in Progress, draft-head-rift-auto-evpn-01, July 2021.
	Jordan Head		Authors' Addresses
			Jordan Head (editor)
	Juniper Networks		Juniper Networks
	1137 Innovation Way		1137 Innovation Way
	Sunnyvale, CA		Sunnyvale, CA
	United States of America		United States of America
	Email: jhead@juniper.net		Email: jhead@juniper.net
	Tony Przygienda		Tony Przygienda
	Juniper Networks		Juniper Networks
	1137 Innovation Way		1137 Innovation Way
	Sunnyvale, CA		Sunnyvale, CA
	United States of America		United States of America
	Email: prz@juniper.net		Email: prz@juniper.net
End of changes. 17 change blocks.
	24 lines changed or deleted		48 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/