Skip to main content

Telechat Review of draft-ietf-ippm-stamp-on-lag-05
review-ietf-ippm-stamp-on-lag-05-intdir-telechat-song-2023-11-16-00

Request Review of draft-ietf-ippm-stamp-on-lag
Requested revision No specific revision (document currently at 06)
Type Telechat Review
Team Internet Area Directorate (intdir)
Deadline 2023-11-23
Requested 2023-11-14
Requested by Éric Vyncke
Authors Zhenqiang Li , Tianran Zhou , Guo Jun , Greg Mirsky , Rakesh Gandhi
I-D last updated 2023-11-16
Completed reviews Intdir Telechat review of -05 by Haoyu Song (diff)
Intdir Telechat review of -05 by Antoine Fressancourt (diff)
Secdir Last Call review of -05 by Nancy Cam-Winget (diff)
Assignment Reviewer Haoyu Song
State Completed
Request Telechat review on draft-ietf-ippm-stamp-on-lag by Internet Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/int-dir/vxDBlUNHlOjyVlpSC2hhAMB4uUc
Reviewed revision 05 (document currently at 06)
Result Ready w/issues
Completed 2023-11-16
review-ietf-ippm-stamp-on-lag-05-intdir-telechat-song-2023-11-16-00
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.

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

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