rfc9692v5.txt		rfc9692.txt
	Internet Engineering Task Force (IETF) T. Przygienda, Ed.		Internet Engineering Task Force (IETF) T. Przygienda, Ed.
	Request for Comments: 9692 J. Head, Ed.		Request for Comments: 9692 J. Head, Ed.
	Category: Standards Track Juniper Networks		Category: Standards Track Juniper Networks
	ISSN: 2070-1721 A. Sharma		ISSN: 2070-1721 A. Sharma
	Hudson River Trading		Hudson River Trading
	P. Thubert		P. Thubert
	B. Rijsman		B. Rijsman
	Individual		Individual
			D. Afanasiev
			Yandex
	March 2025		March 2025
	RIFT: Routing in Fat Trees		RIFT: Routing in Fat Trees
	Abstract		Abstract
	This document defines a specialized, dynamic routing protocol for		This document defines a specialized, dynamic routing protocol for
	Clos, fat tree, and variants thereof. These topologies were		Clos, fat tree, and variants thereof. These topologies were
	initially used within crossbar interconnects and consequently router		initially used within crossbar interconnects and consequently router
	and switch backplanes, but their characteristics make them ideal for		and switch backplanes, but their characteristics make them ideal for
	skipping to change at line 421 ¶		skipping to change at line 423 ¶
	nodes. It should also help cement some of RIFT's core concepts in		nodes. It should also help cement some of RIFT's core concepts in
	the reader's mind.		the reader's mind.
	Last but not least, RIFT has other optional capabilities. One		Last but not least, RIFT has other optional capabilities. One
	example is the key-value datastore, which enables RIFT to advertise		example is the key-value datastore, which enables RIFT to advertise
	data post-convergence in order to bootstrap higher levels of		data post-convergence in order to bootstrap higher levels of
	functionality (e.g., operational telemetry). Those are covered in		functionality (e.g., operational telemetry). Those are covered in
	Section 6.8.		Section 6.8.
	More information related to RIFT can be found in the "RIFT		More information related to RIFT can be found in the "RIFT
	Applicability" [APPLICABILITY] document, which discusses alternate		Applicability" [RFC9696] document, which discusses alternate
	topologies upon which RIFT may be deployed, describes use cases where		topologies upon which RIFT may be deployed, describes use cases where
	it is applicable, and presents operational considerations that		it is applicable, and presents operational considerations that
	complement this document. "RIFT Day One" [DayOne] covers some		complement this document. "RIFT Day One" [DayOne] covers some
	practical details of existing RIFT implementations and deployment		practical details of existing RIFT implementations and deployment
	details.		details.
	3. Reference Frame		3. Reference Frame
	3.1. Terminology		3.1. Terminology
	skipping to change at line 900 ¶		skipping to change at line 902 ¶
	Set of ToFs that are aware of each other by means of south		Set of ToFs that are aware of each other by means of south
	reflection. Planes are designated by capital letters, e.g., plane		reflection. Planes are designated by capital letters, e.g., plane
	A.		A.
	N:		N:
	Denotes the number of independent ToF planes in a topology.		Denotes the number of independent ToF planes in a topology.
	R:		R:
	Denotes a redundancy factor, i.e., the number of ToP nodes in a		Denotes a redundancy factor, i.e., the number of ToP nodes in a
	PoD that are connected to a ToF plane. In a single-plane design,		PoD that are connected to a ToF plane. In a single-plane design,
	R is equal to K_LEAF		R is equal to K_LEAF.
	Fallen Leaf:		Fallen Leaf:
	A fallen leaf in a plane Z is a switch that lost all connectivity		A fallen leaf in a plane Z is a switch that lost all connectivity
	northbound to Z.		northbound to Z.
	5.2.2. Clos as Crossed, Stacked Crossbars		5.2.2. Clos as Crossed, Stacked Crossbars
	The typical topology for which RIFT is defined is built of P number		The typical topology for which RIFT is defined is built of P number
	of PoDs and connected together by S number of ToF nodes. A PoD node		of PoDs and connected together by S number of ToF nodes. A PoD node
	has 2K number of ports. From here on, half of them (K=Radix/2) are		has 2K number of ports. From here on, half of them (K=Radix/2) are
	skipping to change at line 3260 ¶		skipping to change at line 3262 ¶
	parent P over adjacencies ADJ(N, P) and ADJ(P, G). Observe that N		parent P over adjacencies ADJ(N, P) and ADJ(P, G). Observe that N
	does not have enough information to check bidirectional		does not have enough information to check bidirectional
	reachability of ADJ(P, G);		reachability of ADJ(P, G);
	* let R be a redundancy constant integer; a value of 2 or higher for		* let R be a redundancy constant integer; a value of 2 or higher for
	R is RECOMMENDED;		R is RECOMMENDED;
	* let S be a similarity constant integer; a value in range 0 .. 2		* let S be a similarity constant integer; a value in range 0 .. 2
	for S is RECOMMENDED, and the value of 1 SHOULD be used. Two		for S is RECOMMENDED, and the value of 1 SHOULD be used. Two
	cardinalities are considered as equivalent if their absolute		cardinalities are considered as equivalent if their absolute
	difference is less than or equal to S, i.e., |a-b|<=S		difference is less than or equal to S, i.e., |a-b|<=S;
	* let RND be a 64-bit random number (for example, as described in		* let RND be a 64-bit random number (for example, as described in
	[RFC4086]) generated by the system once on startup.		[RFC4086]) generated by the system once on startup.
	The algorithm consists of the following steps:		The algorithm consists of the following steps:
	1. Derive a 64-bit number by XORing N's System ID with RND.		1. Derive a 64-bit number by XORing N's System ID with RND.
	2. Derive a 16-bit pseudo-random unsigned integer PR(N) from the		2. Derive a 16-bit pseudo-random unsigned integer PR(N) from the
	resulting 64-bit number by splitting it into 16-bit-long words		resulting 64-bit number by splitting it into 16-bit-long words
	skipping to change at line 3347 ¶		skipping to change at line 3349 ¶
	i. if there exists an adjacency ADJ(P, G) in |NA(P) such		i. if there exists an adjacency ADJ(P, G) in |NA(P) such
	that c(G) < R, then		that c(G) < R, then
	1. place P in FR set;		1. place P in FR set;
	2. for all adjacencies ADJ(P, G') in |NA(P) increment		2. for all adjacencies ADJ(P, G') in |NA(P) increment
	c(G')		c(G')
	8. If any c(G) is still < R, it was not possible to elect a set of		8. If any c(G) is still < R, it was not possible to elect a set of
	FRs that covers all grandparents with redundancy R		FRs that covers all grandparents with redundancy R.
	Additional rules for flooding reduction:		Additional rules for flooding reduction:
	1. The algorithm MUST be re-evaluated by a node on every change of		1. The algorithm MUST be re-evaluated by a node on every change of
	local adjacencies or reception of a parent South TIE with changed		local adjacencies or reception of a parent South TIE with changed
	adjacencies. A node MAY apply a hysteresis to prevent an		adjacencies. A node MAY apply a hysteresis to prevent an
	excessive amount of computation during periods of network		excessive amount of computation during periods of network
	instability just like in the case of reachability computation.		instability just like in the case of reachability computation.
	2. Upon a change of the flood repeater set, a node SHOULD send out		2. Upon a change of the flood repeater set, a node SHOULD send out
	skipping to change at line 3493 ¶		skipping to change at line 3495 ¶
	with that, the computation cannot progress beyond adjacent nodes.		with that, the computation cannot progress beyond adjacent nodes.
	Once progressing, the computation uses the next higher level's South		Once progressing, the computation uses the next higher level's South
	Node TIEs to find corresponding adjacencies to verify backlink		Node TIEs to find corresponding adjacencies to verify backlink
	connectivity. Two unidirectional links MUST be associated to confirm		connectivity. Two unidirectional links MUST be associated to confirm
	bidirectional connectivity, a process often known as "backlink		bidirectional connectivity, a process often known as "backlink
	check". As part of the check, both Node TIEs MUST contain the		check". As part of the check, both Node TIEs MUST contain the
	correct System IDs *and* expected levels.		correct System IDs *and* expected levels.
	The default route found when crossing an E-W link SHOULD be used if		The default route found when crossing an E-W link SHOULD be used if
	and only if:		and only if
	1. the node itself does *not* have any northbound adjacencies *and*		1. the node itself does *not* have any northbound adjacencies *and*
	2. the adjacent node has one or more northbound adjacencies		2. the adjacent node has one or more northbound adjacencies.
	This rule forms a "one-hop default route split-horizon" and prevents		This rule forms a "one-hop default route split-horizon" and prevents
	looping over default routes while allowing for "one-hop protection"		looping over default routes while allowing for "one-hop protection"
	of nodes that lost all northbound adjacencies, except at the ToF		of nodes that lost all northbound adjacencies, except at the ToF
	where the links are used exclusively to flood topology information in		where the links are used exclusively to flood topology information in
	multi-plane designs.		multi-plane designs.
	Other south prefixes found when crossing E-W links MAY be used if and		Other south prefixes found when crossing E-W links MAY be used if and
	only if		only if
	skipping to change at line 5255 ¶		skipping to change at line 5257 ¶
	may require that a BFD session comes up before advertising the		may require that a BFD session comes up before advertising the
	adjacency.		adjacency.
	For the cases outlined above, RIFT has two approaches to enforce that		For the cases outlined above, RIFT has two approaches to enforce that
	a local port is connected to the correct port on the correct remote		a local port is connected to the correct port on the correct remote
	node. One approach is to piggyback on RIFT's authentication		node. One approach is to piggyback on RIFT's authentication
	mechanism. Assuming the provisioning model (e.g., YANG) is flexible		mechanism. Assuming the provisioning model (e.g., YANG) is flexible
	enough, operators can choose to provision a unique authentication key		enough, operators can choose to provision a unique authentication key
	for the following conceptual models:		for the following conceptual models:
	* each pair of ports in "port-association model"		* each pair of ports in "port-association model",
	* each pair of switches in "node-association model", or		* each pair of switches in "node-association model", or
	* the entire fabric in "fabric-association model".		* the entire fabric in "fabric-association model".
	The other approach is to rely on the System ID, port-id, and level		The other approach is to rely on the System ID, port-id, and level
	fields in the LIE message to validate an adjacency against the		fields in the LIE message to validate an adjacency against the
	expected cabling topology and optionally introduce some new rules in		expected cabling topology and optionally introduce some new rules in
	the FSM to allow the adjacency to come up if the expectations are		the FSM to allow the adjacency to come up if the expectations are
	met.		met.
	skipping to change at line 5455 ¶		skipping to change at line 5457 ¶
	deserialized to obtain the originator.		deserialized to obtain the originator.
	Fingerprint Length: 8 bits		Fingerprint Length: 8 bits
	Length in 32-bit multiples of the following fingerprint (not		Length in 32-bit multiples of the following fingerprint (not
	including lifetime or weak nonces). It allows the structure to be		including lifetime or weak nonces). It allows the structure to be
	navigated when an unknown key type is present. To clarify, a		navigated when an unknown key type is present. To clarify, a
	common corner case when this value is set to 0 is when it		common corner case when this value is set to 0 is when it
	signifies an empty (0 bytes long) security fingerprint.		signifies an empty (0 bytes long) security fingerprint.
	Security Fingerprint: 32 bits * Fingerprint Length.		Security Fingerprint: 32 bits * Fingerprint Length
	This is a signature that is computed over all data following after		This is a signature that is computed over all data following after
	it. If the significant bits of the fingerprint are fewer than the		it. If the significant bits of the fingerprint are fewer than the
	32-bit padded length, then the significant bits MUST be left		32-bit padded length, then the significant bits MUST be left
	aligned and the remaining bits on the right are padded with 0s.		aligned and the remaining bits on the right are padded with 0s.
	When using Public Key Infrastructure (PKI), the security		When using Public Key Infrastructure (PKI), the security
	fingerprint originating node uses its private key to create the		fingerprint originating node uses its private key to create the
	signature. The original packet can then be verified, provided the		signature. The original packet can then be verified, provided the
	public key is shared and current. Methodology to negotiate,		public key is shared and current. Methodology to negotiate,
	distribute, or rollover keys is outside the scope of this		distribute, or rollover keys is outside the scope of this
	skipping to change at line 6535 ¶		skipping to change at line 6537 ¶
	To isolate possible attack vectors on the leaf to the largest		To isolate possible attack vectors on the leaf to the largest
	possible extent, a dedicated leaf-only implementation could run		possible extent, a dedicated leaf-only implementation could run
	without any configuration by:		without any configuration by:
	* hard-coding a well-known adjacency key (which can be always rolled		* hard-coding a well-known adjacency key (which can be always rolled
	over by means of, e.g., a well-known key-value distributed from		over by means of, e.g., a well-known key-value distributed from
	top of the fabric),		top of the fabric),
	* hard-coding a leaf level value, and		* hard-coding a leaf level value, and
	* always setting the overload flag		* always setting the overload flag.
	9.9.1. IPv4 Broadcast and IPv6 All-Routers Multicast Implementations		9.9.1. IPv4 Broadcast and IPv6 All-Routers Multicast Implementations
	Section 6.2 describes an optional implementation that supports LIE		Section 6.2 describes an optional implementation that supports LIE
	exchange over IPv4 broadcast addresses and/or the IPv6 all-routers		exchange over IPv4 broadcast addresses and/or the IPv6 all-routers
	multicast address. It is important to consider that if an		multicast address. It is important to consider that if an
	implementation supports this, the attack surface widens as LIEs may		implementation supports this, the attack surface widens as LIEs may
	be propagated to devices outside of the intended RIFT topology. This		be propagated to devices outside of the intended RIFT topology. This
	may leave RIFT nodes more susceptible to the various attack vectors		may leave RIFT nodes more susceptible to the various attack vectors
	already described in this section.		already described in this section.
	skipping to change at line 7025 ¶		skipping to change at line 7027 ¶
	|1 | name |8.0 | |Node or |		|1 | name |8.0 | |Node or |
	| | | | |adjacency |		| | | | |adjacency |
	| | | | |name. |		| | | | |name. |
	+-----+-----------------------------+-------+--------+--------------+		+-----+-----------------------------+-------+--------+--------------+
	|2 | local_id |8.0 | |Local link |		|2 | local_id |8.0 | |Local link |
	| | | | |ID. |		| | | | |ID. |
	+-----+-----------------------------+-------+--------+--------------+		+-----+-----------------------------+-------+--------+--------------+
	|3 | flood_port |8.0 | |UDP port to |		|3 | flood_port |8.0 | |UDP port to |
	| | | | |which we can |		| | | | |which we can |
	| | | | |receive |		| | | | |receive |
	| | | | |flooded ties. |		| | | | |flooded TIEs. |
	+-----+-----------------------------+-------+--------+--------------+		+-----+-----------------------------+-------+--------+--------------+
	|4 | link_mtu_size |8.0 | |Layer 2 MTU, |		|4 | link_mtu_size |8.0 | |Layer 2 MTU, |
	| | | | |used to |		| | | | |used to |
	| | | | |discover |		| | | | |discover |
	| | | | |mismatch. |		| | | | |mismatch. |
	+-----+-----------------------------+-------+--------+--------------+		+-----+-----------------------------+-------+--------+--------------+
	|5 | link_bandwidth |8.0 | |Local link |		|5 | link_bandwidth |8.0 | |Local link |
	| | | | |bandwidth on |		| | | | |bandwidth on |
	| | | | |the |		| | | | |the |
	| | | | |interface. |		| | | | |interface. |
	skipping to change at line 7103 ¶		skipping to change at line 7105 ¶
	| | | | |node to |		| | | | |node to |
	| | | | |achieve flood |		| | | | |achieve flood |
	| | | | |reduction and |		| | | | |reduction and |
	| | | | |balancing for |		| | | | |balancing for |
	| | | | |northbound |		| | | | |northbound |
	| | | | |flooding. |		| | | | |flooding. |
	+-----+-----------------------------+-------+--------+--------------+		+-----+-----------------------------+-------+--------+--------------+
	|23 | you_are_sending_too_quickly |8.0 | |Indicates to |		|23 | you_are_sending_too_quickly |8.0 | |Indicates to |
	| | | | |the neighbor |		| | | | |the neighbor |
	| | | | |to flood node |		| | | | |to flood node |
	| | | | |ties only and |		| | | | |TIEs only and |
	| | | | |slow down all |		| | | | |slow down all |
	| | | | |other ties. |		| | | | |other TIEs. |
	| | | | |Ignored when |		| | | | |Ignored when |
	| | | | |received from |		| | | | |received from |
	| | | | |the |		| | | | |the |
	| | | | |southbound |		| | | | |southbound |
	| | | | |neighbor. |		| | | | |neighbor. |
	+-----+-----------------------------+-------+--------+--------------+		+-----+-----------------------------+-------+--------+--------------+
	|24 | instance_name |8.0 | |Instance name |		|24 | instance_name |8.0 | |Instance name |
	| | | | |in case |		| | | | |in case |
	| | | | |multiple RIFT |		| | | | |multiple RIFT |
	| | | | |instances are |		| | | | |instances are |
	skipping to change at line 7338 ¶		skipping to change at line 7340 ¶
	+-------+-----------+---------+----------+----------------------+		+-------+-----------+---------+----------+----------------------+
	| 3 | cost | 8.0 | | Cost to neighbor. |		| 3 | cost | 8.0 | | Cost to neighbor. |
	| | | | | Ignore anything |		| | | | | Ignore anything |
	| | | | | equal or larger than |		| | | | | equal or larger than |
	| | | | | 'infinite_distance' |		| | | | | 'infinite_distance' |
	| | | | | and equal to |		| | | | | and equal to |
	| | | | | 'invalid_distance'. |		| | | | | 'invalid_distance'. |
	+-------+-----------+---------+----------+----------------------+		+-------+-----------+---------+----------+----------------------+
	| 4 | link_ids | 8.0 | | Carries description |		| 4 | link_ids | 8.0 | | Carries description |
	| | | | | of multiple parallel |		| | | | | of multiple parallel |
	| | | | | links in a tie. |		| | | | | links in a TIE. |
	+-------+-----------+---------+----------+----------------------+		+-------+-----------+---------+----------+----------------------+
	| 5 | bandwidth | 8.0 | | Total bandwidth to |		| 5 | bandwidth | 8.0 | | Total bandwidth to |
	| | | | | neighbor as sum of |		| | | | | neighbor as sum of |
	| | | | | all parallel links. |		| | | | | all parallel links. |
	+-------+-----------+---------+----------+----------------------+		+-------+-----------+---------+----------+----------------------+
	Table 30: Neighbor of a Node		Table 30: Neighbor of a Node
	10.3.24. RIFTEncodingNodeTIEElement Registry		10.3.24. RIFTEncodingNodeTIEElement Registry
	skipping to change at line 7364 ¶		skipping to change at line 7366 ¶
	| | | Version | Version | |		| | | Version | Version | |
	+=======+=================+=========+==========+====================+		+=======+=================+=========+==========+====================+
	| 0 | Reserved | 8.0 | All | |		| 0 | Reserved | 8.0 | All | |
	| | | | Versions | |		| | | | Versions | |
	+-------+-----------------+---------+----------+--------------------+		+-------+-----------------+---------+----------+--------------------+
	| 1 | level | 8.0 | | Level of the |		| 1 | level | 8.0 | | Level of the |
	| | | | | node. |		| | | | | node. |
	+-------+-----------------+---------+----------+--------------------+		+-------+-----------------+---------+----------+--------------------+
	| 2 | neighbors | 8.0 | | Node's neighbors. |		| 2 | neighbors | 8.0 | | Node's neighbors. |
	| | | | | Multiple node |		| | | | | Multiple node |
	| | | | | ties can carry |		| | | | | TIEs can carry |
	| | | | | disjoint sets of |		| | | | | disjoint sets of |
	| | | | | neighbors. |		| | | | | neighbors. |
	+-------+-----------------+---------+----------+--------------------+		+-------+-----------------+---------+----------+--------------------+
	| 3 | capabilities | 8.0 | | Capabilities of |		| 3 | capabilities | 8.0 | | Capabilities of |
	| | | | | the node. |		| | | | | the node. |
	+-------+-----------------+---------+----------+--------------------+		+-------+-----------------+---------+----------+--------------------+
	| 4 | flags | 8.0 | | Flags of the |		| 4 | flags | 8.0 | | Flags of the |
	| | | | | node. |		| | | | | node. |
	+-------+-----------------+---------+----------+--------------------+		+-------+-----------------+---------+----------+--------------------+
	| 5 | name | 8.0 | | Optional node |		| 5 | name | 8.0 | | Optional node |
	skipping to change at line 7394 ¶		skipping to change at line 7396 ¶
	| 10 | miscabled_links | 8.0 | | If any local |		| 10 | miscabled_links | 8.0 | | If any local |
	| | | | | links are |		| | | | | links are |
	| | | | | miscabled, this |		| | | | | miscabled, this |
	| | | | | indication is |		| | | | | indication is |
	| | | | | flooded. |		| | | | | flooded. |
	+-------+-----------------+---------+----------+--------------------+		+-------+-----------------+---------+----------+--------------------+
	| 12 | same_plane_tofs | 8.0 | | ToFs in the same |		| 12 | same_plane_tofs | 8.0 | | ToFs in the same |
	| | | | | plane. Only |		| | | | | plane. Only |
	| | | | | carried by ToF. |		| | | | | carried by ToF. |
	| | | | | Multiple node |		| | | | | Multiple node |
	| | | | | ties can carry |		| | | | | TIEs can carry |
	| | | | | disjoint sets of |		| | | | | disjoint sets of |
	| | | | | ToFs that must be |		| | | | | ToFs that must be |
	| | | | | joined to form a |		| | | | | joined to form a |
	| | | | | single set. |		| | | | | single set. |
	+-------+-----------------+---------+----------+--------------------+		+-------+-----------------+---------+----------+--------------------+
	| 20 | fabric_id | 8.0 | | It provides the |		| 20 | fabric_id | 8.0 | | It provides the |
	| | | | | optional ID of |		| | | | | optional ID of |
	| | | | | the fabric |		| | | | | the fabric |
	| | | | | configured. |		| | | | | configured. |
	+-------+-----------------+---------+----------+--------------------+		+-------+-----------------+---------+----------+--------------------+
	skipping to change at line 7449 ¶		skipping to change at line 7451 ¶
	| 0 | Reserved | 8.0 | All | |		| 0 | Reserved | 8.0 | All | |
	| | | | Versions | |		| | | | Versions | |
	+-------+---------------+---------+----------+-------------------+		+-------+---------------+---------+----------+-------------------+
	| 1 | major_version | 8.0 | | Major version of |		| 1 | major_version | 8.0 | | Major version of |
	| | | | | protocol. |		| | | | | protocol. |
	+-------+---------------+---------+----------+-------------------+		+-------+---------------+---------+----------+-------------------+
	| 2 | minor_version | 8.0 | | Minor version of |		| 2 | minor_version | 8.0 | | Minor version of |
	| | | | | protocol. |		| | | | | protocol. |
	+-------+---------------+---------+----------+-------------------+		+-------+---------------+---------+----------+-------------------+
	| 3 | sender | 8.0 | | Node sending the |		| 3 | sender | 8.0 | | Node sending the |
	| | | | | packet, in case |		| | | | | packet; in case |
	| | | | | of LIE/TIRE/TIDE |		| | | | | of LIE/TIRE/TIDE |
	| | | | | also the |		| | | | | also the |
	| | | | | originator of it. |		| | | | | originator of it. |
	+-------+---------------+---------+----------+-------------------+		+-------+---------------+---------+----------+-------------------+
	| 4 | level | 8.0 | | Level of the node |		| 4 | level | 8.0 | | Level of the node |
	| | | | | sending the |		| | | | | sending the |
	| | | | | packet, required |		| | | | | packet, required |
	| | | | | on everything |		| | | | | on everything |
	| | | | | except LIEs. |		| | | | | except LIEs. |
	| | | | | Lack of presence |		| | | | | Lack of presence |
	skipping to change at line 7836 ¶		skipping to change at line 7838 ¶
	[SHA-2] NIST, "Secure Hash Standard (SHS)", FIPS PUB 180-4,		[SHA-2] NIST, "Secure Hash Standard (SHS)", FIPS PUB 180-4,
	DOI 10.6028/NIST.FIPS.180-4, July 2015,		DOI 10.6028/NIST.FIPS.180-4, July 2015,
	<https://csrc.nist.gov/pubs/fips/180-4/upd1/final>.		<https://csrc.nist.gov/pubs/fips/180-4/upd1/final>.
	[thrift] Apache Software Foundation, "Apache Thrift Documentation",		[thrift] Apache Software Foundation, "Apache Thrift Documentation",
	<https://thrift.apache.org/docs/>.		<https://thrift.apache.org/docs/>.
	11.2. Informative References		11.2. Informative References
	[APPLICABILITY]
	Wei, Y., Zhang, Z., Afanasiev, D., Thubert, P., and T.
	Przygienda, "RIFT Applicability and Operational
	Considerations", Work in Progress, Internet-Draft, draft-
	ietf-rift-applicability-17, 17 June 2024,
	<https://datatracker.ietf.org/doc/html/draft-ietf-rift-
	applicability-17>.
	[CLOS] Yuan, X., "On Nonblocking Folded-Clos Networks in Computer		[CLOS] Yuan, X., "On Nonblocking Folded-Clos Networks in Computer
	Communication Environments", 2011 IEEE International		Communication Environments", 2011 IEEE International
	Parallel & Distributed Processing Symposium,		Parallel & Distributed Processing Symposium,
	DOI 10.1109/IPDPS.2011.27, 2011,		DOI 10.1109/IPDPS.2011.27, May 2011,
	<https://ieeexplore.ieee.org/document/6012836>.		<https://ieeexplore.ieee.org/document/6012836>.
	[DayOne] Aelmans, M., Vandezande, O., Rijsman, B., Head, J., Graf,		[DayOne] Aelmans, M., Vandezande, O., Rijsman, B., Head, J., Graf,
	C., Alberro, L., Mali, H., and O. Steudler, "Day One:		C., Alberro, L., Mali, H., and O. Steudler, "Day One:
	Routing in Fat Trees (RIFT)", Juniper Network Books,		Routing in Fat Trees (RIFT)", Juniper Network Books,
	ISBN 978-1-7363160-0-9, December 2020.		ISBN 978-1-7363160-0-9, December 2020.
	[DIJKSTRA] Dijkstra, E. W., "A Note on Two Problems in Connexion with		[DIJKSTRA] Dijkstra, E. W., "A Note on Two Problems in Connexion with
	Graphs", Numerische Mathematik, vol. 1, pp. 269-271,		Graphs", Numerische Mathematik, vol. 1, pp. 269-271,
	DOI 10.1007/BF01386390, December 1959,		DOI 10.1007/BF01386390, December 1959,
	<https://link.springer.com/article/10.1007/BF01386390>.		<https://link.springer.com/article/10.1007/BF01386390>.
	[DYNAMO] De Candia, G., Hastorun, D., Jampani, M., Kakulpati, G.,		[DYNAMO] De Candia, G., Hastorun, D., Jampani, M., Kakulpati, G.,
	Lakshman, A., Pilchin, A., Sivasubramanian, S., Vosshall,		Lakshman, A., Pilchin, A., Sivasubramanian, S., Vosshall,
	P., and W. Vogels, "Dynamo: amazon's highly available key-		P., and W. Vogels, "Dynamo: amazon's highly available key-
	value store", ACM SIGOPS Operating Systems Review, vol.		value store", ACM SIGOPS Operating Systems Review, vol.
	41, no. 6, pp. 205-220, DOI 10.1145/1323293.1294281, 2007,		41, no. 6, pp. 205-220, DOI 10.1145/1323293.1294281,
			October 2007,
	<https://dl.acm.org/doi/10.1145/1323293.1294281>.		<https://dl.acm.org/doi/10.1145/1323293.1294281>.
	[EPPSTEIN] Eppstein, D., "Finding the k Shortest Paths", 1997,		[EPPSTEIN] Eppstein, D., "Finding the k Shortest Paths", March 1997,
	<https://ics.uci.edu/~eppstein/pubs/Epp-SJC-98.pdf>.		<https://ics.uci.edu/~eppstein/pubs/Epp-SJC-98.pdf>.
	[FATTREE] Leiserson, C. E., "Fat-Trees: Universal Networks for		[FATTREE] Leiserson, C. E., "Fat-Trees: Universal Networks for
	Hardware-Efficient Supercomputing", IEEE Transactions on		Hardware-Efficient Supercomputing", IEEE Transactions on
	Computers, vol. C-34, no. 10, pp. 892-901,		Computers, vol. C-34, no. 10, pp. 892-901,
	DOI 10.1109/TC.1985.6312192, October 1985,		DOI 10.1109/TC.1985.6312192, October 1985,
	<https://ieeexplore.ieee.org/document/6312192>.		<https://ieeexplore.ieee.org/document/6312192>.
	[IEEEstd1588]		[IEEEstd1588]
	IEEE, "IEEE Standard for a Precision Clock Synchronization		IEEE, "IEEE Standard for a Precision Clock Synchronization
	skipping to change at line 7961 ¶		skipping to change at line 7956 ¶
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,		[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
	Richardson, M., Jiang, S., Lemon, T., and T. Winters,		Richardson, M., Jiang, S., Lemon, T., and T. Winters,
	"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",		"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
	RFC 8415, DOI 10.17487/RFC8415, November 2018,		RFC 8415, DOI 10.17487/RFC8415, November 2018,
	<https://www.rfc-editor.org/info/rfc8415>.		<https://www.rfc-editor.org/info/rfc8415>.
			[RFC9696] Wei, Y., Ed., Zhang, Z., Afanasiev, D., Thubert, P., and
			T. Przygienda, "Routing in Fat Trees (RIFT) Applicability
			and Operational Considerations", RFC 9696,
			DOI 10.17487/RFC9696, March 2025,
			<https://www.rfc-editor.org/info/rfc9696>.
	[VAHDAT08] Al-Fares, M., Loukissas, A., and A. Vahdat, "A Scalable,		[VAHDAT08] Al-Fares, M., Loukissas, A., and A. Vahdat, "A Scalable,
	Commodity Data Center Network Architecture", ACM SIGCOMM		Commodity Data Center Network Architecture", ACM SIGCOMM
	Computer Communication Review, vol. 38, no. 4, pp. 63-74,		Computer Communication Review, vol. 38, no. 4, pp. 63-74,
	DOI 10.1145/1402946.1402967, August 2008,		DOI 10.1145/1402946.1402967, August 2008,
	<https://dl.acm.org/doi/10.1145/1402946.1402967>.		<https://dl.acm.org/doi/10.1145/1402946.1402967>.
	[VFR] Giotsas, V. and S. Zhou, "Valley-free violation in		[VFR] Giotsas, V. and S. Zhou, "Valley-free violation in
	Internet routing - Analysis based on BGP Community data",		Internet routing - Analysis based on BGP Community data",
	2012 IEEE International Conference on Communications		2012 IEEE International Conference on Communications
	(ICC), DOI 10.1109/ICC.2012.6363987, 2012,		(ICC), DOI 10.1109/ICC.2012.6363987, June 2012,
	<https://ieeexplore.ieee.org/document/6363987>.		<https://ieeexplore.ieee.org/document/6363987>.
	Appendix A. Sequence Number Binary Arithmetic		Appendix A. Sequence Number Binary Arithmetic
	This section defines a variant of sequence number arithmetic related		This section defines a variant of sequence number arithmetic related
	to [RFC1982] explained over two complement arithmetic, which is easy		to [RFC1982] explained over two complement arithmetic, which is easy
	to implement.		to implement.
	Assuming straight two complement's subtractions on the bit width of		Assuming straight two complement's subtractions on the bit width of
	the sequence numbers, the corresponding >: and =: relations are		the sequence numbers, the corresponding >: and =: relations are
	skipping to change at line 8423 ¶		skipping to change at line 8424 ¶
	Email: as3957@gmail.com		Email: as3957@gmail.com
	Pascal Thubert		Pascal Thubert
	Individual		Individual
	France		France
	Email: pascal.thubert@gmail.com		Email: pascal.thubert@gmail.com
	Bruno Rijsman		Bruno Rijsman
	Individual		Individual
	Email: brunorijsman@gmail.com		Email: brunorijsman@gmail.com
			Dmitry Afanasiev
			Yandex
			Email: fl0w@yandex-team.ru
End of changes. 24 change blocks.
	28 lines changed or deleted		29 lines changed or added
This html diff was produced by rfcdiff 1.48.