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

[Haoyu Song <[e-mail]>]

Greg and Tianran,

Thanks for the explanation. Now it’s clear to me. I would consider the issue is resolved. Thanks!

Best regards,
Haoyu

From: Tianran Zhou <[e-mail]>
Sent: Monday, December 4, 2023 4:03 PM
To: Greg Mirsky <[e-mail]>; Haoyu Song <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: RE: Intdir telechat review of draft-ietf-ippm-stamp-on-lag-05

Hi Haoyu,

Greg is correct, this is to set up micro-sessions for each LAG member link.
It seems you have concern on how to send packet to a dedicated member link.
Think in this way, the upper layer must know how many L2 interfaces are there, and the id/name. We can even see this from the CLI, right?
This means the upper layer can send packet to a specific member link, but the difference to hashing is the goal.
Hashing is a way to evenly spray flows/packets to each member link.
How to send packet to a dedicated member link is quite implementation specific. I did not see any related standard.

Best,
Tianran


From: Greg Mirsky [mailto:[e-mail]]
Sent: Tuesday, December 5, 2023 4:54 AM
To: Haoyu Song <[e-mail]<mailto:[e-mail]>>
Cc: Tianran Zhou <[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: Re: Intdir telechat review of draft-ietf-ippm-stamp-on-lag-05

Hi Haoyu,
thank you for your detailed review and thoughtful questions. I think that can offer my understanding of the relationship between frame hashing techniques used on LAG and the micro-STAMP test sessions discussed in the draft. It seems like an important point, to note that in the draft micro-STAMP over LAG is defined not as a single STAMP test session but a set of sessions, one per LAG member link. The same approach is described for micro-BFD in RFC 7130<https://datatracker.ietf.org/doc/rfc7130/>, and doesn't use frame hashing on LAG by transmitting a test packet directly over the particular member link.

Regards,
Greg

On Mon, Dec 4, 2023 at 10:39 AM Haoyu Song <[e-mail]<mailto:[e-mail]>> wrote:
Please see my inline response.
Haoyu

-----Original Message-----
From: Tianran Zhou <[e-mail]<mailto:[e-mail]>>
Sent: Sunday, December 3, 2023 10:52 PM
To: Haoyu Song <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]>]
Sent: Friday, November 17, 2023 2:19 AM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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.