Hello, I have been selected as the Routing Directorate reviewer for this draft. https://datatracker.ietf.org/doc/draft-ietf-rift-kv-tie-structure-and-processing/ The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-rift-kv-tie-structure-and-processing-05 Reviewer: Zheng(Sandy) Zhang Review Date: 2025-11-03 Intended Status: Standards Track Summary: This document is basically ready for publication but has nits that should be considered prior to publication. Comments: Please consider the comments listed below with ZZ> to improve the draft. RIFT Key/Value TIE Structure and Processing draft-ietf-rift-kv-tie-structure-and-processing-05 ...... 1. Introduction The Routing in Fat Trees [RFC9692] protocol 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. ZZ> When referring to KV TIE, it would be better to include section number 6.3.1 from RFC 9692. ...... 2. Key-Value Structure This section describes the generic Key structure and semantics, Figure 1 further illustrates these components. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key-Type | Key Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Values (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Generic Key-Value Structure *where:* *Key-Type:* A 1-byte value that identifies the Key-Type. It MUST be a reserved value from the RIFT Key-Type Registry that is defined later in this document. The range of valid values is 1 - 255 (2^8-1). 0 is an illegal value and MUST NOT be allocated to or used by any implementation. It MUST be ignored on receipt. *Key Identifier:* A 3-byte value that identifies the specific key and describes the structure of the contained values. 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 receipt. ZZ> Considering key-type/key sub-type and key identifier, although the description states that a value of 0 should not be assigned and should be ignored by the receiver, if a value of 0 is indeed received from a neighbor, should an error message be displayed besides ignoring it? Furthermore, it would be better to explain whether this affects the parsing of the entire KV TIE. *Values:* A variable length value that contains data associated with the Key Identifier. It SHOULD contain 1 or more elements. Whether the collection of elements allows duplicates and/or is ordered is governed by the particular Key Identifier's specification. ZZ> Is it an error if the value contains 0 elements? 2.1. Key Sub-Type The Key Sub-Type is an OPTIONAL mechanism to further describe the contained values and their structure. This is illustrated by Figure 2. While the Key Sub-Type is optional, it MUST be used when the Key-Type is either Well-Known or Experimental in order to avoid interoperability issues. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key-Type | Key Sub-Type | Key Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Values (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Generic Key-Value Structure with Key Sub-Type *where:* *Key Sub-Type:* An OPTIONAL 1-byte value that identifies the Key Sub-Type which describes the structure of the contained values. If used, it MUST be a reserved value from the RIFT Well-Known Key Sub-Types registry. The range of valid values is 1 - 255 (2^8-1). 0 is an illegal value and MUST NOT be allocated to or used by any implementation. It MUST be ignored on receipt. ZZ> When the key sub-type is not a reserved value in the Well-known list, is it treated the same as when the value is 0? Will the failure to resolve this sub-type affect the processing of all other key sub-types belonging to the same key-type in the message? And will it affect the resolution of the entire KV TIE? ...... 3.1. Tie-Breaking Considerations In cases where KV TIEs are flooded from north to south, policies SHOULD be implemented in order to avoid network-wide flooding. ZZ> For north and south, it is best to specify whether it is from the spine to the leaf or the opposite direction, or refer to the relevant explanation section in RFC9692. ...... 3.1.1. Southbound Key-Value TIE Tie-Break Sub-Type This Key-Value pair contains information that allows an implementation to test and verify proper tie-breaking behavior for the Southbound Key store. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Well-Known | Tie Break | Key Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (System ID, | | Level), | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Southbound Tie-Break (Global) Sub-Type ZZ> What does "Global" mean here? ZZ> Is Tie Break mandatory or optional? ZZ> The term "Southbound" needs to be clearly explained here, referring to whether it's a notification from the spine to the leaf or the opposite direction; otherwise, it may cause misunderstanding for those unfamiliar with RFC 9692. ...... 3.2.1. Key Target Processing Nodes that support the processing of Key Targets MUST only do so on KV TIEs in the southbound direction. Key Targets MUST NOT be present on KV TIEs in the northbound direction and are otherwise ignored and logged. Nodes that do not support the processing of Key Targets MUST continue to send KV TIEs to all nodes in the appropriate direction. Additionally, Key Targets MUST be preserved when KV TIEs are re- originated in the southbound direction. ZZ> Since Tie Break registration has already appeared in section 4.2.1, should Key Target's IANA registration also be included in section 4.2.1? 3.2.1.1. Purging/Rollover There are several reasons a node may select a different KV TIE. For example, the KV TIE is considered newer due to the sequence number incrementing, there was a change in the original tie-breaking result between multiple KV TIEs, or a loss of northbound connectivity to the node that advertised the previously selected KV TIE. Consider a case where Leaf-1, Leaf-2, and Leaf-3 are members of a group of nodes represented by Key Target KT1. If Leaf-2 is removed from that group and a newer instance of the KV TIE needs to be flooded Leaf-2 will have to maintain the older KV TIE in the LSDB until the lifetime expires. This could lead to suboptimal behavior in the fabric. If the new KV TIE being flooded does not include the previous Key Target value, then implementations SHOULD flood the newer instance of the KV TIE with a very short lifetime to nodes that belonged to the previous Key Target but not the new Key Target. This logic only applies to KV TIEs being flooded in the southbound direction. ZZ> Does this mean that if a newly received KV TIE does not contain the previously sent Key type or Key sub-type, the value is considered deleted? Or does this process only apply to the Key Target? ...... 4.2.1. RIFT Well-Known Key Sub-Types Requested Entries This section requests that IANA register the following suggested values to the "RIFT Well-Known Key Sub-Types" Registry. +=======+================+===========================+===========+ | Value | Key-Identifier | Description | Reference | +=======+================+===========================+===========+ | 0 | Illegal | Not allowed. | This | | | | | document. | +-------+----------------+---------------------------+-----------+ | 1 | MAC/IP Binding | To be defined. | To be | | | | | defined. | +-------+----------------+---------------------------+-----------+ | 2 | FAM Security | To be defined. | To be | | | Roll-Over Key | | defined. | +-------+----------------+---------------------------+-----------+ | 127 | Southbound | Used for Southbound | This | | | Tie-Break Key | Keystore tie-breaking | document. | | | Sub-Type | testing and verification. | | +-------+----------------+---------------------------+-----------+ Table 2 ZZ> It seems that the application details in section 4.2.1 of the IANA registry are not yet available. Not sure if this part will need to wait until IANA allocates the data, and then the corresponding values ​​in this document will be modified to reflect the values ​​allocated by IANA. [End of Review]