Re: [ippm] Call for adoption of PM on LAG
Greg Mirsky <gregimirsky@gmail.com> Sat, 10 September 2022 05:51 UTC
Return-Path: <gregimirsky@gmail.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28B6C1522BC for <ippm@ietfa.amsl.com>; Fri, 9 Sep 2022 22:51:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8xowKcaaIDm for <ippm@ietfa.amsl.com>; Fri, 9 Sep 2022 22:51:46 -0700 (PDT)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [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 ietfa.amsl.com (Postfix) with ESMTPS id 0561DC14CE26 for <ippm@ietf.org>; Fri, 9 Sep 2022 22:51:45 -0700 (PDT)
Received: by mail-lf1-x133.google.com with SMTP id bq23so6233759lfb.7 for <ippm@ietf.org>; Fri, 09 Sep 2022 22:51:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <AM0PR07MB4131BFFD304468FA4CCD0484E27B9@AM0PR07MB4131.eurprd07.prod.outlook.com> <2022090717491209387539@unitechs.com> <CA+RyBmVc5skSwJK2Y=xqFkEgmHj5iQ+DgEur7EUBpPNmOYQwCA@mail.gmail.com> <20220909164014393168115@unitechs.com>
In-Reply-To: <20220909164014393168115@unitechs.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Sat, 10 Sep 2022 07:51:32 +0200
Message-ID: <CA+RyBmVzT5koO08+TdRcHVNrGOM2=EJsWiEgsFKPOL3ed6ZREw@mail.gmail.com>
To: Lu Yunyang <luyy@unitechs.com>
Cc: Marcus Ihlar <marcus.ihlar=40ericsson.com@dmarc.ietf.org>, IETF IPPM WG <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e1c50b05e84c4196"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/DVCdSK6iGLizVFEkx7iAGvpkRzI>
Subject: Re: [ippm] Call for adoption of PM on LAG
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=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. Regards, Greg On Fri, Sep 9, 2022 at 12:52 PM Lu Yunyang <luyy@unitechs.com> 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 <gregimirsky@gmail.com> > *Date:* 2022-09-09 14:50 > *To:* Lu Yunyang <luyy@unitechs.com> > *CC:* Marcus Ihlar <marcus.ihlar=40ericsson.com@dmarc.ietf.org>; IETF > IPPM WG <ippm@ietf.org> > *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 <luyy@unitechs.com> 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 <https://datatracker.ietf.org/doc/rfc8762/>. 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 <ippm-bounces@ietf.org> *代表 *Marcus Ihlar >> *发送时间:* 2022年9月2日 00:44 >> *收件人:* IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org> >> *主题:* [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 >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> >
- [ippm] Call for adoption of PM on LAG Marcus Ihlar
- Re: [ippm] Call for adoption of PM on LAG Tianran Zhou
- Re: [ippm] Call for adoption of PM on LAG li_zhenqiang@hotmail.com
- Re: [ippm] Call for adoption of PM on LAG Aijun Wang
- Re: [ippm] Call for adoption of PM on LAG Giuseppe Fioccola
- Re: [ippm] Call for adoption of PM on LAG guo.jun2
- Re: [ippm] Call for adoption of PM on LAG Foote, Footer (Nokia - CA)
- Re: [ippm] Call for adoption of PM on LAG Rakesh Gandhi (rgandhi)
- Re: [ippm] Call for adoption of PM on LAG Greg Mirsky
- Re: [ippm] Call for adoption of PM on LAG xiao.min2
- Re: [ippm] Call for adoption of PM on LAG li_zhenqiang@hotmail.com
- Re: [ippm] Call for adoption of PM on LAG Lizhenbin
- Re: [ippm] Call for adoption of PM on LAG Yisong Liu
- Re: [ippm] Call for adoption of PM on LAG Haoyu Song
- [ippm] 答复: Call for adoption of PM on LAG gongliyan
- Re: [ippm] Call for adoption of PM on LAG Lu Yunyang
- Re: [ippm] Call for adoption of PM on LAG Xuhui Cai
- Re: [ippm] Call for adoption of PM on LAG Alexander L Clemm
- Re: [ippm] Call for adoption of PM on LAG Dongjie (Jimmy)
- Re: [ippm] Call for adoption of PM on LAG Greg Mirsky
- Re: [ippm] Call for adoption of PM on LAG Lu Yunyang
- Re: [ippm] Call for adoption of PM on LAG Greg Mirsky
- Re: [ippm] Call for adoption of PM on LAG li_zhenqiang@hotmail.com
- Re: [ippm] Call for adoption of PM on LAG Marcus Ihlar
- Re: [ippm] Call for adoption of PM on LAG Tianran Zhou
- Re: [ippm] Call for adoption of PM on LAG li_zhenqiang@hotmail.com