[Rift] Re: Mohamed Boucadair's Discuss on draft-ietf-rift-kv-tie-structure-and-processing-06: (with DISCUSS and COMMENT)

[[e-mail]]

Hi Jordan,
(apologies for the delay to follow up as I was out of office).

Thank you for the replies. I also checked the 06/08 diff [1].

I think that most of the points were adequately addressed. Please see inline.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-rift-kv-tie-structure-and-processing-06&url2=draft-ietf-rift-kv-tie-structure-and-processing-08&difftype=--html

De : Head, Jordan <[e-mail]>
Envoyé : vendredi 19 décembre 2025 14:43
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>; The IESG <[e-mail]>
Cc : [e-mail]; [e-mail]; [e-mail]; [e-mail]
Objet : Re: Mohamed Boucadair's Discuss on draft-ietf-rift-kv-tie-structure-and-processing-06: (with DISCUSS and COMMENT)


Hi Med,

Thanks for your patience and thorough review. Replies inline as jhead>>

From: Mohamed Boucadair via Datatracker <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, December 10, 2025 at 6:02 AM
To: The IESG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Mohamed Boucadair's Discuss on draft-ietf-rift-kv-tie-structure-and-processing-06: (with DISCUSS and COMMENT)
Mohamed Boucadair has entered the following ballot position for
draft-ietf-rift-kv-tie-structure-and-processing-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!AjCjW04I0-dN74ZtMVmqoDnAAS4UTQJrGkSx1_IPPvtMQZNeQz2zFu62nZnGLNQwNZA8wkJs1QKKpQ$
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-rift-kv-tie-structure-and-processing/__;!!NEt6yMaO-gk!AjCjW04I0-dN74ZtMVmqoDnAAS4UTQJrGkSx1_IPPvtMQZNeQz2zFu62nZnGLNQwNZA8wkIK6p2t5g$



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi Jordan and Tony,

Thank you for the effort put into this specification.

Thanks to Italo Busi for the excellent OPSDIR review. I appreciate that the
author engaged. I trust that Italo will follow-up as appropriate.


Please find below some comments for DISCUSSion:

# Value decoding

CURRENT:
      *Values:*
         A variable length value that contains data associated with the
         Key Identifier.  It SHOULD contain 1 or more elements.  The
         semantics (i.e., existence, order, duplication, etc.) of any
         contained values is governed by the particular key's
         specification.

It is not clear to me how the length of the values is determined. Even for
registered types, the values are variable.

      jhead>> I agree, I moved the statement RECOMMENDING that implementations use a serialized Thrift model from Section 3 to the top of section 2 and added a mention that Thrift (like the base spec) is used to define packet structure.
      jhead>> “variable” was only intended to show that values could be "anything". I removed most of these mentions from the ASCII images
      jhead>> To be clear, anyone registering a new Key-Type or Well-Known Sub-Type will have to define the semantics of how the Key Identifier and correlated values are determined (meaning that they would no longer be “variable”).

[Med] ACK.

The same applies for the following:

   *where:*

      *System ID:*
         A REQUIRED value indicating the node's unique System ID.

      *Level:*
         A RECOMMENDED value indicating the node's level.

