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

[Haoyu Song <[e-mail]>]

Please see my inline response.
Haoyu

-----Original Message-----
From: Tianran Zhou <[e-mail]> 
Sent: Sunday, December 3, 2023 10:52 PM
To: Haoyu Song <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: Intdir telechat review of draft-ietf-ippm-stamp-on-lag-05

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:[e-mail]] 
Sent: Friday, November 17, 2023 2:19 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
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? 

HS> If so, what meta data is used? AFAIK, LAG uses hashing on header fields like ECMP to pick a member link, so you have to learn the mapping between header field values to links to be able to send packets on a designated link. No matter what behaviors are assumed, I think the document can be more specific to describe those possible solutions.  

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.

HS>Ok, now I understand what this sentence means. However, by varying the five tuples, unless you know the exact tuple value to link mapping, you can't guarantee that the tuples are evenly distributed on all the member links, so the measurement could be biased from the true average.

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.