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

Lu Yunyang <> Wed, 07 September 2022 09:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 24635C152574 for <>; Wed, 7 Sep 2022 02:49:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YXgfSZsNmp-t for <>; Wed, 7 Sep 2022 02:49:18 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 1B076C1524B6 for <>; Wed, 7 Sep 2022 02:49:15 -0700 (PDT)
X-Alimail-AntiSpam: AC=CONTINUE; BC=0.06407107|-1; BR=01201311R101S24rulernew998_84748_2000303; CH=blue; DM=|CONTINUE|false|; DS=CONTINUE|ham_social|0.024085-0.00764932-0.968266; FP=0|0|0|0|0|-1|-1|-1; HT=ay29a033018047205;; NM=1; PH=DS; RN=2; RT=2; SR=0; TI=SMTPD_---.PAA.MqO_1662544151;
Received: from DESKTOP-BIN9HAI( fp:SMTPD_---.PAA.MqO_1662544151) by; Wed, 07 Sep 2022 17:49:12 +0800
Date: Wed, 07 Sep 2022 17:49:13 +0800
From: Lu Yunyang <>
To: 'Marcus Ihlar' <>, 'IETF IPPM WG' <>
References: <>
X-Priority: 3
X-GUID: 5D25B352-BFEF-4153-A32B-6C002BF0AB3A
X-Has-Attach: no
X-Mailer: Foxmail[cn]
Mime-Version: 1.0
Message-ID: <>
Content-Type: multipart/alternative; boundary="----=_001_NextPart761461310844_=----"
Archived-At: <>
Subject: Re: [ippm] Call for adoption of PM on LAG
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Sep 2022 09:49:22 -0000

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.
2)  any protocol modifaction or restriction for such measurements.
3)  other considerations that may involve, like security and compatibility with other TWAMP / STAMP extensions. 
Best regards,
Yunyang Lu

发件人: ippm <> 代表 Marcus Ihlar
发送时间: 2022年9月2日 00:44
收件人: IETF IPPM WG ( <>
主题: [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: 
The second draft specifies extensions to OWAMP and TWAMP and can be found here:
Please reply to this email by Thursday September 15, to indicate whether you support adoption of these documents.
Marcus & Tommy