RIFT KV extensions for address block

Introduction RIFT is a new dynamic routing protocol designed for large-scale data centers. It is specifically tailored to the characteristics of Clos/Fat Tree topologies and simplifies deployment in large-scale data center environments by distinguishing between north-south protocol signaling and processing. Furthermore, its Zero Touch Provisioning (ZTP) capability enables the automated setup of a network with minimal human intervention. When server, such as those housing GPUs or CPUs, are connected to a Clos/Fat Tree topology, each unit requires an IP address. During the address allocation process, the Clos/Fat Tree topology should be taken into account to ensure that the IP addresses assigned to servers connected to the same leaf switch are, as much as possible, contiguous and aggregatable. This allows the leaf switch to advertise an aggregated route rather than individual, specific host routes. Furthermore, this approach helps prevent "black hole" routing issues, reduces the total number of routes within the network, and improves packet forwarding efficiency. This document describes a method for extending RIFT Key/Value , in which Spine switches in a Clos/Fat Tree topology allocate contiguous network address blocks and distribute them to Leaf switches via a new Key/Value (KV) type; these network address blocks are then used to configure the servers connected to the Leaf switches.

Requirements Language 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 .

Format (The specific format for the KV extension is still under discussion; the following is merely a preliminary definition.) Using the "Experimental Key Type 2" defined in Section 2.2 of , introduce new Key Sub-Types, Key Sub-Identifiers, and similar elements to represent the allocated address blocks.

Key Sub-Type: TBD.
Key Sub-Identifier: TBD.
Experimental Values: IP address block information, including prefix and mask.

Specification Since servers typically contain multiple GPUs or similar devices, they generally require multiple addresses. The northbound Spine switches allocate address blocks to Leaf devices; the size of each block is determined by the number of addresses required by the servers connected to that Leaf.

In a two-tier network, for example figure 2, address blocks can be allocated to Leaf switches by a Spine switch. One Spine switch, for instance, Spine1, can be designated as the address allocation device; once it determines the address blocks to be assigned to Leaf1 and Leaf2, it then advertises these blocks to the respective Leaf switches using the KV extension. The specific method by which a Spine switch determines these address blocks, whether through manual configuration or other means, is outside the scope of this document.

In networks with three or more layers, for example figure 3, the address blocks to be allocated to each Leaf switch can be determined by the northernmost Spine switch or the northernmost ToF (Top-of-Fabric) switch. For instance, once ToF1 determines the address blocks to be assigned to Leaf1 and Leaf2, this information can be propagated via the KV extension, passing through the Spine layer to reach Leaf1 and Leaf2, or, given that the ToF has visibility into the entire southward topology, ToF1 can send the address blocks directly to Leaf1 and Leaf2. When a Leaf switch receives an address request packet from a server, it can select an unassigned address from its address block and provide it to the server. The Leaf device may act as a DHCP server; the server only needs to send its address request to the connected Leaf, which can then respond to the request by assigning an address. Since the address block on each Leaf consists of a contiguous range of addresses, a Leaf can advertise an aggregated route rather than individual, specific server routes (provided that there is no route overlap with other Leafs). This approach reduces the total number of routes within the network; in large-scale data centers, it decreases the number of routes that forwarding devices must maintain, thereby improving forwarding efficiency. When the address block allocation policy within the network changes, requiring adjustments to the addresses of servers that have already been assigned addresses, the Spine or ToF switches generate new address blocks and transmit them to the Leaf switches. The Leaf switches then adjust the addresses assigned to the connected servers, thereby enabling automatic address updates.

IANA Considerations IANA is requested to allocate a new code points from the "RIFT Experimental Key Sub-Types" registry. TABLE_1

Type	Description	Reference
TBD	IP Address auto distribution	This Document

Security Considerations The security considerations in and also apply to this document.