Hi Haoyu, Thanks very much for the detailed review and your comments. Please see in line with my thoughts. Cheers, Tianran -----Original Message----- From: Haoyu Song via Datatracker [mailto:noreply@xxxxxxxx] Sent: Friday, November 17, 2023 2:19 AM To: int-dir@xxxxxxxx Cc: draft-ietf-ippm-stamp-on-lag.all@xxxxxxxx; ippm@xxxxxxxx; last-call@xxxxxxxx Subject: Intdir telechat review of draft-ietf-ippm-stamp-on-lag-05 Reviewer: Haoyu Song Review result: Ready with Issues I am the assigned INTDIR reviewer for this draft. Please treat the comments just like any other last call comments. The document is well written and tackles a practical problem by using a well-established protocol. While I believe the scheme works, I’m a little concerned with its implementation. My understanding is that LAG is an L2 MAC function, and the member link of a LAG is indifferentiable at L3. Where will this scheme be implemented? In MAC or in L3+ packet processing? In either case, I think the document should give more consideration and discussion on the implementation issues. ZTR> The implementation is in L3+ packet processing. The packet takes meta data about which interface it's received from. I think it's straight forward. But it seems too implementation specific. What kind of implementation considerations do you think should be documented? Other nits: I don’t understand the second part of this sentence, please consider rephrasing for clarification. “The measured metrics can only reflect the performance of one member link or an average of some/all member links of the LAG.” ZTR> How about this: One STAMP test session can measure the performance of one member link with fixed five tuples. Or it can measure an average of some/all member links of the LAG by varying the five tuples. It seems unnecessary to include the following statement because no solution is given in this document and the topic is irrelevant. “The proposed method could also potentially apply to layer 3 ECMP (Equal Cost Multi-Path), e.g., with Segment Routing Policy [RFC9256]. The details are for future work, and not in the scope of this document.” ZTR> Yes. The authors would like to remove this from the document. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
