Re: [ippm] Call for adoption of PM on LAG

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

Hello Yunyang Lu, Greg and All,

Thank you very much for your discussion and interests.

From the perspective of an operator, we do not need the interoperation between TWAMP and STAMP, nor the extended  micro TWAMP/Light and the traditional TWAMP/light, nor the extended micro STAMP and the original STAMP,  because test sessions are deployed trunk by trunk or link by link, we know the capability of each device and will use the same protocol with the same extension to complete the test task.

We'll state this point clearly in our docs ater the adoption.



Best Regards,
Zhenqiang Li

[e-mail]
 
From: Greg Mirsky
Date: 2022-09-10 13:51
To: Lu Yunyang
CC: Marcus Ihlar; IETF IPPM WG
Subject: Re: [ippm] Call for adoption of PM on LAG
Hi Yunyang Lu,
thank you for your thoughtful arguments. Please find my follow-up notes in-lined below under the GIM2>> tag.

Regards,
Greg

On Fri, Sep 9, 2022 at 12:52 PM Lu Yunyang <[e-mail]> wrote:
Hi Greg, 
I think interoperability between STAMP and TWAMP Light is more than a straghtforward extension. 
The idea that STAMP and TWAMP Light are able to interwork with each other is based on two doctrines:
1) both protocols work in simple sender-reflector mode, without additional server or client roles defined in original TWAMP.
2) the packet formats from sender and reflector sides are exactly the same for both protocols in unauthenticated mode.
Besides, RFC8762 states that ANY STAMP extensions will be ignored and treated as plain Packet Padding field when communicating with a TWAMP Light counterpart. 
GIM2>> Agreed. 
Since all member links in LAG share same IP address and test sessions usually use same port number across these member links, two new fields (Sender / Reflector Micro-session ID) have been introduced as distinguisher to identify different sessions. 
GIM@>> Here, I will point out that "usually" doesn't mean "required". An operator can discover which protocol performs which role and configure individual test sessions per LAG member link accordingly. 
However, PM on LAG has different implementations for STAMP and TWAMP Light. 
GIM2>> I might have not been clear in earlier notes. I think that the protocol interworking over LAG can be handled as a set of independent test sessions per each LAG member link. None of the discussed LAG-specific extensions should be invoked. True, it is not guaranteed that an arbitrary implementation of the Session-Reflector will transmit a reflected packet over the same LAG member link as the received test packet. Thus I agree with you that in a general case, test results in the protocol interworking environment could be uncertain, difficult to interpret.
On sender side, Micro-session IDs are placed right after Error Estimate field in TWAMP packet, occupying part of original padding field defined in RFC4656/5357; while on reflector side Sender and Reflector Micro-session IDs are placed after Sender Error Estimate and Sender TTL, respectively. For STAMP, a new TLV has been requested to carry LAG test session info and should be appended to the end of original packet by RFC8972. As a result, the Micro-session ID carried by TWAMP packet falls in padding area if treated as STAMP packet, and vice versa. If a LAG test session has been deploy in hybrid mode, a regular reflector packet might be sent back in response to a micro-session sender packet from a specific LAG member following the procedure described in RFC8762, which is absolutely not a goal of the new proposal. Even if the sender node discards the response due to session mismatch, test packets will continue to transfer without manual interruption from network operator, making it potentially hazardous.
Personally, I think STAMP and TWAMP Light for PM on LAG are not quite interoperable at current stage, and no operators will actually deploy in this way. But, as a standard protocol, we must consider backward compatibility with existing implementations. By extending PM from L3 links to LAG members, we are not supposed to annul the original STAMP / TWAMP Light interoperability defined in RFC8762. Therefore, it is necessary to clarify the hybrid scenario to avoid unexcepted outcome. 
GIM2>> I agree with your conclusion that the hybrid use of active test protocols is undesirable, and is not recommended. It is a very good idea to state that clearly in the document. The same, I think, applies to an environment that uses, for example, implementations of STAMP that support and doesn't support draft-li-ippm-stamp-on-lag. It seems like this is a general outcome for incremental deployment of a particular extension. What do you think?

Regards,
Greg
Best regards,
Yunyang Lu

From: Greg Mirsky
Date: 2022-09-09 14:50
To: Lu Yunyang
CC: Marcus Ihlar; IETF IPPM WG
Subject: Re: [ippm] Call for adoption of PM on LAG
Hi Yungyang Lu,
thank you for supporting our work and your thoughtful questions. The scenario you've presented is realistic and we believe that our proposal can address it. We'll describe handling of this interoperability scenario in the future version of the draft.  Please find my notes in-lined below under the GIM>> tag.

Regards,
Greg

On Wed, Sep 7, 2022 at 11:49 AM Lu Yunyang <[e-mail]> wrote:
Hi WG,
 
I support the adoption of these drafts. PM on LAG could solve some essential problem for provider and enterprise level network operation. 

Besides, I think it's necessary to add some clarification for interoperability betweet STAMP and TWAMP-Light, as those stated in RFC8762. Several issues should be considered:
1)  whether STAMP sender / TWAMP-Light reflector and TWAMP-Light sender / STAMP reflector combinations can be used for PM on LAG.
GIM>> I think that both scenarios can be supported, although that would expect more from STAMP implementation as well as more configuration by an operator to use STAMP-TWAMP Light interoperability principles described in Section 4.6 of RFC 8762. As a result, each of LAG member links will be configured as a separate test session.
2)  any protocol modifaction or restriction for such measurements.
GIM>> It seems like this scenario would require more operational effort but without specific protocol extensions. What do you think? 
3)  other considerations that may involve, like security and compatibility with other TWAMP / STAMP extensions. 
GIM>> Thank you for this suggestion! We'll certainly work on adding text addressing security and interworking with other STAMP extensions. 
 
Best regards,
Yunyang Lu

发件人: ippm <[e-mail]> 代表 Marcus Ihlar
发送时间: 2022年9月2日 00:44
收件人: IETF IPPM WG ([e-mail]) <[e-mail]>
主题: [ippm] Call for adoption of PM on LAG
 
Hello IPPM,
This email starts an adoption call in the IPPM working group for the draft-li-ippm-stamp-on-lag and draft-li-ippm-otwamp-on-lag documents. These documents extend STAMP, OWAMP and TWAMP to support performance measurements on member links of a Link Aggregation Group.
 
The first draft specifies an extension to STAMP and can be found here:
https://datatracker.ietf.org/doc/draft-li-ippm-stamp-on-lag/ 
https://datatracker.ietf.org/doc/html/draft-li-ippm-stamp-on-lag/ 
 
The second draft specifies extensions to OWAMP and TWAMP and can be found here:
https://datatracker.ietf.org/doc/draft-li-ippm-otwamp-on-lag/
https://datatracker.ietf.org/doc/html/draft-li-ippm-otwamp-on-lag/
 
Please reply to this email by Thursday September 15, to indicate whether you support adoption of these documents.
 
BR
Marcus & Tommy
_______________________________________________
ippm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ippm