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

[Lu Yunyang <[e-mail]>]

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. 
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. However, PM on LAG has different implementations for STAMP and TWAMP Light. 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. 

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