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

Greg Mirsky <> Sat, 10 September 2022 05:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A28B6C1522BC for <>; Fri, 9 Sep 2022 22:51:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h8xowKcaaIDm for <>; Fri, 9 Sep 2022 22:51:46 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::133]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 0561DC14CE26 for <>; Fri, 9 Sep 2022 22:51:45 -0700 (PDT)
Received: by with SMTP id bq23so6233759lfb.7 for <>; Fri, 09 Sep 2022 22:51:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=Aekm9llmnSp0X4Fx7Wuu2Ak44ycAwHIIZamd90dAKoo=; b=pwXTnO1GZtHJ1j3vo65143QQh61hJbD3eXFD8PuQZenhj7BwM1LgHy59qT+4JJZBHV FlMmEbi0UgrQM6ybKz91tOH2ezOUFeltHkbAYqhIEYJ2wif65m5Zy0gU7Jw8c6fpXS8U Oz61MYBc0A4EviSVVoZRiMfSp/nwzy0CJv8XepHdV7bKyjLKCeolyjZyAJnzQEhilV6M 6dw2djNIeDIbJ1AlMBkCbZgFkUuLB83Z8ucq07ix5kKDXT39JcqfBRoNtoF4K35mDuwD bPXXlWERwUXQgC8b2okqwoWEu4ZhYI06VKaYCY2uxvFDwlfE2B0sfjg2ET8c6LtqNKeK 7LiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=Aekm9llmnSp0X4Fx7Wuu2Ak44ycAwHIIZamd90dAKoo=; b=JneWAtrxztxBYRnTGJYBpi3d4414y1MGcRaPhfi8VPRS1HcrVxkKWXHMvpQkqnd/sP e56v7qgLnfkRJQRIa11vQrBG2YYswEMU1/T8xSA2FUDcXszQDY51grINgXdn2R5EiVrY qTfVbvTjitFKUXl3R0lj5vaWsfy9nDAhEeQSN+CJhSlx/KaEp0vIPBmgVn5Mxd8cnbjS J7kJWXH5noprDUoTnY9aYaK4OOUaT1L5Zh+AGcpJF2XSco+A/lmEYCTaH5luPU0rpC9i YA71mMZ6x06WNULKF5w48KbpzcWGUv2xGC1n2XR//XeMIiJrkAnydz8hEYgYfPhu1Ctm aVIw==
X-Gm-Message-State: ACgBeo0WfAEFUwbaU6azHxBESie2GQ/2FSNIzj7dsX+85cV7Bl6JwoLD vPXrX63eci6QUKFDpExX37mVzIgv2lvRI0g6hhuPgaGZzJ8P4XLk
X-Google-Smtp-Source: AA6agR43DMylFDSfXe0U0Es/r2efaMbpbHV52v8WZbeWeqACG8IBvINv6ByPnwgcsgGj/Cz8BH1Cr21Xby77GXBrGSI=
X-Received: by 2002:a05:6512:31c6:b0:48b:2771:d0d2 with SMTP id j6-20020a05651231c600b0048b2771d0d2mr5160753lfe.382.1662789104025; Fri, 09 Sep 2022 22:51:44 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Greg Mirsky <>
Date: Sat, 10 Sep 2022 07:51:32 +0200
Message-ID: <>
To: Lu Yunyang <>
Cc: Marcus Ihlar <>, IETF IPPM WG <>
Content-Type: multipart/alternative; boundary="000000000000e1c50b05e84c4196"
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: Sat, 10 Sep 2022 05:51:50 -0000

Hi Yunyang Lu,
thank you for your thoughtful arguments. Please find my follow-up notes
in-lined below under the GIM2>> tag.


On Fri, Sep 9, 2022 at 12:52 PM Lu Yunyang <> 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?


> 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 <> 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 <> *代表 *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.
>> BR
>> Marcus & Tommy
>> _______________________________________________
>> ippm mailing list