IETF Last Call Review of draft-ietf-rift-kv-tie-structure-and-processing-05
review-ietf-rift-kv-tie-structure-and-processing-05-rtgdir-lc-zhang-2025-11-02-00

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]