Also, it is not clear how an implem determines the presence of the Level (for
this specific case)? How these two are demuxed?

      jhead>> Packet structure in RIFT is defined with an IDL (Apache Thrift), the base spec contains the specific normative models required to implement it. Adhering to this lets implementations serialize/deserialize accordingly.
      jhead>> As an example, the KV spec’s Thrift model “includes” the normative “common.thrift” model from the base spec so that it has access to the necessary types. For example, the SystemIDType is a 64-bit integer and the LevelType is an 8-bit integer (https://www.rfc-editor.org/rfc/rfc9692.html#name-commonthrift) The structure/ordering is also defined in the models as well, e.g., the tie-break Sub-Type sets SystemID as first and Level as second (if used).
      jhead>> If you’re coming from reading/implementing the base spec this is more obvious, I’ll see if I can find a place to “remind” the reader without over specification so that it’s a bit clearer.

[Med] This is indeed clearer. Thanks.

# THRIFT is normative

CURRENT:
   While no restrictions are placed on Key-Value data or what it is used
   for, it is RECOMMENDED that a serialized Thrift [THRIFT] model be
   used for simpler interoperability.

Please list this ref as normative.

      jhead>> Yes, will do.
[Med] ACK


# Idem for [Rust]

CURRENT:
   Any other value MUST be derived from the following normative
   algorithm.  Note that while the algorithm is shown using example code
   written in [Rust], this document does not mandate the use of any
   particular language for implementation.

I appreciate the last sentence, but still this is needed for the first part of
this excerpt.

      jhead>> Can you clarify what you mean here?
[Med] I interpreted the text as that the derivation must be from the algo in Figure 9. If my reading is correct, then one must understand the language used in Figure 9; hence my comment.


# Ket Targets

Where the protocol behavior governing KT is defined? How these objects are
parsed/used? I failed to find this in the base spec. Maybe I was not looking in
the right specs.

      jhead>> The typedef and constant default values are defined in the base spec’s common.thrift model, so if you implement RIFT as recommended you get them for free.
      jhead>> That said, I think adding an explicit reference to that model in the base spec is warranted. Good catch.
[Med] The mention of 7.2 in -08 is helpful. Thanks.


# IANA considerations

There are several issues with that section:

•       Repeat DE guidance already covered in 8126 (first item in the guidance,
for example) •       Use of normative language •       Missing available ranges
for assignment •       Maintenance

      jhead>> I’ll reevaluate this and make it conform. I already have a conversation going with IANA.
[Med] The revised version is much more better.


## How is this supposed to work when the WG is concluded?

CURRENT:
   3.  Ensuring that any requests are made available to the RIFT working
       group for review should the work originate from outside the RIFT
       Working Group.

      jhead>> You’re right, I’ll remove this.
[Med] ACK.


# Appendix is normative

The preamble of the appendix include this mention:

   This section contains the Thrift model that MAY be used to test
   southbound Key-Value tie-breaking based on System ID.

That conflicts with this part in Section 3.1.1:

  All implementations SHOULD use the Appendix A.1 Thrift model

Given that the appendix is normative + short. A simple fix would be to move the
appendix into the main body + delete the appendix preamble.

      jhead>> As discussed elsewhere in this review, we will make support of this Sub-Type a MUST, but yes, use of the exact Thrift model is a SHOULD.

[Med] ACK.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# restriction vs no restriction

Abstract:
   The data contained within these KV TIEs can be used for any
   imaginable purpose.

Introduction:
   There are no restrictions placed on the type of data that
   is contained in KV TIEs nor what the data is used for.

However, Section 3 says:

   Key-Value elements SHOULD NOT be used to carry topology information
   used by RIFT itself to perform distributed computations.

I would reword for consistency.

      jhead>> I do understand your point, but “SHOULD NOT” does not restrict an implementation, we chose that over MUST NOT for exactly this reason. If an implementation really wants to implement something around topology information used by RIFT in a KV it’s up to them.
[Med] I still see a conflict between these two parts of the text as we are recommending against it one place. One way to soften this is to expand a bit the SHOULD NOT text to explain the rationale behind it + simply delete the no restriction sentence.

# Allowed values

I assume “reserved value” means “registered value”. I suggest the following:

OLD:
      *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.

NEW:
      *Key-Type:*
         A 1-byte value that identifies the Key-Type. Values are taken from the
         registry defined in [IANA-RIFT].

No need to use the normative language here as unknown types will be ignored
anyway. Furthermore, varying that type can be used for testing/verification
purposes.

      jhead>> I changed phrasing to registered.
[Med] ACK.
      jhead>> Unknown Key-Types would not be ignored, they would be flooded as normal. However, your point is still valid.
[Med] ACK.

# Logging

Glad to see that the discard is logged here. However, in order to avoid abuse,
such an event can be restricted for the same type.

I suggest the following changes (also applicable for other similar uses in the
doc):

OLD:
         KV TIEs received with this value and MUST
         be discarded and logged on receipt.

NEW:
         KV TIEs received with this value MUST
         be discarded and logged at least once on receipt.

      jhead>> Great catch, yes I’ll update accordingly.
[Med] ACK.


# (minor) On multiple key identifiers

CURRENT:
      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                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

..
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Key-Type    |  Key Sub-Type |        Key Identifier         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Given the variants out there, I would use a distinct field name to easily
distinguish them: For example, “Long Key Identifier” would be better to Figure
1.

      jhead>> I think I’m good with this as it clarifies things for both operators and implementers.
      jhead>> I’ll adjust it to use (Key Type / Key Identifier) and (Key Sub-Type / Key Sub-Identifier)
[Med] Thank you.


# Policies

## Where?

CURRENT:
   In cases where KV TIEs are flooded southbound, policies SHOULD be
   implemented in order to avoid network-wide flooding.

Can we be more explicit about when/where these policies are enforced?

[Med] I see that you changed that one to “mechanism..”.

## Assess enforcement

CURRENT:
   For networks with more than one ToF node, it is RECOMMENDED that
   those ToF nodes contain identical KV TIE information when being
   distributed southbound.

How this is tracked/checked? Can we include some means for the operators?

      jhead>> We can only check after tie breaking occurs.
      jhead>> I’ve rephrased this to say that implementations are RECOMMENDED to ensure that Values are determined independently and consistently to avoid scenarios where you have overlapping keys with differing values. Obviously this is impossible to prevent outright in every scenario, so I also noted that operators should consider failure scenarios a bit more (e.g., ToF split-brain).
[Med] I think that I’m fine with this.

# Testing is important for correct operation verification

CURRENT:
  All implementations SHOULD support this Sub-Type.

I suggest s/SHOULD/MUST

      jhead>> Agreed, MUST support the KV TIE, SHOULD use our thrift model to do so.
[Med] Thank you.


# RFC 9696

I was expecting the document to remind RFC 9696 and indicate aspects that are
specific to the IEs. At least, retrieval and exposure of supported KV TIE,
their activation status, etc. should be discussed in this document.

jhead>> There is one example of what KV could be used for in RFC9696 (key rollover), but the example I provide within this spec (Auto-EVPN) is actually implemented and serves as a better example.
jhead>> If you mean that an implementation should factor in a way to convey (to the operator) what KV TIEs it supports, I don’t think that’s something we should specify as it would be up to the implementation, even if I do like the idea.
[Med] ACK.

Maybe listing items that may be covered in the future by a future augmentation
to RFC 9719 would be helpful (no need to include the modelling here, but only
key parameters).

      jhead>> I agree with you in spirit but with the intended flexibility of KV in that a spec can define the structure however they want, I don’t want to tell an implementation that there is a way they should be doing things with respect to YANG.
[Med] ACK

# Nits

## Section 2 (there are several such occurrences in the doc)

OLD: KV TIEs received with this value and MUST
         be discarded and logged on receipt.

NEW: KV TIEs received with this value and MUST
         be discarded and logged on receipt.

      jhead>> Fixed.
[Med] ACK


OLD:
         A 3-byte value that identifies the specific key and describes
         and the semantics of any contained values.

NEW:
         A 3-byte value that identifies the specific key and describes
         the semantics of any contained values.

      jhead>> Ack, will fix it.
[Med] ACK


## Section 2.1

s/from 3-bytes to 2-bytes/from 3 bytes to 2 bytes

 or

s/from 3-bytes to 2-bytes/from 3-byte to 2-byte

      jhead>> Ah yes, will fix.
[Med] ACK


## Section 2.2

OLD:
   As shown in Figure 3, the Key-Type will be used to identify the Key-
   Type as Experimental.

NEW:
   As shown in Figure 3, the Key-Type set to 1 identifies Experimental Key-
   Types.

      jhead>> Sure.
[Med] ACK


## Section 2.3

OLD:
   As shown in Figure 4, the Key-Type will be used to identify the Key-
   Type as Well-Known.

NEW:
   As shown in Figure 4, the Key-Type set to 2 identifies Well-Known Key-
   Type.

(consider a similar change in 2.4

      jhead>> I’ll adjust in all relevant sections.
[Med] ACK


## Section 3

CURRENT:
   In this scenario, nodes that receive KV TIEs that
   they don't recognize (e.g., an unknown Key-Type) will continue to
   flood them as specified in RIFT [RFC9692].

Please help readers find which section in that RFC they need to look at.

      jhead>> Will do.
[Med] Thanks.


## Section 3.2: s/Targets are 64-bits/Targets are 64-bit

      jhead>> Sure.
[Med] ACK
      

## IANA

###

OLD:
   Experts reviewing requests for new values to either registry MUST
   consider the items in the Expert Review Guidance in  Section 4.3
   section.

NEW:
   Expert Review Guidance is provided in Section 4.3.

      jhead>> You’re right, no need for normative here.
[Med] ACK


### s/illegal/Reserved

      jhead>> We state “Illegal” in the base spec and its IANA registries, I’d like to keep it consistent.

Hope this helps.

Cheers,
Med


____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.