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