Re: [ippm] Warren Kumari's Yes on draft-ietf-ippm-otwamp-on-lag-07: (with COMMENT)

["[e-mail]" <[e-mail]>]

Dear Warren,

Thank you for your yes and comments. Please see my reply inline beginning with [lzq].



Best Regards,
Zhenqiang Li
China Mobile
[e-mail]
 
From: Warren Kumari via Datatracker
Date: 2023-11-30 05:41
To: The IESG
CC: draft-ietf-ippm-otwamp-on-lag; ippm-chairs; ippm; marcus.ihlar; marcus.ihlar
Subject: Warren Kumari's Yes on draft-ietf-ippm-otwamp-on-lag-07: (with COMMENT)
Warren Kumari has entered the following ballot position for
draft-ietf-ippm-otwamp-on-lag-07: Yes
 
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
 
 
Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.
 
 
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-otwamp-on-lag/
 
 
 
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
 
Thank you for writing this - this seems like a very useful document, solving a
real issue.
 
I have have a number of comments and suggestions to try and make the document
even better / clearer:
 
1: "Usually, when forwarding traffic over LAG, the hash-based mechanism is used
to load balance the traffic across the LAG member links." I suggest "when
forwarding traffic over LAG, a hash-based mechanism is used" or "hash-based
mechanisms are used" -- everyone has their own hash based mechanism...

[lzq]: Accept. Will modify.

 
2: "Link delay of each member link varies because of different transport
paths." -- "The link delay might vary between member links because..." -- the
majority of LAGs (citation needed!) are single hop Ethernets between
switches/routers, and have (for all intents and purposes) identical delay.

[lzq]: Accept. We will modify. The scenario to be addressed is mainly  LAGs in WAN especially via different transport paths, not in LAN. For example, the LAG between routers in Chicago and Los Angles. We will also explicitly state this point in the doc.

 
3: "OWAMP [RFC4656] and TWAMP [RFC5357] are two active measurement methods
according to the classification given in [RFC7799], which can complement
passive and hybrid methods." I found this sentence hard to parse. Perhaps
something like "According to the classifications in [RFC7799], OWAMP [RFC4656]
and TWAMP [RFC5357] are active measurement methods, and they can complement
passive and hybrid methods."
 
[lzq]: Thank you. Will modify.


4: "This document intends to address the scenario (e.g., Figure 1) where a LAG
(e.g., the LAG includes four member links) directly connects two nodes (A and
B)." This was another tricky (for me) to parse sentence. Perhaps "This document
intends to address  directly connects two nodes (A and B). An
example of this is in Figure 1, where the LAG consisting of four links connects
nodes A and B." would be clearer?
 
[lzq]: Ok. Will use the text like: The scenario this document is to be addressed is the LAG that directly connects two nodes in WAN (Wide Area Network). An
example of this is shown in Figure 1, where the LAG consisting of four links connects nodes A and B. If needed, LAGs in LAN (Local Area Network) may also use the method introduced in this doc to measure the performance of each member link in the LAGs.

Again, I think that this is a useful document, these are just readability
suggestions...
 
[lzq]: Thank you.