RIFT Z. Zhang Internet-Draft W. Duan Intended status: Standards Track B. Xu Expires: 5 May 2027 ZTE Corporation 1 November 2026 RIFT KV extensions for address block draft-zdx-rift-addsblock-extensions-00 Abstract This document describes a method for extending the address blocks carried within Key/Value extensions in data centers where RIFT (Routing in Fat Trees) is deployed. Status of This Memo 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 5 May 2027. Copyright Notice Copyright (c) 2026 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Zhang, et al. Expires 5 May 2027 [Page 1] Internet-Draft Addsblock KV extensions November 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 3 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 6.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction RIFT [RFC9692] 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 [RFC9992], 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. 1.1. 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 [RFC2119]. Zhang, et al. Expires 5 May 2027 [Page 2] Internet-Draft Addsblock KV extensions November 2026 2. 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 [RFC9992], introduce new Key Sub-Types, Key Sub-Identifiers, and similar elements to represent the allocated address blocks. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | Key Sub-Type | Key Sub-Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Experimental Values | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 * Key Sub-Type: TBD. * Key Sub-Identifier: TBD. * Experimental Values: IP address block information, including prefix and mask. 3. 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. +--------+ +--------+ | Spine1 | | Spine2 | +--+--+--+ +-+---+--+ | | | | | +---------|-+ | | | | | | +---------+ | | | | | | +--+--+--+ +---+-+--+ | Leaf1 | | Leaf2 | +--------+ +--------+ Figure 2 Zhang, et al. Expires 5 May 2027 [Page 3] Internet-Draft Addsblock KV extensions November 2026 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. +--------+ +--------+ | ToF1 | | ToF2 | +--+--+--+ +-+---+--+ | | | | | +---------|-+ | | | | | | +---------+ | | | | | | +--+--+--+ +---+-+--+ | Spine1 | | Spine2 | +--+--+--+ +-+---+--+ | | | | | +---------|-+ | | | | | | +---------+ | | | | | | +--+--+--+ +---+-+--+ | Leaf1 | | Leaf2 | +--------+ +--------+ Figure 3 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. Zhang, et al. Expires 5 May 2027 [Page 4] Internet-Draft Addsblock KV extensions November 2026 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. 4. IANA Considerations IANA is requested to allocate a new code points from the "RIFT Experimental Key Sub-Types" registry. +======+==============================+===============+ | Type | Description | Reference | +======+==============================+===============+ | TBD | IP Address auto distribution | This Document | +------+------------------------------+---------------+ Table 1: TABLE_1 5. Security Considerations The security considerations in [RFC9692] and [RFC9992] also apply to this document. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC9692] Przygienda, T., Ed., Head, J., Ed., Sharma, A., Thubert, P., Rijsman, B., and D. Afanasiev, "RIFT: Routing in Fat Trees", RFC 9692, DOI 10.17487/RFC9692, April 2025, . Zhang, et al. Expires 5 May 2027 [Page 5] Internet-Draft Addsblock KV extensions November 2026 [RFC9992] Head, J., Ed. and T. Przygienda, "Routing in Fat Trees (RIFT) Key/Value Topology Information Elements Structure and Processing", RFC 9992, DOI 10.17487/RFC9992, June 2026, . 6.2. Informative References Authors' Addresses Zheng Zhang ZTE Corporation China Email: zhang.zheng@zte.com.cn Wei Duan ZTE Corporation China Email: duan.wei1@zte.com.cn Benchong Xu ZTE Corporation China Email: xu.benchong@zte.com.cn Zhang, et al. Expires 5 May 2027 [Page 6]