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

[Greg Mirsky <[e-mail]>]

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]> wrote:

> 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.
>
>
>
>