Re: [Int-dir] Intdir telechat review of draft-ietf-ippm-stamp-on-lag-05

[Tianran Zhou <[e-mail]>]

Hi Antonie,

Thanks very much for your detailed review and your comments.
Please see in line.

Best,
Tianran

-----Original Message-----
From: Antoine Fressancourt via Datatracker [mailto:[e-mail]] 
Sent: Tuesday, November 21, 2023 9:27 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Intdir telechat review of draft-ietf-ippm-stamp-on-lag-05

Reviewer: Antoine Fressancourt
Review result: Ready with Issues

I am an assigned INT directorate reviewer for draft-ietf-ippm-stamp-on-lag-05.txt. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>.

Based on my review, if I was on the IESG I would ballot this document as DISCUSS.

* I have the following DISCUSS/ABSTAIN level issues:

** In Section 3.2, the behavior of the Session-Sender and of the Session-Reflector regarding the value of the Reflector Micro-session ID field is problematic. Indeed, the 3rd paragraph of Section 3.2 states that the Session-Sender MUST set the Reflector Micro-session ID field if he knows it, or set it to ZERO otherwise. Yet, the conditions in which this field is supposed to be known are unclear, and the last sentence of the paragraph states that how the Reflector is supposed to know this ID is outside the document's scope. As a potential implementer of this protocol, I find this description puzzling, and let me wonder when the Session-Reflector is supposed to know this ID. The 5th paragraph of Section 3.2 mentions that the Session-Reflector MUST check the value of the Reflector Micro-session ID if it is not set to ZERO, but is rather unclear about what is the benefits one can take out of this verification. 

ZTR> In the document, "The Reflector member link identifier can be obtained from pre-configuration or learned from data plane (e.g., the reflected test packet).", this gives example to get the Reflector member link identifier. And I would like rephrase the following text as "This document does not specify the way to obtain the Reflector member link identifier."

This use and management of the Reflector Micro-session ID is even more confusing when reading the last sentence of Section 3.2 which mentions that any procedure with regards to the Micro-session ID is stateless.

ZTR> In RFC8762, the state is mainly about counter. That means the reflector need to manage/change the counter state based on the packet received. However in this case Micro-session ID is always there without a state change. So I think there is no state management, hence stateless.

The document should either mention the benefit that can be taken from having the Session-Sender set the proper value for the Reflector Micro-session ID and give some more details about how and when the Session-Sender are supposed to learn about this ID, or be more relaxed with regards to the value of this field. Besides, given that, to the best of my knowledge, RFC 8972 does not give any constraint about the length of STAMP optionnal TLVs (even if the examples given in RFC 8972 are all aligned to 4 bytes...), I wonder what is the benefit from keeping the Reflector Micro-session ID in the TLV, so the overall Micro-session ID TLV could be 6 bytes long.

ZTR> The value of setting Reflector Micro-session ID at the Session-Sender is to do the member link validation. In the document, " When the micro STAMP Session-Reflector receives a test packet, if the Reflector Micro-session ID is not zero, the micro STAMP Session-Reflector MUST use the Reflector member link identifier to check whether it is associated with the micro STAMP session. If the validation fails, the test packet MUST be discarded." 

* The following are other issues I found with this document that SHOULD be corrected before publication:

** In Section 2, in the 4th paragraph, it is stated that "each micro STAMP session MUST be assigned with a unique SSID", yet, if I read correctly, in RFC
8972 this MUST is a MAY (3rd paragraph in Section 3 of RFC 8972: "A STAMP Session-Sender MAY generate a locally unique STAMP session Identifier (SSID)."). This should be either harmonized or, if there is a reason for requiring a MUST here, it should be clearly stated.

ZTR> Yes. And together with some other suggestions on validation check, we would like to remove this paragraph. 

* The following are minor issues (typos, misspelling, minor text improvements) with the document:

** In Section 1, the document should include a clear reference to OWAMP and TWAMP to help the reader refer to the document describing those protocols.

ZTR> Yes. I will add the reference in the next version.