From nobody Mon Jan 3 01:18:40 2022 Return-Path: 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 838CF3A0D3D for ; Mon, 3 Jan 2022 01:18:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvD5LkcwfBro for ; Mon, 3 Jan 2022 01:18:35 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D55C83A0D3A for ; Mon, 3 Jan 2022 01:18:34 -0800 (PST) Received: from fraeml712-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JS98m4jffz67nWT; Mon, 3 Jan 2022 17:16:08 +0800 (CST) Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml712-chm.china.huawei.com (10.206.15.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Mon, 3 Jan 2022 10:18:31 +0100 Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.2308.020; Mon, 3 Jan 2022 10:18:31 +0100 From: Giuseppe Fioccola To: "xiao.min2@zte.com.cn" , "ippm@ietf.org" Thread-Topic: Comments on draft-fioccola-rfc8321bis-01 Thread-Index: AQHX+HBOUIuCQOw/1Eeo9KB6v/mPFqxREKRA Date: Mon, 3 Jan 2022 09:18:31 +0000 Message-ID: References: <202112241045151378136@zte.com.cn> In-Reply-To: <202112241045151378136@zte.com.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.95.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] Comments on draft-fioccola-rfc8321bis-01 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2022 09:18:40 -0000 SGkgWGlhbywNClRoYW5rcyBhIGxvdCBmb3IgeW91ciBmZWVkYmFjay4NCkluIHNlY3Rpb24gNSB3 ZSBhbHJlYWR5IG1lbnRpb25lZCBob3cgdG8gdXNlIG9uZSBvciB0d28gZmxhZyBiaXRzIGluIGRp ZmZlcmVudCBkZXBsb3ltZW50cy4gQnV0IHdlIGNhbiBhbHNvIGluY2x1ZGUgYSBzaW1pbGFyIGNv bnNpZGVyYXRpb24gZm9yIHRoZSBTaW5nbGUtTWFya2luZyBNZXRob2RvbG9neSBpbiBzZWN0aW9u IDMuMy4xLiBJZiB0d28gZmxhZyBiaXRzIGFyZSBhdmFpbGFibGUsIERvdWJsZS1NYXJraW5nIE1l dGhvZG9sb2d5IGlzIGRlZmluaXRlbHkgYSBiZXR0ZXIgY2hvaWNlLiANCg0KUmVnYXJkcywNCg0K R2l1c2VwcGUNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogeGlhby5taW4y QHp0ZS5jb20uY24gPHhpYW8ubWluMkB6dGUuY29tLmNuPiANClNlbnQ6IEZyaWRheSwgRGVjZW1i ZXIgMjQsIDIwMjEgMzo0NSBBTQ0KVG86IEdpdXNlcHBlIEZpb2Njb2xhIDxnaXVzZXBwZS5maW9j Y29sYUBodWF3ZWkuY29tPjsgaXBwbUBpZXRmLm9yZw0KU3ViamVjdDogQ29tbWVudHMgb24gZHJh ZnQtZmlvY2NvbGEtcmZjODMyMWJpcy0wMQ0KDQpIaSBHaXVzZXBwZSwNCg0KSSBub3RpY2VkIGlu IHRoZSAtMDEgcmV2aXNpb24geW91IGFkZGVkIHRoYXQgIlRoZSBzd2l0Y2hpbmcgYWZ0ZXIgYSBm aXhlZCBudW1iZXIgb2YgcGFja2V0cyBpcyBhbiBhZGRpdGlvbmFsIHBvc3NpYmlsaXR5IGJ1dCBp dHMgZGV0YWlsZWQgc3BlY2lmaWNhdGlvbiBpcyBvdXQgb2Ygc2NvcGUuIg0KSSBsaWtlIHRoaXMg Y2hhbmdlLCBpdCBnaXZlcyB0aGUgY2xlYXIgcHJhY3RpY2FsIGRpcmVjdGlvbiBvbiBmaXhlZC10 aW1lciBtZXRob2QsIGFzIHdlbGwgYXMgcmVzZXJ2aW5nIHRoZSBwb3NzaWJpbGl0eSBmb3Igc29t ZW9uZSB0byBkZXZlbG9wIGRldGFpbHMgYmFzZWQgb24gZml4ZWQtbnVtYmVyIG1ldGhvZC4NCkkg c3VnZ2VzdCB0byBhcHBseSB0aGUgc2ltaWxhciBkZXNjcmlwdGlvbiBvbiBTaW5nbGUtTWFya2lu ZyBNZXRob2RvbG9neSBkZWZpbmVkIGluIHNlY3Rpb24gMy4zLjEuIFRoZXJlIGFyZSBtYWlubHkg dGhyZWUgcmVhc29ucywgdGhlIGZpcnN0IG9uZSBpcyB0aGF0IERvdWJsZS1NYXJraW5nIE1ldGhv ZG9sb2d5IGRlZmluZWQgaW4gc2VjdGlvbiAzLjMuMiBpcyBhbHJlYWR5IHRoZSBwcmFjdGljYWwg ZGlyZWN0aW9uLCB0aGUgc2Vjb25kIG9uZSBpcyB0aGF0IElNSE8gb25lLWJpdCBzYXZpbmcgb2Yg U2luZ2xlLU1hcmtpbmcgTWV0aG9kb2xvZ3kgZG9lc24ndCBicmluZyBtZWFuaW5nZnVsIGJlbmVm aXQsIHRoZSB0aGlyZCBvbmUgaXMgdGhhdCBTaW5nbGUtTWFya2luZyBNZXRob2RvbG9neSBtYXkg YnJpbmcgaW50cmluc2ljIGVycm9yIGR1ZSB0byBwYWNrZXQgbWlzb3JkZXJpbmcsIGFzIGFkZGVk IGluIHNlY3Rpb24gMy4zLjEgb2YgdGhlIC0wMSByZXZpc2lvbi4NCg0KSGFwcHkgSG9saWRheXMg dG8geW91IGFuZCBhbGwgSVBQTSBmb2xrcyENCg0KQmVzdCBSZWdhcmRzLA0KWGlhbyBNaW4NCg== From nobody Mon Jan 3 07:33:56 2022 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA123A0A9B; Mon, 3 Jan 2022 07:33:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: ippm@ietf.org, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164122403256.7081.8820895477721005138@ietfa.amsl.com> Date: Mon, 03 Jan 2022 07:33:52 -0800 Archived-At: Subject: [ippm] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-ippm-ioam-direct-export X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2022 15:33:55 -0000 Dear Haoyu Song, Barak Gafni, Tianran Zhou, Zhenbin Li, Frank Brockners, Shwetha Bhandari, Ramesh Sivakolundu, Tal Mizrahi: An IPR disclosure that pertains to your Internet-Draft entitled "In-situ OAM Direct Exporting" (draft-ietf-ippm-ioam-direct-export) was submitted to the IETF Secretariat on 2021-12-28 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/5378/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-ippm-ioam-direct-export" Thank you IETF Secretariat From nobody Tue Jan 4 16:23:44 2022 Return-Path: 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 4756F3A219D; Tue, 4 Jan 2022 16:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.325 X-Spam-Level: ** X-Spam-Status: No, score=2.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLZcLpGBcprC; Tue, 4 Jan 2022 16:23:36 -0800 (PST) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CB223A219A; Tue, 4 Jan 2022 16:23:36 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 2050KfuV010682; Tue, 4 Jan 2022 16:23:32 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=6KRs2Jc8irjOJzs1dpE3KSae7ioWh8fHk8h/CQvrvqM=; b=LY7Y/tD8Kt1iESJxqQrfSLBUhKTbTM2jAChfRiPGjKdrFr9YKCMSOD1s4nWn+Xap8Rsv VsFc5emTVJlFch2dIa915trjyIY1LOdkOsuHU6ildf7M+3Zkpm5foyGYiTsjsX04pYdy dksQrflawoSh9LT6t+HG0/ipKK0i7uCUOqUlSR8aYeVRIdWBg/Pw84rc6cuiSLlZHwTf IWWSqW8qmbeTn4x5Gkrj32wCX45HaN90mQu+GTzhQYyGVg3hARljLrVB7+BjSgtTZm6f CzIMHTz62RNcGo1IZ6ZObP4u9KVDroXemxHaFBFxvqKmG9G7u6PD0N+pTHPjkieh2cQQ ew== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 3dapu0tk6t-6 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 04 Jan 2022 16:23:32 -0800 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R570019ONR78300@rn-mailsvcp-mta-lapp01.rno.apple.com>; Tue, 04 Jan 2022 16:23:31 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R5700V00ND9U600@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Tue, 04 Jan 2022 16:23:31 -0800 (PST) X-Va-A: X-Va-T-CD: 81ca60fce39c2560b6c4a7e5841f9b8f X-Va-E-CD: de054fff2f5096dfe99f93b89e853049 X-Va-R-CD: 7d741991045d6b2f869f53b80b980cf0 X-Va-CD: 0 X-Va-ID: 8301b18c-52f4-4a24-ae6c-3783babe23f1 X-V-A: X-V-T-CD: 81ca60fce39c2560b6c4a7e5841f9b8f X-V-E-CD: de054fff2f5096dfe99f93b89e853049 X-V-R-CD: 7d741991045d6b2f869f53b80b980cf0 X-V-CD: 0 X-V-ID: 0c0b4219-538f-4648-8d55-3de7176dbfe0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2022-01-04_11:2022-01-04, 2022-01-04 signatures=0 Received: from smtpclient.apple ([17.192.155.238]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R5700661NR64H00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Tue, 04 Jan 2022 16:23:30 -0800 (PST) From: Christoph Paasch Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_5D6FD931-6B7F-4434-9883-53DA75FDDEA2" MIME-version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) Date: Tue, 04 Jan 2022 16:23:30 -0800 In-reply-to: Cc: Marcus Ihlar , "ippm@ietf.org" , Tommy Pauly To: "MORTON JR., AL" References: X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2022-01-04_11:2022-01-04, 2022-01-04 signatures=0 Archived-At: Subject: Re: [ippm] Adoption call for draft-cpaasch-ippm-responsiveness X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 05 Jan 2022 00:23:42 -0000 --Apple-Mail=_5D6FD931-6B7F-4434-9883-53DA75FDDEA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Al, thanks a lot for your feedback! Please see inline: > On Dec 17, 2021, at 3:50 PM, MORTON JR., AL wrote: >=20 > Hi authors and ippm-chairs, > =20 > Thanks for writing this-up! > =20 > I took one pass through, and have the following comments during = Adoption call for draft-cpaasch-ippm-responsiveness: > =20 > TL;DR: > Many previously undefined terms were used here, and a more direct = description using the term =E2=80=9Csaturation=E2=80=9D seems possible, = IMO. I fully agree with you. We are not very good at describing the "working = conditions"/"saturation" we are aiming for, why we use these and what = the right approach is. The type of "working conditions" is crucial as to what the measurement = result will be For example, flooding the network with UDP traffic will saturate the = network pretty well, but it is far away from a realistic working = condition. What we are aiming for is near worst-case scenario while still being = realistic. At least, that is the intention and it may be good to have an = open discussion about this. > IPPM has used a template for metric drafts, and use of the hierarchy = of singleton, sample, and statistic metrics from RFC 2330 will help with = clarity/answer many of my questions. > =20 > regards (I=E2=80=99m off-line for a while now, so enjoy the holidays), > Al > =20 > =46rom the Abstract: > =20 > This document specifies the "RPM Test" for measuring = responsiveness. > It uses common protocols and mechanisms to measure user experience > especially when the network is fully loaded ("responsiveness under > working conditions".) The measurement is expressed as "Round-trips > Per Minute" (RPM) and should be included with throughput (up and > down) and idle latency as critical indicators of network quality. > =20 > =E2=80=9Cfully loaded=E2=80=9D and =E2=80=9Cworking conditions=E2=80=9D = aren=E2=80=99t necessarily the same, to me. I=E2=80=99ll be looking for = better definitions. Agree'd. > =20 > 3 = . Goals > =20 > The algorithm described here defines an RPM Test that serves as a > good proxy for user experience. This means: > =20 > 1. Today's Internet traffic primarily uses HTTP/2 over TLS. Thus, > the algorithm should use that protocol. > =20 > As a side note: other types of traffic are gaining in = popularity > (HTTP/3) and/or are already being used widely = (RTP). > =20 > There are many measurement stability challenges when TCP is involved, = see section 4 of RFC8337: = https://datatracker.ietf.org/doc/html/rfc8337#section-4 = > RFC8337 intentionally broke the TCP control loop to make measurements = in the face of these challenges. Yes, we are aware of these kind of stability challenges. And actually = sometimes observe them as results can vary to some degree across = different runs. The goal is to get as close as possible to a stable measurement result, = while still using the protocols the end-users use on a day-to-day basis. > =20 > 4.1 = . Working Conditions > =20 > For the purpose of this methodology, typical "working conditions" > represent a state of the network in which the bottleneck node is > experiencing ingress and egress flows similar to those created by > humans in the typical day-to-day pattern. > =20 > While a single HTTP transaction might briefly put a network into > working conditions, making reliable measurements requires = maintaining > the state over sufficient time. > =20 > The algorithm must also detect when the network is in a persistent > working condition, also called "saturation". > =20 > Desired properties of "working condition": > =20 > o Should not waste traffic, since the person may be paying for it > =20 > o Should finish within a short time to avoid impacting other = people > on the same network, to avoid varying network conditions, and = not > try the person's patience. > =20 > These seem like reasonable goals for the traffic that loads the = network. > New terms needing definition were introduced: > =E2=80=9Cpersistent working condition =3D saturation=E2=80=9D, > which is different from > =E2=80=9Cingress and egress flows similar to those created by humans = in the typical day-to-day pattern=E2=80=9D > =20 > Later in 4.1.1, terms like =E2=80=9Csaturate a path=E2=80=9D and = =E2=80=9Cfill the pipe=E2=80=9D appear, and > =20 > The goal of the RPM Test is to keep the network as busy as possible > in a sustained and persistent way. It uses multiple TCP = connections > and gradually adds more TCP flows until saturation is reached. > =20 > The terms =E2=80=9Cbusy as possible=E2=80=9D, and =E2=80=9Ctypical = day-to-day pattern=E2=80=9D, or > =E2=80=9Csaturation=E2=80=9D and =E2=80=9Cworking conditions=E2=80=9D = indicate different load levels to me. > =20 > @@@@ Suggestion: I think it would help to simplify the terminology in = this draft. You intend to measure a saturated path, so just say that. No = =E2=80=9Ctypical=E2=80=9D, no =E2=80=9Cworking conditions=E2=80=9D, = etc., in these early sections.=20 > =20 > The sentence beginning =E2=80=9CThe goal...=E2=80=9D should really = appear in Section 3. Goals > =20 > Also, you have defined a measurement method in the sentence, =E2=80=9CIt= uses...=E2=80=9D above. This method of adding connections has been = observed in other measurement systems, but it isn=E2=80=99t typical of = user traffic, especially when each connection has an ~infinite amount of = data to send during the test. =46rom your comments I see that we definitely need a longer explanation = of the tradeoffs that are being made of measuring this near worst-case, = but realistic scenario. As you correctly point out, we are mixing = confusing and sometimes contradictory terms. This needs to be cleaned = up. For all of the above points, I filed: = https://github.com/network-quality/draft-cpaasch-ippm-responsiveness/issue= s/34 = Please feel free to add to the github issue. > =20 > 4.1.2 = . Parallel vs Sequential Uplink and Downlink > =20 > ... > To measure responsiveness under working conditions, the algorithm > must saturate both directions. > =20 > Bi-directional saturation is really atypical of usage. I don=E2=80=99t = think the benefit of =E2=80=9Cmore data=E2=80=9D pays off. > =20 > ... > =20 > However, a number of caveats come with measuring in parallel: > =20 > o Half-duplex links may not permit simultaneous uplink and = downlink > traffic. This means the test might not saturate both directions > at once. > =20 > o Debuggability of the results becomes harder: During parallel > measurement it is impossible to differentiate whether the = observed > latency happens in the uplink or the downlink direction. > =20 > o Consequently, the test should have an option for sequential > testing. > =20 > @@@@ Suggestion: IMO, tests/results with Downlink saturation OR Uplink = saturation would be more straightforward, and can be understood by users = (especially those who have tested in the past). Avoid the pitfalls and = make Sequential testing the preferred option. I tend to agree with you. We can leave "Parallel" as an interesting = extension to the test that can expose other types of characteristics of = the network. > 4.1.3 = . Reaching saturation > =20 > The RPM Test gradually increases the number of TCP connections and > measures "goodput" - the sum of actual data transferred across all > connections in a unit of time. When the goodput stops increasing, = it > means that saturation has been reached. > ... > =20 > Filling buffers at the bottleneck depends on the congestion control > deployed on the sender side. Congestion control algorithms like = BBR > may reach high throughput without causing queueing because the > bandwidth detection portion of BBR effectively seeks the bottleneck > capacity. > =20 > RPM Test clients and servers should use loss-based congestion > controls like Cubic to fill queues reliably. > =20 > With the evolution of Congestion control algorithms seeking to avoid = filling buffers, does it make sense to require a full buffer at the = bottleneck to achieve saturation? > In fact, the definition above, =E2=80=9CWhen the goodput stops = increasing,...=E2=80=9D does not require full buffers; it requires = maximizing a delivery rate measurement instead. The above paragraph on BBR vs Cubic should probably be changed. With our = goal being to measure "realistic" usage patterns, the recommendation = should be to use the congestion control that is currently most widely = deployed. If the majority of the Internet switches to BBR, then that's = what should be measured. > In 4.1.4, the final steps of the algorithm were not clear to me: > =20 > * Else, network reached saturation for the current flow count. > @@@@ This wording implies it to be the final step, but there are = further conditions to test. > Maybe this step is =E2=80=9CElse, Candidate for stable = saturation=E2=80=9D? Sounds good! > =20 > + If new flows added and for 4 seconds the moving average > throughput did not change: network reached stable = saturation > @@@@ Maybe:=20 > + If the 4 second moving average of "instantaneous aggregate = goodput" with no new=20 > flows added did not change=20 > (defined as: moving average =3D "previous" moving average = +/- 5%), > then the network reached stable saturation That's better! > = --------------------------------------------------------------------------= -------------------------- > =20 > + Else, add four more flows > @@@ ??? and return to start? Yes, the entire thing is evaluated every 1-second interval. I will make = that explicit. > =20 > =20 > Finally, in 4.1.4, the Note explains: > =20 > Note: It is tempting to envision an initial base RTT measurement = and > adjust the intervals as a function of that RTT. However, = experiments > have shown that this makes the saturation detection extremely > unstable in low RTT environments. In the situation where the > "unloaded" RTT is in the single-digit millisecond range, yet the > network's RTT increases under load to more than a hundred > milliseconds, the intervals become much too low to accurately drive > the algorithm. > =20 > Well, TCP senders/control-loops are involved here, and likely play a > role in behavior categorized as =E2=80=9Cdifficult to measure=E2=80=9D. > =20 > By the time we get to > =20 > 4.2 = . Measuring Responsiveness > =20 > Once the network is in a consistent working conditions, the RPM = Test > must "probe" the network multiple times to measure its > responsiveness. > =20 > Each RPM Test probe measures: > =20 > You previously started at least four TCP connections with infinitely = large files. > The =E2=80=9Ccreate connection=E2=80=9D RPM probes establish = additional connections, DNS, TCP, etc. > Is each new connection an RPM probe? or is the set of connection tests = a single probe? > (later we learn it is the set of > What if one of the set of connections fails/times-out? > =20 > I take it that the =E2=80=9Cload-bearing=E2=80=9D connections are = driving the path to saturation. > Maybe =E2=80=9Cload-generating connections=E2=80=9D is more clear? "load-generating" is indeed a better term! For all of the above "minor" edits, I filed = https://github.com/network-quality/draft-cpaasch-ippm-responsiveness/issue= s/35 = =20 > 4.2.1 = . Aggregating the Measurements > =20 > The algorithm produces sets of 5 times for each probe, namely: DNS > handshake, TCP handshake, TLS handshake, HTTP/2 request/response on > separate (idle) connections, HTTP/2 request/response on load = bearing > connections. This fine-grained data is useful, but not necessary = for > creating a useful metric. > =20 > @@@@ So, only ONE of the load-generating connections runs the 1-byte = GET ? (it says connections, and there are at least 4) The various = handshakes result in 4 RT measurements. > =20 > But, do you mean *5 repeated measurement sets*? Each set with: > DNS HS, TCP HS, TLS HS, HTTP/2 idle GET, and the potentially much = longer GET on the=20 > load generating connections. > =20 > To create a single "Responsiveness" (e.g., RPM) number, this first > iteration of the algorithm gives an equal weight to each of these > values. That is, it sums the five time values for each probe, and > divides by the total number of probes to compute an average probe > duration. The reciprocal of this, normalized to 60 seconds, gives > the Round-trips Per Minute (RPM). > =20 > @@@@ I=E2=80=99m missing a step, I think: > Are the =E2=80=9Ctime values for each probe=E2=80=9D the sum of = handshake or response times for > DNS HS, TCP HS, TLS HS, HTTP/2 idle GET and load generating = connections? > The processing doesn=E2=80=99t seem to include this preliminary = calculation to produce=20 > =E2=80=9Cfive time values=E2=80=9D. =20 > =20 > =20 > In Section 5, =E2=80=9Cno new protocol is defined=E2=80=9D, but > =20 > The client begins the responsiveness measurement by querying for = the > JSON configuration. This supplies the URLs for creating the load > bearing connections in the upstream and downstream direction as = well > as the small object for the latency measurements. > =20 > The client needs to know how the server response will be organized, = down to key: value, right? > Some client and server agreements needed... Yes! With "protocol" we mean nothing new at HTTP/TCP/... layer. Just = standard JSON. I don't know if that qualifies as a new "protocol" ;-) Thanks a lot, Christoph > =20 > =20 > From: ippm On Behalf Of Marcus Ihlar > Sent: Monday, December 6, 2021 10:53 AM > To: ippm@ietf.org > Subject: [ippm] Adoption call for draft-cpaasch-ippm-responsiveness > =20 > Hi IPPM, > =20 > This email starts an adoption call for = draft-cpaasch-ippm-responsiveness, "Responsiveness under Working = Conditions=E2=80=9D. This document specifies the =E2=80=9CRPM Test=E2=80=9D= for measuring user experience when the network is fully loaded. The = intended status of the document is Experimental. =20 > =20 > https://datatracker.ietf.org/doc/draft-cpaasch-ippm-responsiveness/ = > = https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-responsiveness-01= = > =20 > This adoption call will last until Monday, December 20. Please review = the document, and reply to this email thread to indicate if you think = IPPM should adopt this document. > =20 > BR, > Marcus=20 > =20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm --Apple-Mail=_5D6FD931-6B7F-4434-9883-53DA75FDDEA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello= Al,

thanks a lot = for your feedback! Please see inline:

On Dec = 17, 2021, at 3:50 PM, MORTON JR., AL <acmorton@att.com> = wrote:

Hi authors and ippm-chairs,
 
Thanks for = writing this-up!
 
I took one = pass through, and have the following comments during Adoption call for = draft-cpaasch-ippm-responsiveness:
 
TL;DR:
Many = previously undefined terms were used here, and a more direct description = using the term =E2=80=9Csaturation=E2=80=9D seems possible, = IMO.

I= fully agree with you. We are not very good at describing the "working = conditions"/"saturation" we are aiming for, why we use these and what = the right approach is.

The type of = "working conditions" is crucial as to what the measurement result will = be
For example, flooding the network with UDP traffic will = saturate the network pretty well, but it is far away from a realistic = working condition.

What we are = aiming for is near worst-case scenario while still being realistic. At = least, that is the intention and it may be good to have an open = discussion about this.

IPPM has used a template for metric drafts, and = use of the hierarchy of singleton, sample, and statistic metrics from = RFC 2330 will help with clarity/answer many of my questions.
 
regards = (I=E2=80=99m off-line for a while now, so enjoy the holidays),
Al
 
=46rom the = Abstract:
 
   This document = specifies the "RPM Test" for measuring responsiveness.
   It uses common = protocols and mechanisms to measure user experience
   especially when the network is fully loaded ("responsiveness = under
   working = conditions".)  The measurement is = expressed as "Round-trips
   Per Minute" (RPM) = and should be included with throughput (up and
   down) and idle = latency as critical indicators of network quality.
 
=E2=80=9Cfully = loaded=E2=80=9D and =E2=80=9Cworking conditions=E2=80=9D aren=E2=80=99t = necessarily the same, to me.  I=E2=80=99ll be = looking for better = definitions.

Agree'd.

 
3.  =
Goals
 
   The algorithm described =
here defines an RPM Test that serves as a
   =
good proxy for user experience.  =
This means:
 
   1.  =
Today's Internet traffic primarily uses HTTP/2 over TLS.  Thus,
       the algorithm =
should use that protocol.
 
       As a side note: =
other types of traffic are gaining in popularity
       (HTTP/3) and/or =
<???? UDP ???> are already being used widely =
(RTP).
 
There are = many measurement stability challenges when TCP is involved, see section = 4 of RFC8337:  https://datatracker.ietf.org/doc/html/rfc8337#section-4
RFC8337 = intentionally broke the TCP control loop to make measurements in the = face of these challenges.

Yes, we are aware of these kind of stability = challenges. And actually sometimes observe them as results can vary to = some degree across different runs.

The= goal is to get as close as possible to a stable measurement result, = while still using the protocols the end-users use on a day-to-day = basis.

 
4.1.  =
Working Conditions
 
   For the purpose of this methodology, =
typical "working conditions"
   =
represent a state of the network in which the bottleneck node =
is
   experiencing ingress and egress flows =
similar to those created by
   =
humans in the typical day-to-day pattern.
 
   While a single HTTP transaction might =
briefly put a network into
   =
working conditions, making reliable measurements requires =
maintaining
   the state over =
sufficient time.
 
   The algorithm must also =
detect when the network is in a persistent
   = working condition, also called "saturation".
 
   Desired properties of "working =
condition":
 
   o  =
Should not waste traffic, since the person may be paying for =
it
 
   o  Should =
finish within a short time to avoid impacting other people
      on the same network, to =
avoid varying network conditions, and not
      try the person's =
patience.
 
These seem = like reasonable goals for the traffic that loads the network.
New terms = needing definition were introduced:
=E2=80=9Cpersistent working condition =3D = saturation=E2=80=9D,
which is different from
=E2=80=9Cingres= s and egress flows similar to those created by humans in the typical day-to-day pattern=E2=80=9D
 
Later in = 4.1.1, terms like =E2=80=9Csaturate a path=E2=80=9D  and =E2=80=9Cfill = the pipe=E2=80=9D appear, and
 
   =
The goal of the RPM Test is to keep the network as =
busy as possible
   in a =
sustained and persistent way.  It uses =
multiple TCP connections
   and =
gradually adds more TCP flows until saturation is reached.
 
The terms = =E2=80=9Cbusy as possible=E2=80=9D, and =E2=80=9Ctypical day-to-day = pattern=E2=80=9D, or
=E2=80=9Csaturation=E2=80=9D and =E2=80=9Cworking = conditions=E2=80=9D indicate different load levels to me.
 
@@@@ = Suggestion: I think it would help to simplify the terminology in this = draft. You intend to measure a saturated path, so just say that. No = =E2=80=9Ctypical=E2=80=9D, no =E2=80=9Cworking conditions=E2=80=9D, = etc., in these early sections. 
 
The sentence = beginning =E2=80=9CThe goal...=E2=80=9D should really appear in Section = 3. Goals
 
Also, you = have defined a measurement method in the sentence, =E2=80=9CIt = uses...=E2=80=9D above. This method of adding connections has been = observed in other measurement systems, but it isn=E2=80=99t typical of = user traffic, especially when each connection has an ~infinite amount of = data to send during the = test.

=46rom your comments I see that we definitely need = a longer explanation of the tradeoffs that are being made of measuring = this near worst-case, but realistic scenario. As you correctly point = out, we are mixing confusing and sometimes contradictory terms. This = needs to be cleaned up.


Please feel free = to add to the github issue.

 
4.1.2.  =
Parallel vs Sequential Uplink and Downlink
 
...
   To measure responsiveness under working =
conditions, the algorithm
   must =
saturate both directions.
 
Bi-directional saturation is really =
atypical of usage. I don=E2=80=99t think the benefit of =E2=80=9Cmore =
data=E2=80=9D pays off.
 
...
 
   However, a number of caveats come with =
measuring in parallel:
 
   =
o  Half-duplex links may not permit =
simultaneous uplink and downlink
      traffic.  This means the test might not saturate both =
directions
      at =
once.
 
   o  =
Debuggability of the results becomes harder: During parallel
      measurement it is =
impossible to differentiate whether the observed
      latency happens in the =
uplink or the downlink direction.
 
   o  =
Consequently, the test should have an option for sequential
      testing.
 
@@@@ = Suggestion: IMO, tests/results with Downlink saturation OR Uplink = saturation would be more straightforward, and can be understood by users = (especially those who have tested in the past). Avoid the pitfalls and = make Sequential testing the preferred = option.

I tend to agree with you. We can leave "Parallel" = as an interesting extension to the test that can expose other types of = characteristics of the network.

4.1.3.  =
Reaching saturation
 
   The RPM Test gradually increases the =
number of TCP connections and
   =
measures "goodput" - the sum of actual data transferred across =
all
   connections in a unit of time.  When the goodput stops increasing, it
   means that saturation has been =
reached.
...
 
   Filling buffers at the =
bottleneck depends on the congestion control
   deployed on the sender side.  Congestion control algorithms like BBR
   may reach high throughput without causing =
queueing because the
   bandwidth =
detection portion of BBR effectively seeks the bottleneck
   capacity.
 
   RPM Test clients and servers should use =
loss-based congestion
   controls =
like Cubic to fill queues reliably.
 
With =
the evolution of Congestion control algorithms seeking to avoid filling =
buffers, does it make sense to require a full buffer at the bottleneck =
to achieve saturation?
In fact, the definition above, =E2=80=9CWhen the =
goodput stops increasing,...=E2=80=9D does not require full buffers; it =
requires maximizing a delivery rate measurement =
instead.

The = above paragraph on BBR vs Cubic should probably be changed. With our = goal being to measure "realistic" usage patterns, the recommendation = should be to use the congestion control that is currently most widely = deployed. If the majority of the Internet switches to BBR, then that's = what should be measured.

In 4.1.4, the final steps of the =
algorithm were not clear to me:
 
      *  =
Else, network reached saturation for the current flow count.
@@@@ =
This wording implies it to be the final step, but there are further =
conditions to test.
     Maybe this =
step is =E2=80=9CElse, Candidate for stable =
saturation=E2=80=9D?

Sounds good!

 
         =
+  If new flows added and for 4 =
seconds the moving average
          &nb=
sp; throughput did not change: network reached stable =
saturation
@@@@ Maybe: 
         +  =
If the 4 second moving average of "instantaneous aggregate =
goodput" with no new 
          &nb=
sp; flows added did not change 
          &nb=
sp; (defined as: moving average =3D "previous" moving =
average +/- 5%),
          &nb=
sp; then the network reached stable =
saturation

That's = better!

---------------------------------------------------------------=
-------------------------------------
 
         =
+  Else, add four more flows
@@@ =
??? and return to start?

Yes, the entire thing is evaluated every 1-second = interval. I will make that explicit.

 
 
Finally, in = 4.1.4, the Note explains:
 
   =
Note: It is tempting to envision an initial base RTT measurement =
and
   adjust the intervals as a function of =
that RTT.  However, experiments
   have shown that this makes the saturation =
detection extremely
   unstable in low RTT =
environments.  In the situation where =
the
   "unloaded" RTT is in the single-digit =
millisecond range, yet the
   =
network's RTT increases under load to more than a hundred
   milliseconds, the intervals become much =
too low to accurately drive
   =
the algorithm.
 
Well, TCP = senders/control-loops are involved here, and likely play a
role in = behavior categorized as =E2=80=9Cdifficult to measure=E2=80=9D.
 
By the time = we get to
 
4.2.  =
Measuring Responsiveness
 
   Once the network is in a consistent =
working conditions, the RPM Test
   =
must "probe" the network multiple times to measure its
   responsiveness.
 
   Each RPM Test probe measures:
 
You = previously started at least four TCP connections with infinitely large = files.
The =E2=80=9Ccr= eate connection=E2=80=9D RPM probes establish additional connections, = DNS, TCP, etc.
Is each new = connection an RPM probe? or is the set of connection tests a single = probe?
(later we = learn it is the set of
What if one of the set of connections = fails/times-out?
 
I take it = that the =E2=80=9Cload-bearing=E2=80=9D connections are driving the path = to saturation.
Maybe = =E2=80=9Cload-generating connections=E2=80=9D is more = clear?

"load-generating" is indeed a better = term!


4.2.1.  =
Aggregating the Measurements
 
   The algorithm produces sets of 5 times =
for each probe, namely: DNS
   =
handshake, TCP handshake, TLS handshake, HTTP/2 request/response =
on
   separate (idle) connections, HTTP/2 =
request/response on load bearing
   =
connections.  This fine-grained data =
is useful, but not necessary for
   =
creating a useful metric.
 
@@@@ =
So, only ONE of the load-generating connections runs the 1-byte GET =
?  (it says connections, and there are at =
least 4) The various handshakes result in 4 RT measurements.
 
But, =
do you mean *5 repeated measurement sets*? Each set =
with:
DNS =
HS, TCP HS, TLS HS, HTTP/2 idle GET, and the potentially much longer GET =
on the 
load generating connections.
 
   To create a single "Responsiveness" =
(e.g., RPM) number, this first
   =
iteration of the algorithm gives an equal weight to each of =
these
   values.  =
That is, it sums the five time values for each probe, and
   divides by the total number of probes to =
compute an average probe
   =
duration.  The reciprocal of this, =
normalized to 60 seconds, gives
   =
the Round-trips Per Minute (RPM).
 
@@@@ =
I=E2=80=99m missing a step, I think:
Are the =E2=80=9Ctime values for =
each probe=E2=80=9D the sum of handshake or response times for
DNS =
HS, TCP HS, TLS HS, HTTP/2 idle GET and load generating connections?
The =
processing doesn=E2=80=99t seem to include this preliminary calculation =
to produce 
=E2=80=9Cfive time values=E2=80=9D.  =
 
 
In Section 5, =E2=80=9Cno new protocol is = defined=E2=80=9D, but
 
   =
The client begins the responsiveness measurement by querying for =
the
   JSON configuration.  =
This supplies the URLs for creating the load
   bearing connections in the upstream and =
downstream direction as well
   =
as the small object for the latency measurements.
 
The client = needs to know how the server response will be organized, down to key: = value, right?
Some client = and server agreements needed...

Yes! With "protocol" we mean nothing new at = HTTP/TCP/... layer. Just standard JSON. I don't know if that qualifies = as a new "protocol" ;-)


Thanks a lot,
Christoph


 
 
From: ippm <ippm-bounces@ietf.org> On Behalf = Of Marcus Ihlar
Sent: Monday, December 6, 2021 = 10:53 AM
To: ippm@ietf.org
Subject: [ippm] Adoption call for = draft-cpaasch-ippm-responsiveness
 
Hi IPPM,
 
This email starts an adoption call = for draft-cpaasch-ippm-responsiveness, "Responsiveness under Working = Conditions=E2=80=9D. This document specifies the =E2=80=9CRPM Test=E2=80=9D= for measuring user experience when the network is fully loaded. The = intended status of the document is Experimental.   
 
https://datatracker.ietf.org/doc/draft-cpaasch-ippm-responsiven= ess/
https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-respon= siveness-01
 
This adoption call will last = until Monday, December 20. Please review the document, and = reply to this email thread to indicate if you think IPPM should adopt = this document.
 
BR,
Marcus 
 
_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm

= --Apple-Mail=_5D6FD931-6B7F-4434-9883-53DA75FDDEA2-- From nobody Tue Jan 4 16:32:21 2022 Return-Path: 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 3BF093A21A6; Tue, 4 Jan 2022 16:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.328 X-Spam-Level: ** X-Spam-Status: No, score=2.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Skz9KrJDyzDH; Tue, 4 Jan 2022 16:32:14 -0800 (PST) Received: from rn-mailsvcp-ppex-lapp45.apple.com (rn-mailsvcp-ppex-lapp45.rno.apple.com [17.179.253.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC8A3A21B7; Tue, 4 Jan 2022 16:32:11 -0800 (PST) Received: from pps.filterd (rn-mailsvcp-ppex-lapp45.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp45.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 2050TcMq011238; Tue, 4 Jan 2022 16:32:06 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=UPlAYS1KN1tCR5gv/LJkve5EigsED0w6mHvwH327CLA=; b=j04jwXkUl1bsVVWa1JAhzPVS7KwTUohxduDXDCF/Fj3EChBYjFUB6n7dIss9FJNDRvR1 +cYJqgtu72RmXmZOGL/795TGaivQgD3+CCz7VecyyD9bwJFp+O16CkyKG7MHoLSdRJ4h v2XARtRgoz0qsl5pUBhxl317a4nvo/l7rMF7kwDQs+PdYQgxiVOkzqeqULsysCV/alrc yNd40W6NglUIkp/Lsi2ogxEQD6e73l3GcE4G0elKINEfObO8+aDIr4c6/iGhbEpwwLrv KeAWCQ1ZEUvIEqCOh5P6HhYofwV4o7QXMPqdVswiy6+JSUHfsWUjoVlicVEkKz+cklLy 0w== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by rn-mailsvcp-ppex-lapp45.rno.apple.com with ESMTP id 3dap4x356b-5 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 04 Jan 2022 16:32:06 -0800 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R5700HITO5GVI50@rn-mailsvcp-mta-lapp02.rno.apple.com>; Tue, 04 Jan 2022 16:32:04 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R5700J00NS4US00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Tue, 04 Jan 2022 16:32:04 -0800 (PST) X-Va-A: X-Va-T-CD: 88be9522c394b0084939bf849bdef634 X-Va-E-CD: de054fff2f5096dfe99f93b89e853049 X-Va-R-CD: 7d741991045d6b2f869f53b80b980cf0 X-Va-CD: 0 X-Va-ID: eb81144f-6ff5-441d-94b0-5faf3c7288d6 X-V-A: X-V-T-CD: 88be9522c394b0084939bf849bdef634 X-V-E-CD: de054fff2f5096dfe99f93b89e853049 X-V-R-CD: 7d741991045d6b2f869f53b80b980cf0 X-V-CD: 0 X-V-ID: 7092fb36-246a-44be-b6f9-6d28a908cb82 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2022-01-04_11:2022-01-04, 2022-01-04 signatures=0 Received: from smtpclient.apple ([17.192.155.238]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R5700CB8O5GRH00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Tue, 04 Jan 2022 16:32:04 -0800 (PST) From: Christoph Paasch Message-id: <4EF94EF0-FD63-4505-B896-099A8B0B36C6@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_4F2BE974-5DE0-41FF-99A7-97E67EEED64C" MIME-version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) Date: Tue, 04 Jan 2022 16:32:03 -0800 In-reply-to: Cc: "MORTON JR., AL" , "ippm@ietf.org" To: Matt Mathis References: X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2022-01-04_11:2022-01-04, 2022-01-04 signatures=0 Archived-At: Subject: Re: [ippm] Adoption call for draft-cpaasch-ippm-responsiveness X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 05 Jan 2022 00:32:19 -0000 --Apple-Mail=_4F2BE974-5DE0-41FF-99A7-97E67EEED64C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Matt, > On Dec 19, 2021, at 7:38 PM, Matt Mathis = wrote: >=20 > I support this draft, and I have even offered to be a co-author. thanks for the support and indeed you will be on the next version of the = draft. > Thank you Al. for the extensive comments. I only have a moment for = some high level responses: >=20 > In some sense this document is opposite of RFC8337. Responsiveness = is about measuring the how well/early the bottleneck signals congestion = to the transport without incurring excessive queueing. This not only = depends on the loop behavior of the bottleneck and the measurement = stream, it also depends on the loop behavior, population and RTT's of = the cross traffic. I do not expect any of the theory to be mature = enough to be able to do any of this as abstractly as IPPM does with most = metrics. At this time I expect a responsiveness metric to require = fingerprinting the hardware, OS and application software, and include a = warning that results may be sensitive to the details of the = implementation. Yes - things can be very implementation-dependent. Different service = deployments can have different ways of generating the "working = conditions". A service with QUIC deployment using BBR may expose = entirely different responsiveness metrics than a TCP-based deployment. I wonder if we can abstract away the definition of "working conditions" = enough so that it becomes independent of the implementation details. = It's gonna be a tradeoff between how much we want different = implementations to measure similar results vs leaving room for = implementations to make their own choices. > WiFi is a poorly modeled half duplex shared broadcast channel, that is = a critical (dominant?) part of the responsiveness for typical Internet = users. Bidirectional traffic matters a lot, but I fear the scope = might be too broad. Agree'd. It complicates things by quite a bit. Christoph >=20 > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay >=20 > We must not tolerate intolerance; > however our response must be carefully measured:=20 > too strong would be hypocritical and risks spiraling out = of control; > too weak risks being mistaken for tacit approval. >=20 >=20 > On Fri, Dec 17, 2021 at 3:51 PM MORTON JR., AL > wrote: > Hi authors and ippm-chairs, >=20 > =20 >=20 > Thanks for writing this-up! >=20 > =20 >=20 > I took one pass through, and have the following comments during = Adoption call for draft-cpaasch-ippm-responsiveness: >=20 > =20 >=20 > TL;DR: >=20 > Many previously undefined terms were used here, and a more direct = description using the term =E2=80=9Csaturation=E2=80=9D seems possible, = IMO. IPPM has used a template for metric drafts, and use of the = hierarchy of singleton, sample, and statistic metrics from RFC 2330 will = help with clarity/answer many of my questions. >=20 > =20 >=20 > regards (I=E2=80=99m off-line for a while now, so enjoy the holidays), >=20 > Al >=20 > =20 >=20 > >=46rom the Abstract: >=20 > =20 >=20 > This document specifies the "RPM Test" for measuring = responsiveness. >=20 > It uses common protocols and mechanisms to measure user experience >=20 > especially when the network is fully loaded ("responsiveness under >=20 > working conditions".) The measurement is expressed as "Round-trips >=20 > Per Minute" (RPM) and should be included with throughput (up and >=20 > down) and idle latency as critical indicators of network quality. >=20 > =20 >=20 > =E2=80=9Cfully loaded=E2=80=9D and =E2=80=9Cworking conditions=E2=80=9D = aren=E2=80=99t necessarily the same, to me. I=E2=80=99ll be looking for = better definitions. >=20 > =20 >=20 > 3 = . Goals > =20 > The algorithm described here defines an RPM Test that serves as a > good proxy for user experience. This means: > =20 > 1. Today's Internet traffic primarily uses HTTP/2 over TLS. Thus, > the algorithm should use that protocol. > =20 > As a side note: other types of traffic are gaining in = popularity > (HTTP/3) and/or are already being used widely = (RTP). > =20 >=20 > There are many measurement stability challenges when TCP is involved, = see section 4 of RFC8337: = https://datatracker.ietf.org/doc/html/rfc8337#section-4 = > RFC8337 intentionally broke the TCP control loop to make measurements = in the face of these challenges. >=20 > =20 >=20 > 4.1 = . Working Conditions > =20 > For the purpose of this methodology, typical "working conditions" > represent a state of the network in which the bottleneck node is > experiencing ingress and egress flows similar to those created by > humans in the typical day-to-day pattern. > =20 > While a single HTTP transaction might briefly put a network into > working conditions, making reliable measurements requires = maintaining > the state over sufficient time. > =20 > The algorithm must also detect when the network is in a persistent > working condition, also called "saturation". > =20 > Desired properties of "working condition": > =20 > o Should not waste traffic, since the person may be paying for it > =20 > o Should finish within a short time to avoid impacting other = people > on the same network, to avoid varying network conditions, and = not > try the person's patience. > =20 >=20 > These seem like reasonable goals for the traffic that loads the = network. >=20 > New terms needing definition were introduced: >=20 > =E2=80=9Cpersistent working condition =3D saturation=E2=80=9D, >=20 > which is different from >=20 > =E2=80=9Cingress and egress flows similar to those created by humans = in the typical day-to-day pattern=E2=80=9D >=20 > =20 >=20 > Later in 4.1.1, terms like =E2=80=9Csaturate a path=E2=80=9D and = =E2=80=9Cfill the pipe=E2=80=9D appear, and >=20 > =20 >=20 > The goal of the RPM Test is to keep the network as busy as possible > in a sustained and persistent way. It uses multiple TCP = connections > and gradually adds more TCP flows until saturation is reached. > =20 >=20 > The terms =E2=80=9Cbusy as possible=E2=80=9D, and =E2=80=9Ctypical = day-to-day pattern=E2=80=9D, or >=20 > =E2=80=9Csaturation=E2=80=9D and =E2=80=9Cworking conditions=E2=80=9D = indicate different load levels to me. >=20 > =20 >=20 > @@@@ Suggestion: I think it would help to simplify the terminology in = this draft. You intend to measure a saturated path, so just say that. No = =E2=80=9Ctypical=E2=80=9D, no =E2=80=9Cworking conditions=E2=80=9D, = etc., in these early sections. >=20 > =20 >=20 > The sentence beginning =E2=80=9CThe goal...=E2=80=9D should really = appear in Section 3. Goals >=20 > =20 >=20 > Also, you have defined a measurement method in the sentence, =E2=80=9CIt= uses...=E2=80=9D above. This method of adding connections has been = observed in other measurement systems, but it isn=E2=80=99t typical of = user traffic, especially when each connection has an ~infinite amount of = data to send during the test. >=20 > =20 >=20 > 4.1.2 = . Parallel vs Sequential Uplink and Downlink > =20 > ... > To measure responsiveness under working conditions, the algorithm > must saturate both directions. > =20 > Bi-directional saturation is really atypical of usage. I don=E2=80=99t = think the benefit of =E2=80=9Cmore data=E2=80=9D pays off. > =20 > ... > =20 > However, a number of caveats come with measuring in parallel: > =20 > o Half-duplex links may not permit simultaneous uplink and = downlink > traffic. This means the test might not saturate both directions > at once. > =20 > o Debuggability of the results becomes harder: During parallel > measurement it is impossible to differentiate whether the = observed > latency happens in the uplink or the downlink direction. > =20 > o Consequently, the test should have an option for sequential > testing. > =20 >=20 > @@@@ Suggestion: IMO, tests/results with Downlink saturation OR Uplink = saturation would be more straightforward, and can be understood by users = (especially those who have tested in the past). Avoid the pitfalls and = make Sequential testing the preferred option. >=20 > =20 >=20 > =20 >=20 > 4.1.3 = . Reaching saturation > =20 > The RPM Test gradually increases the number of TCP connections and > measures "goodput" - the sum of actual data transferred across all > connections in a unit of time. When the goodput stops increasing, = it > means that saturation has been reached. > ... > =20 > Filling buffers at the bottleneck depends on the congestion control > deployed on the sender side. Congestion control algorithms like = BBR > may reach high throughput without causing queueing because the > bandwidth detection portion of BBR effectively seeks the bottleneck > capacity. > =20 > RPM Test clients and servers should use loss-based congestion > controls like Cubic to fill queues reliably. > =20 > With the evolution of Congestion control algorithms seeking to avoid = filling buffers, does it make sense to require a full buffer at the = bottleneck to achieve saturation? > In fact, the definition above, =E2=80=9CWhen the goodput stops = increasing,...=E2=80=9D does not require full buffers; it requires = maximizing a delivery rate measurement instead. > =20 > =20 > In 4.1.4, the final steps of the algorithm were not clear to me: > =20 > * Else, network reached saturation for the current flow count. > @@@@ This wording implies it to be the final step, but there are = further conditions to test. > Maybe this step is =E2=80=9CElse, Candidate for stable = saturation=E2=80=9D? > =20 > + If new flows added and for 4 seconds the moving average > throughput did not change: network reached stable = saturation > @@@@ Maybe:=20 > + If the 4 second moving average of "instantaneous aggregate = goodput" with no new=20 > flows added did not change=20 > (defined as: moving average =3D "previous" moving average = +/- 5%), > then the network reached stable saturation > = --------------------------------------------------------------------------= -------------------------- > =20 > + Else, add four more flows > @@@ ??? and return to start? > =20 >=20 > =20 >=20 > Finally, in 4.1.4, the Note explains: >=20 > =20 >=20 > Note: It is tempting to envision an initial base RTT measurement = and > adjust the intervals as a function of that RTT. However, = experiments > have shown that this makes the saturation detection extremely > unstable in low RTT environments. In the situation where the > "unloaded" RTT is in the single-digit millisecond range, yet the > network's RTT increases under load to more than a hundred > milliseconds, the intervals become much too low to accurately drive > the algorithm. > =20 >=20 > Well, TCP senders/control-loops are involved here, and likely play a >=20 > role in behavior categorized as =E2=80=9Cdifficult to measure=E2=80=9D. >=20 > =20 >=20 > By the time we get to >=20 > =20 > 4.2 = . Measuring Responsiveness > =20 > Once the network is in a consistent working conditions, the RPM = Test > must "probe" the network multiple times to measure its > responsiveness. > =20 > Each RPM Test probe measures: > =20 >=20 > You previously started at least four TCP connections with infinitely = large files. >=20 > The =E2=80=9Ccreate connection=E2=80=9D RPM probes establish = additional connections, DNS, TCP, etc. >=20 > Is each new connection an RPM probe? or is the set of connection tests = a single probe? >=20 > (later we learn it is the set of >=20 > What if one of the set of connections fails/times-out? >=20 > =20 >=20 > I take it that the =E2=80=9Cload-bearing=E2=80=9D connections are = driving the path to saturation. >=20 > Maybe =E2=80=9Cload-generating connections=E2=80=9D is more clear? >=20 > =20 >=20 > 4.2.1 = . Aggregating the Measurements > =20 > The algorithm produces sets of 5 times for each probe, namely: DNS > handshake, TCP handshake, TLS handshake, HTTP/2 request/response on > separate (idle) connections, HTTP/2 request/response on load = bearing > connections. This fine-grained data is useful, but not necessary = for > creating a useful metric. > =20 > @@@@ So, only ONE of the load-generating connections runs the 1-byte = GET ? (it says connections, and there are at least 4) The various = handshakes result in 4 RT measurements. > =20 > But, do you mean *5 repeated measurement sets*? Each set with: > DNS HS, TCP HS, TLS HS, HTTP/2 idle GET, and the potentially much = longer GET on the=20 > load generating connections. > =20 > To create a single "Responsiveness" (e.g., RPM) number, this first > iteration of the algorithm gives an equal weight to each of these > values. That is, it sums the five time values for each probe, and > divides by the total number of probes to compute an average probe > duration. The reciprocal of this, normalized to 60 seconds, gives > the Round-trips Per Minute (RPM). > =20 > @@@@ I=E2=80=99m missing a step, I think: > Are the =E2=80=9Ctime values for each probe=E2=80=9D the sum of = handshake or response times for > DNS HS, TCP HS, TLS HS, HTTP/2 idle GET and load generating = connections? > The processing doesn=E2=80=99t seem to include this preliminary = calculation to produce=20 > =E2=80=9Cfive time values=E2=80=9D. =20 > =20 >=20 > =20 >=20 > In Section 5, =E2=80=9Cno new protocol is defined=E2=80=9D, but >=20 > =20 >=20 > The client begins the responsiveness measurement by querying for = the > JSON configuration. This supplies the URLs for creating the load > bearing connections in the upstream and downstream direction as = well > as the small object for the latency measurements. > =20 >=20 > The client needs to know how the server response will be organized, = down to key: value, right? >=20 > Some client and server agreements needed... >=20 > =20 >=20 > =20 >=20 > From: ippm > On = Behalf Of Marcus Ihlar > Sent: Monday, December 6, 2021 10:53 AM > To: ippm@ietf.org > Subject: [ippm] Adoption call for draft-cpaasch-ippm-responsiveness >=20 > =20 >=20 > Hi IPPM, >=20 > =20 >=20 > This email starts an adoption call for = draft-cpaasch-ippm-responsiveness, "Responsiveness under Working = Conditions=E2=80=9D. This document specifies the =E2=80=9CRPM Test=E2=80=9D= for measuring user experience when the network is fully loaded. The = intended status of the document is Experimental. =20 >=20 > =20 >=20 > https://datatracker.ietf.org/doc/draft-cpaasch-ippm-responsiveness/ = > = https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-responsiveness-01= = > =20 >=20 > This adoption call will last until Monday, December 20. Please review = the document, and reply to this email thread to indicate if you think = IPPM should adopt this document. >=20 > =20 >=20 > BR, >=20 > Marcus >=20 > =20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm = > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm --Apple-Mail=_4F2BE974-5DE0-41FF-99A7-97E67EEED64C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello= Matt,

On Dec 19, 2021, at 7:38 PM, Matt Mathis = <mattmathis=3D40google.com@dmarc.ietf.org> = wrote:

I support this draft, and I have even offered to = be a co-author.

thanks for the support and indeed you will be on = the next version of the draft.

Thank you  Al. for the extensive comments.   I = only have a moment for some high level responses:

In some sense this = document  is opposite of RFC8337.  Responsiveness is = about measuring the how well/early the bottleneck signals = congestion to the transport without incurring excessive = queueing.   This not only depends on the loop behavior of the = bottleneck and the measurement stream, it also depends on the loop = behavior, population and RTT's of the cross traffic.   I do = not expect any of the theory to be mature enough to be able to do any of = this as abstractly as IPPM does with most metrics.   At this = time I expect a responsiveness metric to require fingerprinting the = hardware, OS and application software, and include a warning that = results may be sensitive to the details of the = implementation.

Yes - things can be very implementation-dependent. = Different service deployments can have different ways of generating the = "working conditions". A service with QUIC deployment using BBR may = expose entirely different responsiveness metrics than a TCP-based = deployment.

I wonder if we can = abstract away the definition of "working conditions" enough so that it = becomes independent of the implementation details. It's gonna be a = tradeoff between how much we want different implementations to measure = similar results vs leaving room for implementations to make their own = choices.

WiFi is a poorly modeled half duplex shared broadcast = channel, that is a critical (dominant?) part of the responsiveness for = typical Internet users.     Bidirectional traffic matters = a lot, but I fear the scope might be too = broad.

Agree'd. It complicates things by quite a = bit.


Christoph


Thanks,
--MM--
The best = way to predict the future is to create it.  - Alan Kay

We must not tolerate intolerance;
       however our response = must be carefully measured: 
    =         too strong would be hypocritical and risks = spiraling out of control;
      =       too weak risks being mistaken for tacit = approval.


On Fri, Dec 17, 2021 at 3:51 PM MORTON = JR., AL <acmorton@att.com> wrote:

Hi authors and ippm-chairs,

 

Thanks for writing this-up!

 

I took one pass through, and have the following comments = during Adoption call for draft-cpaasch-ippm-responsiveness:

 

TL;DR:

Many previously undefined terms were used here, and a more = direct description using the term =E2=80=9Csaturation=E2=80=9D seems = possible, IMO. IPPM has used a template for metric drafts, and use of the hierarchy of singleton, sample, and statistic = metrics from RFC 2330 will help with clarity/answer many of my = questions.

 

regards (I=E2=80=99m off-line for a while now, so enjoy the = holidays),

Al

 

>=46rom the Abstract:

 

   This document specifies the "RPM Test" for measuring = responsiveness.

   It uses common protocols and mechanisms to measure user = experience

   especially when the network is fully loaded = ("responsiveness under

   working conditions".)  The measurement is expressed as "Round-trips

   Per Minute" (RPM) and should be included with throughput (up = and

   down) and idle latency as critical indicators of network = quality.

 

=E2=80=9Cfully loaded=E2=80=9D and =E2=80=9Cworking = conditions=E2=80=9D aren=E2=80=99t necessarily the same, to me.  I=E2=80=99ll be looking for better definitions.

 

3.  Goals
 
   The algorithm =
described here defines an RPM Test that serves as a
   good proxy for user =
experience.  This means:
 
   1.  Today's Internet traffic primarily uses HTTP/2 =
over TLS.  Thus,
       =
the algorithm should use that protocol.
 
       =
As a side note: other types of traffic are gaining in =
popularity
       =
(HTTP/3) and/or <???? UDP ???> are =
already being used widely (RTP).

 

There are many measurement stability challenges when TCP is = involved, see section 4 of RFC8337:  https://datatracker.ietf.org/doc/html/rfc8337#section-4

RFC8337 intentionally broke the TCP control loop to make = measurements in the face of these challenges.

 

4.1.  Working Conditions
 
   For the purpose of =
this methodology, typical "working conditions"
   represent a state =
of the network in which the bottleneck node is
   experiencing =
ingress and egress flows similar to those created by
   humans in the =
typical day-to-day pattern.
 
   While a single HTTP =
transaction might briefly put a network into
   working conditions, =
making reliable measurements requires maintaining
   the state over =
sufficient time.
 
   The algorithm must =
also detect when the network is in a persistent
   working condition, =
also called "saturation".
 
   Desired properties =
of "working condition":
 
   o  Should not waste traffic, since the person may =
be paying for it
 
   o  Should finish within a short time to avoid =
impacting other people
      =
on the same network, to avoid varying network conditions, and =
not
      =
try the person's patience.

 

These seem like reasonable goals for the traffic that loads = the network.

New terms needing definition were introduced:

=E2=80=9Cpersistent working condition =3D saturation=E2=80=9D,

which is different from

=E2=80=9Cingress and egress flows similar to those created by = humans in the typical day-to-day pattern=E2=80=9D

 

Later in 4.1.1, terms like =E2=80=9Csaturate a path=E2=80=9D  and =E2=80=9Cfill the pipe=E2=80=9D appear, and

 

   The =
goal of the RPM Test is to keep the network as busy as possible
   in a sustained and =
persistent way.  It uses multiple TCP =
connections
   and gradually adds =
more TCP flows until saturation is reached.

 

The terms =E2=80=9Cbusy as possible=E2=80=9D, and =E2=80=9Ctypi= cal day-to-day pattern=E2=80=9D, or

=E2=80=9Csaturation=E2=80=9D and =E2=80=9Cworking = conditions=E2=80=9D indicate different load levels to me.

 

@@@@ Suggestion: I think it would help to simplify the = terminology in this draft. You intend to measure a saturated path, so = just say that. No =E2=80=9Ctypical=E2=80=9D, no =E2=80=9Cworking conditions=E2=80=9D, etc., in these early sections.

 

The sentence beginning =E2=80=9CThe goal...=E2=80=9D should = really appear in Section 3. Goals

 

Also, you have defined a measurement method in the sentence, = =E2=80=9CIt uses...=E2=80=9D above. This method of adding connections = has been observed in other measurement systems, but it isn=E2=80=99t typical of user traffic, especially when each = connection has an ~infinite amount of data to send during the test.

 

4.1.2.  Parallel vs Sequential Uplink and =
Downlink
 
...
   To measure =
responsiveness under working conditions, the algorithm
   must saturate both =
directions.
 
Bi-directional saturation is really atypical of usage. I =
don=E2=80=99t think the benefit of =E2=80=9Cmore data=E2=80=9D pays =
off.
 
...
 
   However, a number =
of caveats come with measuring in parallel:
 
   o  Half-duplex links may not permit simultaneous =
uplink and downlink
      =
traffic.  This means the test might =
not saturate both directions
      =
at once.
 
   o  Debuggability of the results becomes harder: =
During parallel
      =
measurement it is impossible to differentiate whether the =
observed
      =
latency happens in the uplink or the downlink direction.
 
   o  Consequently, the test should have an option =
for sequential
      =
testing.

 

@@@@ Suggestion: IMO, tests/results with Downlink saturation = OR Uplink saturation would be more straightforward, and can be = understood by users (especially those who have tested in the past). Avoid the pitfalls and make Sequential = testing the preferred option.

 

 

4.1.3.  Reaching saturation
 
   The RPM Test =
gradually increases the number of TCP connections and
   measures "goodput" =
- the sum of actual data transferred across all
   connections in a =
unit of time.  When the goodput stops =
increasing, it
   means that =
saturation has been reached.
...
 
   Filling buffers at =
the bottleneck depends on the congestion control
   deployed on the =
sender side.  Congestion control algorithms =
like BBR
   may reach high =
throughput without causing queueing because the
   bandwidth detection =
portion of BBR effectively seeks the bottleneck
   capacity.
 
   RPM Test clients =
and servers should use loss-based congestion
   controls like Cubic =
to fill queues reliably.
 
With the evolution of Congestion control algorithms =
seeking to avoid filling buffers, does it make sense to require a full =
buffer at the bottleneck to achieve saturation?
In fact, the definition above, =E2=80=9CWhen the goodput =
stops increasing,...=E2=80=9D does not require full buffers; it requires =
maximizing a delivery rate measurement instead.
 
 
In 4.1.4, the final steps of the algorithm were not =
clear to me:
 
      =
*  Else, network reached saturation =
for the current flow count.
@@@@ This wording implies it to be the final step, but =
there are further conditions to test.
     Maybe =
this step is =E2=80=9CElse, Candidate for stable saturation=E2=80=9D?
 
         =
+  If new flows added and for 4 =
seconds the moving average
          &nb=
sp; throughput did not change: network reached stable =
saturation
@@@@ Maybe: 
         +  =
If the 4 second moving average of "instantaneous aggregate =
goodput" with no new 
          &nb=
sp; flows added did not change 
          &nb=
sp; (defined as: moving average =3D "previous" moving =
average +/- 5%),
          &nb=
sp; then the network reached stable saturation
---------------------------------------------------------------=
-------------------------------------
 
         =
+  Else, add four more flows
@@@ ??? and return to start?

 

 

Finally, in 4.1.4, the Note explains:

 

   Note: It is =
tempting to envision an initial base RTT measurement and
   adjust the =
intervals as a function of that RTT.  =
However, experiments
   have shown that =
this makes the saturation detection extremely
   unstable in low RTT =
environments.  In the situation where the
   "unloaded" RTT is =
in the single-digit millisecond range, yet the
   network's RTT =
increases under load to more than a hundred
   milliseconds, the =
intervals become much too low to accurately drive
   the algorithm.

 

Well, TCP senders/control-loops are involved here, and likely = play a

role in behavior categorized as =E2=80=9Cdifficult to = measure=E2=80=9D.

 

By the time we get to 

 
4.2.  Measuring Responsiveness
 
   Once the network is =
in a consistent working conditions, the RPM Test
   must "probe" the =
network multiple times to measure its
   responsiveness.
 
   Each RPM Test probe =
measures:

 

You previously started at least four TCP connections with = infinitely large files.

The =E2=80=9Ccreate connection=E2=80=9D RPM probes establish = additional connections, DNS, TCP, etc.

Is each new = connection an RPM probe? or is the set of connection tests a single = probe?

(later we learn it is the set of

What if one of the set of connections fails/times-out?

 

I take it that the =E2=80=9Cload-bearing=E2=80=9D connections = are driving the path to saturation.

Maybe = =E2=80=9Cload-generating connections=E2=80=9D is more clear?

 

4.2.1.  Aggregating the Measurements
 
   The algorithm =
produces sets of 5 times for each probe, namely: DNS
   handshake, TCP =
handshake, TLS handshake, HTTP/2 request/response on
   separate (idle) =
connections, HTTP/2 request/response on load bearing
   connections.  This fine-grained data is useful, but not =
necessary for
   creating a useful =
metric.
 
@@@@ So, only ONE of the load-generating connections =
runs the 1-byte GET ?  (it says =
connections, and there are at least 4) The various handshakes result in =
4 RT measurements.
 
But, do you mean *5 repeated measurement =
sets*? Each set with:
DNS HS, TCP HS, TLS HS, HTTP/2 idle GET, and the =
potentially much longer GET on the 
load generating connections.
 
   To create a single =
"Responsiveness" (e.g., RPM) number, this first
   iteration of the =
algorithm gives an equal weight to each of these
   values.  That is, it sums the five time values for each =
probe, and
   divides by the =
total number of probes to compute an average probe
   duration.  The reciprocal of this, normalized to 60 =
seconds, gives
   the Round-trips Per =
Minute (RPM).
 
@@@@ I=E2=80=99m missing a step, I think:
Are the =E2=80=9Ctime values for each probe=E2=80=9D the =
sum of handshake or response times for
DNS HS, TCP HS, TLS HS, HTTP/2 idle GET and load =
generating connections?
The processing doesn=E2=80=99t seem to include this =
preliminary calculation to produce 
=E2=80=9Cfive time values=E2=80=9D. =

 

 

In Section 5, =E2=80=9Cno new protocol is defined=E2=80=9D, = but

 

   The client begins =
the responsiveness measurement by querying for the
   JSON =
configuration.  This supplies the URLs for =
creating the load
   bearing connections =
in the upstream and downstream direction as well
   as the small object =
for the latency measurements.

 

The client needs to know how the server response will be = organized, down to key: value, right?

Some client and = server agreements needed...

 

 

From: ippm <ippm-bounces@ietf.org> On Behalf Of Marcus Ihlar
Sent: Monday, December 6, 2021 10:53 AM
To: ippm@ietf.org
Subject: [ippm] Adoption call for = draft-cpaasch-ippm-responsiveness

 

Hi IPPM,

 

This = email starts an adoption call for draft-cpaasch-ippm-responsiveness, = "Responsiveness under Working Conditions=E2=80=9D. This document = specifies the =E2=80=9CRPM Test=E2=80=9D for measuring user experience = when the network is fully loaded. The intended status of the document is = Experimental.   

 

https://datatracker.ietf.org/doc/draft-cpaasch-ippm-responsiven= ess/

https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-respon= siveness-01

 

This adoption call will last until Monday, December 20. Please review the document, and = reply to this email thread to indicate if you think IPPM should adopt = this document.

 

BR,

Marcus

 

_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
_______________________________________________
ippm = mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm

= --Apple-Mail=_4F2BE974-5DE0-41FF-99A7-97E67EEED64C-- From nobody Tue Jan 4 16:55:34 2022 Return-Path: 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 575413A220A; Tue, 4 Jan 2022 16:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.428 X-Spam-Level: ** X-Spam-Status: No, score=2.428 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6yvVm-Izz-2; Tue, 4 Jan 2022 16:55:29 -0800 (PST) Received: from rn-mailsvcp-ppex-lapp14.apple.com (rn-mailsvcp-ppex-lapp14.rno.apple.com [17.179.253.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F6403A220B; Tue, 4 Jan 2022 16:55:26 -0800 (PST) Received: from pps.filterd (rn-mailsvcp-ppex-lapp14.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp14.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 2050tBM7017699; Tue, 4 Jan 2022 16:55:24 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=2SiUY/5rMCFWkYU6qjhQWNszGp4SP6joNRp6N6pEto8=; b=fsjGtOpgwcJmdmPXgN72anpZIxBPX8K0Txmw3RklV4bNvHdCqtrwVK/7VkUOWX1fPHzv fR9jWelRXgZrQ6mDMoL4ZNxqcy1BdDEDErk1nxsejLmrsBvVFyf0WRBNTqbBoAI48ZCz oa5J+ZG1TpJGDIAQ733YWKMNOUD9OJlehwJoay/3QlXOdPxkxXY+rdX19LjKHnyIlj6Z RXQLl4CuaLa/lFAddJIQzKhXNaTpd3q1QOrEMATUZeXbqc4AFvNPcWdan/vOrtYdmLoM APVyYNN38BVdpCClDEVsKNzTBXyr8o0kRdqwEv8bzSZX88zNvVcCwnMpmNfEXL56cWW/ UA== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by rn-mailsvcp-ppex-lapp14.rno.apple.com with ESMTP id 3damqff1b6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 04 Jan 2022 16:55:24 -0800 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R5700Y7HP806E50@rn-mailsvcp-mta-lapp02.rno.apple.com>; Tue, 04 Jan 2022 16:55:12 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R5700E00OWEQ000@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Tue, 04 Jan 2022 16:55:12 -0800 (PST) X-Va-A: X-Va-T-CD: 954b8ddf5120fca5e581bf5dd4991c72 X-Va-E-CD: de054fff2f5096dfe99f93b89e853049 X-Va-R-CD: 7d741991045d6b2f869f53b80b980cf0 X-Va-CD: 0 X-Va-ID: 0801aadf-3b72-456a-a90a-71fd2e126af0 X-V-A: X-V-T-CD: 954b8ddf5120fca5e581bf5dd4991c72 X-V-E-CD: de054fff2f5096dfe99f93b89e853049 X-V-R-CD: 7d741991045d6b2f869f53b80b980cf0 X-V-CD: 0 X-V-ID: da508380-1db2-488f-a1dc-b9bb6891b034 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2022-01-04_11:2022-01-04, 2022-01-04 signatures=0 Received: from smtpclient.apple ([17.192.155.238]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R5700X0KP7Z9J00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Tue, 04 Jan 2022 16:55:11 -0800 (PST) From: Christoph Paasch Message-id: <39395197-5F38-4D1E-8EBA-BAFB09C24CE6@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_3014B326-B698-49CA-800A-8583AC232CA8" MIME-version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) Date: Tue, 04 Jan 2022 16:55:11 -0800 In-reply-to: Cc: "MORTON JR., AL" , Marcus Ihlar , Tommy Pauly , "ippm@ietf.org" To: Christoph Paasch References: X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2022-01-04_11:2022-01-04, 2022-01-04 signatures=0 Archived-At: Subject: Re: [ippm] Adoption call for draft-cpaasch-ippm-responsiveness X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 05 Jan 2022 00:55:33 -0000 --Apple-Mail=_3014B326-B698-49CA-800A-8583AC232CA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 And I just realize I jumped over some parts of your comments. Please see = more inline: > On Jan 4, 2022, at 4:23 PM, Christoph Paasch = wrote: [snip] >> =20 >> =20 >> Finally, in 4.1.4, the Note explains: >> =20 >> Note: It is tempting to envision an initial base RTT measurement = and >> adjust the intervals as a function of that RTT. However, = experiments >> have shown that this makes the saturation detection extremely >> unstable in low RTT environments. In the situation where the >> "unloaded" RTT is in the single-digit millisecond range, yet the >> network's RTT increases under load to more than a hundred >> milliseconds, the intervals become much too low to accurately = drive >> the algorithm. >> =20 >> Well, TCP senders/control-loops are involved here, and likely play a >> role in behavior categorized as =E2=80=9Cdifficult to measure=E2=80=9D.= >> =20 >> By the time we get to >> =20 >> 4.2 = . Measuring Responsiveness >> =20 >> Once the network is in a consistent working conditions, the RPM = Test >> must "probe" the network multiple times to measure its >> responsiveness. >> =20 >> Each RPM Test probe measures: >> =20 >> You previously started at least four TCP connections with infinitely = large files. >> The =E2=80=9Ccreate connection=E2=80=9D RPM probes establish = additional connections, DNS, TCP, etc. >> Is each new connection an RPM probe? or is the set of connection = tests a single probe? >> (later we learn it is the set of >> What if one of the set of connections fails/times-out? Yes, the set will be factored into the final RPM number. >> =20 >> I take it that the =E2=80=9Cload-bearing=E2=80=9D connections are = driving the path to saturation. >> Maybe =E2=80=9Cload-generating connections=E2=80=9D is more clear? >=20 > "load-generating" is indeed a better term! >=20 > For all of the above "minor" edits, I filed = https://github.com/network-quality/draft-cpaasch-ippm-responsiveness/issue= s/35 = =20 >=20 >> 4.2.1 = . Aggregating the Measurements >> =20 >> The algorithm produces sets of 5 times for each probe, namely: DNS >> handshake, TCP handshake, TLS handshake, HTTP/2 request/response = on >> separate (idle) connections, HTTP/2 request/response on load = bearing >> connections. This fine-grained data is useful, but not necessary = for >> creating a useful metric. >> =20 >> @@@@ So, only ONE of the load-generating connections runs the 1-byte = GET ? (it says connections, and there are at least 4) The various = handshakes result in 4 RT measurements. >> =20 >> But, do you mean *5 repeated measurement sets*? Each set with: >> DNS HS, TCP HS, TLS HS, HTTP/2 idle GET, and the potentially much = longer GET on the=20 >> load generating connections. You are right, this is not very clear. I am working on testing a = refinement of the methodology and how the numbers are aggregated. I'm thinking of the following: Each of the RPM-measuring separate connections should get latency = numbers for DNS, TCP, TLS and H2 req/response. Additionally, we have the = measurement on the load-generating connections (one probe on each of = these). This gives us 5 sets of numbers: DNS: [42ms, 39ms, 43ms, ...] -> 75th percentile =3D V TCP: [..., ..., ...] -> 75th percentile =3D W TLS: [... ,..., ...] -> ... =3D X H2: [..., ..., ...] -> ... =3D Y H2 on load-generating: [..., ..., ...] -> ... =3D Z Then, RPM is the average (normalized to 60 seconds) of these values. The tricky part is to choose 75th percentile or 90th percentile,... as = well as how many probes are needed. Does this make it clearer on how the probes are measured and create the = RPM-value ? Christoph >> To create a single "Responsiveness" (e.g., RPM) number, this first >> iteration of the algorithm gives an equal weight to each of these >> values. That is, it sums the five time values for each probe, and >> divides by the total number of probes to compute an average probe >> duration. The reciprocal of this, normalized to 60 seconds, gives >> the Round-trips Per Minute (RPM). >> =20 >> @@@@ I=E2=80=99m missing a step, I think: >> Are the =E2=80=9Ctime values for each probe=E2=80=9D the sum of = handshake or response times for >> DNS HS, TCP HS, TLS HS, HTTP/2 idle GET and load generating = connections? >> The processing doesn=E2=80=99t seem to include this preliminary = calculation to produce=20 >> =E2=80=9Cfive time values=E2=80=9D. =20 >> =20 >> =20 >> In Section 5, =E2=80=9Cno new protocol is defined=E2=80=9D, but >> =20 >> The client begins the responsiveness measurement by querying for = the >> JSON configuration. This supplies the URLs for creating the load >> bearing connections in the upstream and downstream direction as = well >> as the small object for the latency measurements. >> =20 >> The client needs to know how the server response will be organized, = down to key: value, right? >> Some client and server agreements needed... >=20 > Yes! With "protocol" we mean nothing new at HTTP/TCP/... layer. Just = standard JSON. I don't know if that qualifies as a new "protocol" ;-) >=20 >=20 > Thanks a lot, > Christoph >=20 >=20 >> =20 >> =20 >> From: ippm > On = Behalf Of Marcus Ihlar >> Sent: Monday, December 6, 2021 10:53 AM >> To: ippm@ietf.org >> Subject: [ippm] Adoption call for draft-cpaasch-ippm-responsiveness >> =20 >> Hi IPPM, >> =20 >> This email starts an adoption call for = draft-cpaasch-ippm-responsiveness, "Responsiveness under Working = Conditions=E2=80=9D. This document specifies the =E2=80=9CRPM Test=E2=80=9D= for measuring user experience when the network is fully loaded. The = intended status of the document is Experimental. =20 >> =20 >> https://datatracker.ietf.org/doc/draft-cpaasch-ippm-responsiveness/ = >> = https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-responsiveness-01= = >> =20 >> This adoption call will last until Monday, December 20. Please review = the document, and reply to this email thread to indicate if you think = IPPM should adopt this document. >> =20 >> BR, >> Marcus=20 >> =20 >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm = > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm --Apple-Mail=_3014B326-B698-49CA-800A-8583AC232CA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 And = I just realize I jumped over some parts of your comments. Please see = more inline:

On Jan 4, 2022, at 4:23 PM, Christoph Paasch = <cpaasch=3D40apple.com@dmarc.ietf.org> = wrote:

[snip]

 
 
Finally, in = 4.1.4, the Note explains:
 
   =
Note: It is tempting to envision an initial base RTT measurement =
and
   adjust the intervals as a function of =
that RTT.  However, experiments
   have shown that this makes the saturation =
detection extremely
   unstable in low RTT =
environments.  In the situation where =
the
   "unloaded" RTT is in the single-digit =
millisecond range, yet the
   =
network's RTT increases under load to more than a hundred
   milliseconds, the intervals become much =
too low to accurately drive
   =
the algorithm.
 
Well, TCP = senders/control-loops are involved here, and likely play a
role in = behavior categorized as =E2=80=9Cdifficult to measure=E2=80=9D.
 
By the time = we get to
 
4.2.  =
Measuring Responsiveness
 
   Once the network is in a consistent =
working conditions, the RPM Test
   =
must "probe" the network multiple times to measure its
   responsiveness.
 
   Each RPM Test probe measures:
 
You = previously started at least four TCP connections with infinitely large = files.
The =E2=80=9Ccr= eate connection=E2=80=9D RPM probes establish additional connections, = DNS, TCP, etc.
Is each new = connection an RPM probe? or is the set of connection tests a single = probe?
(later we = learn it is the set of
What if one of the set of connections = fails/times-out?

Yes, the set will be factored = into the final RPM number.

 
I take it = that the =E2=80=9Cload-bearing=E2=80=9D connections are driving the path = to saturation.
Maybe = =E2=80=9Cload-generating connections=E2=80=9D is more = clear?

"load-generating" is indeed a better = term!

For all = of the above "minor" edits, I filed https://github.com/network-quality/draft-cpaasch-ippm-responsiv= eness/issues/35 

4.2.1.  =
Aggregating the Measurements
 
   The algorithm produces sets of 5 times =
for each probe, namely: DNS
   =
handshake, TCP handshake, TLS handshake, HTTP/2 request/response =
on
   separate (idle) connections, HTTP/2 =
request/response on load bearing
   =
connections.  This fine-grained data =
is useful, but not necessary for
   =
creating a useful metric.
 
@@@@ =
So, only ONE of the load-generating connections runs the 1-byte GET =
?  (it says connections, and there are at =
least 4) The various handshakes result in 4 RT measurements.
 
But, =
do you mean *5 repeated measurement sets*? Each set =
with:
DNS =
HS, TCP HS, TLS HS, HTTP/2 idle GET, and the potentially much longer GET =
on the 
load generating =
connections.
=

You are right, this is not very clear. I = am working on testing a refinement of the methodology and how the = numbers are aggregated.

I'm thinking = of the following:

Each of the = RPM-measuring separate connections should get latency numbers for DNS, = TCP, TLS and H2 req/response. Additionally, we have the measurement on = the load-generating connections (one probe on each of = these).

This gives us 5 sets of = numbers:
DNS: [42ms, 39ms, 43ms, ...] -> 75th percentile =3D = V
TCP: [..., ..., ...] -> 75th percentile =3D = W
TLS: [... ,..., ...] -> ... =3D X
H2: [..., = ..., ...] ->  ... =3D Y
H2 on load-generating: [..., = ..., ...] -> ... =3D Z

Then, RPM = is the average (normalized to 60 seconds) of these values.

The tricky part is to choose 75th percentile or = 90th percentile,... as well as how many probes are needed.


Does this make it = clearer on how the probes are measured and create the RPM-value = ?


Christoph

   To create a single "Responsiveness" =
(e.g., RPM) number, this first
   =
iteration of the algorithm gives an equal weight to each of =
these
   values.  =
That is, it sums the five time values for each probe, and
   divides by the total number of probes to =
compute an average probe
   =
duration.  The reciprocal of this, =
normalized to 60 seconds, gives
   =
the Round-trips Per Minute (RPM).
 
@@@@ =
I=E2=80=99m missing a step, I think:
Are the =E2=80=9Ctime values for =
each probe=E2=80=9D the sum of handshake or response times for
DNS =
HS, TCP HS, TLS HS, HTTP/2 idle GET and load generating connections?
The =
processing doesn=E2=80=99t seem to include this preliminary calculation =
to produce 
=E2=80=9Cfive time values=E2=80=9D.  =
 
 
In Section 5, =E2=80=9Cno new protocol is = defined=E2=80=9D, but
 
   =
The client begins the responsiveness measurement by querying for =
the
   JSON configuration.  =
This supplies the URLs for creating the load
   bearing connections in the upstream and =
downstream direction as well
   =
as the small object for the latency measurements.
 
The client = needs to know how the server response will be organized, down to key: = value, right?
Some client = and server agreements needed...

Yes! With "protocol" we = mean nothing new at HTTP/TCP/... layer. Just standard JSON. I don't know = if that qualifies as a new "protocol" ;-)


Thanks a lot,
Christoph


 
 
From: ippm <ippm-bounces@ietf.org> On Behalf = Of Marcus Ihlar
Sent: Monday, December 6, 2021 = 10:53 AM
To: ippm@ietf.org
Subject: [ippm] Adoption call for = draft-cpaasch-ippm-responsiveness
 
Hi IPPM,
 
This email starts an adoption call = for draft-cpaasch-ippm-responsiveness, "Responsiveness under Working = Conditions=E2=80=9D. This document specifies the =E2=80=9CRPM Test=E2=80=9D= for measuring user experience when the network is fully loaded. The = intended status of the document is Experimental.   
 
https://datatracker.ietf.org/doc/draft-cpaasch-ippm-responsiven= ess/
https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-respon= siveness-01
 
This adoption call will last = until Monday, December 20. Please review the document, and = reply to this email thread to indicate if you think IPPM should adopt = this document.
 
BR,
Marcus 
 
_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm

_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm

= --Apple-Mail=_3014B326-B698-49CA-800A-8583AC232CA8-- From nobody Wed Jan 5 10:52:21 2022 Return-Path: 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 3610B3A0BFF for ; Wed, 5 Jan 2022 10:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.672 X-Spam-Level: X-Spam-Status: No, score=-2.672 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BtSiidiZW8p for ; Wed, 5 Jan 2022 10:52:17 -0800 (PST) Received: from rn-mailsvcp-ppex-lapp44.apple.com (rn-mailsvcp-ppex-lapp44.rno.apple.com [17.179.253.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BE5E3A0BFC for ; Wed, 5 Jan 2022 10:52:17 -0800 (PST) Received: from pps.filterd (rn-mailsvcp-ppex-lapp44.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp44.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 205IosO0012504; Wed, 5 Jan 2022 10:52:14 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=wNkz2MtFzB0uWTytP7KuVEsW1F58j201zwzZCK/kXg4=; b=bNwzNmQaH7Fu3pRL4UHcCnht7oyMKTqAdrrjGctsHOI1/ugJsB7GRleM/8pmwwQxbKmp bPyxGWEQBu2do0K4C8mIcjP7rCzBB/gobWPcTf/x1Av+fx4Lv18SQuAe7do0iBgRfz/c 1lvGlaZTN6Qr/z+DCpT1fq/JStp4Po1K+my4rIbq5Zrtwq3RgpTSRfSebW18Q2PhE4PM dHGZWNjvyxbwFvCWy6jqONx0xiJpADZleRp83DN2XWnmi8gMrozc/Jslfsb0if+tRQx3 qJEhFNj7D/AUdJwYQ6zpMGkzbV4hCGhXOwqf83NV/x0ZfevYo6IIhQD7rB6Ar3bL6m2S Ow== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by rn-mailsvcp-ppex-lapp44.rno.apple.com with ESMTP id 3dakbdf6va-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 05 Jan 2022 10:52:14 -0800 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R59007IL332GI50@rn-mailsvcp-mta-lapp03.rno.apple.com>; Wed, 05 Jan 2022 10:52:14 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R5900T002WKE200@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 05 Jan 2022 10:52:14 -0800 (PST) X-Va-A: X-Va-T-CD: 1b7e4f4dab179820cbb0a121fe2fe7dc X-Va-E-CD: de054fff2f5096dfe99f93b89e853049 X-Va-R-CD: 7d741991045d6b2f869f53b80b980cf0 X-Va-CD: 0 X-Va-ID: 0b780c99-be64-4ba9-b525-f99bc6e4bc0c X-V-A: X-V-T-CD: 1b7e4f4dab179820cbb0a121fe2fe7dc X-V-E-CD: de054fff2f5096dfe99f93b89e853049 X-V-R-CD: 7d741991045d6b2f869f53b80b980cf0 X-V-CD: 0 X-V-ID: 28ecdd34-b29e-4f83-95b6-1b05197a3915 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2022-01-05_05:2022-01-04, 2022-01-05 signatures=0 Received: from smtpclient.apple ([17.192.155.238]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R5900ECG331DR00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 05 Jan 2022 10:52:13 -0800 (PST) From: Christoph Paasch Message-id: <3DC3F6B6-229E-46C6-BD84-2A6A7FE6DD48@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_F3A9A01C-D3F4-4247-A3DB-E65669D54055" MIME-version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) Date: Wed, 05 Jan 2022 10:52:13 -0800 In-reply-to: Cc: Marcus Ihlar , IETF IPPM WG To: Greg Mirsky References: X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2022-01-05_05:2022-01-04, 2022-01-05 signatures=0 Archived-At: Subject: Re: [ippm] Adoption call for draft-cpaasch-ippm-responsiveness X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 05 Jan 2022 18:52:20 -0000 --Apple-Mail=_F3A9A01C-D3F4-4247-A3DB-E65669D54055 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Greg, thanks for your comments. Please see inline: > On Dec 22, 2021, at 11:43 PM, Greg Mirsky = wrote: >=20 > Dear Marcus, Authors, et al, > apologies for the belated response. > I've read the draft and have some comments to share with you: > as I understand it, the proposed new responsiveness metric is viewed = as the single indicator of a bufferbloat condition in a network. As I = recall, the discussion at Measuring Network Quality for End-Users = workshop and on the mailing list = indicated, that there=E2=80=99s = no consensus on what behaviors, symptoms can reliably signal the = bufferbloat. We are not trying for this responsiveness metric to be "the single = indicator of bufferbloat". Bufferbloat can be measured in many different = number of ways. And each of these will produce a correct, but a = different result. Thus, "bufferbloat" is whatever the methodology tries = to detect. Let me give an example of two methodologies that are both correct but = both will produce entirely different numbers : If we would decide to generate the load by flooding the network with UDP = traffic from a specific 4-tuple and measure latency with parallel ICMP = pings. Then, on a over-buffered FIFO queue we would measure huge = latencies (thus correctly expose bufferbloat), while on a FQ-codel queue = we would not measure any bufferbloat. If on the other hand, the load-generating traffic is changing the = source-port for every single UDP-packet, then in both the FIFO-queue and = the FQ-codel queue we will measure huge amounts of bufferbloat. Thus, these two methods both produced correct results but with hugely = different numbers in the FQ-codel case. [1] Now, while both methods measure some variant of bufferbloat, they both = don't measure a realistic usage of the network. That is why the "Responsiveness under working conditions" tries to = clearly specify how the load is generated and how the latency is being = measured. And it does not measure "bufferbloat" but it measures = "responsiveness under working conditions" based on the methodology that = is being used (using HTTP/2 or HTTP/3, multiple flows, ...). It does = expose bufferbloat which can happen in the network. It also exposes = certain server-side behaviors that can cause (huge amounts of) = additional latency - those behaviors are typically not called = "bufferbloat". > It seems that it would be reasonable to first define what is being = measured, characterized by the responsiveness metric. Having a document = that discusses and defines the bufferbloat would be great. I agree that there is a lack of definition for what "bufferbloat" really = is. The way we look at "responsiveness under working conditions" is that it = measures the latency in conditions that may realistically happen in = worst-case scenarios with end-users/implementations that are = non-malicious (non-malicious to exclude the UDP-flooding scenario). Thus, I assume we should make a better job at explaining this. The lack = of a formal definition of "bufferbloat" doesn't help and thus we are = indeed using this term a bit freely in the current draft. We will = improve the Introduction to better set the stage = (https://github.com/network-quality/draft-cpaasch-ippm-responsiveness/issu= es/31 = ). > It seems like in the foundation of the methodology described in the = draft lies the assumption that without adding new flows the available = bandwidth is constant, does not change. While that is mostly the case, = there are technologies that behave differently and may change bandwidth = because of the outside conditions. Some of these behaviors of links with = variable discrete bandwidth are discussed in, for example, RFC 8330 = and RFC 8625 = . I'm not sure I entirely understand your comment. But let me explain why = we are gradually adding new flows: 1. TCP-implementations have usually a fixed limit for the upper bound of = the receive window. In some networks that upper bound is lower than the = BDP of the network. Thus, the only way to reach full capacity is by = having multiple flows. 2. Having multiple connections allows to quicker achieve full capacity = in high-RTT networks and thus speeds up the test-duration. 3. In some networks with "random" packet-loss, congestion-control may = come in the way of achieving full capacity. Again, multiple flows will = work around that. > Then, I find the motivation not to use time units to express the = responsiveness metric not convincing: > "Latency" is a poor measure of responsiveness, since it can be hard > for the general public to understand. The units are unfamiliar > ("what is a millisecond?") and counterintuitive ("100 msec - that > sounds good - it's only a tenth of a second!"). Can you expand on what exactly is not convincing to you? Do you think = that people will mis-understand the metric or that milli-seconds is the = right way to communicate responsiveness to the general public? Thanks a lot, Christoph [1] And there are many networks that prioritize ICMP pings, thus we = could observe even more different results based on what protocol is used = to measure the latency. >=20 > On Mon, Dec 6, 2021 at 7:53 AM Marcus Ihlar = > wrote: > Hi IPPM, >=20 > =20 >=20 > This email starts an adoption call for = draft-cpaasch-ippm-responsiveness, "Responsiveness under Working = Conditions=E2=80=9D. This document specifies the =E2=80=9CRPM Test=E2=80=9D= for measuring user experience when the network is fully loaded. The = intended status of the document is Experimental. =20 >=20 > =20 >=20 > https://datatracker.ietf.org/doc/draft-cpaasch-ippm-responsiveness/ = > = https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-responsiveness-01= = > =20 >=20 > This adoption call will last until Monday, December 20. Please review = the document, and reply to this email thread to indicate if you think = IPPM should adopt this document. >=20 > =20 >=20 > BR, >=20 > Marcus >=20 > =20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm = > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm --Apple-Mail=_F3A9A01C-D3F4-4247-A3DB-E65669D54055 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello= Greg,

thanks for = your comments. Please see inline:

On Dec = 22, 2021, at 11:43 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:

Dear Marcus, Authors, et al,
apologies for the belated response.
I've = read the draft and have some comments to share with you:
  • as I understand it, the = proposed new responsiveness metric is viewed as the single indicator of = a bufferbloat condition in a network. As I recall, the discussion = at Measuring Network Quality for End-Users workshop and on the mailing list indicated, that = there=E2=80=99s no consensus on what behaviors, symptoms can reliably = signal the bufferbloat. =
We are = not trying for this responsiveness metric to be "the single indicator of = bufferbloat". Bufferbloat can be measured in many different number of = ways. And each of these will produce a correct, but a different result. = Thus, "bufferbloat" is whatever the methodology tries to = detect.

Let me give an example of = two methodologies that are both correct but both will produce entirely = different numbers :

If we would = decide to generate the load by flooding the network with UDP traffic = from a specific 4-tuple and measure latency with parallel ICMP pings. = Then, on a over-buffered FIFO queue we would measure huge latencies = (thus correctly expose bufferbloat), while on a FQ-codel queue we would = not measure any bufferbloat.

If on = the other hand, the load-generating traffic is changing the source-port = for every single UDP-packet, then in both the FIFO-queue and the = FQ-codel queue we will measure huge amounts of = bufferbloat.

Thus, these two methods = both produced correct results but with hugely different numbers in the = FQ-codel case. [1]

Now, while both = methods measure some variant of bufferbloat, they both don't measure a = realistic usage of the network.


That is why the "Responsiveness under working = conditions" tries to clearly specify how the load is generated and how = the latency is being measured. And it does not measure "bufferbloat" but = it measures "responsiveness under working conditions" based on the = methodology that is being used (using HTTP/2 or HTTP/3, multiple flows, = ...). It does expose bufferbloat which can happen in the network. It = also exposes certain server-side behaviors that can cause (huge amounts = of) additional latency - those behaviors are typically not called = "bufferbloat".

    • It seems that = it would be reasonable to first define what is being measured, = characterized by the responsiveness metric. Having a document that = discusses and defines the bufferbloat would be = great.
    I = agree that there is a lack of definition for what "bufferbloat" really = is.

    The way we look at = "responsiveness under working conditions" is that it measures the = latency in conditions that may realistically happen in worst-case = scenarios with end-users/implementations that are non-malicious = (non-malicious to exclude the UDP-flooding scenario).

    Thus, I assume we should make a better job at = explaining this. The lack of a formal definition of "bufferbloat" = doesn't help and thus we are indeed using this term a bit freely in the = current draft. We will improve the Introduction to better set the stage = (https://github.com/network-quality/draft-cpaasch-ippm-responsiv= eness/issues/31).

    • It seems like = in the foundation of the methodology described in the draft lies the = assumption that without adding new flows the = available bandwidth is constant, does not change. While that = is mostly the case, there are technologies that behave differently and = may change bandwidth because of the outside conditions. Some of these = behaviors of links with variable discrete bandwidth are discussed = in, for example, RFC 8330 and RFC = 8625.
    I= 'm not sure I entirely understand your comment. But let me explain why = we are gradually adding new flows:

    1. = TCP-implementations have usually a fixed limit for the upper bound of = the receive window. In some networks that upper bound is lower than the = BDP of the network. Thus, the only way to reach full capacity is by = having multiple flows.
    2. Having multiple connections allows = to quicker achieve full capacity in high-RTT networks and thus speeds up = the test-duration.
    3. In some networks with "random" = packet-loss, congestion-control may come in the way of achieving full = capacity. Again, multiple flows will work around that.
    • Then, I find = the motivation not to use time units to express the responsiveness = metric not convincing:
       "Latency" is a poor measure of = responsiveness, since it can be hard
       for the general public to = understand.  The units are unfamiliar
       ("what is a = millisecond?") and counterintuitive ("100 msec - = that
       sounds good - it's only a tenth of a = second!").

    Can you expand on what exactly is not = convincing to you? Do you think that people will mis-understand the = metric or that milli-seconds is the right way to communicate = responsiveness to the general public?


    Thanks a = lot,
    Christoph

    [1] And = there are many networks that prioritize ICMP pings, thus we could = observe even more different results based on what protocol is used to = measure the latency.


    On Mon, Dec 6, 2021 at 7:53 AM Marcus Ihlar = <marcus.ihlar=3D40ericsson.com@dmarc.ietf.org> wrote:

    Hi IPPM,

     

    This = email starts an adoption call for draft-cpaasch-ippm-responsiveness, = "Responsiveness under Working Conditions=E2=80=9D. This document = specifies the =E2=80=9CRPM Test=E2=80=9D for measuring user experience = when the network is fully loaded. The intended status of the document is = Experimental.   

     

    https://datatracker.ietf.org/doc/draft-cpaasch-ippm-responsiven= ess/

    https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-respon= siveness-01

     

    This adoption call will last until Monday, December 20. Please review the document, and = reply to this email thread to indicate if you think IPPM should adopt = this document.

     

    BR,

    Marcus

     

    _______________________________________________
    ippm mailing list
    ippm@ietf.org
    https://www.ietf.org/mailman/listinfo/ippm
    _______________________________________________
    ippm = mailing list
    ippm@ietf.org
    https://www.ietf.org/mailman/listinfo/ippm

    = --Apple-Mail=_F3A9A01C-D3F4-4247-A3DB-E65669D54055-- From nobody Thu Jan 6 13:47:42 2022 Return-Path: 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 0E9AB3A1708 for ; Thu, 6 Jan 2022 13:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.673 X-Spam-Level: X-Spam-Status: No, score=-2.673 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCoc93auiSYh for ; Thu, 6 Jan 2022 13:47:36 -0800 (PST) Received: from rn-mailsvcp-ppex-lapp35.apple.com (rn-mailsvcp-ppex-lapp35.rno.apple.com [17.179.253.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 932A73A1706 for ; Thu, 6 Jan 2022 13:47:36 -0800 (PST) Received: from pps.filterd (rn-mailsvcp-ppex-lapp35.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp35.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 206LkH4c018661; Thu, 6 Jan 2022 13:47:31 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=xiqhGKnQxqm3UrC1OSncLDEZ5f6e3RE6ET7+8HLhqOg=; b=PsHKBsC1OSvVkple08RbYVPfalhdFh4bLBzYpsSgHAzUBi1bch5pqWEnu8u7RcFnFGb2 x+4yFwg2OhiWTMWUUGC29odsUXCyf1yaL6YSJQyBJrKmOO9J6/4KJIQd8mvibFPCrDNd e7dSi/q6CXze3YcQ86/asRwm0cg9D03ALX7y7IQUhRbfm6hu2QdoOMUglmNLaDSbY9Lu toBDM4ihoBtM3GTbydnpuF7hxRN3oMda7dunyK9XJwvKQQFuvei93v6GvoOuqhPr6uid pCiKRftcbsRjJnWTV46TTJjmbNlg9aQONSgQ26/2PXb6ny3ejuOCn1uZSDYPl6rria/o 1w== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by rn-mailsvcp-ppex-lapp35.rno.apple.com with ESMTP id 3de4y3tkak-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 06 Jan 2022 13:47:31 -0800 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R5B00RII5V6VT30@rn-mailsvcp-mta-lapp04.rno.apple.com>; Thu, 06 Jan 2022 13:47:30 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R5B00U005T4E500@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Thu, 06 Jan 2022 13:47:30 -0800 (PST) X-Va-A: X-Va-T-CD: dce2a0c403c3317da9d5e121f70305f4 X-Va-E-CD: de054fff2f5096dfe99f93b89e853049 X-Va-R-CD: 7d741991045d6b2f869f53b80b980cf0 X-Va-CD: 0 X-Va-ID: e0be11d6-832d-41ed-b1a9-50c381f73077 X-V-A: X-V-T-CD: dce2a0c403c3317da9d5e121f70305f4 X-V-E-CD: de054fff2f5096dfe99f93b89e853049 X-V-R-CD: 7d741991045d6b2f869f53b80b980cf0 X-V-CD: 0 X-V-ID: d07ba130-30c3-4f3b-bf5e-85f8ee7c82ec X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2022-01-06_09:2022-01-05, 2022-01-06 signatures=0 Received: from smtpclient.apple ([17.192.155.238]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R5B00V165V6H900@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Thu, 06 Jan 2022 13:47:30 -0800 (PST) Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) From: Christoph Paasch In-reply-to: Date: Thu, 06 Jan 2022 13:47:29 -0800 Cc: marcus.ihlar@ericsson.com, ippm@ietf.org Content-transfer-encoding: quoted-printable Message-id: <7874DB5E-8408-413A-8DBA-F78A1D6284B7@apple.com> References: To: Ruediger.Geib@telekom.de X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2022-01-06_09:2022-01-05, 2022-01-06 signatures=0 Archived-At: Subject: Re: [ippm] Adoption call for draft-cpaasch-ippm-responsiveness X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2022 21:47:41 -0000 Hello Ruediger, thanks for your feedback! Please see inline: > On Dec 22, 2021, at 11:16 PM, Ruediger.Geib@telekom.de wrote: >=20 > Hi Marcus, >=20 > Noting that some more work needs to be added, I support adoption. >=20 > Some comments: > - I'd appreciate if the draft was covering expectable operational = scenarios, namely > * There may be no bottleneck buffer - the test/metric needs to detect = that and act appropriate. I'm not sure what you mean ? Every flow is limited by some bottleneck = that sits somewhere. Sometimes, it's the last mile, sometimes it's the = Wi-Fi connectivity, sometimes flows become CPU-limited. But there always = is a bottleneck somewhere that is limiting things at which point a = buffer is building up (even though that "buffer" may be just 1 packet = large) > * One might be interested in the metric while the test adds an = insignificant load only. While receiver tries to consume service X, = what's the metric seen from Y?=20 > (may help to clarify, whether the access causes trouble or another = network section). That would indeed be interesting for trouble-shooting and debugging. I = believe this is out-of-scope though. > - Measuring the maximum RPM as seen from the test server is part of = the test or it isn't? That's not clear to me by now. > I'm favouring to make measuring the maximum RPM part of the test, = this may help to scale results. The methodology defines to only measure from the client as we are = interested in responsiveness as a metric that is (as close as possible) = representative of an end-user experience. When you say "maximum RPM", do you mean that on an "idle" network? > - The test set-up should prevent application as DoS attack tool. The json-fetch at the beginning of the test allows server-side CDN = deployments to "rate-limit" clients by simply delaying the response to = the json-fetch. What else do you have in mind regarding a DoS attack tool? Thanks, Christoph > Regards, >=20 > Ruediger >=20 >=20 > From: Marcus Ihlar > Subject: [ippm] Adoption call for draft-cpaasch-ippm-responsiveness > Date: December 6, 2021 at 7:52:58 AM PST > To: "ippm@ietf.org" = > > List-Id: IETF IP Performance Metrics Working Group=20 >=20 > Hi IPPM, >=20 > This email starts an adoption call for = draft-cpaasch-ippm-responsiveness, "Responsiveness under Working = Conditions". This document specifies the "RPM Test" for measuring user = experience when the network is fully loaded. The intended status of the = document is Experimental. >=20 > https://datatracker.ietf.org/doc/draft-cpaasch-ippm-responsiveness/ >=20 > = https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-responsiveness-01= >=20 > This adoption call will last until Monday, December 20. Please review = the document, and reply to this email thread to indicate if you think = IPPM should adopt this document. >=20 > BR, > Marcus >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From nobody Thu Jan 6 15:00:27 2022 Return-Path: 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 7DCD03A089F for ; Thu, 6 Jan 2022 15:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPeVSsSLOfBW for ; Thu, 6 Jan 2022 15:00:21 -0800 (PST) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBA643A087D for ; Thu, 6 Jan 2022 15:00:20 -0800 (PST) Received: by mail-ed1-x530.google.com with SMTP id z9so15135833edm.10 for ; Thu, 06 Jan 2022 15:00:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HyFHTeMHlsP1WYKPW1vodcoI18kcGyZ1XNliIhiYrz4=; b=YYgSP2ByKrgM5oiFY9vYQ9nEybQK6a5HkPBK2pBbsbTNPKoSoU7jp8mpOonL2XIk5+ aqj1x+6QpgNXvGw8ppDrKEAgiA+A/vOVceuHH/AYU5VW8EGRODZ8/FzTWGymVMUOJc1W XpUV6d2LEMj2jG1br+uE84noq73eHiKlRzeo7iCbYnBHuAAlxQY0DWfgqoFI/QtNDJUr pkhd9PVaRpem2cmBn61IXWUoapG0RoZ41SI4aDgwKEMAZ6Xdzd24oa2J0vUlH6v/CiTq b29ySV7yHb6jog9jmsq9KEiEAHua6iiO8QCaZDuvQsmCvkRsZWRp86siiHRYWoa4uCDZ 2XzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HyFHTeMHlsP1WYKPW1vodcoI18kcGyZ1XNliIhiYrz4=; b=IXtDPH1KcM1CdngTCATL2f+Ue/ugP6GD4eTSUSmzYUJgIsNRr892ySTK7m0y72QiVv K+b9h9P7PMVUDut1RGRsZKggnS0er/k2sWzHDO/BUzhKBsEZItxlGoi8veSJQoecUNri RUnryHZkn9sn32dPuBCF3Xj460rtUlpeNS7cj+CkbE9Yz7KTIhLb7qWHe1JzZ5J8ORuz cmV5NqdzzSszgDoe728sYbJKAwBR5mINV1B2ft8S2cPxI1aNqVv3sFB9E14wvtcemZnr OdZaaNSF3b0fowy2shlWD/izqmNYGsQDJAnfdSOu8BPdpQv15rI6NiBZtVEaxHCEtLLS NPfA== X-Gm-Message-State: AOAM533s9ZHcUyoXNoYxg75Rwnf7jhLObNFthQ4JKvjxcgeNue9zgLqA 63I4ZCQ4S8CeWXyVg3sPZSxImtoy6lfnvNEEHIa3eeiHm1o= X-Google-Smtp-Source: ABdhPJwqXgD1h8vwOq3sKhOOLYpmb/kvh0ICZ62ZheCMxJHcuOBhvAu1slV5a3vrowC4gm6vWMU5ryaLP60oZlw61No= X-Received: by 2002:a05:6402:1d81:: with SMTP id dk1mr60583007edb.328.1641510018179; Thu, 06 Jan 2022 15:00:18 -0800 (PST) MIME-Version: 1.0 References: <3DC3F6B6-229E-46C6-BD84-2A6A7FE6DD48@apple.com> In-Reply-To: <3DC3F6B6-229E-46C6-BD84-2A6A7FE6DD48@apple.com> From: Greg Mirsky Date: Thu, 6 Jan 2022 15:00:06 -0800 Message-ID: To: Christoph Paasch Cc: Marcus Ihlar , IETF IPPM WG Content-Type: multipart/alternative; boundary="0000000000008766bc05d4f1d5eb" Archived-At: Subject: Re: [ippm] Adoption call for draft-cpaasch-ippm-responsiveness X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2022 23:00:26 -0000 --0000000000008766bc05d4f1d5eb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Christoph, a happy and healthy New Year to you and All! Thank you for your kind consideration of my notes and detailed responses. Please find my follow-up notes in-line below under the GIM>> tag. Regards, Greg On Wed, Jan 5, 2022 at 10:52 AM Christoph Paasch wrote: > Hello Greg, > > thanks for your comments. Please see inline: > > On Dec 22, 2021, at 11:43 PM, Greg Mirsky wrote: > > Dear Marcus, Authors, et al, > apologies for the belated response. > I've read the draft and have some comments to share with you: > > - as I understand it, the proposed new responsiveness metric is viewed > as the single indicator of a bufferbloat condition in a network. As I > recall, the discussion at Measuring Network Quality for End-Users work= shop > and on the mailing list > > indicated, that there=E2=80=99s no consensus on what behaviors, sympto= ms can > reliably signal the bufferbloat. > > We are not trying for this responsiveness metric to be "the single > indicator of bufferbloat". Bufferbloat can be measured in many different > number of ways. And each of these will produce a correct, but a different > result. Thus, "bufferbloat" is whatever the methodology tries to detect. > > Let me give an example of two methodologies that are both correct but bot= h > will produce entirely different numbers : > > If we would decide to generate the load by flooding the network with UDP > traffic from a specific 4-tuple and measure latency with parallel ICMP > pings. Then, on a over-buffered FIFO queue we would measure huge latencie= s > (thus correctly expose bufferbloat), while on a FQ-codel queue we would n= ot > measure any bufferbloat. > > If on the other hand, the load-generating traffic is changing the > source-port for every single UDP-packet, then in both the FIFO-queue and > the FQ-codel queue we will measure huge amounts of bufferbloat. > > Thus, these two methods both produced correct results but with hugely > different numbers in the FQ-codel case. [1] > > Now, while both methods measure some variant of bufferbloat, they both > don't measure a realistic usage of the network. > GIM>> Thank you for the insights. It seems to me that what the method can demonstrate is rather the level of efficiency of the AQM in the network for a particular class of applications. > > > That is why the "Responsiveness under working conditions" tries to clearl= y > specify how the load is generated and how the latency is being measured. > And it does not measure "bufferbloat" but it measures "responsiveness und= er > working conditions" based on the methodology that is being used (using > HTTP/2 or HTTP/3, multiple flows, ...). It does expose bufferbloat which > can happen in the network. It also exposes certain server-side behaviors > that can cause (huge amounts of) additional latency - those behaviors are > typically not called "bufferbloat". > GIM>> Thank you for pointing out that the result of the RTT measurement has two contributing factors - network and server. It seems worth enhancing the method to localize each contribution and measure them separately. > > > > > - It seems that it would be reasonable to first define what is being > measured, characterized by the responsiveness metric. Having a documen= t > that discusses and defines the bufferbloat would be great. > > I agree that there is a lack of definition for what "bufferbloat" really > is. > > The way we look at "responsiveness under working conditions" is that it > measures the latency in conditions that may realistically happen in > worst-case scenarios with end-users/implementations that are non-maliciou= s > (non-malicious to exclude the UDP-flooding scenario). > > Thus, I assume we should make a better job at explaining this. The lack o= f > a formal definition of "bufferbloat" doesn't help and thus we are indeed > using this term a bit freely in the current draft. We will improve the > Introduction to better set the stage ( > https://github.com/network-quality/draft-cpaasch-ippm-responsiveness/issu= es/31 > ). > > > - It seems like in the foundation of the methodology described in the > draft lies the assumption that without adding new flows the > available bandwidth is constant, does not change. While that is mostly= the > case, there are technologies that behave differently and may change > bandwidth because of the outside conditions. Some of these behaviors o= f > links with variable discrete bandwidth are discussed in, for example, = RFC > 8330 and RFC 8625 > . > > I'm not sure I entirely understand your comment. But let me explain why w= e > are gradually adding new flows: > > 1. TCP-implementations have usually a fixed limit for the upper bound of > the receive window. In some networks that upper bound is lower than the B= DP > of the network. Thus, the only way to reach full capacity is by having > multiple flows. > 2. Having multiple connections allows to quicker achieve full capacity in > high-RTT networks and thus speeds up the test-duration. > 3. In some networks with "random" packet-loss, congestion-control may com= e > in the way of achieving full capacity. Again, multiple flows will work > around that. > GIM>> I might have asked several questions at once. Let me clarify what I am looking for: - As I understand the method of creating the "working conditions in a network" is based on certain assumptions. First, seems is that the bandwidth is symmetrical between the measurement points. Second, that th= e bandwidth doesn't change for the duration of the measurement session. AFAIK, in the access networks, both are not necessarily always the case. - On the other hand, I might have missed how the method of creating the "working conditions" guarantees a symmetrical load between the measureme= nt points. > > - Then, I find the motivation not to use time units to express the > responsiveness metric not convincing: > > "Latency" is a poor measure of responsiveness, since it can be hard > for the general public to understand. The units are unfamiliar > ("what is a millisecond?") and counterintuitive ("100 msec - that > sounds good - it's only a tenth of a second!"). > > > Can you expand on what exactly is not convincing to you? Do you think tha= t > people will mis-understand the metric or that milli-seconds is the right > way to communicate responsiveness to the general public? > GIM>> Let me try. We know packet delay requirements for AR, VR applications. I believe that gamers are familiar with these numbers too. The same is likely the case for the industrial automation use cases served, for example, by Deterministic Networking. > > > Thanks a lot, > Christoph > > [1] And there are many networks that prioritize ICMP pings, thus we could > observe even more different results based on what protocol is used to > measure the latency. > > > On Mon, Dec 6, 2021 at 7:53 AM Marcus Ihlar 40ericsson.com@dmarc.ietf.org> wrote: > >> Hi IPPM, >> >> >> >> This email starts an adoption call for draft-cpaasch-ippm-responsiveness= , >> "Responsiveness under Working Conditions=E2=80=9D. This document specifi= es the =E2=80=9CRPM >> Test=E2=80=9D for measuring user experience when the network is fully lo= aded. The >> intended status of the document is Experimental. >> >> >> >> https://datatracker.ietf.org/doc/draft-cpaasch-ippm-responsiveness/ >> >> https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-responsiveness-= 01 >> >> >> >> This adoption call will last until *Monday, December 20*. Please review >> the document, and reply to this email thread to indicate if you think IP= PM >> should adopt this document. >> >> >> >> BR, >> >> Marcus >> >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > > --0000000000008766bc05d4f1d5eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Christoph,
    a happ= y and healthy New Year to you and All!
    Thank you for your kind co= nsideration of my notes and detailed responses. Please find my follow-up no= tes=C2=A0in-line below under the GIM>> tag.

    = Regards,
    Greg

    On Wed, Jan 5, 2022 at 10:52 AM Christoph Paa= sch <cpaasch@apple.com> wrot= e:
    Hello Greg,

    thanks for your= comments. Please see inline:

    On= Dec 22, 2021, at 11:43 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:

    <= div>
    De= ar Marcus, Authors, et al,
    apologies for the belated response.
    I've read the draft and have some comments to share with you:
    • as I understand it, the proposed new responsiveness metric is vi= ewed as the single indicator of a bufferbloat condition in a network. As I = recall,=C2=A0the discussion at Measuring Network Quality for End-Users work= shop and on the mailing list indicated, that there=E2=80= =99s no consensus on what behaviors, symptoms can reliably signal the buffe= rbloat.
    We = are not trying for this responsiveness metric to be "the single indica= tor of bufferbloat". Bufferbloat can be measured in many different num= ber of ways. And each of these will produce a correct, but a different resu= lt. Thus, "bufferbloat" is whatever the methodology tries to dete= ct.

    Let me give an example of two methodologies th= at are both correct but both will produce entirely different numbers :

    If we would decide to generate the load by flooding th= e network with UDP traffic from a specific 4-tuple and measure latency with= parallel ICMP pings. Then, on a over-buffered FIFO queue we would measure = huge latencies (thus correctly expose bufferbloat), while on a FQ-codel que= ue we would not measure any bufferbloat.

    If on the= other hand, the load-generating traffic is changing the source-port for ev= ery single UDP-packet, then in both the FIFO-queue and the FQ-codel queue w= e will measure huge amounts of bufferbloat.

    Thus, = these two methods both produced correct results but with hugely different n= umbers in the FQ-codel case. [1]

    Now, while both m= ethods measure some variant of bufferbloat, they both don't measure a r= ealistic usage of the network.
    GIM= >> Thank you for the insights. It seems to me that what the method ca= n demonstrate is rather the level of efficiency of the AQM in the network f= or a particular class of applications.


    That is why the "Responsiveness under w= orking conditions" tries to clearly specify how the load is generated = and how the latency is being measured. And it does not measure "buffer= bloat" but it measures "responsiveness under working conditions&q= uot; based on the methodology that is being used (using HTTP/2 or HTTP/3, m= ultiple flows, ...). It does expose bufferbloat which can happen in the net= work. It also exposes certain server-side behaviors that can cause (huge am= ounts of) additional latency - those behaviors are typically not called &qu= ot;bufferbloat".
    GIM>> = Thank you for pointing out that the result of the RTT measurement has two c= ontributing factors - network and server. It seems worth enhancing the meth= od to localize each contribution and measure them separately.

      <= /div>
      • I= t seems that it would be reasonable to first define what is being measured,= characterized=C2=A0by the responsiveness metric. Having a document that di= scusses and defines the bufferbloat would be great.
      I agree that there is a lack of def= inition for what "bufferbloat" really is.

      The way we look at "responsiveness under working conditions" is= that it measures the latency in conditions that may realistically happen i= n worst-case scenarios with end-users/implementations that are non-maliciou= s (non-malicious to exclude the UDP-flooding scenario).

      Thus, I assume we should make a better job at explaining this. The la= ck of a formal definition of "bufferbloat" doesn't help and t= hus we are indeed using this term a bit freely in the current draft. We wil= l improve the Introduction to better set the stage (https://github.com/network-quality/draft-cpaasch-ippm-responsiv= eness/issues/31).

    • It seems like in the foundation of the methodology described in the dr= aft lies the assumption=C2=A0that without adding new flows the available=C2= =A0bandwidth=C2=A0is constant, does not change. While that is mostly the ca= se, there are technologies that behave differently and may change bandwidth= because of the outside conditions. Some of these behaviors of links with v= ariable discrete=C2=A0bandwidth are discussed in, for example,=C2=A0RFC 8330=C2=A0and RFC 8625.
      • I'm not sure I entirel= y understand your comment. But let me explain why we are gradually adding n= ew flows:

      1. TCP-implementations have usually a fi= xed limit for the upper bound of the receive window. In some networks that = upper bound is lower than the BDP of the network. Thus, the only way to rea= ch full capacity is by having multiple flows.
      2. Having multiple = connections allows to quicker achieve full capacity in high-RTT networks an= d thus speeds up the test-duration.
      3. In some networks with &quo= t;random" packet-loss, congestion-control may come in the way of achie= ving full capacity. Again, multiple flows will work around that.
      GIM>> I might have asked several quest= ions at once. Let me clarify what I am looking for:
      • As I = understand the method of creating the "working conditions in a network= " is based on certain assumptions. First, seems is that the bandwidth = is symmetrical between the measurement points. Second, that the bandwidth d= oesn't change for the duration of the measurement session. AFAIK, in th= e access networks, both are not necessarily always the case.
      • On= the other hand, I might have missed how the method of creating the "w= orking conditions" guarantees a symmetrical load between the measureme= nt points.
      <= div dir=3D"auto">

    • Then, I find the motivation not to use time units to express the respo= nsiveness metric not convincing:
      • =C2=A0 = =C2=A0"Latency" is a poor measure of responsiveness, since it can= be hard
      =C2=A0 =C2=A0for the general publi= c to understand.=C2=A0 The units are unfamiliar
      =
      =C2=A0 =C2=A0("what is a millisecond?") and counterintuitive= ("100 msec - that
      =C2=A0 =C2=A0sounds= good - it's only a tenth of a second!").

      Can you expand on what e= xactly is not convincing to you? Do you think that people will mis-understa= nd the metric or that milli-seconds is the right way to communicate respons= iveness to the general public?
      GIM>&g= t; Let me try. We know packet delay requirements for AR, VR applications. I= believe that gamers are familiar with these numbers too. The same is likel= y the case for the industrial automation use cases served, for example, by = Deterministic Networking.

      Thanks a lot,
      Christoph

      [1]= And there are many networks that prioritize ICMP pings, thus we could obse= rve even more different results based on what protocol is used to measure t= he latency.


      <= div class=3D"gmail_quote">
      On Mon, Dec= 6, 2021 at 7:53 AM Marcus Ihlar <marcus.ihlar=3D40ericsson.c= om@dmarc.ietf.org> wrote:

      Hi IPPM,<= u>

      <= /u>=C2=A0

      This email starts an adoption call for draft-cpaasch-ippm-responsiven= ess, "Responsiveness under Working Conditions=E2=80=9D. This document = specifies the =E2=80=9CRPM Test=E2=80=9D for measuring user experience when= the network is fully loaded. The intended status of the document is Experiment= al. =C2=A0=C2=A0

      =C2=A0

      <= span style=3D"font-size:12pt">htt= ps://datatracker.ietf.org/doc/draft-cpaasch-ippm-responsiveness/=

      https://datatracker.ietf.org/= doc/html/draft-cpaasch-ippm-responsiveness-01

      =C2=A0

      This adoption call will last until Monday, December 20. Please review the document, and reply to this e= mail thread to indicate if you think IPPM should adopt this document.

      =C2=A0

      BR,

      Marcus

      =C2=A0

      _______________________________________________
      ippm mailing list
      ippm@= ietf.org
      https://www.ietf.org/mailman/listinfo/ippm<= br>
      _______________________________________________
      ippm mailing list
      ippm@ietf.org
      https://= www.ietf.org/mailman/listinfo/ippm

      --0000000000008766bc05d4f1d5eb-- From nobody Thu Jan 6 16:42:19 2022 Return-Path: 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 DE9673A0BE3 for ; Thu, 6 Jan 2022 16:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.672 X-Spam-Level: X-Spam-Status: No, score=-2.672 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z513DMxkacVP for ; Thu, 6 Jan 2022 16:42:13 -0800 (PST) Received: from rn-mailsvcp-ppex-lapp45.apple.com (rn-mailsvcp-ppex-lapp45.rno.apple.com [17.179.253.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 489F23A0BE0 for ; Thu, 6 Jan 2022 16:42:13 -0800 (PST) Received: from pps.filterd (rn-mailsvcp-ppex-lapp45.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp45.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 2070U0FI017200; Thu, 6 Jan 2022 16:42:10 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=LS8Ucw5H2kGhs4CgVMliCz3KWkQ1WrdSK2Q9cmpmjNU=; b=ndKZ9sad9TROwrPhDUWbKiSwereQBMOA2Z3fP121b/U1SQK5Ns/H5flT1rSpKvGkU3c7 LU4RKlu1dXT8POmsYlkEe9az4ez+AoXYfGCdcZClNyS63D2TGh45AxVl2iFfvcTyLWAE 6zIaBVRHLALI4DkUreO5wiS3QS1euvPpvX94whrhmhWxrD32QDNXPMzIe/Fr1w4xhqPA u9inReJAgWeSOYmzcxquz4E5dhij9R+V6BQ+vJszD1JQ1rzZqoMaO7e7pzbkKEXESPI9 eb+TBMFAHGDGVkM+MVcmnic1t/SVf0fQPRiAJh1XySnZ4pYN024rt9HASd3l1sMEE2qT 6A== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by rn-mailsvcp-ppex-lapp45.rno.apple.com with ESMTP id 3de4xw4fqa-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 06 Jan 2022 16:42:10 -0800 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R5B00D7FDY9GJ00@rn-mailsvcp-mta-lapp04.rno.apple.com>; Thu, 06 Jan 2022 16:42:09 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R5B00C00DY2A700@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Thu, 06 Jan 2022 16:42:09 -0800 (PST) X-Va-A: X-Va-T-CD: 1b7e4f4dab179820cbb0a121fe2fe7dc X-Va-E-CD: de054fff2f5096dfe99f93b89e853049 X-Va-R-CD: 7d741991045d6b2f869f53b80b980cf0 X-Va-CD: 0 X-Va-ID: f714d32f-8a58-4c58-88c7-c51bc92e3b67 X-V-A: X-V-T-CD: 1b7e4f4dab179820cbb0a121fe2fe7dc X-V-E-CD: de054fff2f5096dfe99f93b89e853049 X-V-R-CD: 7d741991045d6b2f869f53b80b980cf0 X-V-CD: 0 X-V-ID: 2554de48-bc70-41d1-97cc-95bba393aab3 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2022-01-06_10:2022-01-05, 2022-01-06 signatures=0 Received: from smtpclient.apple ([17.192.155.238]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R5B00FNIDY98D20@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Thu, 06 Jan 2022 16:42:09 -0800 (PST) From: Christoph Paasch Message-id: <9340CFDA-079C-4490-A01C-EB863D365F8F@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_D522E7BD-A27F-4EA9-8522-13264A649854" MIME-version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) Date: Thu, 06 Jan 2022 16:42:08 -0800 In-reply-to: Cc: Marcus Ihlar , IETF IPPM WG To: Greg Mirsky References: <3DC3F6B6-229E-46C6-BD84-2A6A7FE6DD48@apple.com> X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2022-01-06_10:2022-01-05, 2022-01-06 signatures=0 Archived-At: Subject: Re: [ippm] Adoption call for draft-cpaasch-ippm-responsiveness X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2022 00:42:18 -0000 --Apple-Mail=_D522E7BD-A27F-4EA9-8522-13264A649854 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Greg, > On Jan 6, 2022, at 3:00 PM, Greg Mirsky wrote: >=20 > Hi Christoph, > a happy and healthy New Year to you and All! Happy New Year to you as well! > Thank you for your kind consideration of my notes and detailed = responses. Please find my follow-up notes in-line below under the GIM>> = tag. Thanks for your replies. Please see inline: > On Wed, Jan 5, 2022 at 10:52 AM Christoph Paasch > wrote: > Hello Greg, >=20 > thanks for your comments. Please see inline: >=20 >> On Dec 22, 2021, at 11:43 PM, Greg Mirsky > wrote: >>=20 >> Dear Marcus, Authors, et al, >> apologies for the belated response. >> I've read the draft and have some comments to share with you: >> as I understand it, the proposed new responsiveness metric is viewed = as the single indicator of a bufferbloat condition in a network. As I = recall, the discussion at Measuring Network Quality for End-Users = workshop and on the mailing list = indicated, that there=E2=80=99s = no consensus on what behaviors, symptoms can reliably signal the = bufferbloat. > We are not trying for this responsiveness metric to be "the single = indicator of bufferbloat". Bufferbloat can be measured in many different = number of ways. And each of these will produce a correct, but a = different result. Thus, "bufferbloat" is whatever the methodology tries = to detect. >=20 > Let me give an example of two methodologies that are both correct but = both will produce entirely different numbers : >=20 > If we would decide to generate the load by flooding the network with = UDP traffic from a specific 4-tuple and measure latency with parallel = ICMP pings. Then, on a over-buffered FIFO queue we would measure huge = latencies (thus correctly expose bufferbloat), while on a FQ-codel queue = we would not measure any bufferbloat. >=20 > If on the other hand, the load-generating traffic is changing the = source-port for every single UDP-packet, then in both the FIFO-queue and = the FQ-codel queue we will measure huge amounts of bufferbloat. >=20 > Thus, these two methods both produced correct results but with hugely = different numbers in the FQ-codel case. [1] >=20 > Now, while both methods measure some variant of bufferbloat, they both = don't measure a realistic usage of the network. > GIM>> Thank you for the insights. It seems to me that what the method = can demonstrate is rather the level of efficiency of the AQM in the = network for a particular class of applications. Yes, that is a good description. It is for a "particular class of = applications" and we are trying to make this class of applications = representative of a "typical user-scenario". (admittedly, we can debate = forever on what kind of applications are representative and I would love = to have that debate :-)). On the point of "efficiency of the AQM". I would go even further that = it's not only AQM but also the client- and server-side implementations = of these applications (as noted further below). >=20 >=20 > That is why the "Responsiveness under working conditions" tries to = clearly specify how the load is generated and how the latency is being = measured. And it does not measure "bufferbloat" but it measures = "responsiveness under working conditions" based on the methodology that = is being used (using HTTP/2 or HTTP/3, multiple flows, ...). It does = expose bufferbloat which can happen in the network. It also exposes = certain server-side behaviors that can cause (huge amounts of) = additional latency - those behaviors are typically not called = "bufferbloat". > GIM>> Thank you for pointing out that the result of the RTT = measurement has two contributing factors - network and server. Yes, servers contribute as do the client-side implementations. It's all = three (client, network, server) that need to work "correctly" to achieve = good responsiveness. Btw., as we are now gathering more experience with = our methodology in different environments we find that the biggest = portions of latency actually come from the server-side. We see several = seconds of latency introduced by the HTTP/2 and TCP implementations. > It seems worth enhancing the method to localize each contribution and = measure them separately. With the latency measuring probes being sent on load-bearing connections = and separate connections and with the separate connections serving to = measure DNS/TCP/... individually, the different data-points actually = allow to localize to some extend. However, I would be reluctant to dive too deep into = localization/trouble-shooting/debugging of networks as part of this I-D. = As this opens a whole new can of worms. We could then start thinking = about sending latency-probes while playing with the IP TTL to find which = router is introducing the latency,... It's an entirely different = research-topic IMO :-) Dave Taht was thinking of starting something = along these lines (https://github.com/dtaht/wtbb = ). >> It seems that it would be reasonable to first define what is being = measured, characterized by the responsiveness metric. Having a document = that discusses and defines the bufferbloat would be great. > I agree that there is a lack of definition for what "bufferbloat" = really is. >=20 > The way we look at "responsiveness under working conditions" is that = it measures the latency in conditions that may realistically happen in = worst-case scenarios with end-users/implementations that are = non-malicious (non-malicious to exclude the UDP-flooding scenario). >=20 > Thus, I assume we should make a better job at explaining this. The = lack of a formal definition of "bufferbloat" doesn't help and thus we = are indeed using this term a bit freely in the current draft. We will = improve the Introduction to better set the stage = (https://github.com/network-quality/draft-cpaasch-ippm-responsiveness/issu= es/31 = ). >=20 >> It seems like in the foundation of the methodology described in the = draft lies the assumption that without adding new flows the available = bandwidth is constant, does not change. While that is mostly the case, = there are technologies that behave differently and may change bandwidth = because of the outside conditions. Some of these behaviors of links with = variable discrete bandwidth are discussed in, for example, RFC 8330 = and RFC 8625 = . > I'm not sure I entirely understand your comment. But let me explain = why we are gradually adding new flows: >=20 > 1. TCP-implementations have usually a fixed limit for the upper bound = of the receive window. In some networks that upper bound is lower than = the BDP of the network. Thus, the only way to reach full capacity is by = having multiple flows. > 2. Having multiple connections allows to quicker achieve full capacity = in high-RTT networks and thus speeds up the test-duration. > 3. In some networks with "random" packet-loss, congestion-control may = come in the way of achieving full capacity. Again, multiple flows will = work around that. > GIM>> I might have asked several questions at once. Let me clarify = what I am looking for: > As I understand the method of creating the "working conditions in a = network" is based on certain assumptions. First, seems is that the = bandwidth is symmetrical between the measurement points. Second, that = the bandwidth doesn't change for the duration of the measurement = session. AFAIK, in the access networks, both are not necessarily always = the case. We don't have the assumption that bandwidth is symmetrical (assuming, = you mean uplink/downlink symmetry - please clarify otherwise). The load-generating algorithm runs independently for uplink and downlink = traffic. And it is perfectly fine when both have huge asymmetry. Regarding the stability of the bandwidth: You are making a good point indeed that we assume that the bandwidth is = to some extend stable while ramping up the flows to "working = conditions". Admittedly that assumption does not always hold, and that = is one of the reasons why we try hard for the test to not take too long. I'm not sure how we could adjust the algorithm for varying bandwidth = without introducing too much complexity. I'm open for suggestions :-) > On the other hand, I might have missed how the method of creating the = "working conditions" guarantees a symmetrical load between the = measurement points. As mentioned above, we don't assume a symmetrical load. Can you show us = where in the draft we give that impression, so we can fix that? >>=20 >> Then, I find the motivation not to use time units to express the = responsiveness metric not convincing: >> "Latency" is a poor measure of responsiveness, since it can be = hard >> for the general public to understand. The units are unfamiliar >> ("what is a millisecond?") and counterintuitive ("100 msec - that >> sounds good - it's only a tenth of a second!"). >=20 > Can you expand on what exactly is not convincing to you? Do you think = that people will mis-understand the metric or that milli-seconds is the = right way to communicate responsiveness to the general public? > GIM>> Let me try. We know packet delay requirements for AR, VR = applications. I believe that gamers are familiar with these numbers too. = The same is likely the case for the industrial automation use cases = served, for example, by Deterministic Networking. I can understand that for a technical audience, milli-seconds is easy = and familiar. A non-technical audience might be more open to accepting a = new "higher-is-better" metric. Responsiveness is something new and = abstract so, it's kind of natural that it comes with a new unit. But I fully recognize that that's a controversial topic and can be = discussed at length :) Cheers, Christoph >=20 >=20 > Thanks a lot, > Christoph >=20 > [1] And there are many networks that prioritize ICMP pings, thus we = could observe even more different results based on what protocol is used = to measure the latency. >=20 >>=20 >> On Mon, Dec 6, 2021 at 7:53 AM Marcus Ihlar = > wrote: >> Hi IPPM, >>=20 >> =20 >>=20 >> This email starts an adoption call for = draft-cpaasch-ippm-responsiveness, "Responsiveness under Working = Conditions=E2=80=9D. This document specifies the =E2=80=9CRPM Test=E2=80=9D= for measuring user experience when the network is fully loaded. The = intended status of the document is Experimental. =20 >>=20 >> =20 >>=20 >> https://datatracker.ietf.org/doc/draft-cpaasch-ippm-responsiveness/ = >> = https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-responsiveness-01= = >> =20 >>=20 >> This adoption call will last until Monday, December 20. Please review = the document, and reply to this email thread to indicate if you think = IPPM should adopt this document. >>=20 >> =20 >>=20 >> BR, >>=20 >> Marcus >>=20 >> =20 >>=20 >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm = >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm = >=20 --Apple-Mail=_D522E7BD-A27F-4EA9-8522-13264A649854 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello= Greg,

      On Jan 6, 2022, at 3:00 PM, Greg Mirsky = <gregimirsky@gmail.com> wrote:

      Hi = Christoph,
      a happy and healthy New Year to you and = All!

      Happy New Year to you as well!

      Thank you for your kind consideration of my = notes and detailed responses. Please find my follow-up = notes in-line below under the GIM>> = tag.

      Thanks for your replies. Please see = inline:

      On Wed, Jan 5, 2022 at 10:52 AM Christoph Paasch = <cpaasch@apple.com> wrote:
      Hello Greg,

      thanks for your comments. Please see = inline:

      On Dec 22, 2021, at 11:43 PM, = Greg Mirsky <gregimirsky@gmail.com> wrote:

      Dear Marcus, Authors, = et al,
      apologies for the belated response.
      I've read the draft and have some comments to share with = you:
      • as I understand = it, the proposed new responsiveness metric is viewed as the single = indicator of a bufferbloat condition in a network. As I recall, the = discussion at Measuring Network Quality for End-Users workshop and on the mailing list indicated, that = there=E2=80=99s no consensus on what behaviors, symptoms can reliably = signal the bufferbloat. =
      We are not trying for this responsiveness metric to be "the = single indicator of bufferbloat". Bufferbloat can be measured in many = different number of ways. And each of these will produce a correct, but = a different result. Thus, "bufferbloat" is whatever the methodology = tries to detect.

      Let me give an example of two methodologies that are both = correct but both will produce entirely different numbers :

      If we would decide to = generate the load by flooding the network with UDP traffic from a = specific 4-tuple and measure latency with parallel ICMP pings. Then, on = a over-buffered FIFO queue we would measure huge latencies (thus = correctly expose bufferbloat), while on a FQ-codel queue we would not = measure any bufferbloat.

      If on the other hand, the load-generating traffic is changing = the source-port for every single UDP-packet, then in both the FIFO-queue = and the FQ-codel queue we will measure huge amounts of = bufferbloat.

      Thus, these two methods both produced correct results but = with hugely different numbers in the FQ-codel case. [1]

      Now, while both methods = measure some variant of bufferbloat, they both don't measure a realistic = usage of the network.
      GIM>> Thank you for the insights. It seems to me that = what the method can demonstrate is rather the level of efficiency of the = AQM in the network for a particular class of = applications.

      Yes, that is a good description. It is for a = "particular class of applications" and we are trying to make this class = of applications representative of a "typical user-scenario". = (admittedly, we can debate forever on what kind of applications are = representative and I would love to have that debate :-)).

      On the point of "efficiency of the AQM". I would = go even further that it's not only AQM but also the client- and = server-side implementations of these applications (as noted further = below).




      That is why the "Responsiveness under working conditions" = tries to clearly specify how the load is generated and how the latency = is being measured. And it does not measure "bufferbloat" but it measures = "responsiveness under working conditions" based on the methodology that = is being used (using HTTP/2 or HTTP/3, multiple flows, ...). It does = expose bufferbloat which can happen in the network. It also exposes = certain server-side behaviors that can cause (huge amounts of) = additional latency - those behaviors are typically not called = "bufferbloat".
      GIM>> Thank you for pointing out that the result of the = RTT measurement has two contributing factors - network and = server.

      Yes, servers contribute as do the client-side = implementations. It's all three (client, network, server) that need to = work "correctly" to achieve good responsiveness. Btw., as we are now = gathering more experience with our methodology in different environments = we find that the biggest portions of latency actually come from the = server-side. We see several seconds of latency introduced by the HTTP/2 = and TCP implementations.

      It seems worth = enhancing the method to localize each contribution and measure them = separately.

      With the latency measuring probes being sent on = load-bearing connections and separate connections and with the separate = connections serving to measure DNS/TCP/... individually, the different = data-points actually allow to localize to some extend.

      However, I would be reluctant to dive too deep = into localization/trouble-shooting/debugging of networks as part of this = I-D. As this opens a whole new can of worms. We could then start = thinking about sending latency-probes while playing with the IP TTL to = find which router is introducing the latency,... It's an entirely = different research-topic IMO :-) Dave Taht was thinking of starting = something along these lines (https://github.com/dtaht/wtbb).

        • It seems that = it would be reasonable to first define what is being measured, = characterized by the responsiveness metric. Having a document that = discusses and defines the bufferbloat would be = great.
        I agree that there is a lack of definition for what = "bufferbloat" really is.

        The way we look at "responsiveness under working conditions" = is that it measures the latency in conditions that may realistically = happen in worst-case scenarios with end-users/implementations that are = non-malicious (non-malicious to exclude the UDP-flooding = scenario).

        Thus,= I assume we should make a better job at explaining this. The lack of a = formal definition of "bufferbloat" doesn't help and thus we are indeed = using this term a bit freely in the current draft. We will improve the = Introduction to better set the stage (https://github.com/network-quality/draft-cpaasch-ippm-responsiv= eness/issues/31).

        • It seems like in the foundation of the methodology described = in the draft lies the assumption that without adding new flows the = available bandwidth is constant, does not change. While that = is mostly the case, there are technologies that behave differently and = may change bandwidth because of the outside conditions. Some of these = behaviors of links with variable discrete bandwidth are discussed = in, for example, RFC 8330 and RFC = 8625.
        I'm not sure I entirely understand your comment. But let me = explain why we are gradually adding new flows:

        1. TCP-implementations have usually a = fixed limit for the upper bound of the receive window. In some networks = that upper bound is lower than the BDP of the network. Thus, the only = way to reach full capacity is by having multiple flows.
        2. Having multiple connections allows to quicker achieve full = capacity in high-RTT networks and thus speeds up the = test-duration.
        3. In some networks with "random" = packet-loss, congestion-control may come in the way of achieving full = capacity. Again, multiple flows will work around = that.
        GIM>> I = might have asked several questions at once. Let me clarify what I am = looking for:
        • As I = understand the method of creating the "working conditions in a network" = is based on certain assumptions. First, seems is that the bandwidth is = symmetrical between the measurement points. Second, that the bandwidth = doesn't change for the duration of the measurement session. AFAIK, in = the access networks, both are not necessarily always the = case.
        We don't = have the assumption that bandwidth is symmetrical (assuming, you mean = uplink/downlink symmetry - please clarify otherwise).

        The load-generating algorithm runs independently = for uplink and downlink traffic. And it is perfectly fine when both have = huge asymmetry.


        Regarding the stability of the = bandwidth:
        You are making a good point indeed that we assume = that the bandwidth is to some extend stable while ramping up the flows = to "working conditions". Admittedly that assumption does not always = hold, and that is one of the reasons why we try hard for the test to not = take too long.
        I'm not sure how we could adjust the algorithm = for varying bandwidth without introducing too much complexity. I'm open = for suggestions :-)
        • On = the other hand, I might have missed how the method of creating the = "working conditions" guarantees a symmetrical load between the = measurement = points.
        As = mentioned above, we don't assume a symmetrical load. Can you show us = where in the draft we give that impression, so we can fix that?


        • Then, I find the motivation not to use time = units to express the responsiveness metric not convincing:
           "Latency" is a poor measure of = responsiveness, since it can be hard
           for the general public to = understand.  The units are unfamiliar
           ("what is a = millisecond?") and counterintuitive ("100 msec - = that
           sounds good - it's only a tenth of a = second!").

        Can you expand on what = exactly is not convincing to you? Do you think that people will = mis-understand the metric or that milli-seconds is the right way to = communicate responsiveness to the general = public?
        GIM>> Let me = try. We know packet delay requirements for AR, VR applications. I = believe that gamers are familiar with these numbers too. The same is = likely the case for the industrial automation use cases served, for = example, by Deterministic = Networking.

        I can understand that for a technical audience, = milli-seconds is easy and familiar. A non-technical audience might be = more open to accepting a new "higher-is-better" metric. Responsiveness = is something new and abstract so, it's kind of natural that it comes = with a new unit.

        But I fully = recognize that that's a controversial topic and can be discussed at = length :)


        Cheers,
        Christoph



        Thanks a lot,
        Christoph

        [1] And there are many = networks that prioritize ICMP pings, thus we could observe even more = different results based on what protocol is used to measure the = latency.


        On Mon, Dec = 6, 2021 at 7:53 AM Marcus Ihlar <marcus.ihlar=3D40ericsson.com@dmarc.ietf.org> = wrote:

        Hi IPPM,

         

        This email = starts an adoption call for draft-cpaasch-ippm-responsiveness, = "Responsiveness under Working Conditions=E2=80=9D. This document = specifies the =E2=80=9CRPM Test=E2=80=9D for measuring user experience = when the network is fully loaded. The intended status of the document is = Experimental.   

         

        https://datatracker.ietf.org/doc/draft-cpaasch-ippm-responsiven= ess/

        https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-respon= siveness-01

         

        This adoption call will last until Monday, December 20. Please review the document, and = reply to this email thread to indicate if you think IPPM should adopt = this document.

         

        BR,

        Marcus

         

        _______________________________________________
        ippm mailing list
        ippm@ietf.org
        https://www.ietf.org/mailman/listinfo/ippm
        _______________________________________________
        ippm = mailing list
        ippm@ietf.org
        https://www.ietf.org/mailman/listinfo/ippm


        = --Apple-Mail=_D522E7BD-A27F-4EA9-8522-13264A649854-- From nobody Fri Jan 7 00:03:41 2022 Return-Path: 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 B2F733A1662 for ; Fri, 7 Jan 2022 00:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.671 X-Spam-Level: X-Spam-Status: No, score=-2.671 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4iy6uWCCO_HG for ; Fri, 7 Jan 2022 00:03:32 -0800 (PST) Received: from mailout41.telekom.de (mailout41.telekom.de [194.25.225.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F0273A1660 for ; Fri, 7 Jan 2022 00:03:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1641542611; x=1673078611; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pAlm9DVr+qVQLVxHqCBbit0Grex0Rajj1r7dDRaqJSA=; b=0PJOgEPWdC6qYhD1HFJ+fzFBItzBw7WElIM97tYX8VVWL2SJbblwYCD+ gljracuD3lgzOtrd63yzkjfVu3n04jwCeeeN+cguWl8iQ4tTmUxx4RB7z QZnqF9M2400Gy2fCy3gskWxe+N/t46VYl/GKdaNL3x12kzjSoPUPIn+Hf vJVBpaDv8vv8PGcfzHz5fCABbSBWGh6fZKYz25PORdIII0OY+WxDyYxCH 14drvF6afpfU4pPPtrmcVyoveRjp4C9pFrZYgs6jDz9w3yaCHze1nYmng t5gGdMrvVf1Ei2bu4UFwySsvnRoU3eYcm9M6Yh8i6ebQ326/XIbwlA1or w==; IronPort-SDR: dQ8O9ZKQsNB4SlMXe9/Fc+pq+sV46y8k2MRlj5aHHma/+PfgMtG5EoPBe3YvWW8b2UB0N7lee+ Z16/SWJiqYXw== IronPort-Data: =?us-ascii?q?A9a23=3AqTuc5autbOICLRESHMBlHtyhcufnVHJcMUV32?= =?us-ascii?q?f8akzHdYApBsoF/qtZmKWyPP//fNDTxLo90OY7npE1V68CBz9E3SFRp/CljF?= =?us-ascii?q?3sVpJueD7x1DKtQ0wB+jyH7ocoOA/w2MrEsF+hpCC+MzvuRGuK59yMkjPnXH?= =?us-ascii?q?uOU5NPsYUideyc1EU/Ntjozw4bVsqYw6TSIK1vlVeHa+qUzC3f5s9JACV/43?= =?us-ascii?q?orYwP9ZUFQejxtD1rA2TagjUFYzDBD5BrpHTU26ByOQroW5goeHq+j/ILGRp?= =?us-ascii?q?gs1/j8UJv6Ow+q9fkBMXvvTOxSDkHxfX+6phR0qSi4ai/59baVFLx0K1nPVx?= =?us-ascii?q?ridy/0U3XC0YT00M6HNl+kHFTZVEitWIaBC9bzAJD6zvKR/ymWcLiW9n6gzU?= =?us-ascii?q?CnaOqVdoI6bG1pm9OQALRgMYwyNweWsz9qGpkNE7ig4BNDnMYhO5jdswHfFS?= =?us-ascii?q?PcgXZ3ZRazOo9Rf2V8Nagl1Na62T6IkhfBHNnwsuyFyB2o=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AWqJhNqBjMDjWVvLlHegKsceALOsnbusQ8z?= =?us-ascii?q?AXPh9KOH5om52j5qOTdaogtSMc0AxhKU3Jmbi7SdC9qADnhO5ICO4qTPSftW?= =?us-ascii?q?jdySuVxe5ZnPbfKlHbakrDH6tmpNldmqVFY+EYbmIKz/oSgjPIb+rIqePvmM?= =?us-ascii?q?zG64auqgYIcegpUdAe0+4QMHfGLqQcfng/OXNNLuvn2iMxnUvaRZ14VLXcOp?= =?us-ascii?q?ACZYL+Tj/w+a7OUFojPVoK+QOOhTSn5PrRCB6DxCoTVDtJ3PML7XXFuxaR3N?= =?us-ascii?q?Tnj9iLjjvnk0PD5ZVfn9XsjvFZAtaXt8QTIjLwzi61eYVaXaGYtjxdmpDq1L?= =?us-ascii?q?9qqqiKn/4TBbUr15rjRBDsnfIr4Xi67N8a0Q6l9bZfuwq4nSW2fkNmNyMLv/?= =?us-ascii?q?MrTvKQ0TtTgDg76tMV44vRjesjMTrQ2Cv6/NTGTBdsiw69pmcji/caizhFXZ?= =?us-ascii?q?IZc6I5l/1RwKp5KuZMIMvB0vFqLACuNrCU2N9GNVeBK3zJtGhmx9KhGnw1Ax?= =?us-ascii?q?edW0AH/siYySJfknx1x1YRgJV3pAZAyLstD51fo+jUOKVhk79DCscQcKJmHe?= =?us-ascii?q?8EBc+6EHbETx7AOH+bZV7nCKYEMXTQrIOf2sR62Mi6PJgTiJcikpXIV11V8W?= =?us-ascii?q?Y0ZkL1EMWLmIZG9xjcKV/NFwgFCvsurKSRloeMM4YDABfzAGzGyfHQ18n3Kv?= =?us-ascii?q?erLcqOBA=3D=3D?= Received: from qdec94.de.t-internal.com ([10.171.255.41]) by mailout41.dmznet.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 07 Jan 2022 09:03:27 +0100 IronPort-SDR: tbvuJXYwHJbLH+MfJ6WL8AzQGq+he8+s2FI2lZ0XaKM2Glv7D52Cej9y4B8gWQPocNJmCz0zfV b9vJ2Cey5kPzHWFZ0dvLB5YISXSRdZUr8= X-IronPort-AV: E=Sophos;i="5.88,269,1635199200"; d="scan'208";a="465131673" X-MGA-submission: =?us-ascii?q?MDHIHRyr694gEP69AvcUxQ6KF0ZSo7njTnzMA1?= =?us-ascii?q?bry5jus0XjUrZ30g5mzu3RPiquuhmxm1T8A3m7wIPv8MOztuX4mYieYs?= =?us-ascii?q?POaHbfUQwSoeA3bJMwAtMKssyi3YPoDk+L86jFXwX1cxwF9A/PVwZaTU?= =?us-ascii?q?LnJgE0cFB/z2g04lvNVNTaiA=3D=3D?= Received: from he105717.emea1.cds.t-internal.com ([10.169.118.53]) by QDEC97.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-SHA256; 07 Jan 2022 09:03:27 +0100 Received: from HE105716.EMEA1.cds.t-internal.com (10.169.118.52) by HE105717.emea1.cds.t-internal.com (10.169.118.53) with Microsoft SMTP Server (TLS) id 15.0.1497.26; Fri, 7 Jan 2022 09:03:16 +0100 Received: from HE104164.emea1.cds.t-internal.com (10.171.40.35) by HE105716.EMEA1.cds.t-internal.com (10.169.118.52) with Microsoft SMTP Server (TLS) id 15.0.1497.26 via Frontend Transport; Fri, 7 Jan 2022 09:03:16 +0100 Received: from DEU01-BE0-obe.outbound.protection.outlook.com (104.47.7.175) by O365mail06.telekom.de (172.30.0.233) with Microsoft SMTP Server (TLS) id 15.0.1497.26; Fri, 7 Jan 2022 09:03:15 +0100 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IgRYIeKauZ4NglYn1QOp5NpLvQpcFDYVMfeqE5qYXlAa5hLdrQFbg37Y6ImRSaYKIdSVF6XouquXllmuzfRUxb3ZeFNIRQJPsGQ8bc0j27ONl0P3HYvmc+02Unxl6d59Y9aJ58Dy76+IQZ3WyCwjikxiqh1Qz5He+WPYehCQ+Q5Zg31tQyB31lCV1bPfXH2oCWEwMUO7v3fnXKSynOfp3M4ANF+paZ8Aa4BSKLsmWpWCpGZN+5wue5RE5giawVqnAub5VtBVHEQpnQcKJQD3Vch/DHrdIa1zdz9ZfSoM4vlCIIZ/TJXped7q8GmOadPHWvk/8SQ4fv3shyjK20iFSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=pAlm9DVr+qVQLVxHqCBbit0Grex0Rajj1r7dDRaqJSA=; b=ESgGgUuNBJ2hrsbN0lsZH6Z6LCSubFqMcy8xyIpVUpOY3CjnXPKEii/DsVWPEBxstsKPJYpJcsoPlIUg4XbllOEJ/fekCerg5biZRDGIljRdAbrV09sE1VPDGHFbOJg/ootsdmrUrZq9iDSNifXafXf9wSqyYP/x8IX0rtLj1Tocil3PmmuE6ZGDn+Y5RSShgJWn4Z4RIMhVGMHVRsaEaYXUG/PZbug2GHB1w/gGFLeqqd09qEU2mSO9JpdrpU8KCFDvePYF/T2cozSkSw4yDtEx23MNRLISFBXBgpApzETIpBbqylF5a+NsE/V6GNu+AYeqq/jbgxHDWnYDnqb3uQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telekom.de; dmarc=pass action=none header.from=telekom.de; dkim=pass header.d=telekom.de; arc=none Received: from FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:2c::12) by BE0P281MB0289.DEUP281.PROD.OUTLOOK.COM (2603:10a6:b10:11::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4888.5; Fri, 7 Jan 2022 08:03:15 +0000 Received: from FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM ([fe80::b811:77c:d23c:7437]) by FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM ([fe80::b811:77c:d23c:7437%6]) with mapi id 15.20.4888.005; Fri, 7 Jan 2022 08:03:15 +0000 From: To: CC: Thread-Topic: [ippm] Adoption call for draft-cpaasch-ippm-responsiveness Thread-Index: AQHX9eNXsV8B9xesLkOl2yRH9CQSPKw73AzagAPFj/CAFwCegIAApgeQ Date: Fri, 7 Jan 2022 08:03:15 +0000 Message-ID: References: <7874DB5E-8408-413A-8DBA-F78A1D6284B7@apple.com> In-Reply-To: <7874DB5E-8408-413A-8DBA-F78A1D6284B7@apple.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=telekom.de; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a1faa6cd-4eef-4e0f-17c2-08d9d1b428c2 x-ms-traffictypediagnostic: BE0P281MB0289:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JHlitkBfCrRpRHg3xlD2jks74Wf8nKMbLaBGF4p2N9AOualM3cqL5WUR20ygtxN2zWyJ98p4zimN44G+8Czsra+zYbcUEFZyDHy7F4POKvzCTVMkK0snZmm2RCkA6GOsDYMncec1aHvLKXryF6xCOyOh5QWXhfWjMQK9US2da4xDGf9za6qD1FqDtTChF5QqhbsRq+eoWaWIkpngDMO5G4TTiZILyxDlfgmfE7BzWNyaut1/M1XaoD4r0flzfPXiVgMRpo0j6/AMGlM9ON6R/xrGKcxCKAMqCVe5p2DMUtL+BGdY6azZJX8q0F9jSSLPkhMPI69yBRxKEUdbVho89lizzBaX5KocRFN3IR0uLBQxgs3dGOI7saqTRfZKsOyMdphc4NNBfQ9P38FIhV1g8Zg7kgrdcUESBcPHoi9n2r7EH11bIly0e/gHiMd8KuAeR3rotWI0IpGh+KoZqhlmCDjk98E9wPssbkFVKhmsv/lEG5fIUI9B3aGCVwTueVXPphQQORPjPN9RC4YqV+8t23KshzYxNEHbjJn4z0uRNPj7RFaPReEJMgOF50D/ONAdJL13+Ku7W+Z1O++bHDTRsYek1kt6VKsE5apCGBfbMlzF+SIZWOCnmgXKvjC2GlB7KarAu3xEQ6xyNcVDcoWYJI6uv+hMiRz3xbyzF18TXSZk6fNMWmTX6ed/1I4PVmG76WqD0CSbKxTYPzjyVpz+1A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(38070700005)(26005)(2906002)(186003)(55016003)(38100700002)(122000001)(86362001)(82960400001)(33656002)(71200400001)(52536014)(6916009)(83380400001)(76116006)(316002)(5660300002)(6506007)(66946007)(8676002)(53546011)(8936002)(4326008)(66556008)(9686003)(7696005)(64756008)(66446008)(508600001)(66476007)(20210929001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?CAx6LdmSbFfuFIzis2oQHTXwauihTQTJSPVL1jFntaGLJOmw6iuGFm9lOE?= =?iso-8859-1?Q?qdqFkoWOQxBoY90GJNTicW0AgyEFIM+Lo6zueYF4qbyiyHnjeNkVPQTCrW?= =?iso-8859-1?Q?soVXwYOMMc2to2uPVnmeDHystpSxw7QUNPr7NOgN6YiBJu8t9jXii86PDq?= =?iso-8859-1?Q?oNsCqGrWsLnKqu+vv/2caqRUwYHLrICcFXyTLenUZ9PUsOF3Fc3j6fyZjG?= =?iso-8859-1?Q?jEmeOKLDnPqsRrsNQpID+JStpSwxP8HFViGyX0xxqRMFTZiEFD8imMJsiF?= =?iso-8859-1?Q?EzAc2Ln85P7oJyVDgVdI6IjuNMaBlDhDQ2ZEIcH2Q1zOVv8NiCPfVT339d?= =?iso-8859-1?Q?UhgEObvQ/KZAEwVfiqXo1Z5vIoTIxq8v6BuAXjywaRbw4eTG3JCn/PcVkc?= =?iso-8859-1?Q?1hjpp7GzIpwOgsq97/cnuc+xMSi58cFq+OICO5gawdfErJ4tbGlYvtuxww?= =?iso-8859-1?Q?89EM+TnNH1LoncZPWQLaESw3IhBaDaWiNRMg8oJT6jiHgoa0FBYoEYg8fr?= =?iso-8859-1?Q?80N67Muo0MgFTOrD6e81nKd1HW692+pQgkgofy3zd/TiSQzrNoEvMnEKD8?= =?iso-8859-1?Q?pM0f25X0h7qWslg1kVli9pj5bnoui48JiWn0SW7uXKsCUDg0/pUPLnghaX?= =?iso-8859-1?Q?9bQgC1PflKlhDv+ddKAhC4vBLBxTk2GjqyCBd7J2O2ET9urIOlpXOTUljg?= =?iso-8859-1?Q?FcMF4lT3EPGmRZECHpyzRQdftrdX5csIOoa4PG5mcie+pR8B0nWRnNBW6i?= =?iso-8859-1?Q?nmK/Y9TQXzAlCLL1nmPl9vjo20IG89mm1ZtdjNwWtyxsszp5HJaQM3mAK6?= =?iso-8859-1?Q?LxE9iWEn40wWYDZCrrJrBjGo9Z2Fv7Du3QaYE1G1XJ896qlvkCMSBceApl?= =?iso-8859-1?Q?k4OmosnF8KboagaOVGdWFv2xKa7bXm/YJ//EjVYqR9DGiHkrvVmL43R84F?= =?iso-8859-1?Q?7dZ5i9gHC43Wd/arZKLhvM/VmV9P4y/UOjA02EOqTWaB+DeFPmxxMVi6ry?= =?iso-8859-1?Q?hEw+5hAFWecWEuEBcDkSFhFv0eRodGov0M+mzI0BML0B4LNsbs5alqATdj?= =?iso-8859-1?Q?koTpa+dWmdDfUJ46ixT1FRDrAFNA5+vjlgyZOIF93SfbHZZKUa5OvyPj85?= =?iso-8859-1?Q?+LWoN6I1DBaUpREed9CspoVFarvqcFc5iDuY0fXV9EVMXJBoiT/yHsVfsu?= =?iso-8859-1?Q?dQa7Qy2TJcMLnv/rKIBUKQnGeZ7rqtou7C3Z7bnT2isniRZupUVqak+5s1?= =?iso-8859-1?Q?mw4f9De6NeJEuw8Hqv1RHXrAITPouhDRILnnHdrgBpqsLPIA9DtWLFM1DS?= =?iso-8859-1?Q?It0nHW4VHA70riQ3usydSDJBBNzW6zJIfBxgmm+NM0VX57j946zT9YhhrW?= =?iso-8859-1?Q?sVBlAUtsp7jHQp03PTBUtPRA9X66OUYH3aS031jJUnjdcwo+4FNq7FVLAO?= =?iso-8859-1?Q?OIIVj5TE5qx6S8fQ5mCr3QgmXkka5qufXmaUe+kCNONgop9iCJOiPClA5x?= =?iso-8859-1?Q?dCgM44W2mPS0FqtyxVx+nShfY9zaQaK0PkMifIU+JnBykZZMIA+9A0qz/r?= =?iso-8859-1?Q?S/3g2c+cDB+I508Qi0Dvs9c2tPfqvitvXyRBoQ8Yrr/INO2NJE9nz2GKOo?= =?iso-8859-1?Q?Smr/ag5JJ/4JFW/XcHBFHKjTg4aj0/nvYawd2bVttJdatrVjg6t2LZfCLT?= =?iso-8859-1?Q?29SEXVBx71K9iC1rD2Ga2i2u4TD01JGCF0e2dlalDYDafZWo241F/OVS6W?= =?iso-8859-1?Q?F8Yw=3D=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: a1faa6cd-4eef-4e0f-17c2-08d9d1b428c2 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2022 08:03:15.6669 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pOi0nFoKd3btEg4O9U4ZCfVaDoctTESdJhkyjKxIAPxPPsBcPBeFrYFlJB9hN/1LBd65OtkPoeEP736CSGjE6LbJwLW/Ve2NcyfgzkI4gSQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BE0P281MB0289 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [ippm] Adoption call for draft-cpaasch-ippm-responsiveness X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2022 08:03:39 -0000 Hi Christoph, Replies marked [RG]... You wrote: ----- ----- Hello Ruediger, thanks for your feedback! Please see inline: > On Dec 22, 2021, at 11:16 PM, Ruediger.Geib@telekom.de wrote: >=20 > Hi Marcus, >=20 > Noting that some more work needs to be added, I support adoption. >=20 > Some comments: > - I'd appreciate if the draft was covering expectable operational scenari= os, namely > * There may be no bottleneck buffer - the test/metric needs to detect th= at and act appropriate. I'm not sure what you mean ? Every flow is limited by some bottleneck that = sits somewhere. Sometimes, it's the last mile, sometimes it's the Wi-Fi con= nectivity, sometimes flows become CPU-limited. But there always is a bottle= neck somewhere that is limiting things at which point a buffer is building = up (even though that "buffer" may be just 1 packet large) [RG] 1 packet or 0 packets in the case of policing. There may be drops, but= no added delay. I'm sure, that this will occur someplace in one direction,= whether this condition may affect up- and downstream of the same success, = I can't tell. > * One might be interested in the metric while the test adds an insignifi= cant load only. While receiver tries to consume service X, what's the metri= c seen from Y?=20 > (may help to clarify, whether the access causes trouble or another ne= twork section). That would indeed be interesting for trouble-shooting and debugging. I beli= eve this is out-of-scope though. [RG] If this draft isn't about trouble-shooting and debugging, what is it a= bout? Please mention that capturing above metric is out-of scope in the dra= ft. > - Measuring the maximum RPM as seen from the test server is part of the t= est or it isn't? That's not clear to me by now. > I'm favouring to make measuring the maximum RPM part of the test, this m= ay help to scale results. The methodology defines to only measure from the client as we are intereste= d in responsiveness as a metric that is (as close as possible) representati= ve of an end-user experience. When you say "maximum RPM", do you mean that on an "idle" network? [RG] Thanks for asking. Likely "idle network": the maximum number of RPM me= asured from the client if there's no load on the access. Once these are kno= wn, one can relate the minimum number to be measured by design to them (tha= t's a ratio, if my English doesn't leave me). > - The test set-up should prevent application as DoS attack tool. The json-fetch at the beginning of the test allows server-side CDN deployme= nts to "rate-limit" clients by simply delaying the response to the json-fet= ch. What else do you have in mind regarding a DoS attack tool? [RG] Spoofed addresses in any direction, unexpected messages, undesired aut= omated activation in the background of a client.... ideally, there should b= e no possibility to activate such a test, if the client doesn't want that e= xplicitly. I've also proposed an "emergency stop" for load tests for the ca= pacity measurement metric, and I think such a function may be worth a thoug= ht for all kind of tests aiming to fully consume the capacity of a bottlene= ck. Regards, Ruediger From nobody Mon Jan 10 07:57:11 2022 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC8A3A1369; Mon, 10 Jan 2022 07:57:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ippm-chairs@ietf.org, ippm@ietf.org, martin.h.duke@gmail.com, tpauly@apple.com X-Test-IDTracker: no X-IETF-IDTracker: 7.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164183022807.25033.5288513689101061812@ietfa.amsl.com> Date: Mon, 10 Jan 2022 07:57:08 -0800 Archived-At: Subject: [ippm] ippm - New Meeting Session Request for IETF 113 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2022 15:57:09 -0000 A new meeting session request has just been submitted by Tommy Pauly, a Chair of the ippm working group. --------------------------------------------------------- Working Group Name: IP Performance Measurement Area Name: Transport Area Session Requester: Tommy Pauly Number of Sessions: 1 Length of Session(s): unspecified Number of Attendees: 40 Conflicts to Avoid: Chair conflict: quic taps add masque webtrans iabopen privacypass Technology overlap: tcpm 6man spring Key participant conflict: bmwg People who must be present: Alfred Channon Morton Martin Duke Frank Brockners Greg Mirsky Marcus Ihlar Tommy Pauly Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Jan 10 11:10:23 2022 Return-Path: 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 4B7583A0B14 for ; Mon, 10 Jan 2022 11:10:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.675 X-Spam-Level: X-Spam-Status: No, score=-2.675 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHSXj_HPdJGH for ; Mon, 10 Jan 2022 11:10:16 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on0617.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0e::617]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 432FA3A0B07 for ; Mon, 10 Jan 2022 11:10:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EipXjUz8SJutG/o412FKL4KplNK5sLG3PggVjxDDNrfr84T2h6k+XPwmNVdYApSovvN6155jic6fMhqDcO4tI9yxMWTjeqLaO2CSS/RKpOclZrbirm8r2raaMB6cvk6sm/lzHK770NA/Uw5TnMZA1K2g3XfbYfXYIMG1q/HFKmaL7KBP+dEsNSLIq1DCrrGWLxD2dbBSrIpXh3ApXpFeJpv/e9WCmdsTL4ZBdcbh5z5kX02cH5ihgyc6PMuzY8B2ZBcaDJ7y55dHXefWtrIAxzUyV4X4eCms5ugo+8HkRl8QdkyVlbetrucQOT6407yM9hTPHSPRlND9W/X2zwtn5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=i2Mq3/6ooZCV60Hejs4BX053GbsN8GapqJkd/LF9sSo=; b=MtSWWNkSPlVf6m6vJl4Fu/L5QmoOSdIGaIitPeCCvDMYLuTNLipiy++/LQoNuWFQaMf0XNZYQh8s2ZZ6CDebt2McNuuGUzrNUiMeCWs++cuTyLIjqa+YvMUB4Igq9lnop1K5/rvEsEB6GAuubLeuci0VA6R9TXNQL1uB0+kgdMTo+3spBmxnv61Vs61vzasWFlrubZpBpEPdIzUUMKRh7yS+jp625dZZbzGcz/7VAHibhjWqQ3ejYN6FU24/j0JkGh/ZPe4b5z2Dy3nqTLV1NloEtWxXE1GIzdQsyOIboZScdzdDrD6ZBYIhqiS2eH7pb77JS0I6DKVP38ICNvBPVw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i2Mq3/6ooZCV60Hejs4BX053GbsN8GapqJkd/LF9sSo=; b=evOdMS6t/wH9P6usMM3gRuLfB3k7I1LB8zIVrUs1HiiCQBlHlCNbE9ZnAOkD+fdXjGMD3Xlt11w2F2uyVB2KX/f0CXYWr1zkkvyV7Zpso6GczcJofg/Hg9r5x827tnppeUlUaFs/u/fldUkBe/VcA+rLO6YYLMAyTfvHzc/rJhw= Received: from VI1PR07MB4142.eurprd07.prod.outlook.com (2603:10a6:803:35::30) by DB6PR07MB4150.eurprd07.prod.outlook.com (2603:10a6:6:4b::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4888.5; Mon, 10 Jan 2022 19:10:06 +0000 Received: from VI1PR07MB4142.eurprd07.prod.outlook.com ([fe80::3dcd:27d6:61db:1a86]) by VI1PR07MB4142.eurprd07.prod.outlook.com ([fe80::3dcd:27d6:61db:1a86%6]) with mapi id 15.20.4888.008; Mon, 10 Jan 2022 19:10:05 +0000 From: Marcus Ihlar To: "ippm@ietf.org" Thread-Topic: draft-morton-ippm-capacity-metric-protocol Thread-Index: AdfquL0WtV/2rjPHSECEUqMgTJWSZwbnODcQ Date: Mon, 10 Jan 2022 19:10:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 80d03f7a-9cf3-4bce-1a52-08d9d46ccfdf x-ms-traffictypediagnostic: DB6PR07MB4150:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: c/tPas9kN3nBcImBbPPYT8SNMPnwBxwxasygQE1qfJ73Z7Z3dgjlwB368meGZDjyfnrc6fjArRmrZmJig/Y63vgOc0oVvFTov8NbcKd4FLZIrrVbuYlyJtolQaFyLyYSpE1BazbItRnr+VXkSMRFzmpUPKL8rVWyywfKrXj8QK15tsrpzhTRpV1a+M+FlsJ1eozs4i+bAomsbE7YNxuhJn5wRi1X9glBNpnq1s+hVpx0bBBF6ztZ+k0KnuQdlCLa49PoGAiZKA/WoK2FLHYcTj2eJITak5KRzTLIw3PLX5OZOAtqZEU2FdSkN+TL0KRrfKATDUDYmj2MmlPNN5Z3VAg/gsYruS3TfxA8a++If4yuQ9Qxw84KG1UEjDhPdrr8Ok1g8I+erPfNIFOqemtyMaSLsTrv1AFFHMAVhCYe6mlp9b66DwiK7vriYkVGNlMnDdohe3iYGryr1KwPY7wT99Tszz/rLCtHyo6eP4lsk4PFDUaksTzh3XYxQ8kzZFndtWUAgk60ajVsqXzIV1jufP/c5ZuNrcI4H2FboxOBxU0MHuSR+jMhpey2bTCA4VaOB63ubNdYOOh8Oo8BjS2A2ZcpUgjnP5vun8qM2IFO+YHxKJAi++hBeYefjFfYP3FiXfh7ylfJZKoByizonFPglxD+merA2V9USo/+5rp9U/qGIn0Wf4+KxRfpDw5sxwP5k9pdIo0HYSQ7qCfI2rKxLkBMK17bse0wA8kZhFVA7yNM1Umto8M64Een7kz3cx00NpHYm0BFc5WFssXamFHhh3OoQE+IkNCi+qNE+uOtW7kk1Bx5fu33FfH/UjMH3Q3JXSrrWnbzZy2QAOL04kFtKXdKrBzyjiadeQHRJaRQusAQhfZK98qsoxjCyTJHu2FD x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB4142.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(4744005)(5660300002)(166002)(86362001)(44832011)(38070700005)(2906002)(52536014)(122000001)(38100700002)(82960400001)(9326002)(76116006)(9686003)(186003)(26005)(316002)(66946007)(6916009)(53546011)(508600001)(7696005)(6506007)(71200400001)(8936002)(966005)(66476007)(66556008)(64756008)(66446008)(55016003)(8676002)(33656002)(20210929001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?eGJv4e7e0u3y133TJjioMmEIyk8un7Wo6CeXLFKtfke6lc1Z3WmVumpMVzOV?= =?us-ascii?Q?U5J+CVNEHbEIdglzqIyDQRXPXu2/LTmaKBDHLwRdN+OCy02rd7uMwqjp1AHr?= =?us-ascii?Q?x8WqmtN2e+xKdNSJSGL1UTWOnlH4PUl/HD7o/Jo+n5eamdgPKJscqriWOptq?= =?us-ascii?Q?QhHG6L9iTwEOjdpnFkILqJDuExLZWvkpmkKPeLyRb4nbNkiRNG9mR68gDkxg?= =?us-ascii?Q?j6A9+NOcSVqG0dgXqbmFQpnXj074EZ8b4Cf/9elVdoqBm4bSRxB/n+lZy75q?= =?us-ascii?Q?FzCr8Dy6vVVa/EQb+smTPnywZFNon+DAIR6znxd8UEJ/hELwOBw4QZe8O53s?= =?us-ascii?Q?fHv0S+ga1ijglp+HyxkOQY6OY6o0KhZ0Wlp8WfwtGhA6dYBD6OFSbI/sNul7?= =?us-ascii?Q?/tbZNPvaRLb6FeGItJB1D3Jg6o9LjfnY6DxxLjZOqDdE58gHg4PHNTunBy0x?= =?us-ascii?Q?+EQXa2pBVCBfXBmF63P7gROV5V2TDWZ8dey95SfAUYxEB5aSY8FcWj6f2Vcf?= =?us-ascii?Q?crnbTf4+eM2kc/D5OzQgGVrlDFfADhipPOCGTyt35RK+kMfvrMlY/gB+xgU2?= =?us-ascii?Q?IuYZaen7xIdWzXPNoPWekaiyqLTlCHiOurdTy+OVVmbzhDSmIqkF6Z2+G6Ru?= =?us-ascii?Q?QtzlNrbOi3idRa3WucRs5Xq/LLSRa+x/VF0wj08/UEPhKpBcgTBtlnKdMuoi?= =?us-ascii?Q?vvzSOWmMgLw9O6tvmTfFCgF3e8BZLs0iL+nwbJufuNG04ur0bTsyz6pFDQQJ?= =?us-ascii?Q?3b2GYAuq5qUQISPaGHxd/cTaReVY0Vh+8zKzHYQ9SrQW6FlMLYG47PPE330t?= =?us-ascii?Q?AG2EOw5yPQpxWET2WByAWc6wP0EnAVEwvBe6pD5C2H+MUErMw84nJHgNsQHc?= =?us-ascii?Q?C9kaOlppZTpATkDH6nu3IIcuCzY5pA3BT+Yix7AOeowH/CALcMvpk+JhF+k3?= =?us-ascii?Q?pTjBiH3zciOPuO0V1HxGgQTPBRMFCzw3Oif7kJQeQVkvX8swRegtBCS5DYHg?= =?us-ascii?Q?2k4NOnSM42t5zeAhBBJeh967bSpb3ZWoXwDAb3akis4MCqjXWvCIq/KyYomQ?= =?us-ascii?Q?roc5u2RYpVYD/1Cr3TYcflr0o6z4nviLrGwUhZpy5LDeuo1PeIB7wwxNZtQL?= =?us-ascii?Q?6Fq15jv1UGX/kagEbIY8wPf+ydZGYxTl352tcRzsn+pnUD8Txf00FynWSDvO?= =?us-ascii?Q?ylazL9n2fArqAyM1oNHZ/4pKTwShW0t//Gvk/60lUbZkXwYDrx4Rgi+Ty2sZ?= =?us-ascii?Q?aXuKUmxq9Ng4LDLaJvjZ6aMo0Xj3EQWMf/IcofsEQldqGGxC+xECdLpVExkI?= =?us-ascii?Q?SRyuhYq8k6R96n897k3bfE8hpsO6Q0t3ghwHkuPeFXxF9wkiHedfE55JrJjo?= =?us-ascii?Q?+zdK/Flt/6s+nWHBlDto2LTvJcqAN6Q8UP+rJ8XyAj+eW4DXOOA5YyW8pLuC?= =?us-ascii?Q?IEwf2+3wBlsacGeuBl3Vyz8sodPgb8k1LzOiG8g++rs6neLl8ik43/mHcFat?= =?us-ascii?Q?3S0jSLeDHHm9TTaAfJdr347L4AQa1vzjMk5cbu1mLT49qHIVtPG2Jf/h3GIv?= =?us-ascii?Q?clH5PYv0pAK58pbH5ykQkCGMwh5ugu1YOeQQjNGT9JxSyLYO94q+53yIADel?= =?us-ascii?Q?/TFo+OdPUCgMi68GMBiRJnQ2o7pVQ+2VWepCDlcy/cd0gUnyHkzhlOq37K8Y?= =?us-ascii?Q?GbQvlg=3D=3D?= Content-Type: multipart/alternative; boundary="_000_VI1PR07MB41427837B59C71C8622262FDE2509VI1PR07MB4142eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB4142.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 80d03f7a-9cf3-4bce-1a52-08d9d46ccfdf X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2022 19:10:05.7747 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 86D79PeVytH/O6oyACfF082n5Uhf9m6A1RwYw6UZj1EgcsZkjt5/5RwW664dbn30xYOcM0UVh6xG3FT9FdFQj5+MrvzSzeVHSn+FHEBfFBA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB4150 Archived-At: Subject: Re: [ippm] draft-morton-ippm-capacity-metric-protocol X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2022 19:10:21 -0000 --_000_VI1PR07MB41427837B59C71C8622262FDE2509VI1PR07MB4142eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The adoption call is now finished, the chairs believe there is working grou= p consensus to adopt this as a WG draft. BR, Marcus and Tommy From: ippm On Behalf Of Marcus Ihlar Sent: den 6 december 2021 16:53 To: ippm@ietf.org Subject: [ippm] draft-morton-ippm-capacity-metric-protocol Hi IPPM, This email starts an adoption call for draft-morton-ippm-capacity-metric-pr= otocol, " Test Protocol for One-way IP Capacity Measurement". This documen= t is intended for Standards Track and defines a protocol for measuring Netw= ork Capacity metrics defined in RFC 9097 (https://datatracker.ietf.org/doc/= rfc9097/). https://datatracker.ietf.org/doc/draft-morton-ippm-capacity-metric-protocol= / https://datatracker.ietf.org/doc/html/draft-morton-ippm-capacity-metric-pro= tocol-02 This adoption call will last until Monday, December 20. Please review the d= ocument, and reply to this email thread to indicate if you think IPPM shoul= d adopt this document. BR, Marcus --_000_VI1PR07MB41427837B59C71C8622262FDE2509VI1PR07MB4142eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

        Hi,

        The adoption call is now finished, the chairs believ= e there is working group consensus to adopt this as a WG draft.

         

        BR,

        Marcus and Tommy

         

         

        From: ippm <ippm-bounces@ietf.org> O= n Behalf Of Marcus Ihlar
        Sent: den 6 december 2021 16:53
        To: ippm@ietf.org
        Subject: [ippm] draft-morton-ippm-capacity-metric-protocol

         

        Hi IPPM= ,

        &n= bsp;

        This em= ail starts an adoption call for draft-morton-ippm-capacity-metric-protocol,= " Test Protocol for One-way IP C= apacity Measurement”.  This document is intended for Standards T= rack and defines a protocol for measuring Network Capacity metrics defined = in RFC 9097 (https://= datatracker.ietf.org/doc/rfc9097/).

        &n= bsp;

        https= ://datatracker.ietf.org/doc/draft-morton-ippm-capacity-metric-protocol/=

        &n= bsp;

        This ad= option call will last until Monday, December 20. Please review the document, and reply to this e= mail thread to indicate if you think IPPM should adopt this document.<= /o:p>

        &n= bsp;

        BR,

        Marcus =

         

        --_000_VI1PR07MB41427837B59C71C8622262FDE2509VI1PR07MB4142eurp_-- From nobody Tue Jan 11 10:59:11 2022 Return-Path: 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 E84EE3A07F0; Tue, 11 Jan 2022 10:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uliege.be Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFtZJlStFVtp; Tue, 11 Jan 2022 10:59:05 -0800 (PST) Received: from serv108.segi.ulg.ac.be (serv108.segi.ulg.ac.be [139.165.32.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72EE83A0802; Tue, 11 Jan 2022 10:58:47 -0800 (PST) Received: from mbx12-zne.ulg.ac.be (serv470.segi.ulg.ac.be [139.165.32.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by serv108.segi.ulg.ac.be (Postfix) with ESMTPS id 2BF48200E7D1; Tue, 11 Jan 2022 19:58:45 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 serv108.segi.ulg.ac.be 2BF48200E7D1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uliege.be; s=ulg20190529; t=1641927525; bh=Br1WgSqvbW/B/cw8DLrhEm1qUweoJ8s/nbrFQ3aclh8=; h=Date:From:Reply-To:To:Cc:Subject:From; b=SlsMhryMcCp+MFaTSekrEuhAp8vf262ujLlHqBZI4fQnyQB+OuZoQNpBQqTQpqHp3 69eeilXkChgPolwayCFies6Ia9hgVxZlUVMGeVeDGfJo6lLC7MOJD+6zaPkli8X/Ii fc5ALDpdazn8R4zM7gMY5vNSO60FQ3NYf7/EnxSxT8+zrb6Vg+M54uwVhHIFRMoRQS 3Ub0llW+8Gq+tcNem/2pTC1aSz1QK4ncBYv2Th2RHtoQZDy2uK9Xyi/eWr1wfXoYEy m0Jen22npNKgolwUsStybBE1nHdSgs2YkHsQFj1koa96XzA2XnfkwKBuF7y5RRFqxD nsN90cpDRcKgQ== Received: from localhost (localhost [127.0.0.1]) by mbx12-zne.ulg.ac.be (Postfix) with ESMTP id 2674F60415BEB; Tue, 11 Jan 2022 19:58:45 +0100 (CET) Received: from mbx12-zne.ulg.ac.be ([127.0.0.1]) by localhost (mbx12-zne.ulg.ac.be [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id IZTJRex08BUT; Tue, 11 Jan 2022 19:58:45 +0100 (CET) Received: from mbx12-zne.ulg.ac.be (mbx12-zne.ulg.ac.be [139.165.32.199]) by mbx12-zne.ulg.ac.be (Postfix) with ESMTP id 138BD6008D415; Tue, 11 Jan 2022 19:58:45 +0100 (CET) Date: Tue, 11 Jan 2022 19:58:45 +0100 (CET) From: Justin Iurman Reply-To: Justin Iurman To: ippm@ietf.org Cc: draft-ietf-ippm-ioam-data-integrity@ietf.org Message-ID: <2064022850.261351660.1641927525018.JavaMail.zimbra@uliege.be> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [81.240.24.148] X-Mailer: Zimbra 8.8.15_GA_4018 (ZimbraWebClient - FF95 (Linux)/8.8.15_GA_4026) Thread-Index: PflMqkAsq+YH5JjkbuCX083ZTm6Z/Q== Thread-Topic: draft-ietf-ippm-ioam-data-integrity Archived-At: Subject: [ippm] draft-ietf-ippm-ioam-data-integrity X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2022 18:59:10 -0000 Hi all, On behalf of the authors of draft-ietf-ippm-ioam-data-integrity, and as a new co-author, I wanted to share a key question that arose when working on the next version of the draft. Hope we can get some feedback or advice. Currently, version -00 specifies that not only IOAM data fields are protected (i.e., signed) but also headers (both the IOAM Option-Type and the Integrity Protected Option-Type headers). Headers are signed by the encap node. It is indeed the most secure and complete solution. However, some header fields are updated in place between the encap and decap, which makes it impossible to include them in the signature or the validator won't be able to recompute it. For instance, as defined in draft-ietf-ippm-ioam-data, it is the case for the Trace Option-Type with its Flags field (especially the Overflow bit) and its RemainingLen field. The problem is potentially equivalent for the POT Option-Type and its future "Flags", depending on their definitions (note that the Cumulative field, which is a data field, must be excluded no matter what, for the exact same reason as mentioned above). Therefore, we can think of two solutions, although solution #2 would have our vote. Solution #1: include headers in the signature, exclude header fields that are updated in place. * pros: - some header fields are protected. * cons: - requires to define which fields to include/exclude in/from the signature, and so for each Option-Type header. - more processing due to non-contiguous fields to include, potentially. Solution #2: exclude headers (both the IOAM Option-Type and the Integrity Protected Option-Type) from the signature. * pros: - avoids cons from solution #1. * cons: - headers are not protected. Based on this tradeoff, we'd go for #2. It actually makes sense, as the draft is about "Integrity of In-situ OAM Data Fields". Of course, one could argue that some header fields bring context to data fields and, if altered, could potentially trick nodes on the path (e.g., Namespace-ID). This is true, and it's also exactly why we bring this discussion to the list, so that we can reach a consensus on the best solution to adopt. FYI, draft-ietf-ippm-ioam-data has a section which states that in case you're looking for integrity protection, you can consider the data-integrity draft, or rely on the encapsulating protocol. The latter is therefore a solution for #2. Thanks, Justin From nobody Wed Jan 12 11:48:39 2022 Return-Path: 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 A5A3A3A1A7B; Wed, 12 Jan 2022 11:48:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.673 X-Spam-Level: X-Spam-Status: No, score=-2.673 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygM0H3oZEEQc; Wed, 12 Jan 2022 11:48:33 -0800 (PST) Received: from rn-mailsvcp-ppex-lapp24.apple.com (rn-mailsvcp-ppex-lapp24.rno.apple.com [17.179.253.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A21A3A1A79; Wed, 12 Jan 2022 11:48:33 -0800 (PST) Received: from pps.filterd (rn-mailsvcp-ppex-lapp24.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp24.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 20CJj0G9029634; Wed, 12 Jan 2022 11:48:31 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=noVFtfyliV328UPcZgsXqcn1gTVlUZmOhVgcHF6UKKE=; b=V52e5/hUtqkDKNSitvDFuLMy6n6Ek5xpZh7ykFzGkomikvgT64CotP+269zchGI0i3QT rb5PO9GGz3wsTZRZnVhgyrU8C9h6rDV0/HwGBApGw16OaG7FO0N/sYVyDqzxNZJv+uL8 rUR9O6/CYQN/D2qimVWoPhngAGgnX6tkCaxAxMUCKcoKyeJAToUNGXbDbQ0F6yPXdkpp qVF8pxqstes0w4fMWlXgr11FrG9iaPYgJmMrNUn3KzALj1Aboo0uWkYMU0QkNll+FpQc R4dqaxuSSSyS+2rbIbDSQnFcIg9EnwS9WhzCu4rfKNUKJszZCwokLILLv+vq3PK48VCQ vg== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by rn-mailsvcp-ppex-lapp24.rno.apple.com with ESMTP id 3dj3dmsj1r-6 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 12 Jan 2022 11:48:31 -0800 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R5M00CCO4CU8740@rn-mailsvcp-mta-lapp02.rno.apple.com>; Wed, 12 Jan 2022 11:48:31 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R5M00K0045M6H00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Wed, 12 Jan 2022 11:48:30 -0800 (PST) X-Va-A: X-Va-T-CD: e6091e616f2742cf5fde7f1935bb449e X-Va-E-CD: 0bcc6c31f70f3dc7506ef096334b6f2f X-Va-R-CD: d80fc7e42aa726f61d7c73ea7bd4fd87 X-Va-CD: 0 X-Va-ID: 5d0b919d-8a37-45ba-aef8-454d87d16034 X-V-A: X-V-T-CD: e6091e616f2742cf5fde7f1935bb449e X-V-E-CD: 0bcc6c31f70f3dc7506ef096334b6f2f X-V-R-CD: d80fc7e42aa726f61d7c73ea7bd4fd87 X-V-CD: 0 X-V-ID: 6d0915fb-1aa7-4efc-bd06-fd82944442a8 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2022-01-12_05:2022-01-11, 2022-01-12 signatures=0 Received: from smtpclient.apple (unknown [17.11.168.226]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R5M001F44CTGZ00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Wed, 12 Jan 2022 11:48:30 -0800 (PST) Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) From: Tommy Pauly In-reply-to: <2064022850.261351660.1641927525018.JavaMail.zimbra@uliege.be> Date: Wed, 12 Jan 2022 11:48:29 -0800 Cc: ippm@ietf.org, draft-ietf-ippm-ioam-data-integrity@ietf.org Content-transfer-encoding: quoted-printable Message-id: <42B4FB74-4D64-4E9A-A3B2-6E5635CD9B0A@apple.com> References: <2064022850.261351660.1641927525018.JavaMail.zimbra@uliege.be> To: Justin Iurman X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2022-01-12_05:2022-01-11, 2022-01-12 signatures=0 Archived-At: Subject: Re: [ippm] draft-ietf-ippm-ioam-data-integrity X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 12 Jan 2022 19:48:38 -0000 (No hats) My impression is that solution #2, where we protect the data fields = only, should be sufficient to address the integrity goals. Thanks, Tommy > On Jan 11, 2022, at 10:58 AM, Justin Iurman = wrote: >=20 > Hi all, >=20 > On behalf of the authors of draft-ietf-ippm-ioam-data-integrity, and = as a new > co-author, I wanted to share a key question that arose when working on = the next > version of the draft. Hope we can get some feedback or advice. >=20 > Currently, version -00 specifies that not only IOAM data fields are = protected > (i.e., signed) but also headers (both the IOAM Option-Type and the = Integrity > Protected Option-Type headers). Headers are signed by the encap node. = It is > indeed the most secure and complete solution. However, some header = fields are > updated in place between the encap and decap, which makes it = impossible to > include them in the signature or the validator won't be able to = recompute it. > For instance, as defined in draft-ietf-ippm-ioam-data, it is the case = for the > Trace Option-Type with its Flags field (especially the Overflow bit) = and its > RemainingLen field. The problem is potentially equivalent for the POT > Option-Type and its future "Flags", depending on their definitions = (note that > the Cumulative field, which is a data field, must be excluded no = matter what, > for the exact same reason as mentioned above). Therefore, we can think = of two > solutions, although solution #2 would have our vote. >=20 > Solution #1: include headers in the signature, exclude header fields = that are > updated in place. > * pros: > - some header fields are protected. > * cons: > - requires to define which fields to include/exclude in/from the = signature, > and so for each Option-Type header. > - more processing due to non-contiguous fields to include, = potentially. >=20 > Solution #2: exclude headers (both the IOAM Option-Type and the = Integrity > Protected Option-Type) from the signature. > * pros: > - avoids cons from solution #1. > * cons: > - headers are not protected. >=20 > Based on this tradeoff, we'd go for #2. It actually makes sense, as = the draft is > about "Integrity of In-situ OAM Data Fields". Of course, one could = argue that > some header fields bring context to data fields and, if altered, could > potentially trick nodes on the path (e.g., Namespace-ID). This is = true, and it's > also exactly why we bring this discussion to the list, so that we can = reach a > consensus on the best solution to adopt. FYI, = draft-ietf-ippm-ioam-data has a > section which states that in case you're looking for integrity = protection, you > can consider the data-integrity draft, or rely on the encapsulating = protocol. > The latter is therefore a solution for #2. >=20 > Thanks, > Justin >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From nobody Thu Jan 13 04:32:37 2022 Return-Path: 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 2C7FC3A0C24 for ; Thu, 13 Jan 2022 04:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziKiCtSuwwQn for ; Thu, 13 Jan 2022 04:32:32 -0800 (PST) Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC51B3A0BE1 for ; Thu, 13 Jan 2022 04:32:31 -0800 (PST) Received: by mail-yb1-xb2e.google.com with SMTP id v186so14507321ybg.1 for ; Thu, 13 Jan 2022 04:32:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=lW7InyCUtACkUjrOobxNYGW/J7LIDBVGNYblUJFn8Cg=; b=KNgBjk9ynjC8jk+rzQpLjMed1ubN1HTSCiEtSZY1xebqcX1ijn/pebxIYCNTem4S9h yOjXcDdCIqaAV6hN8D1/j1BK6K5tUwB4z+VuNRvU71jkd6n/2RWytRcUMgSTOFR0f30l /CdujdT2UkAhGldSNtjyCX39qu/ZfUMnrKox8/tYCls0ZAYDqqORsF7suHKdYVcLXeNn gbhIUoFtsS/sipEagUF26spYNlFR7JnaY8DfAfdvZuiiCvDDrCf2mMw6/rKhU0GJTNrr gjdo1uG9c/jKDFd99PTAUodogY8YQP/pKoDW40Y8RhKQI0517EtSrKRJWKkQfwNs7W13 tsag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=lW7InyCUtACkUjrOobxNYGW/J7LIDBVGNYblUJFn8Cg=; b=UAjJQw9wAbNEjJY2RzrZ644IqbtsZtXlJyzLLMoglvpfQE+rRtJUQS+wRtmgsk+PXA QVXl2qj8FWkB1QrFIyet3ikPi+ZNEBr6xpfof9Dcbuw4mJrWf6fzTGnnz3cAotwI1NFN rh58eSd94mrOqgq5unK9oo7X5I+ni8PMna7sNOqyuEoJZDyz4Jm4yGlW2uDuXtat2/Yc ZKEksML6CxNtj5ivePjFvm9ifFVlJwlVjfB6DnSu4hG2WGgGbtG0GSg8YWvm5uZE3Cri pc63hpxHYwiCMnSvF+WgfE2dJfA6BDDxw3AZQf8P1viLCAtPLtjmavyG6c+qWWVHOQSR 8qlQ== X-Gm-Message-State: AOAM533O3ZD7/9Dy3EBa6p7BsaObid82eSoHCcIXFcDNtfsjoINYSn47 mjAQFJZeb/WvnjMqKwY7xWMPe1lAGF0z4lHyjs1xd7UJDKE= X-Google-Smtp-Source: ABdhPJzMIxXRbPFkN4nA2p/B+yTw9lrlYsUJW85IpWaxhF3msMKA6IfccK4DKWRNvm/wjLYWSyKcid43Rl34213rgJc= X-Received: by 2002:a25:ea49:: with SMTP id o9mr5550406ybe.460.1642077150078; Thu, 13 Jan 2022 04:32:30 -0800 (PST) MIME-Version: 1.0 From: Tal Mizrahi Date: Thu, 13 Jan 2022 14:32:18 +0200 Message-ID: To: IETF IPPM WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [ippm] Call for Feedback about IOAM Linux Profile Draft X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2022 12:32:36 -0000 Hi, We are looking for feedback about this draft: - Is it useful for IPPM to work on this draft? - Any comments about the IOAM Linux kernel implementation? - Any specific comments about the draft? https://datatracker.ietf.org/doc/html/draft-mizrahi-ippm-ioam-linux-profile-02 Just a recap: IOAM has been supported in the Linux kernel since version 5.15, and as Justin is continuing his work on the IOAM implementation, the current version of the draft has been slightly updated accordingly. Comments will be welcome. Thanks, Tal. From nobody Thu Jan 13 17:08:47 2022 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 957413A1292; Thu, 13 Jan 2022 17:08:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.42.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ippm@ietf.org Message-ID: <164212252543.24637.8230414962710718767@ietfa.amsl.com> Date: Thu, 13 Jan 2022 17:08:45 -0800 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-ioam-yang-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2022 01:08:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Measurement WG of the IETF. Title : A YANG Data Model for In-Situ OAM Authors : Tianran Zhou Jim Guichard Frank Brockners Srihari Raghavan Filename : draft-ietf-ippm-ioam-yang-02.txt Pages : 26 Date : 2022-01-13 Abstract: In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in user packets while the packets traverse a path between two points in the network. This document defines a YANG module for the IOAM function. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-yang/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-yang-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-ioam-yang-02 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Fri Jan 14 02:00:20 2022 Return-Path: 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 47E323A2094 for ; Fri, 14 Jan 2022 02:00:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.615 X-Spam-Level: X-Spam-Status: No, score=-2.615 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.714, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpx17yIKIAPr for ; Fri, 14 Jan 2022 02:00:15 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50121.outbound.protection.outlook.com [40.107.5.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 512933A2091 for ; Fri, 14 Jan 2022 02:00:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=geTv9+kQ9MUg3rzz5BPUveoACtSnwDEIKhIeik34YJPNoFsHUa22BLns/aU2//kDf4J4rpqlAQ2IrcBBY3VS68L00K7m9D9Xg4TuWVnZUmxQj/CL8KGfI0UQztyb6o7HzdFSGOEmP1fpb+EuiC4QPUvIskhpYvt0nzpeLoHb84g3jHXd3kX2TUR3vxqrCCMS74Dm1HrnV+v0wYbJPswchhQg7s4cemOspeVEp/khI2YBjir/WLEVvuyKeiIrq9XGRvj6pZFiBSAd4qUx2EvZoj33aNBERZg562oit4KihC6T/c6a7E/eKInFALa2qNGyr5dlGMIUr+xJd03EGA38tQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=DwOvp0ZqLr7JLNomirgIFdrYsYdj0bspWQC370GnpUo=; b=jmn9MAeyEsxYKSrQYtL8Z4WqOw3aCNQ8Bnsap++1FrltyBAAtpnuhhegxwDR6wA9AzVEQMFaaRxBcvmgrQ8HOxAMtzrtZK/u3zSVWCfMe3PzGl7rc1LY69USBMaMII3rrfVcagD40t4HrsKesB+Vve6RkdBZ5w9EmzlEJrxtqxdUDhFgLCiKxpiPm75gGNA3YOdo8s5Sx0SsISao1vn21xGtrf2S7NmSvtX4kLInZmK6Y9j1FqFJUygRZ/j0XANuZw3tar+7r99FOupinqzLuaipfaUOjFAeezOlq3ZZLkh2rk4FxKiUHbX8ntQuNu/jwEjp/szyzDzvEQZ6I3lYUQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DwOvp0ZqLr7JLNomirgIFdrYsYdj0bspWQC370GnpUo=; b=cmVjLPbox7ewktHRJfn8a+zJqUsfAcT9xWKHvYl1lPYIBZ7Lg4olGSBOWwbEDKCjGMw/FpEwcTPo6JiNnweuO2XtUEkhav8DJhSnJJNY1O6Ksp//h3QlcCnhDFMg3dvjawJ9t7CIQyEruLKpGyk8oJ8lgPDrdjTt1l8+GfgTHjU= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=btconnect.com; Received: from DB7PR07MB5546.eurprd07.prod.outlook.com (2603:10a6:10:73::23) by VI1PR07MB6542.eurprd07.prod.outlook.com (2603:10a6:800:179::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4909.2; Fri, 14 Jan 2022 09:59:57 +0000 Received: from DB7PR07MB5546.eurprd07.prod.outlook.com ([fe80::2090:eb3c:59e2:b4b2]) by DB7PR07MB5546.eurprd07.prod.outlook.com ([fe80::2090:eb3c:59e2:b4b2%6]) with mapi id 15.20.4909.003; Fri, 14 Jan 2022 09:59:57 +0000 To: ippm@ietf.org References: <164212252543.24637.8230414962710718767@ietfa.amsl.com> From: t petch Message-ID: <61E14995.5000305@btconnect.com> Date: Fri, 14 Jan 2022 09:59:49 +0000 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: <164212252543.24637.8230414962710718767@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0293.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:196::10) To DB7PR07MB5546.eurprd07.prod.outlook.com (2603:10a6:10:73::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: cdca3360-6fe5-4762-410c-08d9d7449e90 X-MS-TrafficTypeDiagnostic: VI1PR07MB6542:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: zLjZL163b3kIsVsljDTBF63fQcxaGgF3eiEsWOR6Dm2xJCh+7tsX9gjtpMW+vQKvUZlpD5fhcYSdt8asIkGxaNSb9v+uhGqv6N6JM7OrEVBxw228mu+wLbdNsy/OfUDxalSjsz/1EUlFVrIY6rxusAZbdeBruYcxRISGr2d+DPFRV2jQF/uR83CEZgyFogT2PhWfe7J+N6A9uiPu6ZmWhoqlYoZsbRv4ZRlnVsVQGiuGkVf3mjXZdeZ97AF7mB6q7WTJ30GOeLsPYKsbgcko6DVTZkF9iFLdQuGLaJ08ugvKG+fvDm1por86GfyzcKEYvRvabYWE1wUmphC6eBeRg99PeyolwHPhT7mf64i4T92mXiSIziLkpfVSzlnBIftQp9BY2YZz7iO4iNxBAVtNhMfLcPyxEPKACso1zp4HQxERqfNNkHjKocuybbHAX9awOpV+nI/JrBgGF6S0maAcyGnQxuIUGp49tEC4rT7fqdtzmhfDRWMbjI5kpBWtiVJyRqu0EFAdJj51Ku0RXGN/zbrB3qeKaAMSxaTExHfXjiwkDig+gJITEXuz5zeDvQJxnqPl3fyDQbqR/IBjdwUWZy6BcU+fClJr+1ptSo0PCNekJwWhu9o2WQCoscP4NlrQ+TsVJUIGKPstckUECRp4RMZcty6ADqTzhENcRiYQPED9iUH+J9RveBJdNNenT0OVPtRXc3GEaWoklAxZNsAzOlp0DGnO9qf4Tcmp26Y73GCJnCWknb2yOWUHqONgR811ZWOq61lR/TxSJxzY0kCXoojLoH7srKvIYqqMQ4dNCsTrlECR+CMKkmj1ijSmoxpYdXPa7UmAMTntQTwnJZ5KoroUv9QKtTJRrROxffMYZgo= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR07MB5546.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(186003)(316002)(82960400001)(26005)(6512007)(5660300002)(6666004)(6506007)(966005)(508600001)(36756003)(6916009)(83380400001)(6486002)(38350700002)(86362001)(53546011)(66946007)(38100700002)(66476007)(52116002)(8676002)(2906002)(2616005)(8936002)(33656002)(66574015)(66556008)(87266011)(20210929001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?Windows-1252?Q?JkroFGZBvgtTBP7dIMn7cib0pzXZRp6uuTSyThsMm8Up5iftAv39TcxD?= =?Windows-1252?Q?EP0DHxEeuJn+KdR3f+Vi3oikPnZC5RYTvVxIGb8M8aQ4F1xzlouogT6L?= =?Windows-1252?Q?4KcPD9DcU6HqMvE9hmKU3rBxXUYZ/U0gQ9KjBdU5RtmcA/TRLh5hVFFl?= =?Windows-1252?Q?HV8IqYdu/CKcnaOMcPJLY1iZW1itPxZX8k8igOq8bdrXJsm2QODjoR6R?= =?Windows-1252?Q?WkmxaJ9GycxJhcJ6PJ0bjpOFiQocoy8sbqquov5cwKH7/t12/tq1RE0I?= =?Windows-1252?Q?eciAZiSwUfoEaMPCvFTxe9Ds3dNkmgrtY1tTuW454B35AduDtCOR6QzD?= =?Windows-1252?Q?rDey5dt63mPtT9RCo66lMJqxXaOqe3xpy+djE/eMXKesDow9tWhxuKqW?= =?Windows-1252?Q?CTRWKLUyp9JpO+faIhRU/UctU8y87sPVAgoYmaBF8xCWriKPO8WpCqW3?= =?Windows-1252?Q?KrLbgZ6TLwmrQ/dWLOHCXjUnQIJVkdTbSHCQ0KaxvBlfSLjrCT8neThj?= =?Windows-1252?Q?1rjqN9kGKbJ/oPQ50TmfuUtDo8j82zzpHsjCAJk0FT3iqBg++n1u48R9?= =?Windows-1252?Q?f3JfEGt/7a5Q+rsCuVqr4l+E0yEGH0rQMIwukEzNJ09+g1cYaF98apab?= =?Windows-1252?Q?uQQjniaVPkTp7XKMMIv7lbCGOTLm0rmpQBxZ+T0xETR03UUK6cbCcLb/?= =?Windows-1252?Q?uYe/Xt4dHuvHth+3wV8zRCMJOu+L1rLP8IrwOAEZIHB9WscXvZeUzPBo?= =?Windows-1252?Q?17SM/5HMZT/h7rcUuAQOYRHMJ+WTCEuML4fOGz2OoZbLK5V3vnOX6ZIa?= =?Windows-1252?Q?MH+A1EW+DV5htqvDYGQPywFvArVsIDgjzq1AW0GpM9iIlQpVq8qZQNOI?= =?Windows-1252?Q?RtV6qHgUcdeY4Qk5WfYs+E2t+mbJn7t/nVcEm6rPGKXOEizavLUNcs4g?= =?Windows-1252?Q?AME+nrqlyZHIkiurwxSFLTrPjn8y7G4Y0n/RQ06aavIbJNzNq7Lt28Ee?= =?Windows-1252?Q?XbDYs0iIOJEAWLIB5wjwmqbqydPPu2nAhCCjGOQZg0jsBSITEGm7AuZw?= =?Windows-1252?Q?5EcoTSAsO7jy2k2co6Hp7V7g7je31EKaQfO25lBehf48JcEvyFAt9Gie?= =?Windows-1252?Q?Q1Aeb+AX7VGvDFdaKyIFAlbqFra9ovA7to7BYHLUFoUXeTsDiwSS/uiO?= =?Windows-1252?Q?DWq3ntK0v56j1hYbraiJHnmiJjYHYuJ2jbU3dWIzi+hyoZ8Wu8NIgAKW?= =?Windows-1252?Q?Ji2JqfImwG3f84g3bc7n6Az83jSoDkDznKyD281/4UKsJxpx2QZhbj0G?= =?Windows-1252?Q?gelPipLQZdhHNBo5E8gy5loOMs90s/65vtaV02Q2ePFGF8bj26mu5Qv5?= =?Windows-1252?Q?+GWOrdNRa5qopBJIzaEDSAOiaAiUdtOddLmHCv/sQurR16VhtJkwHiDt?= =?Windows-1252?Q?p9iVwYN/QV9dN5BR7+d6QnZiE3zY4yGw80YSaK6rPYrbzRW7HWinc6Ao?= =?Windows-1252?Q?O0S2u9t07MSQ+Ixc9jvizOvJiCa/epeFabKRBwrDROORcP04oMK4uqdZ?= =?Windows-1252?Q?WXG8zZoilj1MRztCMPGqgz3jWMSEMNiVvfPyDTLFqgMbdqq2neJnJjHl?= =?Windows-1252?Q?glN4cXqVb/7e/Jgrvlvo3E0vlWxMQ3v4Z5g2Sum+qALrOkGPXFmrgPjJ?= =?Windows-1252?Q?voumoaWUWrO7Zz4LKmirWloaLY/RMpb90FDjJ+g8nscc2pckibtbXJoT?= =?Windows-1252?Q?Yed6mIIc0yG3P9Ah3Uw=3D?= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: cdca3360-6fe5-4762-410c-08d9d7449e90 X-MS-Exchange-CrossTenant-AuthSource: DB7PR07MB5546.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jan 2022 09:59:56.9736 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: kPZx+RCIOfzFuql7FKzDs/JKE7Eb/74gKZOqnC7CiPZwcQV3NU9Z5rXNuxy5jthWzlKMZZv1YDW6QCDjwZ+P+Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB6542 Archived-At: Subject: Re: [ippm] I-D Action: draft-ietf-ippm-ioam-yang-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2022 10:00:18 -0000 This looks like 'it has been another six months so it is time to re-submit' I-D. I note that the YANG module date remains at 2021 which seems a useful indicator! Tom Petch On 14/01/2022 01:08, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Performance Measurement WG of the IETF. > > Title : A YANG Data Model for In-Situ OAM > Authors : Tianran Zhou > Jim Guichard > Frank Brockners > Srihari Raghavan > Filename : draft-ietf-ippm-ioam-yang-02.txt > Pages : 26 > Date : 2022-01-13 > > Abstract: > In-situ Operations, Administration, and Maintenance (IOAM) records > operational and telemetry information in user packets while the > packets traverse a path between two points in the network. This > document defines a YANG module for the IOAM function. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-yang/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-yang-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-ioam-yang-02 > > > Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > . > From nobody Fri Jan 14 02:30:46 2022 Return-Path: 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 D08693A211F for ; Fri, 14 Jan 2022 02:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j69FmsLiQK9b for ; Fri, 14 Jan 2022 02:30:40 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96F1E3A211E for ; Fri, 14 Jan 2022 02:30:40 -0800 (PST) Received: from fraeml709-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JZyHV66wMz67KVW for ; Fri, 14 Jan 2022 18:30:30 +0800 (CST) Received: from kwepeml500001.china.huawei.com (7.221.188.162) by fraeml709-chm.china.huawei.com (10.206.15.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Fri, 14 Jan 2022 11:30:37 +0100 Received: from kwepeml500004.china.huawei.com (7.221.188.141) by kwepeml500001.china.huawei.com (7.221.188.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Fri, 14 Jan 2022 18:30:35 +0800 Received: from kwepeml500004.china.huawei.com ([7.221.188.141]) by kwepeml500004.china.huawei.com ([7.221.188.141]) with mapi id 15.01.2308.020; Fri, 14 Jan 2022 18:30:35 +0800 From: Tianran Zhou To: t petch , ippm Thread-Topic: [ippm] I-D Action: draft-ietf-ippm-ioam-yang-02.txt Thread-Index: AQHYCONY9YSHCkhotEyNjloKbBeKraxhwwuAgACOtjo= Date: Fri, 14 Jan 2022 10:30:35 +0000 Message-ID: <22444b56b795425c936ac794e53d3075@huawei.com> References: <164212252543.24637.8230414962710718767@ietfa.amsl.com>, <61E14995.5000305@btconnect.com> In-Reply-To: <61E14995.5000305@btconnect.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_22444b56b795425c936ac794e53d3075huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] I-D Action: draft-ietf-ippm-ioam-yang-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2022 10:30:45 -0000 --_000_22444b56b795425c936ac794e53d3075huaweicom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgVG9tLA0KSSBhbSBzb3JyeS4gVGhlIGRhdGUgaXMgbm90IGNvcnJlY3QuIEJ1dCB0aGUgZGF0 ZSBpbiB0aGUgWUFORyBtb2RlbCBpcyBjb3JyZWN0Lg0KVGhlIG1ham9yIGltcHJvdmVtZW50IGlz IGFib3V0IHRoZSBpb2FtIGluZm8uDQpXZSBjb2xsZWN0ZWQgc29tZSByZXF1aXJlbWVudHMgYW5k IGFkZGVkIGluLg0KDQpCZXN0LA0KVGlhbnJhbg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQoNClNlbnQgZnJvbSBXZUxpbmsNCreivP7Iy6O6IHQgcGV0Y2g8aWV0ZmFAYnRj b25uZWN0LmNvbTxtYWlsdG86aWV0ZmFAYnRjb25uZWN0LmNvbT4+DQrK1bz+yMujuiBpcHBtPGlw cG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+Pg0K1vfM4qO6IFJlOiBbaXBwbV0gSS1E IEFjdGlvbjogZHJhZnQtaWV0Zi1pcHBtLWlvYW0teWFuZy0wMi50eHQNCsqxvOSjuiAyMDIyLTAx LTE0IDE4OjAwOjQzDQoNClRoaXMgbG9va3MgbGlrZSAnaXQgaGFzIGJlZW4gYW5vdGhlciBzaXgg bW9udGhzIHNvIGl0IGlzIHRpbWUgdG8NCnJlLXN1Ym1pdCcgSS1ELiAgSSBub3RlIHRoYXQgdGhl IFlBTkcgbW9kdWxlIGRhdGUgcmVtYWlucyBhdCAyMDIxIHdoaWNoDQpzZWVtcyBhIHVzZWZ1bCBp bmRpY2F0b3IhDQoNClRvbSBQZXRjaA0KDQpPbiAxNC8wMS8yMDIyIDAxOjA4LCBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmcgd3JvdGU6DQo+DQo+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWls YWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4gVGhp cyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSVAgUGVyZm9ybWFuY2UgTWVhc3VyZW1lbnQg V0cgb2YgdGhlIElFVEYuDQo+DQo+ICAgICAgICAgIFRpdGxlICAgICAgICAgICA6IEEgWUFORyBE YXRhIE1vZGVsIGZvciBJbi1TaXR1IE9BTQ0KPiAgICAgICAgICBBdXRob3JzICAgICAgICAgOiBU aWFucmFuIFpob3UNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgSmltIEd1aWNoYXJkDQo+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZyYW5rIEJyb2NrbmVycw0KPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICBTcmloYXJpIFJhZ2hhdmFuDQo+ICAgICAgICBGaWxlbmFtZSAgICAg ICAgOiBkcmFmdC1pZXRmLWlwcG0taW9hbS15YW5nLTAyLnR4dA0KPiAgICAgICAgUGFnZXMgICAg ICAgICAgIDogMjYNCj4gICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMjItMDEtMTMNCj4NCj4g QWJzdHJhY3Q6DQo+ICAgICBJbi1zaXR1IE9wZXJhdGlvbnMsIEFkbWluaXN0cmF0aW9uLCBhbmQg TWFpbnRlbmFuY2UgKElPQU0pIHJlY29yZHMNCj4gICAgIG9wZXJhdGlvbmFsIGFuZCB0ZWxlbWV0 cnkgaW5mb3JtYXRpb24gaW4gdXNlciBwYWNrZXRzIHdoaWxlIHRoZQ0KPiAgICAgcGFja2V0cyB0 cmF2ZXJzZSBhIHBhdGggYmV0d2VlbiB0d28gcG9pbnRzIGluIHRoZSBuZXR3b3JrLiAgVGhpcw0K PiAgICAgZG9jdW1lbnQgZGVmaW5lcyBhIFlBTkcgbW9kdWxlIGZvciB0aGUgSU9BTSBmdW5jdGlv bi4NCj4NCj4NCj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJh ZnQgaXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaXBw bS1pb2FtLXlhbmcvDQo+DQo+IFRoZXJlIGlzIGFsc28gYW4gaHRtbGl6ZWQgdmVyc2lvbiBhdmFp bGFibGUgYXQ6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQt aWV0Zi1pcHBtLWlvYW0teWFuZy0wMg0KPg0KPiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVy c2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC1pZXRmLWlwcG0taW9hbS15YW5nLTAyDQo+DQo+DQo+IEludGVybmV0LURyYWZ0cyBh cmUgYWxzbyBhdmFpbGFibGUgYnkgcnN5bmMgYXQgcnN5bmMuaWV0Zi5vcmc6OmludGVybmV0LWRy YWZ0cw0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBpcHBtIG1haWxpbmcgbGlzdA0KPiBpcHBtQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBwbQ0KPiAuDQo+DQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQppcHBtIG1haWxpbmcgbGlzdA0KaXBw bUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtDQo= --_000_22444b56b795425c936ac794e53d3075huaweicom_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
        This looks like 'it has been another six months so= it is time to
        re-submit' I-D.  I note that the YANG module date remains at 2021 whic= h
        seems a useful indicator!

        Tom Petch

        On 14/01/2022 01:08, internet-drafts@ietf.org wrote:
        >
        > A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
        > This draft is a work item of the IP Performance Measurement WG of the = IETF.
        >
        >          Title  = ;         : A YANG Data Model for I= n-Situ OAM
        >          Authors &nb= sp;       : Tianran Zhou
        >            = ;            &n= bsp;   Jim Guichard
        >            = ;            &n= bsp;   Frank Brockners
        >            = ;            &n= bsp;   Srihari Raghavan
        >        Filename   &n= bsp;    : draft-ietf-ippm-ioam-yang-02.txt
        >        Pages    = ;       : 26
        >        Date    =         : 2022-01-13
        >
        > Abstract:
        >     In-situ Operations, Administration, and Mainte= nance (IOAM) records
        >     operational and telemetry information in user = packets while the
        >     packets traverse a path between two points in = the network.  This
        >     document defines a YANG module for the IOAM fu= nction.
        >
        >
        > The IETF datatracker status page for this draft is:
        > https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-yang/
        >
        > There is also an htmlized version available at:
        > https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-yang-02=
        >
        > A diff from the previous version is available at:
        > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-ioam-yang-02=
        >
        >
        > Internet-Drafts are also available by rsync at rsync.ietf.org::interne= t-drafts
        >
        >
        > _______________________________________________
        > ippm mailing list
        > ippm@ietf.org
        > https://www.iet= f.org/mailman/listinfo/ippm
        > .
        >

        _______________________________________________
        ippm mailing list
        ippm@ietf.org
        https://www.ietf.org= /mailman/listinfo/ippm
         --_000_22444b56b795425c936ac794e53d3075huaweicom_-- From nobody Sun Jan 16 15:15:39 2022 Return-Path: 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 90D803A15E6; Sun, 16 Jan 2022 15:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sk81GSyAyhk3; Sun, 16 Jan 2022 15:15:27 -0800 (PST) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2975A3A15E5; Sun, 16 Jan 2022 15:15:27 -0800 (PST) Received: by mail-ed1-x52d.google.com with SMTP id m4so57997584edb.10; Sun, 16 Jan 2022 15:15:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CdASCptek7Pt2e0j2mWI7KjmNTbSklNbEE55ePXnh4s=; b=enJWrB/fsZsfC96z3TTa/rtg51ZkIdQAPrlyPiqSDVdwBM7ZVqTZrj53svbumhu55t DrYDqNpHsqVE2i0MnUYaiu9CgeETzNab9u4d9/n494tG4EuZ3VWHNR4V1+GC2ikC5a5a e9dIEqts1p1tROjCMGRkIsc0px4ymkvnMC3DTsiBUtp5LzhB9W8/sSPaVqKwB7c9R/96 TRFe+vtU4CFDgH5/1C9ILNkF527KeNIkjZ0RFGMhe60AOkVvV79klQQzjhkwJ5uX756O xNPNjX2bHZvwn/n9VM24NTD6COmKfB6jro7Xo/VBkjBIOHLdjq+AukY7GAPxkj9r31IL Ga2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CdASCptek7Pt2e0j2mWI7KjmNTbSklNbEE55ePXnh4s=; b=aCC7S37F3GoExpJEU6eVKewV1S24gqrwXuNjrrNovuGWB2/ZvFAsI11n0MlzDXKWKd Qu89cIdhizVBgxo/Z9ndFZ+8AlF9QESi/Nmjob+cjTe6LdbOJFLHEwBW8dQ43k+aJSa3 qOvqVzJbjjyy3XwBEfZdWOcfO/oQdIe4cxBDpT0XxacaZjGytvPL8m85OC+F+CaNGlcZ Yg18AMN5CqR/lme7Y+N1/1ZAZXA4EWl/uEDfvai3intw3+E1BGwz0Yp/FmcgvX8hpyV7 N3Aa5tuscFtCdZeUNjhd0/wNy43x8lHSY0vGRuS2WOhJu6ZovZlppPla1PvlIpMDjVpj KjpQ== X-Gm-Message-State: AOAM531CV3ZvYlGWAtkTjoVkzz/euaxIdaPc08nG9RDr1VSk/v9Q+0A6 EGBjz3NIRfl+fE2xsOWwClR3tul8EVLBpuuXO4f/kqh9FUQ= X-Google-Smtp-Source: ABdhPJypTwYEzWwWSHlxS0MT5qfl1pny1EizXZoFbv60J2pRa/JxaQ7DcCrX9U35YNZqegbv3cnBfgC/xsYZz/+gKXY= X-Received: by 2002:aa7:cac7:: with SMTP id l7mr18654835edt.302.1642374924039; Sun, 16 Jan 2022 15:15:24 -0800 (PST) MIME-Version: 1.0 References: <06c601d80af4$50751ce0$f15f56a0$@olddog.co.uk> In-Reply-To: <06c601d80af4$50751ce0$f15f56a0$@olddog.co.uk> From: Greg Mirsky Date: Sun, 16 Jan 2022 15:15:12 -0800 Message-ID: To: adrian@olddog.co.uk Cc: draft-ietf-opsawg-yang-vpn-service-pm@ietf.org, opsawg@ietf.org, ippm@ietf.org, ippm-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000ef780105d5bb3544" Archived-At: Subject: Re: [ippm] [OPSAWG] A review of draft-ietf-opsawg-yang-vpn-service-pm-01 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2022 23:15:32 -0000 --000000000000ef780105d5bb3544 Content-Type: text/plain; charset="UTF-8" Hi Adrian, the Authors, and All, thank you Adrian for reviewing the draft and inviting further discussion. I've commented on this work earlier suggesting considering the performance metrics listed in the STAMP YANG data model. I appreciate that the Authors have found them helpful and included them in this model. But I still wonder what, if anything, is special for a VPN service from a performance metrics perspective compared to, for example, an underlay? Would it be possible and simpler to have a single PM data model applicable to any underlay or overlay network? Regards, Greg On Sun, Jan 16, 2022 at 8:16 AM Adrian Farrel wrote: > Hi authors, > > This draft has been safely inside the OPSAWG for a while, so I though > it was probably due a review. > > "The usual" two top-level issues: > > - The draft expired earlier this month, so you need at a least a > keep-alive version. > > - The draft has more than five front-page authors so the AD or RFC > Editor will object. It is probably best for you to resolve this issue > sooner rather than later. > > Otherwise, my comments are a collection of small nits and nothing > alarming. Thanks for your work on this document. > > Best, > Adrian > > == Questions == > > Looking at Figure 1, an obvious question is why this model doesn't > augment the L2/L3NM or the common VPN model. It is OK (for me) that you > have chosen to augment the network topology model, but it is not clear > to the reader why you have done this. > > --- > > I wonder whether the work in this document would benefit from using > data tags (draft-ietf-netmod-node-tags). I might be wrong, but it seems > particularly related and useful. > > --- > > If, in Figure 3, VPN1 is configured as hub and spoke with S1A as the > hub, why is there a link in the virtual network between VN2 and VN3? > > --- > > 5. > > General question about counters based on my memory of how we did MIBs > (So I am old! Quite possible that YANG does this differently.) Don't > you need something to handle resets? That is, to distinguish between > wrapping and resetting, we used to include a timestamp for when the > counters were last reset. Sometimes this was a timestamp per counter, > but usually enough for one timestamp across all counters. > > (This probably makes a difference to the gauges and percentiles, too.) > > Re-reading, it is possible that this is covered by 'reference-time' and > 'measurement-interval'. If so, this could be a lot clearer in 4.4. > > --- > > 5. > > leaf pm-source { > type string; > config false; > description > "The OAM tool used to collect the PM data."; > } > > I'm not convinced that using a string here is helpful. How does the > device know what string to use to convey meaning to the application? > > Or is the point that this is just printable information for display and > human consumption? If so, perhaps a note to this effect in Section 4.4. > > == Nits === > > Abstract > > It would be nice to say what the model in 8345 is. So... > > The data model for network topologies defined in RFC 8345 introduces > vertical layering relationships between networks that can be > augmented to cover network and service topologies. > > --- > > Abstract > > I think PM stands for 'performance monitoring' not 'network performance > monitoring', so for the avoidance of doubt... > > This document defines a YANG module for > performance monitoring (PM) of both networks and VPN services that > can be used to monitor and manage network performance on the topology > at higher layer or the service topology between VPN sites. > > --- > > 2. > > You have the BCP 14 boilerplate, but the uses of "should" and "must" in > the document are in lower case. There is one use of upper case "MAY" in > the Security Considerations which should be, I think, lower case since > it is a statement of fact not guidance to an implementer of this spec. > > --- > > 3. > > s/Such an information/Such information/ > s/should be setup/should be set up/ > s/using network performance/using a network performance/ > s/information from Traffic/information from the Traffic/ > > --- > > The Legend for Figure 3 could usefully add > S:Site > > It might also help to indicate the difference between links that are > shown as | and mappings that are shown as : > > --- > > 4.2 > > s/do not need to be extended./does not need to be extended./ > > --- > > 4.2, 4.3 > > Figures 4 and 5 should be referred to from the text. > > --- > > 4.4 > > OLD > Setting a percentile into > 0.00 indicates the client is not interested in receiving > particular percentile. > NEW > Setting a percentile to > 0.00 indicates the client is not interested in receiving > that particular percentile. > END > > s/metric (e.g./metric (e.g.,/ > > OLD > "reference-time" "measurement-interval" > NEW > "reference-time" and "measurement-interval" > END > > --- > > 5. > > The "ietf-network-vpn-pm" module uses types defined in [RFC8345], > [RFC6991], and [RFC8532]. > > You probably need to add [I-D.ietf-opsawg-vpn-common]. > > "RFC CCCC: A Layer 2/3 VPN Common YANG Model"; > > I think you need a note to the RFC Editor to change that (although it > is likely that the RFC will come out relatively soon and you may get to > fix it up yourself). > > Similarly... > > This version of this YANG module is part of RFC XXXX; see > the RFC itself for full legal notices."; > > revision 2021-07-06 { > description > "Initial revision."; > reference > "RFC XXXX: A YANG Model for Network and VPN Service Performance > Monitoring"; > > You need a note to the RFC Editor to fix this up. > > --- > > 5. > > Shouldn't 'percentile' also have a range? > > --- > > 6. > > There are a number of data nodes defined in this YANG module that are > writable/creatable/deletable (i.e., config true, which is the > default). These data nodes may be considered sensitive or vulnerable > in some network environments. Write operations (e.g., edit-config) > to these data nodes without proper protection can have a negative > effect on network operations. These are the subtrees and data nodes > and their sensitivity/vulnerability: > > o /nw:networks/nw:network/svc-topo:svc-telemetry-attributes > > o /nw:networks/nw:network/nw:node/svc-topo:node-attributes > > This feels like it may have been block copied from another document. I > think it needs updating for the specific writeable objects in this > module and the negative effects (which are surely not very great) of > them being unprotected. > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --000000000000ef780105d5bb3544 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
        Hi Adrian, the Authors, and All,
        thank you = Adrian for reviewing the draft and inviting further discussion. I've co= mmented on this work earlier suggesting considering the performance metrics= listed in the STAMP YANG data model. I appreciate that the Authors have fo= und them helpful and included them in this model. But I still wonder what,= =C2=A0if anything, is special for a VPN service from a performance metrics= =C2=A0perspective compared to, for example, an underlay? Would it be possib= le and simpler=C2=A0to have a single PM data model applicable to any underl= ay or overlay network?

        Regards,
        Greg
        On S= un, Jan 16, 2022 at 8:16 AM Adrian Farrel <adrian@olddog.co.uk> wrote:
        Hi authors,

        This draft has been safely inside the OPSAWG for a while, so I though
        it was probably due a review.

        "The usual" two top-level issues:

        - The draft expired earlier this month, so you need at a least a
        =C2=A0 keep-alive version.

        - The draft has more than five front-page authors so the AD or RFC
        =C2=A0 Editor will object. It is probably best for you to resolve this issu= e
        =C2=A0 sooner rather than later.

        Otherwise, my comments are a collection of small nits and nothing
        alarming.=C2=A0 Thanks for your work on this document.

        Best,
        Adrian

        =3D=3D Questions =3D=3D

        Looking at Figure 1, an obvious question is why this model doesn't
        augment the L2/L3NM or the common VPN model. It is OK (for me) that you
        have chosen to augment the network topology model, but it is not clear
        to the reader why you have done this.

        ---

        I wonder whether the work in this document would benefit from using
        data tags (draft-ietf-netmod-node-tags). I might be wrong, but it seems particularly related and useful.

        ---

        If, in Figure 3, VPN1 is configured as hub and spoke with S1A as the
        hub, why is there a link in the virtual network between VN2 and VN3?

        ---

        5.

        General question about counters based on my memory of how we did MIBs
        (So I am old! Quite possible that YANG does this differently.) Don't you need something to handle resets? That is, to distinguish between
        wrapping and resetting, we used to include a timestamp for when the
        counters were last reset. Sometimes this was a timestamp per counter,
        but usually enough for one timestamp across all counters.

        (This probably makes a difference to the gauges and percentiles, too.)

        Re-reading, it is possible that this is covered by 'reference-time'= and
        'measurement-interval'.=C2=A0 If so, this could be a lot clearer in= 4.4.

        ---

        5.

        =C2=A0 =C2=A0 =C2=A0 leaf pm-source {
        =C2=A0 =C2=A0 =C2=A0 =C2=A0 type string;
        =C2=A0 =C2=A0 =C2=A0 =C2=A0 config false;
        =C2=A0 =C2=A0 =C2=A0 =C2=A0 description
        =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "The OAM tool used to collect the P= M data.";
        =C2=A0 =C2=A0 =C2=A0 }

        I'm not convinced that using a string here is helpful. How does the
        device know what string to use to convey meaning to the application?

        Or is the point that this is just printable information for display and
        human consumption? If so, perhaps a note to this effect in Section 4.4.

        =3D=3D Nits =3D=3D=3D

        Abstract

        It would be nice to say what the model in 8345 is. So...

        =C2=A0 =C2=A0The data model for network topologies defined in RFC 8345 intr= oduces
        =C2=A0 =C2=A0vertical layering relationships between networks that can be =C2=A0 =C2=A0augmented to cover network and service topologies.

        ---

        Abstract

        I think PM stands for 'performance monitoring' not 'network per= formance
        monitoring', so for the avoidance of doubt...

        =C2=A0 =C2=A0This document defines a YANG module for
        =C2=A0 =C2=A0performance monitoring (PM) of both networks and VPN services = that
        =C2=A0 =C2=A0can be used to monitor and manage network performance on the t= opology
        =C2=A0 =C2=A0at higher layer or the service topology between VPN sites.

        ---

        2.

        You have the BCP 14 boilerplate, but the uses of "should" and &qu= ot;must" in
        the document are in lower case. There is one use of upper case "MAY&qu= ot; in
        the Security Considerations which should be, I think, lower case since
        it is a statement of fact not guidance to an implementer of this spec.

        ---

        3.

        s/Such an information/Such information/
        s/should be setup/should be set up/
        s/using network performance/using a network performance/
        s/information from Traffic/information from the Traffic/

        ---

        The Legend for Figure 3 could usefully add
        =C2=A0 =C2=A0S:Site

        It might also help to indicate the difference between links that are
        shown as | and mappings that are shown as :

        ---

        4.2

        s/do not need to be extended./does not need to be extended./

        ---

        4.2, 4.3

        Figures 4 and 5 should be referred to from the text.

        ---

        4.4

        OLD
        =C2=A0 =C2=A0 =C2=A0 Setting a percentile into
        =C2=A0 =C2=A0 =C2=A0 0.00 indicates the client is not interested in receivi= ng
        =C2=A0 =C2=A0 =C2=A0 particular percentile.
        NEW
        =C2=A0 =C2=A0 =C2=A0 Setting a percentile to
        =C2=A0 =C2=A0 =C2=A0 0.00 indicates the client is not interested in receivi= ng
        =C2=A0 =C2=A0 =C2=A0 that particular percentile.
        END

        s/metric (e.g./metric (e.g.,/

        OLD=C2=A0 =C2=A0
        =C2=A0 =C2=A0"reference-time" "measurement-interval" NEW
        =C2=A0 =C2=A0"reference-time" and "measurement-interval"= ;
        END

        ---

        5.

        =C2=A0 =C2=A0The "ietf-network-vpn-pm" module uses types defined = in [RFC8345],
        =C2=A0 =C2=A0[RFC6991], and [RFC8532].

        You probably need to add [I-D.ietf-opsawg-vpn-common].

        =C2=A0 =C2=A0 =C2=A0 "RFC CCCC: A Layer 2/3 VPN Common YANG Model"= ;;

        I think you need a note to the RFC Editor to change that (although it
        is likely that the RFC will come out relatively soon and you may get to
        fix it up yourself).

        Similarly...

        =C2=A0 =C2=A0 =C2=A0This version of this YANG module is part of RFC XXXX; s= ee
        =C2=A0 =C2=A0 =C2=A0the RFC itself for full legal notices.";

        =C2=A0 revision 2021-07-06 {
        =C2=A0 =C2=A0 description
        =C2=A0 =C2=A0 =C2=A0 "Initial revision.";
        =C2=A0 =C2=A0 reference
        =C2=A0 =C2=A0 =C2=A0 "RFC XXXX: A YANG Model for Network and VPN Servi= ce Performance
        =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Monitoring&qu= ot;;

        You need a note to the RFC Editor to fix this up.

        ---

        5.

        Shouldn't 'percentile' also have a range?

        ---

        6.

        =C2=A0 =C2=A0There are a number of data nodes defined in this YANG module t= hat are
        =C2=A0 =C2=A0writable/creatable/deletable (i.e., config true, which is the<= br> =C2=A0 =C2=A0default).=C2=A0 These data nodes may be considered sensitive o= r vulnerable
        =C2=A0 =C2=A0in some network environments.=C2=A0 Write operations (e.g., ed= it-config)
        =C2=A0 =C2=A0to these data nodes without proper protection can have a negat= ive
        =C2=A0 =C2=A0effect on network operations.=C2=A0 These are the subtrees and= data nodes
        =C2=A0 =C2=A0and their sensitivity/vulnerability:

        =C2=A0 =C2=A0o=C2=A0 /nw:networks/nw:network/svc-topo:svc-telemetry-attribu= tes

        =C2=A0 =C2=A0o=C2=A0 /nw:networks/nw:network/nw:node/svc-topo:node-attribut= es

        This feels like it may have been block copied from another document. I
        think it needs updating for the specific writeable objects in this
        module and the negative effects (which are surely not very great) of
        them being unprotected.

        _______________________________________________
        OPSAWG mailing list
        OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
        --000000000000ef780105d5bb3544-- From nobody Mon Jan 17 04:25:22 2022 Return-Path: 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 EA31E3A0F04 for ; Mon, 17 Jan 2022 04:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.415 X-Spam-Level: X-Spam-Status: No, score=-2.415 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-0.714, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pigHKGkWPz_p for ; Mon, 17 Jan 2022 04:25:15 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70119.outbound.protection.outlook.com [40.107.7.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 815153A0F00 for ; Mon, 17 Jan 2022 04:25:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bZ727PQgqk7T6/Zr0YHttNSa+uhZBTdDWmXWrruBGSiyTxvmE9c8yslC5sTT33Eg3OporJztmqCr9IU7+Ax2nzRIJqs8FvzvPo6plTyJB90qQjArgTpRQywEYwKKb1vli+v5VXqN9twjIhs8uYO4itzTLTnpYJA/4KvhdOanbSD+55PpHREZWgo5EEKYYTVylqYqQUz6IMXkloSwf5jage93MOvDEDNdlslujj+AWc9b370dtrMOo+y4FG6biqUyYzompgCyyhrwRHeUFQ7GhIxfLZzgH7WSVBVCkHOXhsvMB9Y3W7L981la0Of4YZzNfFxA2Ah0dt+06SgCLk1Ueg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KW6BmFKKfxG8PyheKtTKKq7qcsa046EtqykrdZfTqqM=; b=aKhegWhfv9MqMflpaCi5wraNLao1XKEsZMz1/JnFGefo664Lc3FFiXLsIdd6Btf/NyryEpkcirXpE5FvBLmFMWcqGUw8qCzjhfmlN73KvQ9wR3MsUNo1cGgMAUw+51OnNi38Ub9y9+Purl6y/eseUHbN4WTDeBnbF2XAQ730wG6p2RiuEscZh6wwVzDXe4122M3n2+uooj4uSRDpSvCe9qr2HXLwO4wQLdRz1CjicavuoGghdnjEUYGinraOx42zpB/7nZQzWAbwAQoyhHrw3xCwSwtLRq7CtUlToyt4x4zt1KYfokg6/o2QePUICkzm6ibLSezNEJdLKHgpKn/HLw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KW6BmFKKfxG8PyheKtTKKq7qcsa046EtqykrdZfTqqM=; b=SGH4jKY+WzBSwnFXyX5xxzQLzl/oex5lmx7eiO6brGjW3O2xFlD2fxjIJGfEU0JnCAyJlky8U9aI+JANADycCO3KWJccllFKp/rZ93rSNoyRhJBIp7q/kV0CZnAe4hwA3YBOXkSb0JEAZjBWCPgJDxZ8nrXyHJCUzpaiPnT7a/E= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=btconnect.com; Received: from DB7PR07MB5546.eurprd07.prod.outlook.com (2603:10a6:10:73::23) by DU0PR07MB8491.eurprd07.prod.outlook.com (2603:10a6:10:357::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4909.3; Mon, 17 Jan 2022 12:25:12 +0000 Received: from DB7PR07MB5546.eurprd07.prod.outlook.com ([fe80::2090:eb3c:59e2:b4b2]) by DB7PR07MB5546.eurprd07.prod.outlook.com ([fe80::2090:eb3c:59e2:b4b2%6]) with mapi id 15.20.4909.006; Mon, 17 Jan 2022 12:25:12 +0000 To: Tianran Zhou , ippm References: <164212252543.24637.8230414962710718767@ietfa.amsl.com> <61E14995.5000305@btconnect.com> <22444b56b795425c936ac794e53d3075@huawei.com> From: t petch Message-ID: <61E5601E.8040405@btconnect.com> Date: Mon, 17 Jan 2022 12:25:02 +0000 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: <22444b56b795425c936ac794e53d3075@huawei.com> Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P265CA0418.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a0::22) To DB7PR07MB5546.eurprd07.prod.outlook.com (2603:10a6:10:73::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a5715b94-62c1-439c-3a61-08d9d9b468b0 X-MS-TrafficTypeDiagnostic: DU0PR07MB8491:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: s5CccPW4s6SGoXod4qU3W6CCGMT5OsgIqTzmISEmwIae7mG4Ryt+LZXjWgTrceSpbKL+AZdd8nOpQyFEHXcOywBz9b7vqQiM/b1P3warf0+TkTP5Sxq8r/ysmL1cf0kJPcKbvOJgZj2U3f/GubxE6YSI0NUK7zipWhS8uUF2v2FLDM7CX3B9Gn6OEuxIRVCqraE4PiQ8TnclS/31bprRIy6sPNlODJTPWpWNAJW3Fqnb/x+IMGXkVN3kVPZAAifp7JMCGHu2Gvra1mDHAQZiSQ9oFzMzJwJf74x7qF33M9uHOQDqcUwYQ0G7vZ2zFz1kaVhDZgtTxyEZiFPFrdk60tg76YmFgLA7Haw31Fp1GdAOIDLw4ngoOpob5EQf9YAvn8Zv4JNGl8iCBYphfWPKP/bMOVKiy6cbRo00Pq1cVSJtF8/QGNgwGj8wHLMJvHfj+CB/atBOnCGdMUX0feD8qBN+sPDS6Ie+/VGuFBaO2UrUJcIikD9yVlsVwnE/N9JkEH3jq5WNQXiisdBeNCYm6NioQ+S8XzG0761iO52DjepTHiaWssOCfvJx0c6C4VKrCha1xkkrQsDux+k4wHk7R/Yu1ZbfurijXtJsMzig/EgkOXpsb7usGUGVQ5YEg7U363Q8DHLrBCHUdkV+vSgVlQRtnRwE1+1rniMSOnUkSNwiV94bnq71yRgAsObkYDaJNo1mMBNIoxEdGPOJFMjxuS8nX6YlnSaNG7qMKgx76ml6rd6Pf7w9mkHMCh0arAo1OT/GK1G6uAQx3w9eOh1otteXLF5RsOY4+0gcubSArKR/Gm3bn9wNXMt6LcV07yGV X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR07MB5546.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(6506007)(6486002)(66946007)(87266011)(8676002)(2616005)(52116002)(508600001)(66556008)(53546011)(6666004)(966005)(316002)(86362001)(110136005)(66574015)(6512007)(66476007)(8936002)(83380400001)(33656002)(36756003)(82960400001)(186003)(26005)(2906002)(38100700002)(38350700002)(5660300002)(20210929001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?gb2312?B?STJVSmZOUktId3ZwZDFPU3NQZzJHYVBrQUdoN2tpS25hbW9lemZsc3pkb0hU?= =?gb2312?B?NENpS00rMjkrYnBZV3FuVTBOTDUzbXc2M3lnbWVWOG9TdGtCSVNRUThGRFR0?= =?gb2312?B?WFlVU0JtdGJsSmJ0eXBLbUNNcytvNHZYaTk5d3dNckVGNUNBa0d2c1VZelZF?= =?gb2312?B?MVhmZDE4UUYzNkI4VXhPVWsrUkluM0x0UGZ0Q2tFWkU5cHRlOGJvL2tPNlZV?= =?gb2312?B?Z2tzbnZOcWUzU0hpSFhXUnNGT2xmWDZIb2orQnlnUjBhN2c3TDlPWTV2YWVo?= =?gb2312?B?N21mYlREWWNuazVJRUt6SFdnNEJDcXIxZkkzV3MydlB2T2RzbWhFL0VUTUUv?= =?gb2312?B?a25QZjdBYVc5ZG50Q3craERzeS9Dakh5dDRETVFLZVRBYTBpSUt3VUNkdExn?= =?gb2312?B?aVpEQ2x5SlMwRngzSE9zcUwvVlF1Yi9NS0YrVThtbFhCc1U3WU9rZjlUM1VJ?= =?gb2312?B?U1N6UGwwL2RnQzlUaS9nbG1zYnpzSWpVRzFTRGpGN3dBT1AxYjR6YnFiNXB2?= =?gb2312?B?ajYvcmRiL2wvT0dWeU5Vd2d4S1lrUnNrNTdiRm9DaDQzd09jZXJXbjNqcDlC?= =?gb2312?B?L2kyTDZ4d295bDRNTGMvZ2xqeUVyd2VoenlFU2NOaW0rN0pCbmMvdldCTTdn?= =?gb2312?B?SHc0SUs0U1ZGOEI3TldTMWpVb3VGWDI0eTlHTTFiLzQxOER0Q0hveVUrSzYy?= =?gb2312?B?R2NWUk8vRW1veDg0ckZ2S1FNSUc2cXNERjlUN3lrQkI5K3phK09vRGpkeXA0?= =?gb2312?B?dlNhZm5oRVN1RGRsT1VQMzMrSGNYcWpGbGh0cVpiZWxhWmNNcDZqc2d6WXAv?= =?gb2312?B?VnZmZk1EazBqbSs2L2hCUzA1ODdCNkFCcjYyM2dOTlVyVkwwOHlhWDNZTHND?= =?gb2312?B?WjZxbXNzdHlncUVvWVA4Z0phVDlzRC8xZ1RJT0owd0NTSDlaZVJrcUhFNXdE?= =?gb2312?B?QkNNVVJ2c25rcE9pVnVxK2JDNnBLYWJCcFhjMmtHTjMyZUk2ZmMxVkVHYm5k?= =?gb2312?B?eDZXYlZ6ZUpyalZIc1YrMnpPMUdhcUk1NzBjbXA3Q0tzY09oeFloYzZrMjUv?= =?gb2312?B?WitGT3BnVlBuQ0Y5dHZBMEo3M3BQQ1loQktESVBHSHFKOEVvSGlXeStaUlZD?= =?gb2312?B?MTVHY0k5N0dFRVhNYWo1c2p5NVRpNXBDYm9EaFJwSForMXQ2SWpZYXZ0T2pI?= =?gb2312?B?aE1MUU1hQ3BHL3lHY2kranlnQXU5Q0t2SWxKMXlLNFNhTG1zSDhtN2daR1Ex?= =?gb2312?B?YVdzb3BGTGhKVFBMS2U5amZxY3h2RWs1OFZ1ZDBCM05VMXZFWEpmUjZaTUR4?= =?gb2312?B?ams4UXVBS3hLZVZiY0k0SUVXWlYxYXY5K2tOTjJma3MxdHBsUnBvc000UElW?= =?gb2312?B?dnJiWTZ1dHR1d1hVRE9xKytwQ2g4QXZka0t4Wk5YOGt5Y2NiZWNGcG9vY2Nu?= =?gb2312?B?S0hjUXNTOXkxc2t4OTF1aEtlcmRqMEEwZThnTk1Ia1BwWHVXTUZhcDM5UjJm?= =?gb2312?B?aHVlWnVGaHhNZUJkOW0zRXpOMmZDa3QwZFpOcU1tT09Fc01vQ2JQSTZLUEJW?= =?gb2312?B?bytYSXpYa2xmMHpWZy9mMlhqSTdIOVRCaWpVYUNWRnFnMjZpdGwwb1RIck10?= =?gb2312?B?SldvbXZReFBKbm9NY1Blc0d1VXZ0c29rSi9yMXFUMVNZZGlucitxemxCM0Ni?= =?gb2312?B?QWgwMEFzQzB4TXNnbkF0eU5Eb0JxSHFNd0dDaDBES0w0K1VVbUxZT0dRVVNw?= =?gb2312?B?aGp2Vnp1VEZ6ZFg4Z1pndVdXWmUzQjNobXhpQ2RGUEtHSEZocjRhRm1WOExU?= =?gb2312?B?NTlYVy9CVkg3Y0tBdjcwcjdSRFExQW1hcGdwT25zQm12UXYvZ0UxZ0ZFa0wv?= =?gb2312?B?b0dITk9KVE9vcXpSUHZsUG5SMEs4YWIrVURraGI3QVRwTzhwd2RoMnIyQ0xX?= =?gb2312?B?aU1LZ1VROTJTRWhnbU85elB6QjVZaDFwRGFoZCtzeVhPYUpSQW5TY0hHa2NC?= =?gb2312?B?a2MzRkZzRFNVMytydUswSTBaYmFLSW8zU3ZjN1lINUI4VHJxaEhiOFZPTkRS?= =?gb2312?B?NVBKb21NK3JTOTc0R1hWQ2prWjFjejk2QTUzbFp4a3VXcEVyVmFQVUlweXBP?= =?gb2312?B?U3lFSndDU2FRVHdzU054U2cwMUlTeEJnZU9vYUhhUjlOcXYxazdvRXR3ZlB4?= =?gb2312?Q?WKGoqbBSFmHeup4yuTZGbiw=3D?= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: a5715b94-62c1-439c-3a61-08d9d9b468b0 X-MS-Exchange-CrossTenant-AuthSource: DB7PR07MB5546.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jan 2022 12:25:12.4875 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: I/WaWu3LPK16bwdTinuUtVVD2hTv0DDKsnZXICuRvfLdGUUMUm99YUh6JASKDR3eH2Ab+MUPExaw8F4f+KwdUg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR07MB8491 Archived-At: Subject: Re: [ippm] I-D Action: draft-ietf-ippm-ioam-yang-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2022 12:25:20 -0000 On 14/01/2022 10:30, Tianran Zhou wrote: > Hi Tom, > I am sorry. The date is not correct. But the date in the YANG model is correct. > The major improvement is about the ioam info. > We collected some requirements and added in. Indeed; it is completely different. I don't know what I was looking at:-( 'namespace' confuses me. In ioam-data, it is 16 bit. Here it is identity. How do you map one to the other? pot-type seems similar; it is an 8-bit field for which you have type and identity. I think that ioam-data does a bad job of explaining how pot-type are identified. The text has changed a lot but not in a coherent manner IMHO and if you are trying to model something incoherent, well, then the model is likely to be incoherent. (I appreciate that ioam-data is with the RFC Editor so there is hope for it yet:-) I would find it clearer if the five options were listed as such, in a list, with references, probably in the Introduction. What is a timestamp subsecond? Is it a nanosecond? /prove/proof/ mostly fixed but not quite all; likewise edge-to-edge /http:tools/https:datatracker/ /RFC RFC 8532/RFC 8532/ and it needs adding to the I-D References /for encapsulate/ to encapsulate/ ("for encapsulation" is fine) YANG module references I find clearer as e.g. "RFC YYYY: Data Fields for In-situ OAM" since that is the name for the long term, I-D names are ephemeral I think that many of the YANG identifiers are prolix e..g. identity ipv6-protocol base base-protocol only needs identity ipv6 base protocol IMHO Any use of base, protocol, type , action etc is likely to be unnecessary, confusing even; probably most uses of trace too. You may find that your YANG Doctor makes a few hundred comments along these lines - most do. Security Considerations is out of date Tom Petch > > Best, > Tianran > > > ________________________________ > > Sent from WeLink > ·¢¼þÈË£º t petch> > ÊÕ¼þÈË£º ippm> > Ö÷Ì⣺ Re: [ippm] I-D Action: draft-ietf-ippm-ioam-yang-02.txt > ʱ¼ä£º 2022-01-14 18:00:43 > > This looks like 'it has been another six months so it is time to > re-submit' I-D. I note that the YANG module date remains at 2021 which > seems a useful indicator! > > Tom Petch > > On 14/01/2022 01:08, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the IP Performance Measurement WG of the IETF. >> >> Title : A YANG Data Model for In-Situ OAM >> Authors : Tianran Zhou >> Jim Guichard >> Frank Brockners >> Srihari Raghavan >> Filename : draft-ietf-ippm-ioam-yang-02.txt >> Pages : 26 >> Date : 2022-01-13 >> >> Abstract: >> In-situ Operations, Administration, and Maintenance (IOAM) records >> operational and telemetry information in user packets while the >> packets traverse a path between two points in the network. This >> document defines a YANG module for the IOAM function. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-yang/ >> >> There is also an htmlized version available at: >> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-yang-02 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-ioam-yang-02 >> >> >> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts >> >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> . >> > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > From nobody Wed Jan 19 22:12:15 2022 Return-Path: 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 AFDA23A1708; Wed, 19 Jan 2022 22:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ojYAWLWqGAB; Wed, 19 Jan 2022 22:12:04 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77F823A1706; Wed, 19 Jan 2022 22:12:04 -0800 (PST) Received: from fraeml735-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JfXBp5V6fz67xXB; Thu, 20 Jan 2022 14:08:50 +0800 (CST) Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by fraeml735-chm.china.huawei.com (10.206.15.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2308.21; Thu, 20 Jan 2022 07:12:00 +0100 Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by dggeme754-chm.china.huawei.com (10.3.19.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.21; Thu, 20 Jan 2022 14:11:59 +0800 Received: from dggeme752-chm.china.huawei.com ([10.6.80.76]) by dggeme752-chm.china.huawei.com ([10.6.80.76]) with mapi id 15.01.2308.021; Thu, 20 Jan 2022 14:11:59 +0800 From: "Wubo (lana)" To: Greg Mirsky , "adrian@olddog.co.uk" CC: "opsawg@ietf.org" , "ippm-chairs@ietf.org" , "draft-ietf-opsawg-yang-vpn-service-pm@ietf.org" , "ippm@ietf.org" Thread-Topic: [OPSAWG] A review of draft-ietf-opsawg-yang-vpn-service-pm-01 Thread-Index: AdgNQNndg+3Rj8X+R7aMWDB3e1AoaQ== Date: Thu, 20 Jan 2022 06:11:58 +0000 Message-ID: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.102.123] Content-Type: multipart/alternative; boundary="_000_fd72d945f4354032be2198fec7ddaa88huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] [OPSAWG] A review of draft-ietf-opsawg-yang-vpn-service-pm-01 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2022 06:12:10 -0000 --_000_fd72d945f4354032be2198fec7ddaa88huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR3JlZywNCg0KVGhhbmtzIGZvciB0aGUgY29tbWVudHMuIEJ1dCBJIGFtIG5vdCBzdXJlIEkg dW5kZXJzdGFuZCB0aGlzIHF1ZXN0aW9uLg0KDQpBc3N1bWluZyB0aGUgcXVlc3Rpb24gaXMgYWJv dXQgbW9kZWxsaW5nIGNvbnNpZGVyYXRpb24sIHdlIGhhdmUgYWRkZWQgdGhlIGZvbGxvd2luZyBk ZXNjcmlwdGlvbiB0byB0aGUgbmV3IHZlcnNpb246DQoNClRoZSBwZXJmb3JtYW5jZSBvZiBWUE4g c2VydmljZXMgaXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBwZXJmb3JtYW5jZQ0KICAgY2hhbmdlcyBv ZiB0aGUgdW5kZXJsYXkgbmV0d29yayB0aGF0IGNhcnJpZXMgVlBOIHNlcnZpY2VzLCBzdWNoIGFz DQogICB0aGUgZGVsYXkgb2YgdGhlIHVuZGVybGF5IHR1bm5lbHMgYW5kIHRoZSBwYWNrZXQgbG9z cyBzdGF0dXMgb2YgdGhlDQogICBkZXZpY2UgaW50ZXJmYWNlcy4gIEFkZGl0aW9uYWxseSwgdGhl IGludGVncmF0aW9uIG9mIExheWVyIDIvTGF5ZXIgMw0KICAgVlBOIHBlcmZvcm1hbmNlIGFuZCBu ZXR3b3JrIHBlcmZvcm1hbmNlIGRhdGEgZW5hYmxlcyB0aGUgb3JjaGVzdHJhdG9yDQogICB0byBz dWJzY3JpYmUgdG8gVlBOIHNlcnZpY2UgcGVyZm9ybWFuY2UgaW4gYSB1bmlmaWVkIG1hbm5lci4N CiAgIFRoZXJlZm9yZSwgdGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgWUFORyBtb2R1bGUgZm9yIGJv dGggbmV0d29yayBhbmQNCiAgIFZQTiBzZXJ2aWNlIHBlcmZvcm1hbmNlIG1vbml0b3JpbmcgKFBN KS4gIFRoZSBtb2R1bGUgY2FuIGJlIHVzZWQgdG8NCiAgIG1vbml0b3IgYW5kIG1hbmFnZSBuZXR3 b3JrIHBlcmZvcm1hbmNlIG9uIHRoZSB0b3BvbG9neSBsZXZlbCBvciB0aGUNCiAgIHNlcnZpY2Ug dG9wb2xvZ3kgYmV0d2VlbiBWUE4gc2l0ZXMsIGluIHBhcnRpY3VsYXINCg0KSG9wZSB0aGlzIGhl bHBzLg0KDQpUaGFua3MsDQpCbw0KDQrlj5Hku7bkuro6IE9QU0FXRyBbbWFpbHRvOm9wc2F3Zy1i b3VuY2VzQGlldGYub3JnXSDku6PooaggR3JlZyBNaXJza3kNCuWPkemAgeaXtumXtDogMjAyMuW5 tDHmnIgxN+aXpSA3OjE1DQrmlLbku7bkuro6IGFkcmlhbkBvbGRkb2cuY28udWsNCuaKhOmAgTog b3BzYXdnQGlldGYub3JnOyBpcHBtLWNoYWlyc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1vcHNhd2ct eWFuZy12cG4tc2VydmljZS1wbUBpZXRmLm9yZzsgaXBwbUBpZXRmLm9yZw0K5Li76aKYOiBSZTog W09QU0FXR10gQSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1vcHNhd2cteWFuZy12cG4tc2VydmljZS1w bS0wMQ0KDQpIaSBBZHJpYW4sIHRoZSBBdXRob3JzLCBhbmQgQWxsLA0KdGhhbmsgeW91IEFkcmlh biBmb3IgcmV2aWV3aW5nIHRoZSBkcmFmdCBhbmQgaW52aXRpbmcgZnVydGhlciBkaXNjdXNzaW9u LiBJJ3ZlIGNvbW1lbnRlZCBvbiB0aGlzIHdvcmsgZWFybGllciBzdWdnZXN0aW5nIGNvbnNpZGVy aW5nIHRoZSBwZXJmb3JtYW5jZSBtZXRyaWNzIGxpc3RlZCBpbiB0aGUgU1RBTVAgWUFORyBkYXRh IG1vZGVsLiBJIGFwcHJlY2lhdGUgdGhhdCB0aGUgQXV0aG9ycyBoYXZlIGZvdW5kIHRoZW0gaGVs cGZ1bCBhbmQgaW5jbHVkZWQgdGhlbSBpbiB0aGlzIG1vZGVsLiBCdXQgSSBzdGlsbCB3b25kZXIg d2hhdCwgaWYgYW55dGhpbmcsIGlzIHNwZWNpYWwgZm9yIGEgVlBOIHNlcnZpY2UgZnJvbSBhIHBl cmZvcm1hbmNlIG1ldHJpY3MgcGVyc3BlY3RpdmUgY29tcGFyZWQgdG8sIGZvciBleGFtcGxlLCBh biB1bmRlcmxheT8gV291bGQgaXQgYmUgcG9zc2libGUgYW5kIHNpbXBsZXIgdG8gaGF2ZSBhIHNp bmdsZSBQTSBkYXRhIG1vZGVsIGFwcGxpY2FibGUgdG8gYW55IHVuZGVybGF5IG9yIG92ZXJsYXkg bmV0d29yaz8NCg0KUmVnYXJkcywNCkdyZWcNCg0KT24gU3VuLCBKYW4gMTYsIDIwMjIgYXQgODox NiBBTSBBZHJpYW4gRmFycmVsIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPG1haWx0bzphZHJpYW5Ab2xk ZG9nLmNvLnVrPj4gd3JvdGU6DQpIaSBhdXRob3JzLA0KDQpUaGlzIGRyYWZ0IGhhcyBiZWVuIHNh ZmVseSBpbnNpZGUgdGhlIE9QU0FXRyBmb3IgYSB3aGlsZSwgc28gSSB0aG91Z2gNCml0IHdhcyBw cm9iYWJseSBkdWUgYSByZXZpZXcuDQoNCiJUaGUgdXN1YWwiIHR3byB0b3AtbGV2ZWwgaXNzdWVz Og0KDQotIFRoZSBkcmFmdCBleHBpcmVkIGVhcmxpZXIgdGhpcyBtb250aCwgc28geW91IG5lZWQg YXQgYSBsZWFzdCBhDQogIGtlZXAtYWxpdmUgdmVyc2lvbi4NCg0KLSBUaGUgZHJhZnQgaGFzIG1v cmUgdGhhbiBmaXZlIGZyb250LXBhZ2UgYXV0aG9ycyBzbyB0aGUgQUQgb3IgUkZDDQogIEVkaXRv ciB3aWxsIG9iamVjdC4gSXQgaXMgcHJvYmFibHkgYmVzdCBmb3IgeW91IHRvIHJlc29sdmUgdGhp cyBpc3N1ZQ0KICBzb29uZXIgcmF0aGVyIHRoYW4gbGF0ZXIuDQoNCk90aGVyd2lzZSwgbXkgY29t bWVudHMgYXJlIGEgY29sbGVjdGlvbiBvZiBzbWFsbCBuaXRzIGFuZCBub3RoaW5nDQphbGFybWlu Zy4gIFRoYW5rcyBmb3IgeW91ciB3b3JrIG9uIHRoaXMgZG9jdW1lbnQuDQoNCkJlc3QsDQpBZHJp YW4NCg0KPT0gUXVlc3Rpb25zID09DQoNCkxvb2tpbmcgYXQgRmlndXJlIDEsIGFuIG9idmlvdXMg cXVlc3Rpb24gaXMgd2h5IHRoaXMgbW9kZWwgZG9lc24ndA0KYXVnbWVudCB0aGUgTDIvTDNOTSBv ciB0aGUgY29tbW9uIFZQTiBtb2RlbC4gSXQgaXMgT0sgKGZvciBtZSkgdGhhdCB5b3UNCmhhdmUg Y2hvc2VuIHRvIGF1Z21lbnQgdGhlIG5ldHdvcmsgdG9wb2xvZ3kgbW9kZWwsIGJ1dCBpdCBpcyBu b3QgY2xlYXINCnRvIHRoZSByZWFkZXIgd2h5IHlvdSBoYXZlIGRvbmUgdGhpcy4NCg0KLS0tDQoN Ckkgd29uZGVyIHdoZXRoZXIgdGhlIHdvcmsgaW4gdGhpcyBkb2N1bWVudCB3b3VsZCBiZW5lZml0 IGZyb20gdXNpbmcNCmRhdGEgdGFncyAoZHJhZnQtaWV0Zi1uZXRtb2Qtbm9kZS10YWdzKS4gSSBt aWdodCBiZSB3cm9uZywgYnV0IGl0IHNlZW1zDQpwYXJ0aWN1bGFybHkgcmVsYXRlZCBhbmQgdXNl ZnVsLg0KDQotLS0NCg0KSWYsIGluIEZpZ3VyZSAzLCBWUE4xIGlzIGNvbmZpZ3VyZWQgYXMgaHVi IGFuZCBzcG9rZSB3aXRoIFMxQSBhcyB0aGUNCmh1Yiwgd2h5IGlzIHRoZXJlIGEgbGluayBpbiB0 aGUgdmlydHVhbCBuZXR3b3JrIGJldHdlZW4gVk4yIGFuZCBWTjM/DQoNCi0tLQ0KDQo1Lg0KDQpH ZW5lcmFsIHF1ZXN0aW9uIGFib3V0IGNvdW50ZXJzIGJhc2VkIG9uIG15IG1lbW9yeSBvZiBob3cg d2UgZGlkIE1JQnMNCihTbyBJIGFtIG9sZCEgUXVpdGUgcG9zc2libGUgdGhhdCBZQU5HIGRvZXMg dGhpcyBkaWZmZXJlbnRseS4pIERvbid0DQp5b3UgbmVlZCBzb21ldGhpbmcgdG8gaGFuZGxlIHJl c2V0cz8gVGhhdCBpcywgdG8gZGlzdGluZ3Vpc2ggYmV0d2Vlbg0Kd3JhcHBpbmcgYW5kIHJlc2V0 dGluZywgd2UgdXNlZCB0byBpbmNsdWRlIGEgdGltZXN0YW1wIGZvciB3aGVuIHRoZQ0KY291bnRl cnMgd2VyZSBsYXN0IHJlc2V0LiBTb21ldGltZXMgdGhpcyB3YXMgYSB0aW1lc3RhbXAgcGVyIGNv dW50ZXIsDQpidXQgdXN1YWxseSBlbm91Z2ggZm9yIG9uZSB0aW1lc3RhbXAgYWNyb3NzIGFsbCBj b3VudGVycy4NCg0KKFRoaXMgcHJvYmFibHkgbWFrZXMgYSBkaWZmZXJlbmNlIHRvIHRoZSBnYXVn ZXMgYW5kIHBlcmNlbnRpbGVzLCB0b28uKQ0KDQpSZS1yZWFkaW5nLCBpdCBpcyBwb3NzaWJsZSB0 aGF0IHRoaXMgaXMgY292ZXJlZCBieSAncmVmZXJlbmNlLXRpbWUnIGFuZA0KJ21lYXN1cmVtZW50 LWludGVydmFsJy4gIElmIHNvLCB0aGlzIGNvdWxkIGJlIGEgbG90IGNsZWFyZXIgaW4gNC40Lg0K DQotLS0NCg0KNS4NCg0KICAgICAgbGVhZiBwbS1zb3VyY2Ugew0KICAgICAgICB0eXBlIHN0cmlu ZzsNCiAgICAgICAgY29uZmlnIGZhbHNlOw0KICAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAg ICJUaGUgT0FNIHRvb2wgdXNlZCB0byBjb2xsZWN0IHRoZSBQTSBkYXRhLiI7DQogICAgICB9DQoN CkknbSBub3QgY29udmluY2VkIHRoYXQgdXNpbmcgYSBzdHJpbmcgaGVyZSBpcyBoZWxwZnVsLiBI b3cgZG9lcyB0aGUNCmRldmljZSBrbm93IHdoYXQgc3RyaW5nIHRvIHVzZSB0byBjb252ZXkgbWVh bmluZyB0byB0aGUgYXBwbGljYXRpb24/DQoNCk9yIGlzIHRoZSBwb2ludCB0aGF0IHRoaXMgaXMg anVzdCBwcmludGFibGUgaW5mb3JtYXRpb24gZm9yIGRpc3BsYXkgYW5kDQpodW1hbiBjb25zdW1w dGlvbj8gSWYgc28sIHBlcmhhcHMgYSBub3RlIHRvIHRoaXMgZWZmZWN0IGluIFNlY3Rpb24gNC40 Lg0KDQo9PSBOaXRzID09PQ0KDQpBYnN0cmFjdA0KDQpJdCB3b3VsZCBiZSBuaWNlIHRvIHNheSB3 aGF0IHRoZSBtb2RlbCBpbiA4MzQ1IGlzLiBTby4uLg0KDQogICBUaGUgZGF0YSBtb2RlbCBmb3Ig bmV0d29yayB0b3BvbG9naWVzIGRlZmluZWQgaW4gUkZDIDgzNDUgaW50cm9kdWNlcw0KICAgdmVy dGljYWwgbGF5ZXJpbmcgcmVsYXRpb25zaGlwcyBiZXR3ZWVuIG5ldHdvcmtzIHRoYXQgY2FuIGJl DQogICBhdWdtZW50ZWQgdG8gY292ZXIgbmV0d29yayBhbmQgc2VydmljZSB0b3BvbG9naWVzLg0K DQotLS0NCg0KQWJzdHJhY3QNCg0KSSB0aGluayBQTSBzdGFuZHMgZm9yICdwZXJmb3JtYW5jZSBt b25pdG9yaW5nJyBub3QgJ25ldHdvcmsgcGVyZm9ybWFuY2UNCm1vbml0b3JpbmcnLCBzbyBmb3Ig dGhlIGF2b2lkYW5jZSBvZiBkb3VidC4uLg0KDQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBZ QU5HIG1vZHVsZSBmb3INCiAgIHBlcmZvcm1hbmNlIG1vbml0b3JpbmcgKFBNKSBvZiBib3RoIG5l dHdvcmtzIGFuZCBWUE4gc2VydmljZXMgdGhhdA0KICAgY2FuIGJlIHVzZWQgdG8gbW9uaXRvciBh bmQgbWFuYWdlIG5ldHdvcmsgcGVyZm9ybWFuY2Ugb24gdGhlIHRvcG9sb2d5DQogICBhdCBoaWdo ZXIgbGF5ZXIgb3IgdGhlIHNlcnZpY2UgdG9wb2xvZ3kgYmV0d2VlbiBWUE4gc2l0ZXMuDQoNCi0t LQ0KDQoyLg0KDQpZb3UgaGF2ZSB0aGUgQkNQIDE0IGJvaWxlcnBsYXRlLCBidXQgdGhlIHVzZXMg b2YgInNob3VsZCIgYW5kICJtdXN0IiBpbg0KdGhlIGRvY3VtZW50IGFyZSBpbiBsb3dlciBjYXNl LiBUaGVyZSBpcyBvbmUgdXNlIG9mIHVwcGVyIGNhc2UgIk1BWSIgaW4NCnRoZSBTZWN1cml0eSBD b25zaWRlcmF0aW9ucyB3aGljaCBzaG91bGQgYmUsIEkgdGhpbmssIGxvd2VyIGNhc2Ugc2luY2UN Cml0IGlzIGEgc3RhdGVtZW50IG9mIGZhY3Qgbm90IGd1aWRhbmNlIHRvIGFuIGltcGxlbWVudGVy IG9mIHRoaXMgc3BlYy4NCg0KLS0tDQoNCjMuDQoNCnMvU3VjaCBhbiBpbmZvcm1hdGlvbi9TdWNo IGluZm9ybWF0aW9uLw0Kcy9zaG91bGQgYmUgc2V0dXAvc2hvdWxkIGJlIHNldCB1cC8NCnMvdXNp bmcgbmV0d29yayBwZXJmb3JtYW5jZS91c2luZyBhIG5ldHdvcmsgcGVyZm9ybWFuY2UvDQpzL2lu Zm9ybWF0aW9uIGZyb20gVHJhZmZpYy9pbmZvcm1hdGlvbiBmcm9tIHRoZSBUcmFmZmljLw0KDQot LS0NCg0KVGhlIExlZ2VuZCBmb3IgRmlndXJlIDMgY291bGQgdXNlZnVsbHkgYWRkDQogICBTOlNp dGUNCg0KSXQgbWlnaHQgYWxzbyBoZWxwIHRvIGluZGljYXRlIHRoZSBkaWZmZXJlbmNlIGJldHdl ZW4gbGlua3MgdGhhdCBhcmUNCnNob3duIGFzIHwgYW5kIG1hcHBpbmdzIHRoYXQgYXJlIHNob3du IGFzIDoNCg0KLS0tDQoNCjQuMg0KDQpzL2RvIG5vdCBuZWVkIHRvIGJlIGV4dGVuZGVkLi9kb2Vz IG5vdCBuZWVkIHRvIGJlIGV4dGVuZGVkLi8NCg0KLS0tDQoNCjQuMiwgNC4zDQoNCkZpZ3VyZXMg NCBhbmQgNSBzaG91bGQgYmUgcmVmZXJyZWQgdG8gZnJvbSB0aGUgdGV4dC4NCg0KLS0tDQoNCjQu NA0KDQpPTEQNCiAgICAgIFNldHRpbmcgYSBwZXJjZW50aWxlIGludG8NCiAgICAgIDAuMDAgaW5k aWNhdGVzIHRoZSBjbGllbnQgaXMgbm90IGludGVyZXN0ZWQgaW4gcmVjZWl2aW5nDQogICAgICBw YXJ0aWN1bGFyIHBlcmNlbnRpbGUuDQpORVcNCiAgICAgIFNldHRpbmcgYSBwZXJjZW50aWxlIHRv DQogICAgICAwLjAwIGluZGljYXRlcyB0aGUgY2xpZW50IGlzIG5vdCBpbnRlcmVzdGVkIGluIHJl Y2VpdmluZw0KICAgICAgdGhhdCBwYXJ0aWN1bGFyIHBlcmNlbnRpbGUuDQpFTkQNCg0Kcy9tZXRy aWMgKGUuZy4vbWV0cmljIChlLmcuLC8NCg0KT0xEDQogICAicmVmZXJlbmNlLXRpbWUiICJtZWFz dXJlbWVudC1pbnRlcnZhbCINCk5FVw0KICAgInJlZmVyZW5jZS10aW1lIiBhbmQgIm1lYXN1cmVt ZW50LWludGVydmFsIg0KRU5EDQoNCi0tLQ0KDQo1Lg0KDQogICBUaGUgImlldGYtbmV0d29yay12 cG4tcG0iIG1vZHVsZSB1c2VzIHR5cGVzIGRlZmluZWQgaW4gW1JGQzgzNDVdLA0KICAgW1JGQzY5 OTFdLCBhbmQgW1JGQzg1MzJdLg0KDQpZb3UgcHJvYmFibHkgbmVlZCB0byBhZGQgW0ktRC5pZXRm LW9wc2F3Zy12cG4tY29tbW9uXS4NCg0KICAgICAgIlJGQyBDQ0NDOiBBIExheWVyIDIvMyBWUE4g Q29tbW9uIFlBTkcgTW9kZWwiOw0KDQpJIHRoaW5rIHlvdSBuZWVkIGEgbm90ZSB0byB0aGUgUkZD IEVkaXRvciB0byBjaGFuZ2UgdGhhdCAoYWx0aG91Z2ggaXQNCmlzIGxpa2VseSB0aGF0IHRoZSBS RkMgd2lsbCBjb21lIG91dCByZWxhdGl2ZWx5IHNvb24gYW5kIHlvdSBtYXkgZ2V0IHRvDQpmaXgg aXQgdXAgeW91cnNlbGYpLg0KDQpTaW1pbGFybHkuLi4NCg0KICAgICBUaGlzIHZlcnNpb24gb2Yg dGhpcyBZQU5HIG1vZHVsZSBpcyBwYXJ0IG9mIFJGQyBYWFhYOyBzZWUNCiAgICAgdGhlIFJGQyBp dHNlbGYgZm9yIGZ1bGwgbGVnYWwgbm90aWNlcy4iOw0KDQogIHJldmlzaW9uIDIwMjEtMDctMDYg ew0KICAgIGRlc2NyaXB0aW9uDQogICAgICAiSW5pdGlhbCByZXZpc2lvbi4iOw0KICAgIHJlZmVy ZW5jZQ0KICAgICAgIlJGQyBYWFhYOiBBIFlBTkcgTW9kZWwgZm9yIE5ldHdvcmsgYW5kIFZQTiBT ZXJ2aWNlIFBlcmZvcm1hbmNlDQogICAgICAgICAgICAgICAgIE1vbml0b3JpbmciOw0KDQpZb3Ug bmVlZCBhIG5vdGUgdG8gdGhlIFJGQyBFZGl0b3IgdG8gZml4IHRoaXMgdXAuDQoNCi0tLQ0KDQo1 Lg0KDQpTaG91bGRuJ3QgJ3BlcmNlbnRpbGUnIGFsc28gaGF2ZSBhIHJhbmdlPw0KDQotLS0NCg0K Ni4NCg0KICAgVGhlcmUgYXJlIGEgbnVtYmVyIG9mIGRhdGEgbm9kZXMgZGVmaW5lZCBpbiB0aGlz IFlBTkcgbW9kdWxlIHRoYXQgYXJlDQogICB3cml0YWJsZS9jcmVhdGFibGUvZGVsZXRhYmxlIChp LmUuLCBjb25maWcgdHJ1ZSwgd2hpY2ggaXMgdGhlDQogICBkZWZhdWx0KS4gIFRoZXNlIGRhdGEg bm9kZXMgbWF5IGJlIGNvbnNpZGVyZWQgc2Vuc2l0aXZlIG9yIHZ1bG5lcmFibGUNCiAgIGluIHNv bWUgbmV0d29yayBlbnZpcm9ubWVudHMuICBXcml0ZSBvcGVyYXRpb25zIChlLmcuLCBlZGl0LWNv bmZpZykNCiAgIHRvIHRoZXNlIGRhdGEgbm9kZXMgd2l0aG91dCBwcm9wZXIgcHJvdGVjdGlvbiBj YW4gaGF2ZSBhIG5lZ2F0aXZlDQogICBlZmZlY3Qgb24gbmV0d29yayBvcGVyYXRpb25zLiAgVGhl c2UgYXJlIHRoZSBzdWJ0cmVlcyBhbmQgZGF0YSBub2Rlcw0KICAgYW5kIHRoZWlyIHNlbnNpdGl2 aXR5L3Z1bG5lcmFiaWxpdHk6DQoNCiAgIG8gIC9udzpuZXR3b3Jrcy9udzpuZXR3b3JrL3N2Yy10 b3BvOnN2Yy10ZWxlbWV0cnktYXR0cmlidXRlcw0KDQogICBvICAvbnc6bmV0d29ya3Mvbnc6bmV0 d29yay9udzpub2RlL3N2Yy10b3BvOm5vZGUtYXR0cmlidXRlcw0KDQpUaGlzIGZlZWxzIGxpa2Ug aXQgbWF5IGhhdmUgYmVlbiBibG9jayBjb3BpZWQgZnJvbSBhbm90aGVyIGRvY3VtZW50LiBJDQp0 aGluayBpdCBuZWVkcyB1cGRhdGluZyBmb3IgdGhlIHNwZWNpZmljIHdyaXRlYWJsZSBvYmplY3Rz IGluIHRoaXMNCm1vZHVsZSBhbmQgdGhlIG5lZ2F0aXZlIGVmZmVjdHMgKHdoaWNoIGFyZSBzdXJl bHkgbm90IHZlcnkgZ3JlYXQpIG9mDQp0aGVtIGJlaW5nIHVucHJvdGVjdGVkLg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT1BTQVdHIG1haWxpbmcg bGlzdA0KT1BTQVdHQGlldGYub3JnPG1haWx0bzpPUFNBV0dAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2F3Zw0K --_000_fd72d945f4354032be2198fec7ddaa88huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OuW+rui9r+mbhem7kTsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+SGkgR3JlZyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciB0aGUgY29tbWVudHMuIEJ1dCBJ IGFtIG5vdCBzdXJlIEkgdW5kZXJzdGFuZCB0aGlzIHF1ZXN0aW9uLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Bc3N1 bWluZyB0aGUgcXVlc3Rpb24gaXMgYWJvdXQgbW9kZWxsaW5nIGNvbnNpZGVyYXRpb24sIHdlIGhh dmUgYWRkZWQgdGhlIGZvbGxvd2luZyBkZXNjcmlwdGlvbiB0byB0aGUgbmV3IHZlcnNpb246PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlRoZSBwZXJmb3JtYW5jZSBvZiBWUE4gc2VydmljZXMgaXMgYXNzb2NpYXRl ZCB3aXRoIHRoZSBwZXJmb3JtYW5jZTxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyBjaGFuZ2VzIG9mIHRoZSB1bmRlcmxheSBuZXR3b3JrIHRoYXQgY2Fy cmllcyBWUE4gc2VydmljZXMsIHN1Y2ggYXM8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4mbmJzcDsmbmJzcDsgdGhlIGRlbGF5IG9mIHRoZSB1bmRlcmxheSB0dW5uZWxzIGFu ZCB0aGUgcGFja2V0IGxvc3Mgc3RhdHVzIG9mIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBkZXZpY2UgaW50ZXJmYWNlcy4mbmJzcDsgQWRkaXRp b25hbGx5LCB0aGUgaW50ZWdyYXRpb24gb2YgTGF5ZXIgMi9MYXllciAzPG86cD48L286cD48L3Nw YW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IFZQTiBwZXJmb3JtYW5jZSBhbmQg bmV0d29yayBwZXJmb3JtYW5jZSBkYXRhIGVuYWJsZXMgdGhlIG9yY2hlc3RyYXRvcjxvOnA+PC9v OnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyB0byBzdWJzY3JpYmUg dG8gVlBOIHNlcnZpY2UgcGVyZm9ybWFuY2UgaW4gYSB1bmlmaWVkIG1hbm5lci48bzpwPjwvbzpw Pjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgVGhlcmVmb3JlLCB0aGlz IGRvY3VtZW50IGRlZmluZXMgYSBZQU5HIG1vZHVsZSBmb3IgYm90aCBuZXR3b3JrIGFuZDxvOnA+ PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBWUE4gc2Vydmlj ZSBwZXJmb3JtYW5jZSBtb25pdG9yaW5nIChQTSkuJm5ic3A7IFRoZSBtb2R1bGUgY2FuIGJlIHVz ZWQgdG88bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsg bW9uaXRvciBhbmQgbWFuYWdlIG5ldHdvcmsgcGVyZm9ybWFuY2Ugb24gdGhlIHRvcG9sb2d5IGxl dmVsIG9yIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyBzZXJ2aWNlIHRvcG9sb2d5IGJldHdlZW4gVlBOIHNpdGVzLCBpbiBwYXJ0aWN1bGFyPG86 cD48L286cD48L3NwYW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5Ib3BlIHRoaXMgaGVscHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xp u5EmcXVvdDssc2Fucy1zZXJpZiI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+ PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPiBPUFNBV0cgW21h aWx0bzpvcHNhd2ctYm91bmNlc0BpZXRmLm9yZ10NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1z ZXJpZiI+5Luj6KGoIDwvc3Bhbj4NCjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2Vy aWYiPkdyZWcgTWlyc2t5PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7lj5Hp gIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/p m4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+IDIwMjI8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYi PuW5tDxzcGFuIGxhbmc9IkVOLVVTIj4xPC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj4xNzwv c3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+DQogNzoxNTxicj4NCjwvc3Bhbj48Yj7mlLbku7bk uro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBhZHJp YW5Ab2xkZG9nLmNvLnVrPGJyPg0KPC9zcGFuPjxiPuaKhOmAgTxzcGFuIGxhbmc9IkVOLVVTIj46 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IG9wc2F3Z0BpZXRmLm9yZzsgaXBwbS1jaGFp cnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtb3BzYXdnLXlhbmctdnBuLXNlcnZpY2UtcG1AaWV0Zi5v cmc7IGlwcG1AaWV0Zi5vcmc8YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMi Pjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUmU6IFtPUFNBV0ddIEEgcmV2aWV3IG9m IGRyYWZ0LWlldGYtb3BzYXdnLXlhbmctdnBuLXNlcnZpY2UtcG0tMDE8bzpwPjwvbzpwPjwvc3Bh bj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIEFkcmlhbiwgdGhlIEF1dGhvcnMsIGFuZCBBbGws PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPnRoYW5rIHlvdSBBZHJpYW4gZm9yIHJldmlld2luZyB0aGUg ZHJhZnQgYW5kIGludml0aW5nIGZ1cnRoZXIgZGlzY3Vzc2lvbi4gSSd2ZSBjb21tZW50ZWQgb24g dGhpcyB3b3JrIGVhcmxpZXIgc3VnZ2VzdGluZyBjb25zaWRlcmluZyB0aGUgcGVyZm9ybWFuY2Ug bWV0cmljcyBsaXN0ZWQgaW4gdGhlIFNUQU1QIFlBTkcgZGF0YSBtb2RlbC4gSSBhcHByZWNpYXRl IHRoYXQgdGhlIEF1dGhvcnMNCiBoYXZlIGZvdW5kIHRoZW0gaGVscGZ1bCBhbmQgaW5jbHVkZWQg dGhlbSBpbiB0aGlzIG1vZGVsLiBCdXQgSSBzdGlsbCB3b25kZXIgd2hhdCwmbmJzcDtpZiBhbnl0 aGluZywgaXMgc3BlY2lhbCBmb3IgYSBWUE4gc2VydmljZSBmcm9tIGEgcGVyZm9ybWFuY2UgbWV0 cmljcyZuYnNwO3BlcnNwZWN0aXZlIGNvbXBhcmVkIHRvLCBmb3IgZXhhbXBsZSwgYW4gdW5kZXJs YXk/IFdvdWxkIGl0IGJlIHBvc3NpYmxlIGFuZCBzaW1wbGVyJm5ic3A7dG8gaGF2ZSBhIHNpbmds ZSBQTSBkYXRhDQogbW9kZWwgYXBwbGljYWJsZSB0byBhbnkgdW5kZXJsYXkgb3Igb3ZlcmxheSBu ZXR3b3JrPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+R3JlZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFN1biwgSmFuIDE2LCAyMDIyIGF0IDg6MTYgQU0gQWRyaWFu IEZhcnJlbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWsiPmFkcmlhbkBv bGRkb2cuY28udWs8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIGF1dGhvcnMsPGJyPg0KPGJyPg0K VGhpcyBkcmFmdCBoYXMgYmVlbiBzYWZlbHkgaW5zaWRlIHRoZSBPUFNBV0cgZm9yIGEgd2hpbGUs IHNvIEkgdGhvdWdoPGJyPg0KaXQgd2FzIHByb2JhYmx5IGR1ZSBhIHJldmlldy48YnI+DQo8YnI+ DQomcXVvdDtUaGUgdXN1YWwmcXVvdDsgdHdvIHRvcC1sZXZlbCBpc3N1ZXM6PGJyPg0KPGJyPg0K LSBUaGUgZHJhZnQgZXhwaXJlZCBlYXJsaWVyIHRoaXMgbW9udGgsIHNvIHlvdSBuZWVkIGF0IGEg bGVhc3QgYSA8YnI+DQombmJzcDsga2VlcC1hbGl2ZSB2ZXJzaW9uLjxicj4NCjxicj4NCi0gVGhl IGRyYWZ0IGhhcyBtb3JlIHRoYW4gZml2ZSBmcm9udC1wYWdlIGF1dGhvcnMgc28gdGhlIEFEIG9y IFJGQzxicj4NCiZuYnNwOyBFZGl0b3Igd2lsbCBvYmplY3QuIEl0IGlzIHByb2JhYmx5IGJlc3Qg Zm9yIHlvdSB0byByZXNvbHZlIHRoaXMgaXNzdWU8YnI+DQombmJzcDsgc29vbmVyIHJhdGhlciB0 aGFuIGxhdGVyLjxicj4NCjxicj4NCk90aGVyd2lzZSwgbXkgY29tbWVudHMgYXJlIGEgY29sbGVj dGlvbiBvZiBzbWFsbCBuaXRzIGFuZCBub3RoaW5nIDxicj4NCmFsYXJtaW5nLiZuYnNwOyBUaGFu a3MgZm9yIHlvdXIgd29yayBvbiB0aGlzIGRvY3VtZW50Ljxicj4NCjxicj4NCkJlc3QsPGJyPg0K QWRyaWFuPGJyPg0KPGJyPg0KPT0gUXVlc3Rpb25zID09PGJyPg0KPGJyPg0KTG9va2luZyBhdCBG aWd1cmUgMSwgYW4gb2J2aW91cyBxdWVzdGlvbiBpcyB3aHkgdGhpcyBtb2RlbCBkb2Vzbid0PGJy Pg0KYXVnbWVudCB0aGUgTDIvTDNOTSBvciB0aGUgY29tbW9uIFZQTiBtb2RlbC4gSXQgaXMgT0sg KGZvciBtZSkgdGhhdCB5b3U8YnI+DQpoYXZlIGNob3NlbiB0byBhdWdtZW50IHRoZSBuZXR3b3Jr IHRvcG9sb2d5IG1vZGVsLCBidXQgaXQgaXMgbm90IGNsZWFyPGJyPg0KdG8gdGhlIHJlYWRlciB3 aHkgeW91IGhhdmUgZG9uZSB0aGlzLjxicj4NCjxicj4NCi0tLTxicj4NCjxicj4NCkkgd29uZGVy IHdoZXRoZXIgdGhlIHdvcmsgaW4gdGhpcyBkb2N1bWVudCB3b3VsZCBiZW5lZml0IGZyb20gdXNp bmc8YnI+DQpkYXRhIHRhZ3MgKGRyYWZ0LWlldGYtbmV0bW9kLW5vZGUtdGFncykuIEkgbWlnaHQg YmUgd3JvbmcsIGJ1dCBpdCBzZWVtcyA8YnI+DQpwYXJ0aWN1bGFybHkgcmVsYXRlZCBhbmQgdXNl ZnVsLjxicj4NCjxicj4NCi0tLTxicj4NCjxicj4NCklmLCBpbiBGaWd1cmUgMywgVlBOMSBpcyBj b25maWd1cmVkIGFzIGh1YiBhbmQgc3Bva2Ugd2l0aCBTMUEgYXMgdGhlIDxicj4NCmh1Yiwgd2h5 IGlzIHRoZXJlIGEgbGluayBpbiB0aGUgdmlydHVhbCBuZXR3b3JrIGJldHdlZW4gVk4yIGFuZCBW TjM/PGJyPg0KPGJyPg0KLS0tPGJyPg0KPGJyPg0KNS48YnI+DQo8YnI+DQpHZW5lcmFsIHF1ZXN0 aW9uIGFib3V0IGNvdW50ZXJzIGJhc2VkIG9uIG15IG1lbW9yeSBvZiBob3cgd2UgZGlkIE1JQnM8 YnI+DQooU28gSSBhbSBvbGQhIFF1aXRlIHBvc3NpYmxlIHRoYXQgWUFORyBkb2VzIHRoaXMgZGlm ZmVyZW50bHkuKSBEb24ndDxicj4NCnlvdSBuZWVkIHNvbWV0aGluZyB0byBoYW5kbGUgcmVzZXRz PyBUaGF0IGlzLCB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuPGJyPg0Kd3JhcHBpbmcgYW5kIHJlc2V0 dGluZywgd2UgdXNlZCB0byBpbmNsdWRlIGEgdGltZXN0YW1wIGZvciB3aGVuIHRoZTxicj4NCmNv dW50ZXJzIHdlcmUgbGFzdCByZXNldC4gU29tZXRpbWVzIHRoaXMgd2FzIGEgdGltZXN0YW1wIHBl ciBjb3VudGVyLDxicj4NCmJ1dCB1c3VhbGx5IGVub3VnaCBmb3Igb25lIHRpbWVzdGFtcCBhY3Jv c3MgYWxsIGNvdW50ZXJzLjxicj4NCjxicj4NCihUaGlzIHByb2JhYmx5IG1ha2VzIGEgZGlmZmVy ZW5jZSB0byB0aGUgZ2F1Z2VzIGFuZCBwZXJjZW50aWxlcywgdG9vLik8YnI+DQo8YnI+DQpSZS1y ZWFkaW5nLCBpdCBpcyBwb3NzaWJsZSB0aGF0IHRoaXMgaXMgY292ZXJlZCBieSAncmVmZXJlbmNl LXRpbWUnIGFuZDxicj4NCidtZWFzdXJlbWVudC1pbnRlcnZhbCcuJm5ic3A7IElmIHNvLCB0aGlz IGNvdWxkIGJlIGEgbG90IGNsZWFyZXIgaW4gNC40Ljxicj4NCjxicj4NCi0tLTxicj4NCjxicj4N CjUuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgbGVhZiBwbS1zb3VyY2Ugezxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0eXBlIHN0cmluZzs8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgY29uZmlnIGZhbHNlOzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBkZXNjcmlwdGlvbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJnF1b3Q7VGhlIE9BTSB0b29sIHVzZWQgdG8gY29sbGVjdCB0aGUgUE0gZGF0YS4mcXVvdDs7 PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgfTxicj4NCjxicj4NCkknbSBub3QgY29udmluY2Vk IHRoYXQgdXNpbmcgYSBzdHJpbmcgaGVyZSBpcyBoZWxwZnVsLiBIb3cgZG9lcyB0aGU8YnI+DQpk ZXZpY2Uga25vdyB3aGF0IHN0cmluZyB0byB1c2UgdG8gY29udmV5IG1lYW5pbmcgdG8gdGhlIGFw cGxpY2F0aW9uPyA8YnI+DQo8YnI+DQpPciBpcyB0aGUgcG9pbnQgdGhhdCB0aGlzIGlzIGp1c3Qg cHJpbnRhYmxlIGluZm9ybWF0aW9uIGZvciBkaXNwbGF5IGFuZDxicj4NCmh1bWFuIGNvbnN1bXB0 aW9uPyBJZiBzbywgcGVyaGFwcyBhIG5vdGUgdG8gdGhpcyBlZmZlY3QgaW4gU2VjdGlvbiA0LjQu PGJyPg0KPGJyPg0KPT0gTml0cyA9PT08YnI+DQo8YnI+DQpBYnN0cmFjdDxicj4NCjxicj4NCkl0 IHdvdWxkIGJlIG5pY2UgdG8gc2F5IHdoYXQgdGhlIG1vZGVsIGluIDgzNDUgaXMuIFNvLi4uPGJy Pg0KPGJyPg0KJm5ic3A7ICZuYnNwO1RoZSBkYXRhIG1vZGVsIGZvciBuZXR3b3JrIHRvcG9sb2dp ZXMgZGVmaW5lZCBpbiBSRkMgODM0NSBpbnRyb2R1Y2VzPGJyPg0KJm5ic3A7ICZuYnNwO3ZlcnRp Y2FsIGxheWVyaW5nIHJlbGF0aW9uc2hpcHMgYmV0d2VlbiBuZXR3b3JrcyB0aGF0IGNhbiBiZTxi cj4NCiZuYnNwOyAmbmJzcDthdWdtZW50ZWQgdG8gY292ZXIgbmV0d29yayBhbmQgc2VydmljZSB0 b3BvbG9naWVzLjxicj4NCjxicj4NCi0tLTxicj4NCjxicj4NCkFic3RyYWN0PGJyPg0KPGJyPg0K SSB0aGluayBQTSBzdGFuZHMgZm9yICdwZXJmb3JtYW5jZSBtb25pdG9yaW5nJyBub3QgJ25ldHdv cmsgcGVyZm9ybWFuY2UgPGJyPg0KbW9uaXRvcmluZycsIHNvIGZvciB0aGUgYXZvaWRhbmNlIG9m IGRvdWJ0Li4uPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgZGVmaW5lcyBh IFlBTkcgbW9kdWxlIGZvciA8YnI+DQombmJzcDsgJm5ic3A7cGVyZm9ybWFuY2UgbW9uaXRvcmlu ZyAoUE0pIG9mIGJvdGggbmV0d29ya3MgYW5kIFZQTiBzZXJ2aWNlcyB0aGF0PGJyPg0KJm5ic3A7 ICZuYnNwO2NhbiBiZSB1c2VkIHRvIG1vbml0b3IgYW5kIG1hbmFnZSBuZXR3b3JrIHBlcmZvcm1h bmNlIG9uIHRoZSB0b3BvbG9neTxicj4NCiZuYnNwOyAmbmJzcDthdCBoaWdoZXIgbGF5ZXIgb3Ig dGhlIHNlcnZpY2UgdG9wb2xvZ3kgYmV0d2VlbiBWUE4gc2l0ZXMuPGJyPg0KPGJyPg0KLS0tPGJy Pg0KPGJyPg0KMi48YnI+DQo8YnI+DQpZb3UgaGF2ZSB0aGUgQkNQIDE0IGJvaWxlcnBsYXRlLCBi dXQgdGhlIHVzZXMgb2YgJnF1b3Q7c2hvdWxkJnF1b3Q7IGFuZCAmcXVvdDttdXN0JnF1b3Q7IGlu PGJyPg0KdGhlIGRvY3VtZW50IGFyZSBpbiBsb3dlciBjYXNlLiBUaGVyZSBpcyBvbmUgdXNlIG9m IHVwcGVyIGNhc2UgJnF1b3Q7TUFZJnF1b3Q7IGluPGJyPg0KdGhlIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zIHdoaWNoIHNob3VsZCBiZSwgSSB0aGluaywgbG93ZXIgY2FzZSBzaW5jZTxicj4NCml0 IGlzIGEgc3RhdGVtZW50IG9mIGZhY3Qgbm90IGd1aWRhbmNlIHRvIGFuIGltcGxlbWVudGVyIG9m IHRoaXMgc3BlYy48YnI+DQo8YnI+DQotLS08YnI+DQo8YnI+DQozLjxicj4NCjxicj4NCnMvU3Vj aCBhbiBpbmZvcm1hdGlvbi9TdWNoIGluZm9ybWF0aW9uLzxicj4NCnMvc2hvdWxkIGJlIHNldHVw L3Nob3VsZCBiZSBzZXQgdXAvPGJyPg0Kcy91c2luZyBuZXR3b3JrIHBlcmZvcm1hbmNlL3VzaW5n IGEgbmV0d29yayBwZXJmb3JtYW5jZS88YnI+DQpzL2luZm9ybWF0aW9uIGZyb20gVHJhZmZpYy9p bmZvcm1hdGlvbiBmcm9tIHRoZSBUcmFmZmljLzxicj4NCjxicj4NCi0tLTxicj4NCjxicj4NClRo ZSBMZWdlbmQgZm9yIEZpZ3VyZSAzIGNvdWxkIHVzZWZ1bGx5IGFkZDxicj4NCiZuYnNwOyAmbmJz cDtTOlNpdGU8YnI+DQo8YnI+DQpJdCBtaWdodCBhbHNvIGhlbHAgdG8gaW5kaWNhdGUgdGhlIGRp ZmZlcmVuY2UgYmV0d2VlbiBsaW5rcyB0aGF0IGFyZTxicj4NCnNob3duIGFzIHwgYW5kIG1hcHBp bmdzIHRoYXQgYXJlIHNob3duIGFzIDo8YnI+DQo8YnI+DQotLS08YnI+DQo8YnI+DQo0LjI8YnI+ DQo8YnI+DQpzL2RvIG5vdCBuZWVkIHRvIGJlIGV4dGVuZGVkLi9kb2VzIG5vdCBuZWVkIHRvIGJl IGV4dGVuZGVkLi88YnI+DQo8YnI+DQotLS08YnI+DQo8YnI+DQo0LjIsIDQuMzxicj4NCjxicj4N CkZpZ3VyZXMgNCBhbmQgNSBzaG91bGQgYmUgcmVmZXJyZWQgdG8gZnJvbSB0aGUgdGV4dC48YnI+ DQo8YnI+DQotLS08YnI+DQo8YnI+DQo0LjQ8YnI+DQo8YnI+DQpPTEQ8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyBTZXR0aW5nIGEgcGVyY2VudGlsZSBpbnRvPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgMC4wMCBpbmRpY2F0ZXMgdGhlIGNsaWVudCBpcyBub3QgaW50ZXJlc3RlZCBpbiByZWNl aXZpbmc8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBwYXJ0aWN1bGFyIHBlcmNlbnRpbGUuPGJy Pg0KTkVXPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgU2V0dGluZyBhIHBlcmNlbnRpbGUgdG88 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAwLjAwIGluZGljYXRlcyB0aGUgY2xpZW50IGlzIG5v dCBpbnRlcmVzdGVkIGluIHJlY2VpdmluZzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoYXQg cGFydGljdWxhciBwZXJjZW50aWxlLjxicj4NCkVORDxicj4NCjxicj4NCnMvbWV0cmljIChlLmcu L21ldHJpYyAoZS5nLiwvPGJyPg0KPGJyPg0KT0xEJm5ic3A7ICZuYnNwOzxicj4NCiZuYnNwOyAm bmJzcDsmcXVvdDtyZWZlcmVuY2UtdGltZSZxdW90OyAmcXVvdDttZWFzdXJlbWVudC1pbnRlcnZh bCZxdW90Ozxicj4NCk5FVzxicj4NCiZuYnNwOyAmbmJzcDsmcXVvdDtyZWZlcmVuY2UtdGltZSZx dW90OyBhbmQgJnF1b3Q7bWVhc3VyZW1lbnQtaW50ZXJ2YWwmcXVvdDs8YnI+DQpFTkQ8YnI+DQo8 YnI+DQotLS08YnI+DQo8YnI+DQo1Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtUaGUgJnF1b3Q7 aWV0Zi1uZXR3b3JrLXZwbi1wbSZxdW90OyBtb2R1bGUgdXNlcyB0eXBlcyBkZWZpbmVkIGluIFtS RkM4MzQ1XSw8YnI+DQombmJzcDsgJm5ic3A7W1JGQzY5OTFdLCBhbmQgW1JGQzg1MzJdLjxicj4N Cjxicj4NCllvdSBwcm9iYWJseSBuZWVkIHRvIGFkZCBbSS1ELmlldGYtb3BzYXdnLXZwbi1jb21t b25dLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O1JGQyBDQ0NDOiBBIExh eWVyIDIvMyBWUE4gQ29tbW9uIFlBTkcgTW9kZWwmcXVvdDs7PGJyPg0KPGJyPg0KSSB0aGluayB5 b3UgbmVlZCBhIG5vdGUgdG8gdGhlIFJGQyBFZGl0b3IgdG8gY2hhbmdlIHRoYXQgKGFsdGhvdWdo IGl0PGJyPg0KaXMgbGlrZWx5IHRoYXQgdGhlIFJGQyB3aWxsIGNvbWUgb3V0IHJlbGF0aXZlbHkg c29vbiBhbmQgeW91IG1heSBnZXQgdG88YnI+DQpmaXggaXQgdXAgeW91cnNlbGYpLjxicj4NCjxi cj4NClNpbWlsYXJseS4uLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7VGhpcyB2ZXJz aW9uIG9mIHRoaXMgWUFORyBtb2R1bGUgaXMgcGFydCBvZiBSRkMgWFhYWDsgc2VlPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDt0aGUgUkZDIGl0c2VsZiBmb3IgZnVsbCBsZWdhbCBub3RpY2VzLiZx dW90Ozs8YnI+DQo8YnI+DQombmJzcDsgcmV2aXNpb24gMjAyMS0wNy0wNiB7PGJyPg0KJm5ic3A7 ICZuYnNwOyBkZXNjcmlwdGlvbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O0luaXRp YWwgcmV2aXNpb24uJnF1b3Q7Ozxicj4NCiZuYnNwOyAmbmJzcDsgcmVmZXJlbmNlPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7UkZDIFhYWFg6IEEgWUFORyBNb2RlbCBmb3IgTmV0d29y ayBhbmQgVlBOIFNlcnZpY2UgUGVyZm9ybWFuY2U8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO01vbml0b3JpbmcmcXVvdDs7 PGJyPg0KPGJyPg0KWW91IG5lZWQgYSBub3RlIHRvIHRoZSBSRkMgRWRpdG9yIHRvIGZpeCB0aGlz IHVwLjxicj4NCjxicj4NCi0tLTxicj4NCjxicj4NCjUuPGJyPg0KPGJyPg0KU2hvdWxkbid0ICdw ZXJjZW50aWxlJyBhbHNvIGhhdmUgYSByYW5nZT88YnI+DQo8YnI+DQotLS08YnI+DQo8YnI+DQo2 Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtUaGVyZSBhcmUgYSBudW1iZXIgb2YgZGF0YSBub2Rl cyBkZWZpbmVkIGluIHRoaXMgWUFORyBtb2R1bGUgdGhhdCBhcmU8YnI+DQombmJzcDsgJm5ic3A7 d3JpdGFibGUvY3JlYXRhYmxlL2RlbGV0YWJsZSAoaS5lLiwgY29uZmlnIHRydWUsIHdoaWNoIGlz IHRoZTxicj4NCiZuYnNwOyAmbmJzcDtkZWZhdWx0KS4mbmJzcDsgVGhlc2UgZGF0YSBub2RlcyBt YXkgYmUgY29uc2lkZXJlZCBzZW5zaXRpdmUgb3IgdnVsbmVyYWJsZTxicj4NCiZuYnNwOyAmbmJz cDtpbiBzb21lIG5ldHdvcmsgZW52aXJvbm1lbnRzLiZuYnNwOyBXcml0ZSBvcGVyYXRpb25zIChl LmcuLCBlZGl0LWNvbmZpZyk8YnI+DQombmJzcDsgJm5ic3A7dG8gdGhlc2UgZGF0YSBub2RlcyB3 aXRob3V0IHByb3BlciBwcm90ZWN0aW9uIGNhbiBoYXZlIGEgbmVnYXRpdmU8YnI+DQombmJzcDsg Jm5ic3A7ZWZmZWN0IG9uIG5ldHdvcmsgb3BlcmF0aW9ucy4mbmJzcDsgVGhlc2UgYXJlIHRoZSBz dWJ0cmVlcyBhbmQgZGF0YSBub2Rlczxicj4NCiZuYnNwOyAmbmJzcDthbmQgdGhlaXIgc2Vuc2l0 aXZpdHkvdnVsbmVyYWJpbGl0eTo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7byZuYnNwOyAvbnc6 bmV0d29ya3Mvbnc6bmV0d29yay9zdmMtdG9wbzpzdmMtdGVsZW1ldHJ5LWF0dHJpYnV0ZXM8YnI+ DQo8YnI+DQombmJzcDsgJm5ic3A7byZuYnNwOyAvbnc6bmV0d29ya3Mvbnc6bmV0d29yay9udzpu b2RlL3N2Yy10b3BvOm5vZGUtYXR0cmlidXRlczxicj4NCjxicj4NClRoaXMgZmVlbHMgbGlrZSBp dCBtYXkgaGF2ZSBiZWVuIGJsb2NrIGNvcGllZCBmcm9tIGFub3RoZXIgZG9jdW1lbnQuIEk8YnI+ DQp0aGluayBpdCBuZWVkcyB1cGRhdGluZyBmb3IgdGhlIHNwZWNpZmljIHdyaXRlYWJsZSBvYmpl Y3RzIGluIHRoaXM8YnI+DQptb2R1bGUgYW5kIHRoZSBuZWdhdGl2ZSBlZmZlY3RzICh3aGljaCBh cmUgc3VyZWx5IG5vdCB2ZXJ5IGdyZWF0KSBvZjxicj4NCnRoZW0gYmVpbmcgdW5wcm90ZWN0ZWQu PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpPUFNBV0cgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9QU0FXR0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9QU0FXR0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2F3ZyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzYXdnPC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_fd72d945f4354032be2198fec7ddaa88huaweicom_-- From nobody Sun Jan 23 22:23:24 2022 Return-Path: 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 7685E3A1CD1 for ; Sun, 23 Jan 2022 22:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGwkmmVjxltv for ; Sun, 23 Jan 2022 22:23:16 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02B8D3A1CBD for ; Sun, 23 Jan 2022 22:23:16 -0800 (PST) Received: from fraeml707-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Jj0Fg4dsPz67WSN for ; Mon, 24 Jan 2022 14:19:51 +0800 (CST) Received: from kwepeml100005.china.huawei.com (7.221.188.221) by fraeml707-chm.china.huawei.com (10.206.15.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Mon, 24 Jan 2022 07:23:13 +0100 Received: from kwepeml500004.china.huawei.com (7.221.188.141) by kwepeml100005.china.huawei.com (7.221.188.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Mon, 24 Jan 2022 14:23:11 +0800 Received: from kwepeml500004.china.huawei.com ([7.221.188.141]) by kwepeml500004.china.huawei.com ([7.221.188.141]) with mapi id 15.01.2308.021; Mon, 24 Jan 2022 14:23:11 +0800 From: Tianran Zhou To: "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt Thread-Index: AQHYEOoOM8BWGUje9EistfVjjUvI2qxxspug Date: Mon, 24 Jan 2022 06:23:11 +0000 Message-ID: References: <164300504281.12619.16642699818590435984@ietfa.amsl.com> In-Reply-To: <164300504281.12619.16642699818590435984@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.112.40.195] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2022 06:23:22 -0000 SGkgV0csDQoNCldlIHRoaW5rIHRoaXMgaXMgYW4gdXNlZnVsIHdvcmsgb24gYWRhcHRpbmcgT1dB TVAvVFdBTVAgaW4gTEFHIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50Lg0KV2UgdXBkYXRlZCB0aGlz IGRyYWZ0IGJhc2VkIG9uIHRoZSBjb21tZW50cyBmcm9tIHRoZSBtZWV0aW5nIGRpc2N1c3Npb24g YW5kIG1haWxpbmcgbGlzdC4NClRoYW5rcyBmb3IgYWxsIHRoZSBzdWdnZXN0aW9ucy4NCk1vcmUg cmV2aWV3cyBhbmQgY29tbWVudHMgYXJlIHdlbGNvbWUuDQoNCkNoZWVycywNClRpYW5yYW4NCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIEphbnVh cnkgMjQsIDIwMjIgMjoxNyBQTQ0KVG86IEdyZWcgTWlyc2t5IDxncmVnaW1pcnNreUBnbWFpbC5j b20+OyBHdW8gSnVuIDxndW8uanVuMkB6dGUuY29tLmNuPjsgSnVuIEd1byA8Z3VvLmp1bjJAenRl LmNvbS5jbj47IFJha2VzaCBHYW5kaGkgPHJnYW5kaGlAY2lzY28uY29tPjsgVGlhbnJhbiBaaG91 IDx6aG91dGlhbnJhbkBodWF3ZWkuY29tPjsgWmhlbnFpYW5nIExpIDxsaV96aGVucWlhbmdAaG90 bWFpbC5jb20+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxp LWlwcG0tb3R3YW1wLW9uLWxhZy0wMi50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtbGktaXBwbS1vdHdhbXAtb24tbGFnLTAyLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBUaWFucmFuIFpob3UgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5 Lg0KDQpOYW1lOgkJZHJhZnQtbGktaXBwbS1vdHdhbXAtb24tbGFnDQpSZXZpc2lvbjoJMDINClRp dGxlOgkJT25lLXdheS9Ud28td2F5IEFjdGl2ZSBNZWFzdXJlbWVudCBQcm90b2NvbCBFeHRlbnNp b25zIGZvciBQZXJmb3JtYW5jZSBNZWFzdXJlbWVudCBvbiBMQUcNCkRvY3VtZW50IGRhdGU6CTIw MjItMDEtMjQNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTEzDQpVUkw6 ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1saS1pcHBt LW90d2FtcC1vbi1sYWctMDIudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtbGktaXBwbS1vdHdhbXAtb24tbGFnLw0KSHRtbGl6ZWQ6ICAg ICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbGktaXBwbS1v dHdhbXAtb24tbGFnDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LWxpLWlwcG0tb3R3YW1wLW9uLWxhZy0wMg0KDQpBYnN0cmFjdDoNCiAgIFRo aXMgZG9jdW1lbnQgZGVmaW5lcyBleHRlbnNpb25zIHRvIE9uZS13YXkgQWN0aXZlIE1lYXN1cmVt ZW50DQogICBQcm90b2NvbCAoT1dBTVApLCBhbmQgVHdvLXdheSBBY3RpdmUgTWVhc3VyZW1lbnQg UHJvdG9jb2wgKFRXQU1QKSB0bw0KICAgaW1wbGVtZW50IHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50 IG9uIGV2ZXJ5IG1lbWJlciBsaW5rIG9mIGEgTGluaw0KICAgQWdncmVnYXRpb24gR3JvdXAgKExB RykuICBLbm93aW5nIHRoZSBtZWFzdXJlZCBtZXRyaWNzIG9mIGVhY2ggbWVtYmVyDQogICBsaW5r IG9mIGEgTEFHIGVuYWJsZXMgb3BlcmF0b3JzIHRvIGVuZm9yY2UgdGhlIHBlcmZvcm1hbmNlIGJh c2VkDQogICB0cmFmZmljIHN0ZWVyaW5nIHBvbGljeSBhY3Jvc3MgdGhlIG1lbWJlciBsaW5rcy4N Cg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQN Cg0KDQo= From nobody Sun Jan 23 22:38:57 2022 Return-Path: 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 7AC563A1D6C for ; Sun, 23 Jan 2022 22:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFeA2U_dkFcQ for ; Sun, 23 Jan 2022 22:38:51 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4472E3A1D6E for ; Sun, 23 Jan 2022 22:38:51 -0800 (PST) Received: from fraeml737-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Jj0g71ytqz67XMQ for ; Mon, 24 Jan 2022 14:38:27 +0800 (CST) Received: from dggpemm100001.china.huawei.com (7.185.36.93) by fraeml737-chm.china.huawei.com (10.206.15.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Mon, 24 Jan 2022 07:38:47 +0100 Received: from dggpemm500002.china.huawei.com (7.185.36.229) by dggpemm100001.china.huawei.com (7.185.36.93) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Mon, 24 Jan 2022 14:38:45 +0800 Received: from dggpemm500002.china.huawei.com ([7.185.36.229]) by dggpemm500002.china.huawei.com ([7.185.36.229]) with mapi id 15.01.2308.021; Mon, 24 Jan 2022 14:38:45 +0800 From: Mach Chen To: Tianran Zhou , "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt Thread-Index: AQHYEOoOM8BWGUje9EistfVjjUvI2qxxspuggAAE5tA= Date: Mon, 24 Jan 2022 06:38:45 +0000 Message-ID: <3c96d7f74be649dcbb23773c3840c2cc@huawei.com> References: <164300504281.12619.16642699818590435984@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.110.46.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2022 06:38:56 -0000 Hi Tianran, Thanks very much for taking this useful work up. After several revisions, I see this draft is much improved and mature. I would like to see the WG to move this draft forward. Although I will not hold the pen for this draft anymore, I would like to co= ntinue to contribute. Regards, Mach > -----Original Message----- > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Tianran Zhou > Sent: Monday, January 24, 2022 2:23 PM > To: IETF IPPM WG (ippm@ietf.org) > Subject: [ippm] FW: New Version Notification for > draft-li-ippm-otwamp-on-lag-02.txt >=20 > Hi WG, >=20 > We think this is an useful work on adapting OWAMP/TWAMP in LAG > performance measurement. > We updated this draft based on the comments from the meeting discussion > and mailing list. > Thanks for all the suggestions. > More reviews and comments are welcome. >=20 > Cheers, > Tianran >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, January 24, 2022 2:17 PM > To: Greg Mirsky ; Guo Jun ; > Jun Guo ; Rakesh Gandhi ; > Tianran Zhou ; Zhenqiang Li > > Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt >=20 >=20 > A new version of I-D, draft-li-ippm-otwamp-on-lag-02.txt > has been successfully submitted by Tianran Zhou and posted to the IETF > repository. >=20 > Name: draft-li-ippm-otwamp-on-lag > Revision: 02 > Title: One-way/Two-way Active Measurement Protocol Extensions > for Performance Measurement on LAG > Document date: 2022-01-24 > Group: Individual Submission > Pages: 13 > URL: > https://www.ietf.org/archive/id/draft-li-ippm-otwamp-on-lag-02.txt > Status: > https://datatracker.ietf.org/doc/draft-li-ippm-otwamp-on-lag/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-li-ippm-otwamp-on-lag > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-li-ippm-otwamp-on-lag-02 >=20 > Abstract: > This document defines extensions to One-way Active Measurement > Protocol (OWAMP), and Two-way Active Measurement Protocol (TWAMP) > to > implement performance measurement on every member link of a Link > Aggregation Group (LAG). Knowing the measured metrics of each > member > link of a LAG enables operators to enforce the performance based > traffic steering policy across the member links. >=20 >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From nobody Sun Jan 23 22:58:23 2022 Return-Path: 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 C910E3A1E27 for ; Sun, 23 Jan 2022 22:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSnE9wCq1igb for ; Sun, 23 Jan 2022 22:58:17 -0800 (PST) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59E553A1E20 for ; Sun, 23 Jan 2022 22:58:17 -0800 (PST) Received: by mail-pj1-x1033.google.com with SMTP id q63so10853825pja.1 for ; Sun, 23 Jan 2022 22:58:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=an2eMVPmioNkB+jQN1TfcGflWU9AeamI1+enVfD2xoM=; b=dJGdi+Ayr3/ABq0npyn/K/1QnjZpGHNd11Rnljqg+M+2OgsqUlCBc+WBt1Wfd2fBKc NKguMVXNcCsjNtV5b50qaxfV7qIvzHqnKiyoSacTeul0ER3SO5JCFw3epYLG/ClOHKBX qEHq2jrYr39hY/R8MY+UPOSjiUtk6h387mtqynmnxcHlVt8FVO9bK5JUWJfOWDBRchPk gbEfvh4RxwGpldeCE0hx6o1Uxd5xDiFPvOa0zhLQNfwjM/3LTZWsYXyI9GER/+wj0ITF aHEtZccsqSnFysCD1pbhnRGrp8srD0JsnWKbeCd3WGu5R1nhWeCEgloVtcGHjS+rQjvy xLfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=an2eMVPmioNkB+jQN1TfcGflWU9AeamI1+enVfD2xoM=; b=rACd9OP7n7rDxnE5zPgj4WBmKrcBd/cvPA5DKQQN/9krHBxCySVfyEHst21xmjqF8t ZLDXKSQmR9m75Hn+Xul42c4BQDfBwHusWLkBZ712mBJbXKuwtnx5Ahz47aK+1BcUoORi qGQU8iDNN7oUUnLfm1c7vuTjHtM7mzKkpoAcvpYf4oslUSUoAUW7cfYxEe8rLn5D5bsH 5Ymzi0jqv/keLlrjTUokaYkl12FxiwldN7jEqKnfvG22g7OXmeYbbWU+q+CnQL5UHZ1h zVs/RWBt86h5ofkd1Uz+1xhe9zJgFqS3IV0U16k/6/y0FKpXtYClF6DhcKNS3tBHg+jJ 4COA== X-Gm-Message-State: AOAM530b33ZuPIsJeaj4yuVeMYGD+zjlLH3Zgzh6Di/0AVzDq4nYcx5x n7/jA+RaOzviuzeFi3tsJRXr7ROqqCs= X-Google-Smtp-Source: ABdhPJwsz7THx3heAgD1qfc9h7s/uk+/r4wEioUh34QHji3yr8nqPeMFX2nq7s4gl31FE1nu/aHYNw== X-Received: by 2002:a17:90b:1801:: with SMTP id lw1mr566449pjb.215.1643007495454; Sun, 23 Jan 2022 22:58:15 -0800 (PST) Received: from smtpclient.apple (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id a6sm11091002pgq.62.2022.01.23.22.58.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 23 Jan 2022 22:58:14 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Jeff Tantsura Mime-Version: 1.0 (1.0) Date: Sun, 23 Jan 2022 22:58:13 -0800 Message-Id: <39FF0425-B2B3-40B3-A88B-FE9275F35251@gmail.com> References: <3c96d7f74be649dcbb23773c3840c2cc@huawei.com> Cc: Tianran Zhou , "IETF IPPM WG (ippm@ietf.org)" In-Reply-To: <3c96d7f74be649dcbb23773c3840c2cc@huawei.com> To: Mach Chen X-Mailer: iPhone Mail (19C63) Archived-At: Subject: Re: [ippm] New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2022 06:58:22 -0000 +1, useful work, support its progress. Cheers, Jeff > On Jan 23, 2022, at 22:39, Mach Chen wrote: >=20 > =EF=BB=BFHi Tianran, >=20 > Thanks very much for taking this useful work up. > After several revisions, I see this draft is much improved and mature. > I would like to see the WG to move this draft forward. > Although I will not hold the pen for this draft anymore, I would like to c= ontinue to contribute. >=20 > Regards, > Mach >=20 >> -----Original Message----- >> From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Tianran Zhou >> Sent: Monday, January 24, 2022 2:23 PM >> To: IETF IPPM WG (ippm@ietf.org) >> Subject: [ippm] FW: New Version Notification for >> draft-li-ippm-otwamp-on-lag-02.txt >>=20 >> Hi WG, >>=20 >> We think this is an useful work on adapting OWAMP/TWAMP in LAG >> performance measurement. >> We updated this draft based on the comments from the meeting discussion >> and mailing list. >> Thanks for all the suggestions. >> More reviews and comments are welcome. >>=20 >> Cheers, >> Tianran >>=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Monday, January 24, 2022 2:17 PM >> To: Greg Mirsky ; Guo Jun ; >> Jun Guo ; Rakesh Gandhi ; >> Tianran Zhou ; Zhenqiang Li >> >> Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt >>=20 >>=20 >> A new version of I-D, draft-li-ippm-otwamp-on-lag-02.txt >> has been successfully submitted by Tianran Zhou and posted to the IETF >> repository. >>=20 >> Name: draft-li-ippm-otwamp-on-lag >> Revision: 02 >> Title: One-way/Two-way Active Measurement Protocol Extensions >> for Performance Measurement on LAG >> Document date: 2022-01-24 >> Group: Individual Submission >> Pages: 13 >> URL: >> https://www.ietf.org/archive/id/draft-li-ippm-otwamp-on-lag-02.txt >> Status: >> https://datatracker.ietf.org/doc/draft-li-ippm-otwamp-on-lag/ >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-li-ippm-otwamp-on-lag >> Diff: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-li-ippm-otwamp-on-lag-02 >>=20 >> Abstract: >> This document defines extensions to One-way Active Measurement >> Protocol (OWAMP), and Two-way Active Measurement Protocol (TWAMP) >> to >> implement performance measurement on every member link of a Link >> Aggregation Group (LAG). Knowing the measured metrics of each >> member >> link of a LAG enables operators to enforce the performance based >> traffic steering policy across the member links. >>=20 >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >>=20 >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From nobody Mon Jan 24 09:06:57 2022 Return-Path: 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 374ED3A0AB6 for ; Mon, 24 Jan 2022 09:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_LmWNM2zu1o for ; Mon, 24 Jan 2022 09:06:50 -0800 (PST) Received: from NAM02-BN1-obe.outbound.protection.outlook.com (mail-bn1nam07on2111.outbound.protection.outlook.com [40.107.212.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1819B3A0AAD for ; Mon, 24 Jan 2022 09:06:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LWBCh7qwKwhQdUGooKld0hIH39gcBJCAicqyb8qwQEAZXofBpj2pjw/MNbnOZfk7kEuZVicfbp9kta27iokk/kVxQNVQOiel7OTsSFzVFeSHtzO4qqm1+cs2TLuGV7ha0PjGlFlp+I11DdHIIMPP///nl6MR9gwIDk0eMq1TcsW0vecdaqI6qSwy3O/Yeja6b47lsN4TPXcqEScs6lRzg4x/H/t7ToHG/oVW/Lyrc6vRcoEgV5ZWLQGwZ9AIpX9Gl9t5ursz4IK1Q9PQ1Ty13/iaHoOTESbny4igfABTOskM0wbqGWckQlabiTyX7q/bvUVgKgjPyhRW+bShL6sUug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ND1ylS6WCafuivolWvCeE1+3ZOjvy9WhZHv7LFinqTw=; b=CFvNto86lO+y3luIBR1ZczLWYErR8An2qMKtlvhnyLAZXDjaIFt2DrVwM0BeAUkrDpqSfwFV+zRIxdOp92q6Y2CQnn31G603vD3C1J33HuZmP0oZPNgEt//vBFVJxBAaqJSaqQdsAsQ+grYO92MpZuj0D06Z6gSLLKzh3pQCxJkZloda36q/yLvM7STcBE9sUIYeW63uj0amn5wBaDEh5ZS7ld56cCrsnkjqg2keDCLWlbVF6n3aptQwt1cZ/g5tDgxx/B5Bb0GVsE6MqT9IxvbKyG8dKV3Fm8ucA5WxJntOe6iW+uHg8VXX28E1Z2eGetE0LT7FADy1JYD4Ng0P3w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ND1ylS6WCafuivolWvCeE1+3ZOjvy9WhZHv7LFinqTw=; b=kvJtfayI4rKRGtQzmbPUhF/UVteVcpXCT2FSTgWjeTpXeJ5YRtjh+umtVltlOLU9wTgatL0PoB/fzcmR4RCt1JvxISTFXtKLeILUAnhwSrPd9UWwPPyYghY4XJW2D4G/dRJsnFuBlQRhFe5+n/fX+iwQ3ioSJHUWu41ENdav6Bc= Received: from BY3PR13MB4787.namprd13.prod.outlook.com (2603:10b6:a03:357::13) by PH0PR13MB5329.namprd13.prod.outlook.com (2603:10b6:510:f8::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4930.4; Mon, 24 Jan 2022 17:06:45 +0000 Received: from BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::618d:61cf:753e:be55]) by BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::618d:61cf:753e:be55%7]) with mapi id 15.20.4930.014; Mon, 24 Jan 2022 17:06:44 +0000 From: Haoyu Song To: Tianran Zhou , "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt Thread-Index: AQHYEOoOM8BWGUje9EistfVjjUvI2qxxspuggACz9nA= Date: Mon, 24 Jan 2022 17:06:44 +0000 Message-ID: References: <164300504281.12619.16642699818590435984@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1d6751a5-5056-49c6-295a-08d9df5be663 x-ms-traffictypediagnostic: PH0PR13MB5329:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JTxrrUvz3LDnLJh9b5LOH94A+crxn+JceJ98HZM2Q3sjF6V8R+eqSfyeaXGNl8pfOlIxfdi1dsGk7OY26RyoKYteEB9sMZ9inX9beh7Yt+vsQzN2NGjuTywfTHxbq3WIhRgyOy1Mr/ZBhjbCh2wNUq2dLD7ZArHU7QGiVFFfIQFywtBtf4c5YbFXOnM0iVvKjo8raVubCNntfpPKZOufhNC7vXB5LqtGU4nDJx+eYf9BSO54N5vhueZUwZUzalRvt5GbZ7w375/ZJQgFQJudVAYG5VxBGYL5fLcsMCt/YfI7hu+4qBxWJTnzoG0gfg8OGABGDS41s83goE7HpW8qwl4tT5wrCM4bN5d7jyU/hrJ8QVos0JQbj1MrkJlTDSDgZ1EU4QnTkT68VwgFwT8nR1zl0f5TEno3mWuoTRm58KCTGMJlreRVqOaXhSL6pHuLTgnW6qNUrSIZRNqVHvlZhibvK4LahYG9T6QCJ/HJDH6m8PFjStckWLi75W/ysTwnIDAXN/IJAczonvo+RfQOUYjqD2aLYAHuTDy4isf3mF6wOCxNQCUNtmOzzBBqOZk4ErcPPgY5aEZO9NE6YNhp6qW6W7SBPvR+R6HLSbQr5zHagwJGEgBXoKVVXWmtKS8L452+oEHl5JjGbuE38w5Uzml0oVVfBStCZXFg4eC8MmUIL5qq/eWustks3dy7r6S362ZXatBlf2khXNUBkTsLz+VohBwHV03UdpqWIor3Ddn+2ImQ7VV5G+ykMKkeQvkyqlEfdB7GGGdOOXCy3D2pVd4NCjW7MCK5RcrD/2CUqEUeCMKyFmZXvafLUrrJhAwib/G0Raz+qrsIhcI8VmjG9A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR13MB4787.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(55016003)(38070700005)(86362001)(33656002)(38100700002)(122000001)(7696005)(6506007)(76116006)(53546011)(66446008)(66556008)(66476007)(66946007)(64756008)(8676002)(8936002)(52536014)(508600001)(45080400002)(9686003)(5660300002)(966005)(316002)(110136005)(71200400001)(66574015)(83380400001)(2906002)(15650500001)(44832011)(186003)(26005)(20210929001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?n7FQJeg5IiS6Fg6BpUhAJ8l1hGTfUXpTnrZOAke8LCMITe70VjsMTmlQI1Xp?= =?us-ascii?Q?WLm3c6mIHnTVRXts/2hS/SAPNUrDMehDEw7jtPXmgJfQwvacsNF7Yvrj7tKd?= =?us-ascii?Q?Fu/1cVV4D8U7k9ge6JGDXcXRo4M2k/IVg6MSyxlaBHKp1ID4wpVw7LkX/3K6?= =?us-ascii?Q?BEh5Kv5vW5llRfy6HyyRj0sfHVEHN3Y8k7kVtbJh+EdXuK3YcH5nv+H2Yux/?= =?us-ascii?Q?pKNMFkxcKDIZhAHDfWbK6m46VjU394XTyIJZAToEinp+3C6AJ1INpN0oOY1T?= =?us-ascii?Q?Uc5bN5qGEPJAgjspzUP/gvqO4vWy8RJFNfdZJFuBrECOfn8e00jgU94Zn+jn?= =?us-ascii?Q?65aTSP0UX3F63EpBcUkJyCMckkpODyjRrqjAstgJU9JE9I2CUZJasF8q4ert?= =?us-ascii?Q?478atQbMngvyMmZezHboOrgmeLk+MmlQiWLe4GDBCt65iBrHWFJujGP/1pL+?= =?us-ascii?Q?aogJara4p5A39e2t4V3LSw89L5PhR48+H6ZgmrZ7cSZZXksbw46iI0balmFF?= =?us-ascii?Q?3qsF6HNYrsfuHhNXYs2pryRqOmpqUNQhyhxtoRZ+R58tojCjFxAv75KHASi0?= =?us-ascii?Q?SgNy/x2cUcGbnnoV+Z41TGRU5WPcaHbMgvSzR52E8YiL7LdlVuyC74Y2vnyk?= =?us-ascii?Q?ebdB7nKL0VuI+YQN3ef+0tnE54vZdpv1EWv+dQzxiOC9+DRhdjD9SaY2Rvsj?= =?us-ascii?Q?jQgEiuTXFfCxg8RwupBXwfhUj/unVqwcVL3lLJWAn3H8Ll6k3PcAY9mQCHgL?= =?us-ascii?Q?n1ojour60QzwNxCt/CAoMLDXr9vkYcRLACsU94NwQO8Uvlq+OjFrZAMX7z8k?= =?us-ascii?Q?U0M4shlud6YekZ3r68tUEcFj/rYvIz02plRvGw8eqzi8ncQdUQhWcDAXMFwq?= =?us-ascii?Q?IO9wpDaWuVB+jCYBfZSiPgaZnu1yzQ5zpH/qns9V8vFZ1QKMFJNPo5nEUZku?= =?us-ascii?Q?/9OpXeDfR6GIsNHN7LKkpw3IllfQpOd8KSaSguUIKjYtrmdDgqsIqGWyxRCk?= =?us-ascii?Q?6buJUW1wlzoAW1wbvOOOX0ldhluZ9vGEsfTvT8KEx6rV7LGnKflJT0VwKKOH?= =?us-ascii?Q?3xsUFqZJOMOfEj6wsx5wA379UFu9JrNJA81PNuG5DXQQCufMsS2hwrcddi/m?= =?us-ascii?Q?RRUVnYGdFQiULBBJGj3MFzqB5QWyAj5KlrMbmfZpZIEv+zyzD4DuDIAAtlFU?= =?us-ascii?Q?p9c3azby+naP84rBWQyqS0bb8Zc/3wGsgwf5H/FIXvPzontRHZ+4WJvZfrt4?= =?us-ascii?Q?CsJIxrxvu0gS9TIvgmMBXJ2xVIOwv6tED262ZbpSKaUcEPHXtjB7oMAszwwB?= =?us-ascii?Q?ybo0bsGLYTN+uTPjVLOxiuWCBNVYo/YvjqjkzoWNMsYefvJRDFf24J/Pma36?= =?us-ascii?Q?L8N5tnJV1kn9gwO2jbVSYX5werElVnM5j22n3OT2nQI8VCiHSCxcYUuFYzjY?= =?us-ascii?Q?NRRnqYcAYyFKuFbeYxVhsOZHebX4O3fiXGTsRzJ1xqiqP4FPlinNX1NJj1gu?= =?us-ascii?Q?3l/Dy6CdJD2XNKklouoSDCltsyK34mb9wChvd6zsfSOff1qfB8J7mHB4cD7n?= =?us-ascii?Q?ouPab+eK33NviAL04grCkRKJeM1PUpPsTsp30wemZK9msJwLXkPEBWi9P7qm?= =?us-ascii?Q?Kg=3D=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB4787.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1d6751a5-5056-49c6-295a-08d9df5be663 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2022 17:06:44.8194 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: cxBNNxPZItAVYQKOoR8aH0AzuwXsrM4Art8mPCE3BObkDbH078BtemqXisjy9WtlP43mVEQOD25zxLY2evB0yw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR13MB5329 Archived-At: Subject: Re: [ippm] New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2022 17:06:55 -0000 WG,=20 I think the scenario for LAG performance measurement is practical and the m= ethod is sound, so I support this work. For Figure 1, I think usually for load balancing with hashing, the number o= f links of a LAG would be power of two.=20 Best, Haoyu Song -----Original Message----- From: ippm On Behalf Of Tianran Zhou Sent: Sunday, January 23, 2022 10:23 PM To: IETF IPPM WG (ippm@ietf.org) Subject: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-la= g-02.txt Hi WG, We think this is an useful work on adapting OWAMP/TWAMP in LAG performance = measurement. We updated this draft based on the comments from the meeting discussion and= mailing list. Thanks for all the suggestions. More reviews and comments are welcome. Cheers, Tianran -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Monday, January 24, 2022 2:17 PM To: Greg Mirsky ; Guo Jun ; Jun= Guo ; Rakesh Gandhi ; Tianran Zhou= ; Zhenqiang Li Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt A new version of I-D, draft-li-ippm-otwamp-on-lag-02.txt has been successfully submitted by Tianran Zhou and posted to the IETF repo= sitory. Name: draft-li-ippm-otwamp-on-lag Revision: 02 Title: One-way/Two-way Active Measurement Protocol Extensions for Performa= nce Measurement on LAG Document date: 2022-01-24 Group: Individual Submission Pages: 13 URL: https://nam11.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-li-ippm-otwamp-on-lag-02.txt&a= mp;data=3D04%7C01%7Chaoyu.song%40futurewei.com%7Ca16115736bab48d99c2f08d9df= 020bed%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637786022170908705%7CUn= known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ= XVCI6Mn0%3D%7C3000&sdata=3DO1SD54x5%2FM99g7YjxnzaMjaZuJ9S4UxNGcm6NAkTXn= g%3D&reserved=3D0 Status: https://nam11.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-li-ippm-otwamp-on-lag%2F&da= ta=3D04%7C01%7Chaoyu.song%40futurewei.com%7Ca16115736bab48d99c2f08d9df020be= d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637786022170908705%7CUnknown= %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6= Mn0%3D%7C3000&sdata=3DUYUXVf0BvrCuH20ydOjxCI26KjgpAopEIV40%2BqjuxKY%3D&= amp;reserved=3D0 Htmlized: https://nam11.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-li-ippm-otwamp-on-lag&am= p;data=3D04%7C01%7Chaoyu.song%40futurewei.com%7Ca16115736bab48d99c2f08d9df0= 20bed%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637786022170908705%7CUnk= nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX= VCI6Mn0%3D%7C3000&sdata=3DgN9hSIQaMM%2BE%2BtDLSFxe95J%2FyX4omBdv6rtBTMB= 4B8o%3D&reserved=3D0 Diff: https://nam11.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-li-ippm-otwamp-on-lag-02&= ;data=3D04%7C01%7Chaoyu.song%40futurewei.com%7Ca16115736bab48d99c2f08d9df02= 0bed%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637786022170908705%7CUnkn= own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV= CI6Mn0%3D%7C3000&sdata=3DNPJcFQoHUAw47%2FJ%2BO4SeOLEaQUNe%2FAI4UDUGMA%2= BKK%2Fo%3D&reserved=3D0 Abstract: This document defines extensions to One-way Active Measurement Protocol (OWAMP), and Two-way Active Measurement Protocol (TWAMP) to implement performance measurement on every member link of a Link Aggregation Group (LAG). Knowing the measured metrics of each member link of a LAG enables operators to enforce the performance based traffic steering policy across the member links. = =20 The IETF Secretariat _______________________________________________ ippm mailing list ippm@ietf.org https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fippm&data=3D04%7C01%7Chaoyu.song%40futurew= ei.com%7Ca16115736bab48d99c2f08d9df020bed%7C0fee8ff2a3b240189c753a1d5591fed= c%7C1%7C0%7C637786022170908705%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi= LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DDHVbIOrP6= nfAfjGnIl5N%2F%2B5B0O6qDonb%2F%2Beq2uTEJu4%3D&reserved=3D0 From nobody Mon Jan 24 15:06:52 2022 Return-Path: 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 484CD3A15D4 for ; Mon, 24 Jan 2022 15:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOgZG6K8vpnV for ; Mon, 24 Jan 2022 15:06:45 -0800 (PST) Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFC0D3A15D9 for ; Mon, 24 Jan 2022 15:06:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id C70FE424B435; Mon, 24 Jan 2022 15:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5pq63pscmWg; Mon, 24 Jan 2022 15:06:45 -0800 (PST) Received: from [192.168.1.16] (cpe-76-95-228-63.socal.res.rr.com [76.95.228.63]) by c8a.amsl.com (Postfix) with ESMTPSA id 74DA7424B434; Mon, 24 Jan 2022 15:06:45 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Chris Smiley In-Reply-To: <20211127211835.526DAF5D08@rfc-editor.org> Date: Mon, 24 Jan 2022 15:06:43 -0800 Cc: RFC Errata System , nmalykh@ieee.org, "MORTON JR., AL" , ippm@ietf.org, kld@att.com, philip.eardley@bt.com, marcelo@it.uc3m.es Content-Transfer-Encoding: quoted-printable Message-Id: <5EA0BA63-4E14-4B39-8BAB-873DB59A5F65@amsl.com> References: <20211127211835.526DAF5D08@rfc-editor.org> To: martin.h.duke@gmail.com, Zaheduzzaman Sarker X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [ippm] [Editorial Errata Reported] RFC8912 (6755) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2022 23:06:50 -0000 Greetings, We are unable to verify this erratum that the submitter marked as = editorial. =20 Please note that we have changed the =E2=80=9CType=E2=80=9D of the = following errata=20 report to =E2=80=9CTechnical=E2=80=9D. As Stream Approver, please = review and set the=20 Status and Type accordingly (see the definitions at=20 https://www.rfc-editor.org/errata-definitions/). You may review the report at:=20 https://www.rfc-editor.org/errata/eid6755 Please see https://www.rfc-editor.org/how-to-verify/ for further=20 information on how to verify errata reports. Further information on errata can be found at:=20 https://www.rfc-editor.org/errata.php. Thank you. RFC Editor/cs > On Nov 27, 2021, at 1:18 PM, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC8912, > "Initial Performance Metrics Registry Entries". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6755 >=20 > -------------------------------------- > Type: Editorial > Reported by: Nikolai Malykh >=20 > Section: 5.3.5 >=20 > Original Text > ------------- > 5.3.5. Runtime Parameters and Data Format >=20 > Src: The IP address of the host in the Src Role (format > ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value > for IPv6; see Section 4 of [RFC6991]). >=20 >=20 > Corrected Text > -------------- > 5.3.5. Runtime Parameters and Data Format >=20 > Runtime Parameters are input factors that must be determined, > configured into the measurement system, and reported with the = results > for the context to be complete. >=20 > Src: The IP address of the host in the Src Role (format > ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value > for IPv6; see Section 4 of [RFC6991]). >=20 >=20 > Notes > ----- > Skipped paragraph. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC8912 (draft-ietf-ippm-initial-registry-16) > -------------------------------------- > Title : Initial Performance Metrics Registry Entries > Publication Date : November 2021 > Author(s) : A. Morton, M. Bagnulo, P. Eardley, K. D'Souza > Category : PROPOSED STANDARD > Source : IP Performance Measurement > Area : Transport > Stream : IETF > Verifying Party : IESG >=20 From nobody Mon Jan 24 17:05:45 2022 Return-Path: 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 ED96D3A1B91 for ; Mon, 24 Jan 2022 17:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.897 X-Spam-Level: X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZvplj_nnNHK for ; Mon, 24 Jan 2022 17:05:34 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C3933A1B10 for ; Mon, 24 Jan 2022 17:05:32 -0800 (PST) Received: from fraeml712-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JjT7Z5SrDz687ZY for ; Tue, 25 Jan 2022 09:01:14 +0800 (CST) Received: from kwepeml100005.china.huawei.com (7.221.188.221) by fraeml712-chm.china.huawei.com (10.206.15.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Tue, 25 Jan 2022 02:05:28 +0100 Received: from kwepeml500004.china.huawei.com (7.221.188.141) by kwepeml100005.china.huawei.com (7.221.188.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Tue, 25 Jan 2022 09:05:27 +0800 Received: from kwepeml500004.china.huawei.com ([7.221.188.141]) by kwepeml500004.china.huawei.com ([7.221.188.141]) with mapi id 15.01.2308.021; Tue, 25 Jan 2022 09:05:27 +0800 From: Tianran Zhou To: Haoyu Song , Tianran Zhou , "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt Thread-Index: AQHYEOoOM8BWGUje9EistfVjjUvI2qxxspuggACz9nCAAIZf8A== Date: Tue, 25 Jan 2022 01:05:27 +0000 Message-ID: <76b3ef6c675a4cabac450d4ddea02fbb@huawei.com> References: <164300504281.12619.16642699818590435984@ietfa.amsl.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.112.40.195] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2022 01:05:44 -0000 Hi Haoyu, Thanks very much for your comments. Your perspective is correct. I will revise the document in the next version. Best, Tianran -----Original Message----- From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Haoyu Song Sent: Tuesday, January 25, 2022 1:07 AM To: Tianran Zhou ; IETF IPPM WG = (ippm@ietf.org) Subject: Re: [ippm] New Version Notification for draft-li-ippm-otwamp-on-la= g-02.txt WG,=20 I think the scenario for LAG performance measurement is practical and the m= ethod is sound, so I support this work. For Figure 1, I think usually for load balancing with hashing, the number o= f links of a LAG would be power of two.=20 Best, Haoyu Song -----Original Message----- From: ippm On Behalf Of Tianran Zhou Sent: Sunday, January 23, 2022 10:23 PM To: IETF IPPM WG (ippm@ietf.org) Subject: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-la= g-02.txt Hi WG, We think this is an useful work on adapting OWAMP/TWAMP in LAG performance = measurement. We updated this draft based on the comments from the meeting discussion and= mailing list. Thanks for all the suggestions. More reviews and comments are welcome. Cheers, Tianran -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Monday, January 24, 2022 2:17 PM To: Greg Mirsky ; Guo Jun ; Jun= Guo ; Rakesh Gandhi ; Tianran Zhou= ; Zhenqiang Li Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt A new version of I-D, draft-li-ippm-otwamp-on-lag-02.txt has been successfully submitted by Tianran Zhou and posted to the IETF repo= sitory. Name: draft-li-ippm-otwamp-on-lag Revision: 02 Title: One-way/Two-way Active Measurement Protocol Extensions for Performa= nce Measurement on LAG Document date: 2022-01-24 Group: Individual Submission Pages: 13 URL: https://nam11.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-li-ippm-otwamp-on-lag-02.txt&a= mp;data=3D04%7C01%7Chaoyu.song%40futurewei.com%7Ca16115736bab48d99c2f08d9df= 020bed%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637786022170908705%7CUn= known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ= XVCI6Mn0%3D%7C3000&sdata=3DO1SD54x5%2FM99g7YjxnzaMjaZuJ9S4UxNGcm6NAkTXn= g%3D&reserved=3D0 Status: https://nam11.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-li-ippm-otwamp-on-lag%2F&da= ta=3D04%7C01%7Chaoyu.song%40futurewei.com%7Ca16115736bab48d99c2f08d9df020be= d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637786022170908705%7CUnknown= %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6= Mn0%3D%7C3000&sdata=3DUYUXVf0BvrCuH20ydOjxCI26KjgpAopEIV40%2BqjuxKY%3D&= amp;reserved=3D0 Htmlized: https://nam11.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-li-ippm-otwamp-on-lag&am= p;data=3D04%7C01%7Chaoyu.song%40futurewei.com%7Ca16115736bab48d99c2f08d9df0= 20bed%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637786022170908705%7CUnk= nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX= VCI6Mn0%3D%7C3000&sdata=3DgN9hSIQaMM%2BE%2BtDLSFxe95J%2FyX4omBdv6rtBTMB= 4B8o%3D&reserved=3D0 Diff: https://nam11.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-li-ippm-otwamp-on-lag-02&= ;data=3D04%7C01%7Chaoyu.song%40futurewei.com%7Ca16115736bab48d99c2f08d9df02= 0bed%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637786022170908705%7CUnkn= own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV= CI6Mn0%3D%7C3000&sdata=3DNPJcFQoHUAw47%2FJ%2BO4SeOLEaQUNe%2FAI4UDUGMA%2= BKK%2Fo%3D&reserved=3D0 Abstract: This document defines extensions to One-way Active Measurement Protocol (OWAMP), and Two-way Active Measurement Protocol (TWAMP) to implement performance measurement on every member link of a Link Aggregation Group (LAG). Knowing the measured metrics of each member link of a LAG enables operators to enforce the performance based traffic steering policy across the member links. = =20 The IETF Secretariat _______________________________________________ ippm mailing list ippm@ietf.org https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fippm&data=3D04%7C01%7Chaoyu.song%40futurew= ei.com%7Ca16115736bab48d99c2f08d9df020bed%7C0fee8ff2a3b240189c753a1d5591fed= c%7C1%7C0%7C637786022170908705%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi= LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DDHVbIOrP6= nfAfjGnIl5N%2F%2B5B0O6qDonb%2F%2Beq2uTEJu4%3D&reserved=3D0 _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From nobody Mon Jan 24 22:30:59 2022 Return-Path: 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 9B0A13A18D2 for ; Mon, 24 Jan 2022 22:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GT02-tVDMM21 for ; Mon, 24 Jan 2022 22:30:53 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE0A73A18D3 for ; Mon, 24 Jan 2022 22:30:52 -0800 (PST) Received: from fraeml702-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JjcRQ6Pgbz67xFd for ; Tue, 25 Jan 2022 14:30:26 +0800 (CST) Received: from kwepeml100006.china.huawei.com (7.221.188.192) by fraeml702-chm.china.huawei.com (10.206.15.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.21; Tue, 25 Jan 2022 07:30:47 +0100 Received: from kwepeml500004.china.huawei.com (7.221.188.141) by kwepeml100006.china.huawei.com (7.221.188.192) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Tue, 25 Jan 2022 14:30:46 +0800 Received: from kwepeml500004.china.huawei.com ([7.221.188.141]) by kwepeml500004.china.huawei.com ([7.221.188.141]) with mapi id 15.01.2308.021; Tue, 25 Jan 2022 14:30:46 +0800 From: Tianran Zhou To: "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: New Version Notification for draft-li-ippm-stamp-on-lag-01.txt Thread-Index: AQHYEbShqdotlpDAekmWBk6hf+yM2KxzRiXw Date: Tue, 25 Jan 2022 06:30:46 +0000 Message-ID: <49bb582d835b4b938cda7e0ad680083c@huawei.com> References: <164309204653.26831.5703411217906566536@ietfa.amsl.com> In-Reply-To: <164309204653.26831.5703411217906566536@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.112.40.195] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [ippm] FW: New Version Notification for draft-li-ippm-stamp-on-lag-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2022 06:30:58 -0000 SGkgV0csDQoNCkluIGFkZGl0aW9uIHRvIExBRyBQTSBvbiBPV0FNUC9UV0FNUCwgdGhpcyBkcmFm dCBleHRlbmRzIFNUQU1QIGZvciBMQUcgUE0uDQpMb29rIGZvcndhcmQgdG8geW91ciByZXZpZXcg YW5kIGNvbW1lbnRzLg0KDQpUaGFua3MsDQpUaWFucmFuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmddIA0KU2VudDogVHVlc2RheSwgSmFudWFyeSAyNSwgMjAyMiAyOjI3IFBN DQpUbzogR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbT47IEd1byBKdW4gPGd1by5q dW4yQHp0ZS5jb20uY24+OyBKdW4gR3VvIDxndW8uanVuMkB6dGUuY29tLmNuPjsgUmFrZXNoIEdh bmRoaSA8cmdhbmRoaUBjaXNjby5jb20+OyBUaWFucmFuIFpob3UgPHpob3V0aWFucmFuQGh1YXdl aS5jb20+OyBaaGVucWlhbmcgTGkgPGxpX3poZW5xaWFuZ0Bob3RtYWlsLmNvbT4NClN1YmplY3Q6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGktaXBwbS1zdGFtcC1vbi1sYWct MDEudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWxpLWlwcG0tc3RhbXAtb24t bGFnLTAxLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFRpYW5yYW4gWmhv dSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1saS1p cHBtLXN0YW1wLW9uLWxhZw0KUmV2aXNpb246CTAxDQpUaXRsZToJCVNpbXBsZSBUd28tV2F5IEFj dGl2ZSBNZWFzdXJlbWVudCBQcm90b2NvbCBFeHRlbnNpb25zIGZvciBQZXJmb3JtYW5jZSBNZWFz dXJlbWVudCBvbiBMQUcNCkRvY3VtZW50IGRhdGU6CTIwMjItMDEtMjQNCkdyb3VwOgkJSW5kaXZp ZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTgNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5p ZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LWxpLWlwcG0tc3RhbXAtb24tbGFnLTAxLnR4dA0KU3Rh dHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxpLWlw cG0tc3RhbXAtb24tbGFnLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbGktaXBwbS1zdGFtcC1vbi1sYWcNCkRpZmY6ICAgICAgICAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbGktaXBwbS1zdGFtcC1v bi1sYWctMDENCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGV4dGVuZHMgU2ltcGxlIFR3 by1XYXkgQWN0aXZlIE1lYXN1cmVtZW50IFByb3RvY29sDQogICAoU1RBTVApIHRvIGltcGxlbWVu dCBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudCBvbiBldmVyeSBtZW1iZXIgbGluayBvZg0KICAgYSBM aW5rIEFnZ3JlZ2F0aW9uIEdyb3VwIChMQUcpLiAgS25vd2luZyB0aGUgbWVhc3VyZWQgbWV0cmlj cyBvZiBlYWNoDQogICBtZW1iZXIgbGluayBvZiBhIExBRyBlbmFibGVzIG9wZXJhdG9ycyB0byBl bmZvcmNlIGEgcGVyZm9ybWFuY2UgYmFzZWQNCiAgIHRyYWZmaWMgc3RlZXJpbmcgcG9saWN5IGFj cm9zcyB0aGUgbWVtYmVyIGxpbmtzLg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0K DQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg== From nobody Tue Jan 25 01:49:25 2022 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E78BC3A1511; Tue, 25 Jan 2022 01:49:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.43.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ippm@ietf.org Message-ID: <164310415686.19692.9810261413202836828@ietfa.amsl.com> Date: Tue, 25 Jan 2022 01:49:16 -0800 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-ioam-yang-03.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2022 09:49:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Measurement WG of the IETF. Title : A YANG Data Model for In-Situ OAM Authors : Tianran Zhou Jim Guichard Frank Brockners Srihari Raghavan Filename : draft-ietf-ippm-ioam-yang-03.txt Pages : 26 Date : 2022-01-25 Abstract: In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in user packets while the packets traverse a path between two points in the network. This document defines a YANG module for the IOAM function. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-yang/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-yang-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-ioam-yang-03 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Tue Jan 25 01:57:41 2022 Return-Path: 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 724193A1569 for ; Tue, 25 Jan 2022 01:57:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.897 X-Spam-Level: X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uly-6lYZ23rZ for ; Tue, 25 Jan 2022 01:57:34 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5956A3A1563 for ; Tue, 25 Jan 2022 01:57:34 -0800 (PST) Received: from fraeml704-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Jjj1x0N49z67x9D for ; Tue, 25 Jan 2022 17:57:09 +0800 (CST) Received: from kwepeml100005.china.huawei.com (7.221.188.221) by fraeml704-chm.china.huawei.com (10.206.15.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.21; Tue, 25 Jan 2022 10:57:30 +0100 Received: from kwepeml500004.china.huawei.com (7.221.188.141) by kwepeml100005.china.huawei.com (7.221.188.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Tue, 25 Jan 2022 17:57:28 +0800 Received: from kwepeml500004.china.huawei.com ([7.221.188.141]) by kwepeml500004.china.huawei.com ([7.221.188.141]) with mapi id 15.01.2308.021; Tue, 25 Jan 2022 17:57:28 +0800 From: Tianran Zhou To: t petch , ippm Thread-Topic: [ippm] I-D Action: draft-ietf-ippm-ioam-yang-02.txt Thread-Index: AQHYCONY9YSHCkhotEyNjloKbBeKraxhwwuAgACOtjqABFDcAIAM7ZcQ Date: Tue, 25 Jan 2022 09:57:28 +0000 Message-ID: References: <164212252543.24637.8230414962710718767@ietfa.amsl.com> <61E14995.5000305@btconnect.com> <22444b56b795425c936ac794e53d3075@huawei.com> <61E5601E.8040405@btconnect.com> In-Reply-To: <61E5601E.8040405@btconnect.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.112.40.195] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] I-D Action: draft-ietf-ippm-ioam-yang-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2022 09:57:40 -0000 SGkgVG9tLA0KVGhhbmtzIHZlcnkgbXVjaCBmb3IgeW91ciBkZXRhaWxlZCByZXZpZXcuDQpJIGp1 c3Qgc3VibWl0dGVkIGEgbmV3IHJldmlzaW9uIHRvIGFkZHJlc3MgeW91ciBjb21tZW50cy4NCmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaXBwbS1pb2FtLXlhbmcv DQpTb21lIHJlcGxpZXMgcGxlYXNlIHNlZSBpbiBsaW5lLg0KDQpCZXN0LA0KVGlhbnJhbg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdCBwZXRjaCBbbWFpbHRvOmlldGZhQGJ0 Y29ubmVjdC5jb21dIA0KU2VudDogTW9uZGF5LCBKYW51YXJ5IDE3LCAyMDIyIDg6MjUgUE0NClRv OiBUaWFucmFuIFpob3UgPHpob3V0aWFucmFuQGh1YXdlaS5jb20+OyBpcHBtIDxpcHBtQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFtpcHBtXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWlwcG0taW9h bS15YW5nLTAyLnR4dA0KDQpPbiAxNC8wMS8yMDIyIDEwOjMwLCBUaWFucmFuIFpob3Ugd3JvdGU6 DQo+IEhpIFRvbSwNCj4gSSBhbSBzb3JyeS4gVGhlIGRhdGUgaXMgbm90IGNvcnJlY3QuIEJ1dCB0 aGUgZGF0ZSBpbiB0aGUgWUFORyBtb2RlbCBpcyBjb3JyZWN0Lg0KPiBUaGUgbWFqb3IgaW1wcm92 ZW1lbnQgaXMgYWJvdXQgdGhlIGlvYW0gaW5mby4NCj4gV2UgY29sbGVjdGVkIHNvbWUgcmVxdWly ZW1lbnRzIGFuZCBhZGRlZCBpbi4NCg0KSW5kZWVkOyBpdCBpcyBjb21wbGV0ZWx5IGRpZmZlcmVu dC4gIEkgZG9uJ3Qga25vdyB3aGF0IEkgd2FzIGxvb2tpbmcgYXQ6LSgNCg0KJ25hbWVzcGFjZScg Y29uZnVzZXMgbWUuICBJbiBpb2FtLWRhdGEsIGl0IGlzIDE2IGJpdC4gIEhlcmUgaXQgaXMgaWRl bnRpdHkuICBIb3cgZG8geW91IG1hcCBvbmUgdG8gdGhlIG90aGVyPw0KDQpwb3QtdHlwZSBzZWVt cyBzaW1pbGFyOyBpdCBpcyBhbiA4LWJpdCBmaWVsZCBmb3Igd2hpY2ggeW91IGhhdmUgdHlwZSBh bmQgaWRlbnRpdHkuICBJIHRoaW5rIHRoYXQgaW9hbS1kYXRhIGRvZXMgYSBiYWQgam9iIG9mIGV4 cGxhaW5pbmcgaG93IHBvdC10eXBlIGFyZSBpZGVudGlmaWVkLiAgVGhlIHRleHQgaGFzIGNoYW5n ZWQgYSBsb3QgYnV0IG5vdCBpbiAgYSBjb2hlcmVudCBtYW5uZXIgSU1ITyBhbmQgaWYgeW91IGFy ZSB0cnlpbmcgdG8gbW9kZWwgc29tZXRoaW5nIGluY29oZXJlbnQsIHdlbGwsIHRoZW4gdGhlIG1v ZGVsIGlzIGxpa2VseSB0byBiZSBpbmNvaGVyZW50LiAgKEkgYXBwcmVjaWF0ZSB0aGF0IGlvYW0t ZGF0YSBpcyB3aXRoIHRoZSBSRkMgRWRpdG9yIHNvIHRoZXJlIGlzIGhvcGUgZm9yIGl0DQp5ZXQ6 LSkNCg0KWlRSPiBJIHJldmlzZWQgdGhlIG5hbWVzcGFjZSBhbmQgcG90LXR5cGUgZGVzY3JpcHRp b24sIGludHJvZHVjZWQgdGhlIG1hcHBpbmcuDQoNCkkgd291bGQgZmluZCBpdCBjbGVhcmVyIGlm IHRoZSBmaXZlIG9wdGlvbnMgd2VyZSBsaXN0ZWQgYXMgc3VjaCwgaW4gYSBsaXN0LCB3aXRoIHJl ZmVyZW5jZXMsIHByb2JhYmx5IGluIHRoZSBJbnRyb2R1Y3Rpb24uDQoNClpUUj4gWWVzLiBJIGxp c3RlZCBpbiB0aGUgaW50cm9kdWN0aW9uLg0KDQpXaGF0IGlzICBhIHRpbWVzdGFtcCBzdWJzZWNv bmQ/ICBJcyBpdCBhIG5hbm9zZWNvbmQ/DQoNCi9wcm92ZS9wcm9vZi8gbW9zdGx5IGZpeGVkIGJ1 dCBub3QgcXVpdGUgYWxsOyBsaWtld2lzZSBlZGdlLXRvLWVkZ2UNCg0KL2h0dHA6dG9vbHMvaHR0 cHM6ZGF0YXRyYWNrZXIvDQoNCi9SRkMgUkZDIDg1MzIvUkZDIDg1MzIvDQphbmQgaXQgbmVlZHMg YWRkaW5nIHRvIHRoZSBJLUQgUmVmZXJlbmNlcw0KDQpaVFI+IEkgdXBkYXRlZCBhbGwgdGhlIGFi b3ZlIG5pdHMuIEJ1dCBJIGZvcmdvdCB0byBhZGQgdGhlIElEIHJlZmVyZW5jZS4gOlANCldpbGwg YWRkIGluIHRoZSBuZXh0IHZlcnNpb24uIA0KDQovZm9yIGVuY2Fwc3VsYXRlLyB0byBlbmNhcHN1 bGF0ZS8NCigiZm9yIGVuY2Fwc3VsYXRpb24iIGlzIGZpbmUpDQoNCllBTkcgbW9kdWxlIHJlZmVy ZW5jZXMgSSBmaW5kIGNsZWFyZXIgYXMgZS5nLg0KIlJGQyBZWVlZOiBEYXRhIEZpZWxkcyBmb3Ig SW4tc2l0dSBPQU0iDQpzaW5jZSB0aGF0IGlzIHRoZSBuYW1lIGZvciB0aGUgbG9uZyB0ZXJtLCBJ LUQgbmFtZXMgYXJlIGVwaGVtZXJhbA0KDQpJIHRoaW5rIHRoYXQgbWFueSBvZiB0aGUgWUFORyBp ZGVudGlmaWVycyBhcmUgcHJvbGl4IGUuLmcuDQppZGVudGl0eSBpcHY2LXByb3RvY29sDQpiYXNl IGJhc2UtcHJvdG9jb2wNCg0Kb25seSBuZWVkcw0KaWRlbnRpdHkgaXB2Ng0KYmFzZSBwcm90b2Nv bA0KSU1ITw0KICBBbnkgdXNlIG9mIGJhc2UsIHByb3RvY29sLCB0eXBlICwgYWN0aW9uIGV0YyBp cyBsaWtlbHkgdG8gYmUgdW5uZWNlc3NhcnksIGNvbmZ1c2luZyBldmVuOyBwcm9iYWJseSBtb3N0 IHVzZXMgb2YgdHJhY2UgdG9vLiAgWW91IG1heSBmaW5kIHRoYXQgeW91ciBZQU5HIERvY3RvciBt YWtlcyBhIGZldyBodW5kcmVkIGNvbW1lbnRzIGFsb25nIHRoZXNlIGxpbmVzIC0gbW9zdCBkby4N Cg0KU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgaXMgb3V0IG9mIGRhdGUNCg0KDQpaVFI+IFllcywg SSByZXZpc2VkIGFsbCB0aGUgYWJvdmUuDQoNClRvbSBQZXRjaA0KDQo+DQo+IEJlc3QsDQo+IFRp YW5yYW4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4NCj4gU2Vu dCBmcm9tIFdlTGluaw0KPiC3orz+yMujuiB0IHBldGNoPGlldGZhQGJ0Y29ubmVjdC5jb208bWFp bHRvOmlldGZhQGJ0Y29ubmVjdC5jb20+Pg0KPiDK1bz+yMujuiBpcHBtPGlwcG1AaWV0Zi5vcmc8 bWFpbHRvOmlwcG1AaWV0Zi5vcmc+Pg0KPiDW98zio7ogUmU6IFtpcHBtXSBJLUQgQWN0aW9uOiBk cmFmdC1pZXRmLWlwcG0taW9hbS15YW5nLTAyLnR4dA0KPiDKsbzko7ogMjAyMi0wMS0xNCAxODow MDo0Mw0KPg0KPiBUaGlzIGxvb2tzIGxpa2UgJ2l0IGhhcyBiZWVuIGFub3RoZXIgc2l4IG1vbnRo cyBzbyBpdCBpcyB0aW1lIHRvIA0KPiByZS1zdWJtaXQnIEktRC4gIEkgbm90ZSB0aGF0IHRoZSBZ QU5HIG1vZHVsZSBkYXRlIHJlbWFpbnMgYXQgMjAyMSANCj4gd2hpY2ggc2VlbXMgYSB1c2VmdWwg aW5kaWNhdG9yIQ0KPg0KPiBUb20gUGV0Y2gNCj4NCj4gT24gMTQvMDEvMjAyMiAwMTowOCwgaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOg0KPj4NCj4+IEEgTmV3IEludGVybmV0LURyYWZ0 IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmll cy4NCj4+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIElQIFBlcmZvcm1hbmNlIE1l YXN1cmVtZW50IFdHIG9mIHRoZSBJRVRGLg0KPj4NCj4+ICAgICAgICAgICBUaXRsZSAgICAgICAg ICAgOiBBIFlBTkcgRGF0YSBNb2RlbCBmb3IgSW4tU2l0dSBPQU0NCj4+ICAgICAgICAgICBBdXRo b3JzICAgICAgICAgOiBUaWFucmFuIFpob3UNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBKaW0gR3VpY2hhcmQNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGcmFuayBCcm9j a25lcnMNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTcmloYXJpIFJhZ2hhdmFuDQo+ PiAgICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtaXBwbS1pb2FtLXlhbmctMDIu dHh0DQo+PiAgICAgICAgIFBhZ2VzICAgICAgICAgICA6IDI2DQo+PiAgICAgICAgIERhdGUgICAg ICAgICAgICA6IDIwMjItMDEtMTMNCj4+DQo+PiBBYnN0cmFjdDoNCj4+ICAgICAgSW4tc2l0dSBP cGVyYXRpb25zLCBBZG1pbmlzdHJhdGlvbiwgYW5kIE1haW50ZW5hbmNlIChJT0FNKSByZWNvcmRz DQo+PiAgICAgIG9wZXJhdGlvbmFsIGFuZCB0ZWxlbWV0cnkgaW5mb3JtYXRpb24gaW4gdXNlciBw YWNrZXRzIHdoaWxlIHRoZQ0KPj4gICAgICBwYWNrZXRzIHRyYXZlcnNlIGEgcGF0aCBiZXR3ZWVu IHR3byBwb2ludHMgaW4gdGhlIG5ldHdvcmsuICBUaGlzDQo+PiAgICAgIGRvY3VtZW50IGRlZmlu ZXMgYSBZQU5HIG1vZHVsZSBmb3IgdGhlIElPQU0gZnVuY3Rpb24uDQo+Pg0KPj4NCj4+IFRoZSBJ RVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPj4gaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pcHBtLWlvYW0teWFuZy8NCj4+ DQo+PiBUaGVyZSBpcyBhbHNvIGFuIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPj4g aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWlwcG0taW9h bS15YW5nLTAyDQo+Pg0KPj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZh aWxhYmxlIGF0Og0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWll dGYtaXBwbS1pb2FtLXlhbmctMDINCj4+DQo+Pg0KPj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNv IGF2YWlsYWJsZSBieSByc3luYyBhdCANCj4+IHJzeW5jLmlldGYub3JnOjppbnRlcm5ldC1kcmFm dHMNCj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+IGlwcG0gbWFpbGluZyBsaXN0DQo+PiBpcHBtQGlldGYub3JnDQo+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0NCj4+IC4NCj4+DQo+DQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGlwcG0gbWFpbGlu ZyBsaXN0DQo+IGlwcG1AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pcHBtDQo+DQo= From nobody Tue Jan 25 06:22:03 2022 Return-Path: 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 7D1CD3A1461 for ; Tue, 25 Jan 2022 06:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOTFyhlE1Tt5 for ; Tue, 25 Jan 2022 06:21:56 -0800 (PST) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-lo2gbr01on0629.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe15::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F5E53A1458 for ; Tue, 25 Jan 2022 06:21:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mNF6chThoOg5MgMa4AV34+0nMP7Tm6cAQ0j0igO9DMRIg9EHM87Cn+jgzRmpJBjm6Lymto28qtXvRl0Po3V9021uRZ9VtFo35cu7gTgoHH4G290edcafOxNwpOAdCHfo3dqg4/SXVggHXh0sJAF7PXCEbBw4BC1Nt1KdS/q9kUwVh2NsMidpdMX1rIysEVnEUNI73IzItR8YYAe9iFWvZVBdNPPPmf3nrJGSlGriqAVIKRqtb5RSFHSEgnCKPy8pOmqvdaxZTdxLHNG45fQOBEzq2ab1h4pfd2R1DnPbbl6gX8vLJXJFSze5pRNS4FuLc1wW70YOtWeSiCG3EiyaqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=k7VM7tykpvEuDDtVPvIVId1DDfVGxeDX0s/Ea+g7d/M=; b=XVZj7dvqNRdzzzJmFtiiGlF8PWYdraSIlrriK98tmPvz9hHcj4X5gFpQXg7JCq+oNeSwD0xJTm/W5KnekZ0aeDijTN36UAZ0AoBPzH0fcQydFoCzOkdtNCniqRFu7Lw+RzZCDSM0a20eRobNkTxHpbu/uQHTwGxAteIrUvMG3SAYm/Ovuk354h4DCIPvZylLZUK+xVdvG8OHYDhZywS78Uh6GAfd9hjWxDUvf6wDmyIR0YEEeKEVz+ZyiGEv1q0swodAD2nP9XZa80QGKg1fdlQGTS/ezF+/Ct3X0eQa8563yH84vjUoZU9dTWijtt9+4nN2qKktrWG78Va0MUd3sQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bt.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=k7VM7tykpvEuDDtVPvIVId1DDfVGxeDX0s/Ea+g7d/M=; b=C9Uud13XXJhleRjc2kFN1HKiCXzPceS8lqwMgj26YCPmjfHwV/5E9NdzJm3+UzKhHheZN2ePT7dOdv3fFP+p9iZRDyVIusGJmSBZz8d8iw5/Y9pJxpohIHovDdubG5qx9ZR4EAMz/NYn8NJg7+1Xpv60md4sJEa8pubQ5ReOUHY= Received: from LO0P123MB6063.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:244::5) by CWLP123MB3027.GBRP123.PROD.OUTLOOK.COM (2603:10a6:400:49::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4909.7; Tue, 25 Jan 2022 14:21:49 +0000 Received: from LO0P123MB6063.GBRP123.PROD.OUTLOOK.COM ([fe80::5595:8e39:4f6:1bc4]) by LO0P123MB6063.GBRP123.PROD.OUTLOOK.COM ([fe80::5595:8e39:4f6:1bc4%5]) with mapi id 15.20.4909.017; Tue, 25 Jan 2022 14:21:49 +0000 From: To: , , CC: , , , , , Thread-Topic: [Editorial Errata Reported] RFC8912 (6755) Thread-Index: AQHX49R3mGmv/Se9NUKsl986nCdo5axzJnGAgAD+yNA= Date: Tue, 25 Jan 2022 14:21:49 +0000 Message-ID: References: <20211127211835.526DAF5D08@rfc-editor.org> <5EA0BA63-4E14-4B39-8BAB-873DB59A5F65@amsl.com> In-Reply-To: <5EA0BA63-4E14-4B39-8BAB-873DB59A5F65@amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_55818d02-8d25-4bb9-b27c-e4db64670887_Enabled=true; MSIP_Label_55818d02-8d25-4bb9-b27c-e4db64670887_SetDate=2022-01-25T14:21:48Z; MSIP_Label_55818d02-8d25-4bb9-b27c-e4db64670887_Method=Standard; MSIP_Label_55818d02-8d25-4bb9-b27c-e4db64670887_Name=55818d02-8d25-4bb9-b27c-e4db64670887; MSIP_Label_55818d02-8d25-4bb9-b27c-e4db64670887_SiteId=a7f35688-9c00-4d5e-ba41-29f146377ab0; MSIP_Label_55818d02-8d25-4bb9-b27c-e4db64670887_ActionId=c71de145-6a03-413d-b274-cb06d81e84d3; MSIP_Label_55818d02-8d25-4bb9-b27c-e4db64670887_ContentBits=0 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=bt.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 54937b76-bf39-4828-613a-08d9e00e06d3 x-ms-traffictypediagnostic: CWLP123MB3027:EE_ x-microsoft-antispam-prvs: x-antispam-2: 1 x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: meoAQ7zoMiWDlmoClfpr/1E0hBXp6oQujSNsJp5DjWgTWpPVvZweqrvOci3Upp5Z3bmgse7vDQgeNjgdFm6tWl40u+KDJjtPqm7ZXDyS8WzzSXNcmHGHsSugGjt3UTdlobtw/Qgf1KYleKRBkBZcWM6B0pXGQaih//l9lLKr+9ibRPmF15qN3Z5Uzc1qEA4ebagKfmPmS2vgXtZLfXPGFX/Eo6bjFk6Wb/3LP/gLLhX/ffN4X65f+M0Y7uXUzKP3qa5LDlEDGQldOEtqCXSI1333UaOxX6ClyT9j1Vm9iMpt6NfsWPmpQyy25wsUiXWC3OoIgWGvlU6GPuMlRNfckwbzR5dphBNB0oIw3Muv9G/SIq+mFb8wiHFPq/ADBE72RkbSAKX5ify8kXMae/haNpTwB5fM0O6VV95ZKl4k7gALJQJb1vbQqxJOq3gCyqYkusb5LBM5GW3Rdar8+1frwDOiAE6NZR1jGmnLj5IHOThAQodJYx4uPrOVpgHebmomFQdB27CNV7XaX6bZbgHVG0L06YJ0H5oezVZeG8Crdj9r1Q7HTm+LhwMJJr+AigqHukOzJx0L7ImfbZ7j51WZzZDH9JSHIyvmV8qfNVIlihQ5mLcdebLZqI0x6RIu6WpK0Y9y59RZXjXJiVyCMYMv12+KRs+a9R42do9wrYt/gt8IYiqMERfuMXnXg+6bMnxr4qaAxyr5veCGShNWO7rVQ//5uvmpm00K+xZQ5OLJODB0csJ+RgfgBhOPo5BIDrzUoyGKfLGS/GmcWgU+m2JW2OhwB4PZUuF4A+TE8nnNajXkUxYiqeeEjITw2eGU3stw x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO0P123MB6063.GBRP123.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(6506007)(53546011)(122000001)(9686003)(38100700002)(52536014)(316002)(38070700005)(110136005)(54906003)(71200400001)(26005)(186003)(45080400002)(16799955002)(5660300002)(8676002)(86362001)(508600001)(7696005)(64756008)(76116006)(4326008)(2906002)(66476007)(66946007)(66556008)(33656002)(966005)(83380400001)(66446008)(55016003)(8936002)(82960400001)(10090945008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?Ab+BJSUVLgIhlzeBThy7VFxAnQ2r/k112JMOZAfrHWNn97xtJr5BGz3aMq1z?= =?us-ascii?Q?aR9VeEbfxOsPYANqyBdvO1IiV0WZuDevZFWRP1D72GY6Xqx4Z9uq3pRqV9aj?= =?us-ascii?Q?v+Ml3ax8yBvnuSnnSDGebP/0XTReFVc++j5dUcCOn25/XuaWgEBo7BOx8HTG?= =?us-ascii?Q?PDVuQ8rQE1Ky5oAqYlIHOLagTDxh8hQE3hy5ADn9DA0FEdMrzmkb1yp6rPcV?= =?us-ascii?Q?ODxhmitRr3aPeRipItnuwNVpQ2KlSn5AVbOnewRUAg0ExvMggaDM/RlqFPcs?= =?us-ascii?Q?9X3WRlsisn34N/ZQwga5afXRlzT4XS7NQXnEAjqzqdGA5YCFrWX5ggt1U25x?= =?us-ascii?Q?hLNx3w3Qg/Pu4zd825L6Qp6U2gXYP7fZTKOfgpHDANvFoMw0FahgCKeD8ot6?= =?us-ascii?Q?8tgtJOP5ie2qhFSeyKpxsVvh4e1M0Y4Pb74ndhHnCjJ+MGagUiIyyJZ6A3E+?= =?us-ascii?Q?fKWLVyP2o9Bxyud8f/rc7yolOb00H7q+YuOQPfn0LokTJ/Le1ti53d4+O7wV?= =?us-ascii?Q?Cr6ZXw25FrmaC2H8AJC96tinsNRXmyGrgLmZ88j8WG/4a8jgzmZ/crq8k7K1?= =?us-ascii?Q?OjjZLSpBaRte26K2+2zwomd7SRF8HoNc/Cp4P0G/cXg4O5WV3MfQUn8Ol1ny?= =?us-ascii?Q?t+KoEBSBgcrDLVkrZp8bXRqZOTBRx4c4dDuUe+K3iP8QdFY4krpWO+0naZ41?= =?us-ascii?Q?NtdKkVUCUd20xPRlr39EWTq/PW1omlVOJa1/IC9FYHWQAjBJc42YEbJEKtGC?= =?us-ascii?Q?ZqM8rtDHPjSt33vpjaW/jnZFzEnRz7S3Tj4hhhGDDU5HZIBLBVj9B6DUXPAd?= =?us-ascii?Q?tPBF2JRuAczD5obiQFyCIR78WRYVQkrIc1A58KKki7NIorMp0PallhRp4YfD?= =?us-ascii?Q?j7DqFYBalERqFjj9HJ05uPNrdgMYLi3fe+CxasX3xmrZw63OH/dQ8XzsB34I?= =?us-ascii?Q?OyNcCIRNntQ2gmhPIwfYMPsoK7MeIcZtfUlZD2kDma9CO4yXCWSGcoWRi4BE?= =?us-ascii?Q?sNovcgcz0hXlJ/sea6LUX+PAaxa7rCLsT83gvXrGl4wC9UIVs5HPOEFXgcdG?= =?us-ascii?Q?LHtr0ruVxmddw41uheVE7L24yttlUIklhtVaggd1QeKHZp5fbyUgUDT4AC3g?= =?us-ascii?Q?9oyZX4gx5r0rZOUWsn41sNEQ7P4op6oud+hHZLEoa0GDhbjsqbo7TxVS9MWN?= =?us-ascii?Q?BkLVs4gaMJqHKWtRH2ixlln8jjwt0x4SHdDOyCZ5lQbuDQF+y7AV3nZwK5in?= =?us-ascii?Q?74J1d+g/nKhPrLMhhpLjqMphHccAVyvpg7NakJnIDwQzKevdj35GRuLyLSty?= =?us-ascii?Q?VYh2MDu/D9sslvrYPw4xOFZqMuNnM9UBAmFDJM4y7V/CMNSvkV95DOXEuYQ4?= =?us-ascii?Q?aQecw0LXX1xKH0C6NZrafcPIaQLgPpKbma2Qa9DEGIcc5244FeNCkuNbBsYY?= =?us-ascii?Q?YszuHHaVTxbq2bNLZxzeJ1OGspLs4b6zbATz8j4lb9efgtYqqQloIBGB55I3?= =?us-ascii?Q?HpIi26J4d4aDSMetLpZHexvqdrZreZNvrUyOhUW9/deFTV2aSxf2vgEYQKpq?= =?us-ascii?Q?osK0XaORu0mNLD0n56Zrj248KpuRTYie/gUIqry0ocBvDgiEDUNcRkgb9J8w?= =?us-ascii?Q?zw=3D=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: bt.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LO0P123MB6063.GBRP123.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 54937b76-bf39-4828-613a-08d9e00e06d3 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2022 14:21:49.7847 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nq3WG42W+7op78gikeWLa+0UTzO5CQdP+hsdbzCX3YTGJ4tbPpWI3U9G9qXTwTDh6cfL4q5Y6W5pz1+cCWW+eA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CWLP123MB3027 Archived-At: Subject: Re: [ippm] [Editorial Errata Reported] RFC8912 (6755) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2022 14:22:02 -0000 Thanks to Nikolai for this. I think it's a reasonable editorial change to add the proposed sentence, f= or consistency with the other entries for the Performance Metrics Registry = that are defined in this RFC. Best wishes, Phil > -----Original Message----- > From: Chris Smiley > Sent: 24 January 2022 23:07 > To: martin.h.duke@gmail.com; Zaheduzzaman Sarker > > Cc: RFC Errata System ; nmalykh@ieee.org; MORT= ON > JR., AL ; ippm@ietf.org; kld@att.com; Eardley,PL,Philip= ,TUD1 > R ; marcelo@it.uc3m.es > Subject: Re: [Editorial Errata Reported] RFC8912 (6755) >=20 > [You don't often get email from csmiley@amsl.com. Learn why this is impor= tant at > http://aka.ms/LearnAboutSenderIdentification.] >=20 > Greetings, >=20 > We are unable to verify this erratum that the submitter marked as editori= al. > Please note that we have changed the "Type" of the following errata repor= t to > "Technical". As Stream Approver, please review and set the Status and Ty= pe > accordingly (see the definitions at > https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.r= fc- > editor.org%2Ferrata- > definitions%2F&data=3D04%7C01%7Cphilip.eardley%40bt.com%7Cfb8814f4a67 > c48aa144608d9df8e3e5c%7Ca7f356889c004d5eba4129f146377ab0%7C0%7C0% > 7C637786624889069552%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3D > CJ4RN%2FKZt6UYto4EAY1G3Wu3riKRqFW8NFLKmAQs34c%3D&reserved > =3D0). >=20 > You may review the report at: > https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.r= fc- > editor.org%2Ferrata%2Feid6755&data=3D04%7C01%7Cphilip.eardley%40bt.co= m > %7Cfb8814f4a67c48aa144608d9df8e3e5c%7Ca7f356889c004d5eba4129f146377a > b0%7C0%7C0%7C637786624889069552%7CUnknown%7CTWFpbGZsb3d8eyJW > IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30 > 00&sdata=3DOHy05pZaRETzu6BBt1hUK5QxOogAcak8BXESXVMNjpU%3D&a > mp;reserved=3D0 >=20 > Please see > https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.r= fc- > editor.org%2Fhow-to- > verify%2F&data=3D04%7C01%7Cphilip.eardley%40bt.com%7Cfb8814f4a67c48a > a144608d9df8e3e5c%7Ca7f356889c004d5eba4129f146377ab0%7C0%7C0%7C63 > 7786624889069552%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC > JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DBTueJ > 1EQlswqawvNvSj1eW3mJtcZ1Z9tua3%2FkDCtyOw%3D&reserved=3D0 for > further information on how to verify errata reports. >=20 > Further information on errata can be found at: > https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.r= fc- > editor.org%2Ferrata.php&data=3D04%7C01%7Cphilip.eardley%40bt.com%7Cfb= 8 > 814f4a67c48aa144608d9df8e3e5c%7Ca7f356889c004d5eba4129f146377ab0%7C0 > %7C0%7C637786624889069552%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4 > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&am > p;sdata=3DsdmFLvY5ojS4mXppR9YandoaE%2Bls9v1BMyuPzT%2B9%2FQU%3D&a > mp;reserved=3D0. >=20 > Thank you. >=20 > RFC Editor/cs >=20 > > On Nov 27, 2021, at 1:18 PM, RFC Errata System > wrote: > > > > The following errata report has been submitted for RFC8912, "Initial > > Performance Metrics Registry Entries". > > > > -------------------------------------- > > You may review the report below and at: > > https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= . > > rfc-editor.org%2Ferrata%2Feid6755&data=3D04%7C01%7Cphilip.eardley%4= 0 > > > bt.com%7Cfb8814f4a67c48aa144608d9df8e3e5c%7Ca7f356889c004d5eba4129f14 > 6 > > > 377ab0%7C0%7C0%7C637786624889069552%7CUnknown%7CTWFpbGZsb3d8 > eyJWIjoiMC > > > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&a > mp;sd > > > ata=3DOHy05pZaRETzu6BBt1hUK5QxOogAcak8BXESXVMNjpU%3D&reserved > =3D0 > > > > -------------------------------------- > > Type: Editorial > > Reported by: Nikolai Malykh > > > > Section: 5.3.5 > > > > Original Text > > ------------- > > 5.3.5. Runtime Parameters and Data Format > > > > Src: The IP address of the host in the Src Role (format > > ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value > > for IPv6; see Section 4 of [RFC6991]). > > > > > > Corrected Text > > -------------- > > 5.3.5. Runtime Parameters and Data Format > > > > Runtime Parameters are input factors that must be determined, > > configured into the measurement system, and reported with the results > > for the context to be complete. > > > > Src: The IP address of the host in the Src Role (format > > ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value > > for IPv6; see Section 4 of [RFC6991]). > > > > > > Notes > > ----- > > Skipped paragraph. > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or rejected. > > When a decision is reached, the verifying party can log in to change > > the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC8912 (draft-ietf-ippm-initial-registry-16) > > -------------------------------------- > > Title : Initial Performance Metrics Registry Entries > > Publication Date : November 2021 > > Author(s) : A. Morton, M. Bagnulo, P. Eardley, K. D'Souza > > Category : PROPOSED STANDARD > > Source : IP Performance Measurement > > Area : Transport > > Stream : IETF > > Verifying Party : IESG > > From nobody Tue Jan 25 09:08:16 2022 Return-Path: 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 078DF3A0125 for ; Tue, 25 Jan 2022 09:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0GpT_WKtoTT for ; Tue, 25 Jan 2022 09:08:10 -0800 (PST) Received: from mx0b-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A8483A011B for ; Tue, 25 Jan 2022 09:08:10 -0800 (PST) Received: from pps.filterd (m0288867.ppops.net [127.0.0.1]) by m0288867.ppops.net-00191d01. (8.16.1.2/8.16.1.2) with SMTP id 20PFLH47012957; Tue, 25 Jan 2022 12:08:02 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0288867.ppops.net-00191d01. with ESMTP id 3dt4wcenkj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Jan 2022 12:08:01 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 20PH81l0029435; Tue, 25 Jan 2022 12:08:01 -0500 Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [135.66.87.47]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 20PH7qe7029052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 25 Jan 2022 12:07:54 -0500 Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [127.0.0.1]) by zlp27126.vci.att.com (Service) with ESMTP id C5AB04005960; Tue, 25 Jan 2022 17:07:52 +0000 (GMT) Received: from MISOUT7MSGEX2AF.ITServices.sbc.com (unknown [135.66.184.205]) by zlp27126.vci.att.com (Service) with ESMTP id A63F04005951; Tue, 25 Jan 2022 17:07:52 +0000 (GMT) Received: from MISOUT7MSGEX2AB.ITServices.sbc.com (135.66.184.210) by MISOUT7MSGEX2AF.ITServices.sbc.com (135.66.184.205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.17; Tue, 25 Jan 2022 12:07:52 -0500 Received: from MISOUT7MSGETA02.tmg.ad.att.com (144.160.12.220) by MISOUT7MSGEX2AB.ITServices.sbc.com (135.66.184.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.17 via Frontend Transport; Tue, 25 Jan 2022 12:07:52 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.107) by edgeso2.exch.att.com (144.160.12.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.17; Tue, 25 Jan 2022 12:07:48 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CZNUyRieRi7n1r28CN2ycNsq3VS5L8DwXuEVUcGGHUFDU7GWGIsTEUoIuHL5BMgaYv1XLjTDH272iWGR6Xp7B8kbZ4pk94kxsIg6InfcHLgLnf2RLvJ5VaZpV9OIrqAXLYgJm5+WJUphj/TCkwR7+a4mTwisDaC3Cqa3vJRqDjtO7JXiiF3Dh1Zf9WoNPP6rA3F1onrKJMmUyiQ6a/9ahqgRFyMmBlcQpPWcoQ5TlAUtOvN5epyGpyKO0jLVkfvi6OCsyE2gQ3nD8wzI6Qm9bBRHKYlmcQOfZ7BpPPerGjbQrFnGmeCDgUs2C5nktcHug2NEIq0WJFal9fzWQgJs7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WRRGi4BGT4wcJf8smyVPVY+8B4Q/WvbViMQTXlhFqUI=; b=jglvSUZUwHFyAdPlZOsc8Zt8qwT1Zm+0kpKI4OWt/9yfGsGP2AuJ7HIk/4ir7lGPXiUCsM0KP0FX27szoZO+Ri0B8gF3ioHV/WBGuyV+A1bQem5S+x4BDTK3I2JH4sO1Bh+zYnPaDI/+tY8vIZzalk6MakdFSRRwVGxohf+SbW2cBaVdDH7wO6Xt50tmeiIw5Gr2oy5PiKWtcsARY0ZzblwrNz5H3kziCfQZqi/ynnr5bI2ZIR1SkbFs3JTf7qRIb2IE7mQGY3+o0cYNA/R9gNVu4VzyzZzAMd+0QdjFxkJTZYocJhPnwF+9yXIB53TTUqsltV1wAX1mmSV0xhvsUQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WRRGi4BGT4wcJf8smyVPVY+8B4Q/WvbViMQTXlhFqUI=; b=CcGk4+dPXA7TCgyq/Hs89WatLLu3syANC1CWa/blkZDj5viKPWlgtrvRxeQ4xx0cDmmRRo6/LczRRjlNMhPlTx/uS/MjaNTCBA+9SrYX6/LaFVG5MU2s4CqOhAgSxWPYMnZM2adb1rIlhMUerpejctLmQUCwerhHaL43w7wN8fY= Received: from CH0PR02MB7980.namprd02.prod.outlook.com (2603:10b6:610:105::17) by DM8PR02MB8263.namprd02.prod.outlook.com (2603:10b6:5:314::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4909.10; Tue, 25 Jan 2022 17:07:47 +0000 Received: from CH0PR02MB7980.namprd02.prod.outlook.com ([fe80::a032:e38:2c60:766]) by CH0PR02MB7980.namprd02.prod.outlook.com ([fe80::a032:e38:2c60:766%9]) with mapi id 15.20.4909.019; Tue, 25 Jan 2022 17:07:47 +0000 From: "MORTON JR., AL" To: "philip.eardley@bt.com" , "csmiley@amsl.com" , "martin.h.duke@gmail.com" , "Zaheduzzaman.Sarker@ericsson.com" CC: "rfc-editor@rfc-editor.org" , "nmalykh@ieee.org" , "ippm@ietf.org" , "D'SOUZA, KEVIN L" , "marcelo@it.uc3m.es" Thread-Topic: [Editorial Errata Reported] RFC8912 (6755) Thread-Index: AQHYEXcjL3fjApVvu0uPqxnvY0wKUaxzytmAgAAtf5A= Date: Tue, 25 Jan 2022 17:07:46 +0000 Message-ID: References: <20211127211835.526DAF5D08@rfc-editor.org> <5EA0BA63-4E14-4B39-8BAB-873DB59A5F65@amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_55818d02-8d25-4bb9-b27c-e4db64670887_Enabled=true; MSIP_Label_55818d02-8d25-4bb9-b27c-e4db64670887_SetDate=2022-01-25T14:21:48Z; MSIP_Label_55818d02-8d25-4bb9-b27c-e4db64670887_Method=Standard; MSIP_Label_55818d02-8d25-4bb9-b27c-e4db64670887_Name=55818d02-8d25-4bb9-b27c-e4db64670887; MSIP_Label_55818d02-8d25-4bb9-b27c-e4db64670887_SiteId=a7f35688-9c00-4d5e-ba41-29f146377ab0; MSIP_Label_55818d02-8d25-4bb9-b27c-e4db64670887_ActionId=c71de145-6a03-413d-b274-cb06d81e84d3; MSIP_Label_55818d02-8d25-4bb9-b27c-e4db64670887_ContentBits=0 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 46c123b5-5e09-46bf-1f73-08d9e02535c4 x-ms-traffictypediagnostic: DM8PR02MB8263:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vSQuxmuXOLL9rtF37Ilb4YiHthjerezcCw6hjevZMSA82BnAVte/Ka92iJ2SPzKdrd2HBwCPUloH7i6hGPMmj6eCQ7ymSlIyJxDzzOKx8iL3ddzCMNitLYzfxis2HX9iL51keYpd9ZZJ9TSk9wDcCwFAR72sgemIclBOFQGmYiLtu2m0nYm3biqTVQGSFxE6DUGWrVCKn6IkTtzfo59B0WoqxYil5R2sFk0r9ZR2W736EJkaH7ViLfkMysV0Hof5aH2ZhU1+Gmu73N/q+exGvdCaPfpRKPyd1Qmntb8nepZuOxKq0JttDUyJCxacQFPNBM+TMrE9MQw950q0haApOkmSI6SZoKQ7twvsO+TRObeW8gY6oL+Ry7iDBHK/P8ZeVlhatszPx11HRdVZ8BVvfbTsg8bgPx3lDh5tIrHnadUuJl/G2YI97Ugf4WoDeahRQhhViYlMAR3XLUO+K3oD0sAPIVZ0B/kEFJXkvAbH09m5s211LifnoVtIT9zRuAu3ZJa4sVtxKdp9JzU2JkOzXNQpS7C0oZfZ5gsRSjmDG9mMi59J6FQPwTwlGxs34PokB4RcQhFrbEuOsggzUxx4wtsfVGAoLf5KaJjJgXwAJqqTOsFgWg1tMTxJwDt5EW/b44j0W4+If4B1UyvSkec4AeO/rhfDq8EBpvlzOlSOlCbF5qYP6HSXrBfi1P8ebl0/XnobBrTPpDhAt1OGr0MRJTG4n2dT8C6toPUH/E6fR11g7099k9g7oiyoYNrIowENo15swbmgcU9SWETbcCrNQpluQpQ9iMA68hUQsN6LiiM= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH0PR02MB7980.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(8936002)(38070700005)(55016003)(82202003)(86362001)(186003)(9686003)(316002)(8676002)(110136005)(122000001)(16799955002)(6506007)(38100700002)(71200400001)(7696005)(83380400001)(53546011)(52536014)(508600001)(2906002)(966005)(66446008)(33656002)(45080400002)(66946007)(66556008)(66476007)(64756008)(54906003)(26005)(5660300002)(76116006)(82960400001)(4326008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?yYZLQcrCYZa9uP8pFlzMTBJyzLcMCuANQB0eHVeiWNnuF216MqSGXQ7Nny8C?= =?us-ascii?Q?TgL7Ovwri8RL1tc4vKFz8ISXB/ZuuBZWSlSpfZYbv5umhInDfh8etcXG74Lg?= =?us-ascii?Q?bZXG/x6vxUoQ8Fd3G17CeWH24DbJECvFVK5gpEh8Qlb0WEmWBNMbwvMa1gOo?= =?us-ascii?Q?4jstutv8oMoMlkQOFYVW6c4mw4OJ8W0UgUXhYpWBoz7Ts5+SG9Ozcfv5L7gh?= =?us-ascii?Q?ftFN67p9wBw1VKva9BPchEPRBPiMfUsi81xlPUwhltiQu2MKSEH6YVtKfXlU?= =?us-ascii?Q?3h8qFn3NE8mnikFc9OXk+UJeuNCWJ8ACCLD9IjmNkCcyjtvUuLkpBiTKzScH?= =?us-ascii?Q?urTJ9FE+qq9xPm7UPT9iPZsoN/ZKILxxpa83v3FYkBdJDs9/Xnbpjc+LdULq?= =?us-ascii?Q?4ChDz7DwaccBMxQzaDGRkIopBtQZ5gYjLMMyyxKgZaX9JBrtNzr+77CUKKmm?= =?us-ascii?Q?ayqWdpwmj500YbWsnFF+MNq903lNan/orF4embugTNkIWnEsUqJKB9RqGyKW?= =?us-ascii?Q?Fe7CsMOOYt8Dz3I7CqkJJaLUpoHH1XFT/HI4mBJkPc4djjBtSilvFqnRiHqv?= =?us-ascii?Q?0oZS3SLZCWjNik3GNi+71GVm/afCm0y2OGi0mGLpNBPYVkp7j6trLBS2byVh?= =?us-ascii?Q?mm5xaiQ2pi88+V+zgqkAjkp3IPmVyppebKK940l+UkTUXl9XEywfh9UQupXv?= =?us-ascii?Q?F0qFU8usGgGePo3+tkVmr3eGDX6oiaR9vYRr3xdmOGDy7OOjY1RHvEjyw3YP?= =?us-ascii?Q?+4GgGxteJrClWOOfNyUC8rlq9q6hAMouVJZpPSHGlrLj4mxsZItqvzvJK5Lj?= =?us-ascii?Q?sfvHabC0bS6mhig4wB5O0BXr7JYNMRr0qs7+uAKBRW8vpousBjHSdaP3kJsu?= =?us-ascii?Q?mlP95Iv29c8qjcIOPMJswbWFLlni4xE+ca40BZ/3+eAUaePxc+WV6B4Pybhp?= =?us-ascii?Q?VG2b5rMv1Vd4+gqvRcBxbRhYFZJJex7YLC/KAs4R9UiXObRL5PoQuIhtvniG?= =?us-ascii?Q?u8CrSsvIn+lh/Z4rBE3Iwjurn8y1OAL6WgdyOBCPXBGdtWGUCS83Hm/JdQQy?= =?us-ascii?Q?2DmzlBDaB0kCwj/+H1yMdt80TUEA0FeBGmcq1q4cY4zBQDy0h2AKpC2KOVZ1?= =?us-ascii?Q?P9pJay2wBSWtYCew09ZcIKL6fWhuHqv/22QtajC6IhrrIyoVc0W3VyCpbOI5?= =?us-ascii?Q?un/cy4hHxL2BXD7RhIsiY/LILAKyhwPJ25xKtcMyzZ0xF4aeiGWp+NoIskEO?= =?us-ascii?Q?aOwJO3bLin4yFv7Ait8ckARB6NcEEdOvODXP6MExYNvjGLyGOE57oPDMDiB+?= =?us-ascii?Q?ifA5SiOwECwVVQryqST59Ezz6oleShJ1ZijdpCOC1wWNNw2T/tRSJcKMA2Zj?= =?us-ascii?Q?PrgkEAP901rDWbnqQf33kMt1ph2fCDt6tYlouMeS1w2dQ987UwqEAQZqXhMT?= =?us-ascii?Q?PYGTwLr2NtdIBT1MJcQmafrwbxry5augdo1mKem2mdgC9kVFgeGLDKhe3ViP?= =?us-ascii?Q?Fx95IJqaOAaYWQPxm0lcKnxKnTUiofodMBo2mFr2IvR/y+WTr+6Yib/lbR2r?= =?us-ascii?Q?4YJVBOPG2Up5tAHo/0I=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH0PR02MB7980.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 46c123b5-5e09-46bf-1f73-08d9e02535c4 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2022 17:07:46.8999 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: PSYP/u058hak28r8ewmS82KLdKQhVakbIk/doOzwd/pyfPB2n3iOPb208PW/ToMy X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM8PR02MB8263 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: 25908B9CDE62253C01A7FB4C535C9AD3A4878F0B46BA8BBEC0FF22AA5F533E7C2 X-Proofpoint-ORIG-GUID: 3dbLvbcgihNNcnidNDkvjq5JsGoLRkRA X-Proofpoint-GUID: 3dbLvbcgihNNcnidNDkvjq5JsGoLRkRA X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-01-25_03,2022-01-25_02,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 mlxlogscore=999 phishscore=0 spamscore=0 priorityscore=1501 bulkscore=0 suspectscore=0 mlxscore=0 impostorscore=0 malwarescore=0 clxscore=1011 adultscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2201250106 Archived-At: Subject: Re: [ippm] [Editorial Errata Reported] RFC8912 (6755) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2022 17:08:15 -0000 +1, this might appear to be a "lot of text", but it is a consistency change= =3D Editorial. The first place we might fix this is in the related registry entries themse= lves. Al > -----Original Message----- > From: philip.eardley@bt.com > Sent: Tuesday, January 25, 2022 9:22 AM > To: csmiley@amsl.com; martin.h.duke@gmail.com; > Zaheduzzaman.Sarker@ericsson.com > Cc: rfc-editor@rfc-editor.org; nmalykh@ieee.org; MORTON JR., AL > ; ippm@ietf.org; D'SOUZA, KEVIN L ; > marcelo@it.uc3m.es > Subject: RE: [Editorial Errata Reported] RFC8912 (6755) >=20 > Thanks to Nikolai for this. > I think it's a reasonable editorial change to add the proposed sentence,= for > consistency with the other entries for the Performance Metrics Registry t= hat > are defined in this RFC. >=20 > Best wishes, > Phil >=20 > > -----Original Message----- > > From: Chris Smiley > > Sent: 24 January 2022 23:07 > > To: martin.h.duke@gmail.com; Zaheduzzaman Sarker > > > > Cc: RFC Errata System ; nmalykh@ieee.org; MO= RTON > > JR., AL ; ippm@ietf.org; kld@att.com; > Eardley,PL,Philip,TUD1 > > R ; marcelo@it.uc3m.es > > Subject: Re: [Editorial Errata Reported] RFC8912 (6755) > > > > [You don't often get email from csmiley@amsl.com. Learn why this is > important at > > > https://urldefense.com/v3/__http://aka.ms/LearnAboutSenderIdentification_= _;!!B > hdT!w_DS_ZFaIvqmgq6Y6w6-nvDvuWysC7zGe73iUxIFA1ZX1xhZGeDqJuZFloBf$ .] > > > > Greetings, > > > > We are unable to verify this erratum that the submitter marked as edito= rial. > > Please note that we have changed the "Type" of the following errata rep= ort > to > > "Technical". As Stream Approver, please review and set the Status and = Type > > accordingly (see the definitions at > > > https://urldefense.com/v3/__https://eur02.safelinks.protection.outlook.co= m/?ur > l=3Dhttps*3A*2F*2Fwww.rfc-__;JSUl!!BhdT!w_DS_ZFaIvqmgq6Y6w6- > nvDvuWysC7zGe73iUxIFA1ZX1xhZGeDqJim04Hqi$ > > editor.org%2Ferrata- > > definitions%2F&data=3D04%7C01%7Cphilip.eardley%40bt.com%7Cfb8814f4a= 67 > > c48aa144608d9df8e3e5c%7Ca7f356889c004d5eba4129f146377ab0%7C0%7C0% > > 7C637786624889069552%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM > > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3D > > CJ4RN%2FKZt6UYto4EAY1G3Wu3riKRqFW8NFLKmAQs34c%3D&reserved > > =3D0). > > > > You may review the report at: > > > https://urldefense.com/v3/__https://eur02.safelinks.protection.outlook.co= m/?ur > l=3Dhttps*3A*2F*2Fwww.rfc-__;JSUl!!BhdT!w_DS_ZFaIvqmgq6Y6w6- > nvDvuWysC7zGe73iUxIFA1ZX1xhZGeDqJim04Hqi$ > > editor.org%2Ferrata%2Feid6755&data=3D04%7C01%7Cphilip.eardley%40bt.= com > > %7Cfb8814f4a67c48aa144608d9df8e3e5c%7Ca7f356889c004d5eba4129f146377a > > b0%7C0%7C0%7C637786624889069552%7CUnknown%7CTWFpbGZsb3d8eyJW > > IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30 > > 00&sdata=3DOHy05pZaRETzu6BBt1hUK5QxOogAcak8BXESXVMNjpU%3D&a > > mp;reserved=3D0 > > > > Please see > > > https://urldefense.com/v3/__https://eur02.safelinks.protection.outlook.co= m/?ur > l=3Dhttps*3A*2F*2Fwww.rfc-__;JSUl!!BhdT!w_DS_ZFaIvqmgq6Y6w6- > nvDvuWysC7zGe73iUxIFA1ZX1xhZGeDqJim04Hqi$ > > editor.org%2Fhow-to- > > verify%2F&data=3D04%7C01%7Cphilip.eardley%40bt.com%7Cfb8814f4a67c48= a > > a144608d9df8e3e5c%7Ca7f356889c004d5eba4129f146377ab0%7C0%7C0%7C63 > > 7786624889069552%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC > > JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DBTueJ > > 1EQlswqawvNvSj1eW3mJtcZ1Z9tua3%2FkDCtyOw%3D&reserved=3D0 for > > further information on how to verify errata reports. > > > > Further information on errata can be found at: > > > https://urldefense.com/v3/__https://eur02.safelinks.protection.outlook.co= m/?ur > l=3Dhttps*3A*2F*2Fwww.rfc-__;JSUl!!BhdT!w_DS_ZFaIvqmgq6Y6w6- > nvDvuWysC7zGe73iUxIFA1ZX1xhZGeDqJim04Hqi$ > > editor.org%2Ferrata.php&data=3D04%7C01%7Cphilip.eardley%40bt.com%7C= fb8 > > 814f4a67c48aa144608d9df8e3e5c%7Ca7f356889c004d5eba4129f146377ab0%7C0 > > %7C0%7C637786624889069552%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4 > > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&am > > p;sdata=3DsdmFLvY5ojS4mXppR9YandoaE%2Bls9v1BMyuPzT%2B9%2FQU%3D&a > > mp;reserved=3D0. > > > > Thank you. > > > > RFC Editor/cs > > > > > On Nov 27, 2021, at 1:18 PM, RFC Errata System > > wrote: > > > > > > The following errata report has been submitted for RFC8912, "Initial > > > Performance Metrics Registry Entries". > > > > > > -------------------------------------- > > > You may review the report below and at: > > > > https://urldefense.com/v3/__https://eur02.safelinks.protection.outlook.co= m/?ur > l=3Dhttps*3A*2F*2Fwww__;JSUl!!BhdT!w_DS_ZFaIvqmgq6Y6w6- > nvDvuWysC7zGe73iUxIFA1ZX1xhZGeDqJnVEPRnG$ . > > > rfc-editor.org%2Ferrata%2Feid6755&data=3D04%7C01%7Cphilip.eardley= %40 > > > > > bt.com%7Cfb8814f4a67c48aa144608d9df8e3e5c%7Ca7f356889c004d5eba4129f14 > > 6 > > > > > 377ab0%7C0%7C0%7C637786624889069552%7CUnknown%7CTWFpbGZsb3d8 > > eyJWIjoiMC > > > > > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&a > > mp;sd > > > > > ata=3DOHy05pZaRETzu6BBt1hUK5QxOogAcak8BXESXVMNjpU%3D&reserved > > =3D0 > > > > > > -------------------------------------- > > > Type: Editorial > > > Reported by: Nikolai Malykh > > > > > > Section: 5.3.5 > > > > > > Original Text > > > ------------- > > > 5.3.5. Runtime Parameters and Data Format > > > > > > Src: The IP address of the host in the Src Role (format > > > ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone valu= e > > > for IPv6; see Section 4 of [RFC6991]). > > > > > > > > > Corrected Text > > > -------------- > > > 5.3.5. Runtime Parameters and Data Format > > > > > > Runtime Parameters are input factors that must be determined, > > > configured into the measurement system, and reported with the resul= ts > > > for the context to be complete. > > > > > > Src: The IP address of the host in the Src Role (format > > > ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone valu= e > > > for IPv6; see Section 4 of [RFC6991]). > > > > > > > > > Notes > > > ----- > > > Skipped paragraph. > > > > > > Instructions: > > > ------------- > > > This erratum is currently posted as "Reported". If necessary, please > > > use "Reply All" to discuss whether it should be verified or rejected. > > > When a decision is reached, the verifying party can log in to change > > > the status and edit the report, if necessary. > > > > > > -------------------------------------- > > > RFC8912 (draft-ietf-ippm-initial-registry-16) > > > -------------------------------------- > > > Title : Initial Performance Metrics Registry Entries > > > Publication Date : November 2021 > > > Author(s) : A. Morton, M. Bagnulo, P. Eardley, K. D'Souza > > > Category : PROPOSED STANDARD > > > Source : IP Performance Measurement > > > Area : Transport > > > Stream : IETF > > > Verifying Party : IESG > > > From nobody Wed Jan 26 00:08:17 2022 Return-Path: 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 D5BAE3A2A45 for ; Wed, 26 Jan 2022 00:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.223 X-Spam-Level: X-Spam-Status: No, score=-1.223 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, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kqIq9Nw1AH1 for ; Wed, 26 Jan 2022 00:08:11 -0800 (PST) Received: from AUS01-ME3-obe.outbound.protection.outlook.com (mail-me3aus01olkn2080d.outbound.protection.outlook.com [IPv6:2a01:111:f403:7004::80d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A5583A2A41 for ; Wed, 26 Jan 2022 00:08:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cNMdH/yxEPcjiMuJR68Juf1ooZBtYB8upU9a6haIkM7nF1XrxtsRO0/tAyQPAqI6n4hn5RgiTaHJgkvs5c4AGxkPjrQ1qxqxm6d0jMvUZxiLhFdzroAwl90BP0m7nlI7lXcxVBpexjmVv++2gNf3DlmhQB3M6BqiAzyyBcZ0G/zYJhDDf89tHRN7TXGMsYvINzO7/wrQb0OM0rO6hfqnOYEARgwqiFuDWfSDWcPypULCOxLULKAopk8lXtfKoaCYfoUdt2k3AdPNqYEQfXvP3lk4oslPb9lqRirjXdlKefD/Uvclvhm1r2GdXtea3TVZh8sdIXifYtyVcCp8BfGW+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=OfyXb3Bq4IuYgfTDt3dosgmXYyVK3hED8oNr0OnHSKE=; b=bV2tNRsDqcz+HYkh2ZqMpHzcPkLCuue6XFYIqGtv3BoOpyTI7BP8YKwAXlfPUsXpmm3L8K4BlWtc1G6TOPTsQWJwKeVQcoA4y7jLHMbAQrndtULGERL7ShtF1Y6juJ4YV9/xHKeJgxjpkvEpu2zAIDL3CSvw93+UMQr+NKALNW/akEI+LGVBNzYMQrlQi0+6XxdaVHlH7cOcxxva9EofCppqVR3FxjM7IUt1liCItjLUrtQvEQRvwCD6Jma9mRka4E/Vu6ZFwiwRU21gsUiqxc/AjGZVSdshcrbeZRSBKgxamraLOmTlX4Rdha28I8/0DbakzW+/VXhdgoC/8mNiSw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OfyXb3Bq4IuYgfTDt3dosgmXYyVK3hED8oNr0OnHSKE=; b=fkXxoryB0Jgf7r1ZEVYySQuBcOt+x+HNAXq2SXl9dnAiDPg7q0hB8JqHkVAdM7dBuKzJNsVGMWVc95Rh/7OjL1oXvsQP0LTlifNUBIo4mC9743r+L52J0wnX3txPH/TnHmqYxMzCMTl3YM7PBMSQ3yp8qHSmAIIoa6FxO29GcJOIjxdrHR/OI48Gt78SQ+BXElk2Dt7xv56pzB7/JlY2EixHKyeDz4eaG8mYdYuG3pQ9mwr6pKFeiVgTPhB4LlGV8mQWWnuyz9rON7zlVHvnXqUWSgKQxHpn03YCXBdyKoQwX3UTw9E6yhwKrKd2lZYueK5/D/OIo3bydf+nW14xyw== Received: from MEYP282MB2942.AUSP282.PROD.OUTLOOK.COM (2603:10c6:220:157::9) by MEYP282MB2896.AUSP282.PROD.OUTLOOK.COM (2603:10c6:220:149::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4930.15; Wed, 26 Jan 2022 08:08:05 +0000 Received: from MEYP282MB2942.AUSP282.PROD.OUTLOOK.COM ([fe80::bd6f:5b76:dc38:e4e6]) by MEYP282MB2942.AUSP282.PROD.OUTLOOK.COM ([fe80::bd6f:5b76:dc38:e4e6%7]) with mapi id 15.20.4930.015; Wed, 26 Jan 2022 08:08:05 +0000 Date: Wed, 26 Jan 2022 16:09:38 +0800 From: "li_zhenqiang@hotmail.com" To: "Tianran Zhou" , ippm References: <164309204653.26831.5703411217906566536@ietfa.amsl.com>, <49bb582d835b4b938cda7e0ad680083c@huawei.com> X-Has-Attach: no X-Mailer: Foxmail 7.2.9.156[cn] Message-ID: Content-Type: multipart/alternative; boundary="----=_001_NextPart675721106514_=----" X-TMN: [piHYT8lmPWi25II721SBbIuWmE4BxQbg] X-ClientProxiedBy: HK2PR04CA0051.apcprd04.prod.outlook.com (2603:1096:202:14::19) To MEYP282MB2942.AUSP282.PROD.OUTLOOK.COM (2603:10c6:220:157::9) X-Microsoft-Original-Message-ID: <2022012616093511987529@hotmail.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 69e1460a-cdfc-42e3-3bff-08d9e0a2fb09 X-MS-TrafficTypeDiagnostic: MEYP282MB2896:EE_ X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: KRzVkJzLEkfPXtLJuF641FzdK+Ba0sC8xPIiBYKFfBMT4Kgyi2WhuKh2cFT0ZKoTMbkOPNelk2dAIxGGgqlpG53tJ6e1vqrXS4R3zDoWHWeTPqj9RD77JUBXqIStxJvaNWUluXM/jzJA9fk/GdwISrriEUEdgvLfIHRjweLqpMGwYl0mZQby7KcWn8ILd0690ctqT+6Hrb0DeCo5r2xkm/S1ELOwswBMYjiOjnCBa7SBHvi6ta29xsQHJJIgoOfQkqrSNVkWJ/gHW4sIwSrW+JJd6JLCiv+ZjREBGtJktxN+hiaxEXl36WT/R6nx4cm378PSXsASbTv26iSb0OfAE41BS25GeB+EaIGfy+8LXCIfTTfXtq8TfTYzbvK4hQJKvf7+ysbfGHtw5gMR7542jAKAm+mkG0QcJf/XW76XF6idVvvy0Z+HjTuYRQg4lnsyCaMH3qz7stbT4jDDUm+dZ7QfVIQKznOk9cr6bv70ic2PYZYy51JDQRDyV6vJgje922pMMNa29Q9HDU3QZ/p2bL+jOtGI9sidN1eYMjmWYk5osJa7X9aMoqYfSfKlgyhjAkSHT0EvyFlBqG7gi6bmTitu5NIOJ3raT4h/8OzHvokHb3oYnjQ2sB3f1dzfwAAGkC1zuhKYDx0mRIzz4Acntg== X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cTJRRlQreW5qOHZYRlBXc2paWGYyZzBudTJUQytOY0tLc2xWWWR6Qi9GZ1kw?= =?utf-8?B?czhQMVh1YVBod09KUitabXE5MEJlcVVDekt3SjlXZi9aTHVoQjZBcFZJL3NE?= =?utf-8?B?eEc5aW9Gb2diVkZQd28rQWJjWVhqbE9yckN4QUdoMnIwZGRaL0p2TldhS1Jl?= =?utf-8?B?MFJwTTRORDV4ejEybGF0bHVnenhtQTVwalNTaE5IaWlmK0toa0FZYUZSTndM?= =?utf-8?B?aGpuUlhMNXNRaHh5ZVBvUUkyNEdZZGYrQ1pXYnRpaW5IZWF4bkY3ZnpMYmhl?= =?utf-8?B?eGJHVy9NUVRuNzY0a01XYjJxL1JsQzdhb1RXTmpSVXNnQnVFYXVOQzNHVEg4?= =?utf-8?B?TE5zSnFtUEgvYTdCOTNsRGxrYWlPWGsyQkJzM29tOTc1dWlnQzNQazNPNEZU?= =?utf-8?B?T2EvYm1rd2w1NkxTVFRhNkdvK1Y3V0ZlUHNsVWtQK3lUNitPV0kzR3FCeXRo?= =?utf-8?B?cU5lU0kzWHZISlpxOW44dHVVNWszaGQ1RDY3Uzd2OG8rUG1UQmZUMVg0SDJu?= =?utf-8?B?Ui9SekhSRThQTWRBSDRBMVluYWcwZVl4TkdoZTRNSkhpNk0wRm52cDM5VDA2?= =?utf-8?B?WGU5R0w4dnk2U3R5Q1dJZVRPd0ZUdENEWUpmSlhmamQwSzVscDhhOGV0Vkds?= =?utf-8?B?bXJrUFhJaGhkWUswRkc0RWN4bDlSSWFnMUtQVWgwOUdqNEkxRW1uYnRqNkE5?= =?utf-8?B?ci94RCsrOE9YOUVSN01CSlJscXM3WDJnSzlmNCt1T1pqTE8zRHN2eGROZU5T?= =?utf-8?B?SGh4Q09XVlFudW9EYy9VNzlwUURnUEZ4MDhKOXgwa3FsTFZDb0pXdVR3Z2tw?= =?utf-8?B?dUd4TTZTSEp3ZmZmM0JWczVaMnJQYWIxdTg4K2t3Ynl4S1NQcnUxeTJjdWQw?= =?utf-8?B?anJvdXJOdStCNkxMNkFkKzB2a0FFR3RMZXdsdmRYOHpRMXJDbEs0YzJCb3FB?= =?utf-8?B?Q3g5clA4WHM5UDlIVGVaQWNqMHpZSWNYMkYxRnVpTDFIR1I0NTIvZlNvRGVZ?= =?utf-8?B?eHhSc0RjRDRPOFdPQ01DKzN5MmZvU1pQWDh2N0tXVnRudkFuU1EvalhCT0tW?= =?utf-8?B?a0tzcFp4RkZtWVlOTXJZUzBzeWd1T1RIMjd4K3ZpUGdFMUFlMXRSb28yVGw0?= =?utf-8?B?MEFKSE9zSGVBVUptRHZmektwQmt5ZGp1TGpGek9xT2hOMzlwTU1SU3NZMkdy?= =?utf-8?B?YkwzTGJHSHdqaGVkYk5BMmZVaDZjcUpzaklsWUxyRDlyN2JYN05GOFI0TTB6?= =?utf-8?B?bDYxMGhpa2VRMkk5U0U4dHJYRCtGZUI4MEdENlUvZldhNzVsdz09?= X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-746f3.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 69e1460a-cdfc-42e3-3bff-08d9e0a2fb09 X-MS-Exchange-CrossTenant-AuthSource: MEYP282MB2942.AUSP282.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jan 2022 08:08:05.4239 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MEYP282MB2896 Archived-At: Subject: Re: [ippm] FW: New Version Notification for draft-li-ippm-stamp-on-lag-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 26 Jan 2022 08:08:16 -0000 ------=_001_NextPart675721106514_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gVGlhbnJhbiBhbmQgQWxsLA0KDQpUaGVzZSB0d28gZHJhZnRzIGFpbXMgdG8gYWRkcmVz cyB0aGUgc2FtZSBwcm9ibGVtLCB0byBtZWFzdXJlIHRoZSBwZXJmb3JtYW5jZSBvZiBlYWNoIG1l bWJlciBsaW5rIGluIGEgTEFHLiBTaW5jZSBkaWZmZXJlbnQgcGFja2V0IGZvcm1hdHMgYXJlIHVz ZWQgZm9yIFRXQU1QL09XQU1QIGFuZCBTVEFNUCwgd2Ugc3VibWl0dGVkIHR3byBkcmFmdHMgYWNj b3JkaW5nIHRvIHNvbWUgZXhwZXJ0cycgc3VnZ2VzdGlvbnMuDQpUaGUgbWV0aG9kcyBwcm9wb3Nl ZCBhcmUgdmVyeSB1c2VmdWwuIEluIGZhY3QsIENoaW5hIE1vYmlsZSBoYXMgYWxyZWFkeSBkZXBs b3llZCBtaWNybyBUV0FNUCBsaWdodCBpbiBvdXIgZmllbGQgbmV0d29yay4gVGhhbmtzIHRvIG91 ciB2ZW5kb3JzIHRvIGltcGxlbWVudCB0aGlzIGZlYXR1cmUgaW4gdGhlaXIgY29tbWVyY2lhbCBy ZWxlYXNlLiANCg0KDQoNCkJlc3QgUmVnYXJkcywNClpoZW5xaWFuZyBMaQ0KDQpsaV96aGVucWlh bmdAaG90bWFpbC5jb20NCiANCkZyb206IFRpYW5yYW4gWmhvdQ0KRGF0ZTogMjAyMi0wMS0yNSAx NDozMA0KVG86IElFVEYgSVBQTSBXRyAoaXBwbUBpZXRmLm9yZykNClN1YmplY3Q6IFtpcHBtXSBG VzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saS1pcHBtLXN0YW1wLW9uLWxh Zy0wMS50eHQNCkhpIFdHLA0KIA0KSW4gYWRkaXRpb24gdG8gTEFHIFBNIG9uIE9XQU1QL1RXQU1Q LCB0aGlzIGRyYWZ0IGV4dGVuZHMgU1RBTVAgZm9yIExBRyBQTS4NCkxvb2sgZm9yd2FyZCB0byB5 b3VyIHJldmlldyBhbmQgY29tbWVudHMuDQogDQpUaGFua3MsDQpUaWFucmFuDQogDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWls dG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjUs IDIwMjIgMjoyNyBQTQ0KVG86IEdyZWcgTWlyc2t5IDxncmVnaW1pcnNreUBnbWFpbC5jb20+OyBH dW8gSnVuIDxndW8uanVuMkB6dGUuY29tLmNuPjsgSnVuIEd1byA8Z3VvLmp1bjJAenRlLmNvbS5j bj47IFJha2VzaCBHYW5kaGkgPHJnYW5kaGlAY2lzY28uY29tPjsgVGlhbnJhbiBaaG91IDx6aG91 dGlhbnJhbkBodWF3ZWkuY29tPjsgWmhlbnFpYW5nIExpIDxsaV96aGVucWlhbmdAaG90bWFpbC5j b20+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpLWlwcG0t c3RhbXAtb24tbGFnLTAxLnR4dA0KIA0KIA0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWxp LWlwcG0tc3RhbXAtb24tbGFnLTAxLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IFRpYW5yYW4gWmhvdSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQogDQpO YW1lOiBkcmFmdC1saS1pcHBtLXN0YW1wLW9uLWxhZw0KUmV2aXNpb246IDAxDQpUaXRsZTogU2lt cGxlIFR3by1XYXkgQWN0aXZlIE1lYXN1cmVtZW50IFByb3RvY29sIEV4dGVuc2lvbnMgZm9yIFBl cmZvcm1hbmNlIE1lYXN1cmVtZW50IG9uIExBRw0KRG9jdW1lbnQgZGF0ZTogMjAyMi0wMS0yNA0K R3JvdXA6IEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6IDgNClVSTDogICAgICAgICAgICBo dHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LWxpLWlwcG0tc3RhbXAtb24tbGFn LTAxLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWxpLWlwcG0tc3RhbXAtb24tbGFnLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbGktaXBwbS1zdGFtcC1vbi1sYWcNCkRp ZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbGkt aXBwbS1zdGFtcC1vbi1sYWctMDENCiANCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBleHRl bmRzIFNpbXBsZSBUd28tV2F5IEFjdGl2ZSBNZWFzdXJlbWVudCBQcm90b2NvbA0KICAgKFNUQU1Q KSB0byBpbXBsZW1lbnQgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQgb24gZXZlcnkgbWVtYmVyIGxp bmsgb2YNCiAgIGEgTGluayBBZ2dyZWdhdGlvbiBHcm91cCAoTEFHKS4gIEtub3dpbmcgdGhlIG1l YXN1cmVkIG1ldHJpY3Mgb2YgZWFjaA0KICAgbWVtYmVyIGxpbmsgb2YgYSBMQUcgZW5hYmxlcyBv cGVyYXRvcnMgdG8gZW5mb3JjZSBhIHBlcmZvcm1hbmNlIGJhc2VkDQogICB0cmFmZmljIHN0ZWVy aW5nIHBvbGljeSBhY3Jvc3MgdGhlIG1lbWJlciBsaW5rcy4NCiANCiANCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICANCiANCiANClRoZSBJRVRGIFNlY3JldGFyaWF0DQogDQogDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KaXBwbSBtYWlsaW5nIGxpc3QN CmlwcG1AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBw bQ0K ------=_001_NextPart675721106514_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable body { line-height: 1.5; }blockquote { margin-top: 0px; margin-bottom:= 0px; margin-left: 0.5em; }body { font-size: 10.5pt; font-family: =E5=BE=AE= =E8=BD=AF=E9=9B=85=E9=BB=91; color: rgb(0, 0, 0); line-height: 1.5; }=0A=
        Hello Tianran and All,

        These two= drafts aims to address the same problem, to measure the performance of eac= h member link in a LAG. Since different packet formats are used for TWAMP/O= WAMP and STAMP, we submitted two drafts according to some experts' suggesti= ons.
        The methods proposed are very useful. In fact, China Mobile = has already deployed micro TWAMP light in our field network. Thanks to our = vendors to implement this feature in their commercial release. 
        = =0A=

        =0A=
        Best Regards,
        Zhenqiang Li

        li_zhenqiang@hotmail.com<= /div>
        =0A=
         
        Date: 2022-01-25 14:30
        Su= bject: [ippm] FW: New Version Notification for draft-li-ippm-stamp= -on-lag-01.txt
        Hi WG,
        =0A=
         
        =0A=
        In addition to LAG PM on OWAMP/TWAMP, this draft extends STAMP for LAG= PM.
        =0A=
        Look forward to your review and comments.
        =0A=
         
        =0A=
        Thanks,
        =0A=
        Tianran
        =0A=
         
        =0A=
        -----Original Message-----
        =0A=
        From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] =0A=
        Sent: Tuesday, January 25, 2022 2:27 PM
        =0A=
        To: Greg Mirsky <gregimirsky@gmail.com>; Guo Jun <guo.jun2@zt= e.com.cn>; Jun Guo <guo.jun2@zte.com.cn>; Rakesh Gandhi <rgandh= i@cisco.com>; Tianran Zhou <zhoutianran@huawei.com>; Zhenqiang Li = <li_zhenqiang@hotmail.com>
        =0A=
        Subject: New Version Notification for draft-li-ippm-stamp-on-lag-01.tx= t
        =0A=
         
        =0A=
         
        =0A=
        A new version of I-D, draft-li-ippm-stamp-on-lag-01.txt has been succe= ssfully submitted by Tianran Zhou and posted to the IETF repository.
        = =0A=
         
        =0A=
        Name: draft-li-ippm-stamp-on-lag
        =0A=
        Revision: 01
        =0A=
        Title: Simple Two-Way Active Measurement Protocol Extensions for Perf= ormance Measurement on LAG
        =0A=
        Document date: 2022-01-24
        =0A=
        Group: Individual Submission
        =0A=
        Pages: 8
        =0A=
        URL:           = https://www.ietf.org/archive/id/draft-li-ippm-stamp-on-lag-01.txt
        =0A=
        Status:         https://datatr= acker.ietf.org/doc/draft-li-ippm-stamp-on-lag/
        =0A=
        Htmlized:       https://datatracker.ietf= .org/doc/html/draft-li-ippm-stamp-on-lag
        =0A=
        Diff:           http= s://www.ietf.org/rfcdiff?url2=3Ddraft-li-ippm-stamp-on-lag-01
        =0A=
         
        =0A=
        Abstract:
        =0A=
           This document extends Simple Two-Way Active Measurement P= rotocol
        =0A=
           (STAMP) to implement performance measurement on every mem= ber link of
        =0A=
           a Link Aggregation Group (LAG).  Knowing the measure= d metrics of each
        =0A=
           member link of a LAG enables operators to enforce a perfo= rmance based
        =0A=
           traffic steering policy across the member links.
        =0A=
         
        =0A=
         
        =0A=
                   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;      
        =0A=
         
        =0A=
         
        =0A=
        The IETF Secretariat
        =0A=
         
        =0A=
         
        =0A=
        _______________________________________________
        =0A=
        ippm mailing list
        =0A=
        ippm@ietf.org
        =0A=
        https://www.ietf.org/mailman/listinfo/ippm
        =0A=
        =0A= = ------=_001_NextPart675721106514_=------ From nobody Wed Jan 26 01:20:53 2022 Return-Path: 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 0EE8C3A2CC5 for ; Wed, 26 Jan 2022 01:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ADoQmqaCXPX for ; Wed, 26 Jan 2022 01:20:46 -0800 (PST) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.227]) by ietfa.amsl.com (Postfix) with ESMTP id 8334B3A2CC9 for ; Wed, 26 Jan 2022 01:20:46 -0800 (PST) HMM_SOURCE_IP: 172.18.0.188:51478.1125904617 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-219.142.69.75 (unknown [172.18.0.188]) by chinatelecom.cn (HERMES) with SMTP id 0C9E82800EF; Wed, 26 Jan 2022 17:20:41 +0800 (CST) X-189-SAVE-TO-SEND: 66040164@chinatelecom.cn Received: from ([172.18.0.188]) by app0023 with ESMTP id 93ce7e12cc4a417db9364eeae5ee1d87 for ippm@ietf.org; Wed, 26 Jan 2022 17:20:43 CST X-Transaction-ID: 93ce7e12cc4a417db9364eeae5ee1d87 X-Real-From: wangaj3@chinatelecom.cn X-Receive-IP: 172.18.0.188 X-MEDUSA-Status: 0 Sender: wangaj3@chinatelecom.cn From: "Aijun Wang" To: "'Tianran Zhou'" , "'IETF IPPM WG'" References: <164300504281.12619.16642699818590435984@ietfa.amsl.com> In-Reply-To: Date: Wed, 26 Jan 2022 17:20:40 +0800 Message-ID: <015a01d81295$fdd37370$f97a5a50$@chinatelecom.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFSW9tjDYRgLyz9iGSKYYx+rezmPQGWFUuIrXPBCCA= Content-Language: zh-cn Archived-At: Subject: Re: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 26 Jan 2022 09:20:51 -0000 Hi, Tianran: Have a brief review of this draft. I think its aim is straightforward and will be useful to utilize the member link within the LAG. Some comments are below: 1) It seems there is no Sender/Reflector behavior description for the Mirco OWAMP session and the packet format? 2) For the newly defined Session-Sender Packet/Session-Reflector Packet, how to assure the backward compatibility? What I have seen is that you add two additional fields within the existing Packet? Best Regards Aijun Wang China Telecom -----Original Message----- From: ippm On Behalf Of Tianran Zhou Sent: Monday, January 24, 2022 2:23 PM To: IETF IPPM WG (ippm@ietf.org) Subject: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt Hi WG, We think this is an useful work on adapting OWAMP/TWAMP in LAG performance measurement. We updated this draft based on the comments from the meeting discussion and mailing list. Thanks for all the suggestions. More reviews and comments are welcome. Cheers, Tianran -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, January 24, 2022 2:17 PM To: Greg Mirsky ; Guo Jun ; Jun Guo ; Rakesh Gandhi ; Tianran Zhou ; Zhenqiang Li Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt A new version of I-D, draft-li-ippm-otwamp-on-lag-02.txt has been successfully submitted by Tianran Zhou and posted to the IETF repository. Name: draft-li-ippm-otwamp-on-lag Revision: 02 Title: One-way/Two-way Active Measurement Protocol Extensions for Performance Measurement on LAG Document date: 2022-01-24 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/archive/id/draft-li-ippm-otwamp-on-lag-02.txt Status: https://datatracker.ietf.org/doc/draft-li-ippm-otwamp-on-lag/ Htmlized: https://datatracker.ietf.org/doc/html/draft-li-ippm-otwamp-on-lag Diff: https://www.ietf.org/rfcdiff?url2=draft-li-ippm-otwamp-on-lag-02 Abstract: This document defines extensions to One-way Active Measurement Protocol (OWAMP), and Two-way Active Measurement Protocol (TWAMP) to implement performance measurement on every member link of a Link Aggregation Group (LAG). Knowing the measured metrics of each member link of a LAG enables operators to enforce the performance based traffic steering policy across the member links. The IETF Secretariat _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From nobody Wed Jan 26 01:23:20 2022 Return-Path: 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 681743A2CD4 for ; Wed, 26 Jan 2022 01:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDGfSYm15i26 for ; Wed, 26 Jan 2022 01:23:14 -0800 (PST) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.223]) by ietfa.amsl.com (Postfix) with ESMTP id CBA0C3A2CD0 for ; Wed, 26 Jan 2022 01:23:12 -0800 (PST) HMM_SOURCE_IP: 172.18.0.218:48780.2077374420 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-219.142.69.75 (unknown [172.18.0.218]) by chinatelecom.cn (HERMES) with SMTP id DEA172800B0; Wed, 26 Jan 2022 17:23:09 +0800 (CST) X-189-SAVE-TO-SEND: 66040164@chinatelecom.cn Received: from ([172.18.0.218]) by app0025 with ESMTP id d68a06c847324c8f9d6ce7fce036f67d for ippm@ietf.org; Wed, 26 Jan 2022 17:23:10 CST X-Transaction-ID: d68a06c847324c8f9d6ce7fce036f67d X-Real-From: wangaj3@chinatelecom.cn X-Receive-IP: 172.18.0.218 X-MEDUSA-Status: 0 Sender: wangaj3@chinatelecom.cn From: "Aijun Wang" To: "'Tianran Zhou'" , "'IETF IPPM WG'" References: <164309204653.26831.5703411217906566536@ietfa.amsl.com> <49bb582d835b4b938cda7e0ad680083c@huawei.com> In-Reply-To: <49bb582d835b4b938cda7e0ad680083c@huawei.com> Date: Wed, 26 Jan 2022 17:23:01 +0800 Message-ID: <015b01d81296$558ae530$00a0af90$@chinatelecom.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQF4l4T/+sYi2cZoNPZShVQ5bBaGDwH1Yo92rSRSHXA= Content-Language: zh-cn Archived-At: Subject: Re: [ippm] FW: New Version Notification for draft-li-ippm-stamp-on-lag-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 26 Jan 2022 09:23:18 -0000 Hi, Tianran: I think this draft is more clear than the OWAMP/TWAMP related draft. They can be discussed and forwarded together later. Best Regards Aijun Wang China Telecom -----Original Message----- From: ippm On Behalf Of Tianran Zhou Sent: Tuesday, January 25, 2022 2:31 PM To: IETF IPPM WG (ippm@ietf.org) Subject: [ippm] FW: New Version Notification for draft-li-ippm-stamp-on-lag-01.txt Hi WG, In addition to LAG PM on OWAMP/TWAMP, this draft extends STAMP for LAG PM. Look forward to your review and comments. Thanks, Tianran -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Tuesday, January 25, 2022 2:27 PM To: Greg Mirsky ; Guo Jun ; Jun Guo ; Rakesh Gandhi ; Tianran Zhou ; Zhenqiang Li Subject: New Version Notification for draft-li-ippm-stamp-on-lag-01.txt A new version of I-D, draft-li-ippm-stamp-on-lag-01.txt has been successfully submitted by Tianran Zhou and posted to the IETF repository. Name: draft-li-ippm-stamp-on-lag Revision: 01 Title: Simple Two-Way Active Measurement Protocol Extensions for Performance Measurement on LAG Document date: 2022-01-24 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/archive/id/draft-li-ippm-stamp-on-lag-01.txt Status: https://datatracker.ietf.org/doc/draft-li-ippm-stamp-on-lag/ Htmlized: https://datatracker.ietf.org/doc/html/draft-li-ippm-stamp-on-lag Diff: https://www.ietf.org/rfcdiff?url2=draft-li-ippm-stamp-on-lag-01 Abstract: This document extends Simple Two-Way Active Measurement Protocol (STAMP) to implement performance measurement on every member link of a Link Aggregation Group (LAG). Knowing the measured metrics of each member link of a LAG enables operators to enforce a performance based traffic steering policy across the member links. The IETF Secretariat _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From nobody Wed Jan 26 02:03:33 2022 Return-Path: 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 8D8643A2E48 for ; Wed, 26 Jan 2022 02:03:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8me3qT6dxic for ; Wed, 26 Jan 2022 02:03:26 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 979753A2E49 for ; Wed, 26 Jan 2022 02:03:26 -0800 (PST) Received: from fraeml715-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JkK2g37Vbz680ZP for ; Wed, 26 Jan 2022 17:59:55 +0800 (CST) Received: from kwepeml500002.china.huawei.com (7.221.188.128) by fraeml715-chm.china.huawei.com (10.206.15.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Wed, 26 Jan 2022 11:03:23 +0100 Received: from kwepeml500004.china.huawei.com (7.221.188.141) by kwepeml500002.china.huawei.com (7.221.188.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Wed, 26 Jan 2022 18:03:21 +0800 Received: from kwepeml500004.china.huawei.com ([7.221.188.141]) by kwepeml500004.china.huawei.com ([7.221.188.141]) with mapi id 15.01.2308.021; Wed, 26 Jan 2022 18:03:21 +0800 From: Tianran Zhou To: "wangaj3@chinatelecom.cn" , 'IETF IPPM WG' Thread-Topic: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt Thread-Index: AQHYEOoOM8BWGUje9EistfVjjUvI2qxxspuggALRbQCAAI1nUA== Date: Wed, 26 Jan 2022 10:03:21 +0000 Message-ID: <70c388c86215411796ef55d48711b216@huawei.com> References: <164300504281.12619.16642699818590435984@ietfa.amsl.com> <015a01d81295$fdd37370$f97a5a50$@chinatelecom.cn> In-Reply-To: <015a01d81295$fdd37370$f97a5a50$@chinatelecom.cn> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.112.40.195] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 26 Jan 2022 10:03:32 -0000 Hi Anjun, Thanks very much for your interest and comments. Both are good questions. Please see in line. Cheers, Tianran -----Original Message----- From: wangaj3@chinatelecom.cn [mailto:wangaj3@chinatelecom.cn]=20 Sent: Wednesday, January 26, 2022 5:21 PM To: Tianran Zhou ; 'IETF IPPM WG' Subject: RE: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-o= n-lag-02.txt Hi, Tianran: Have a brief review of this draft. I think its aim is straightforward and w= ill be useful to utilize the member link within the LAG. Some comments are below: 1) It seems there is no Sender/Reflector behavior description for the Mirco= OWAMP session and the packet format?=20 ZTR> OWAMP is simple and there is no reflector. The sender cannot get the a= ck from the receiver. So we are not going to extend the OWAMP test packet. The behavior is described in section 3.2: " The micro OWAMP Sender MUST send the micro OWAMP-Test packets over the me= mber link with which the session is associated. When receives a Test packet= , the micro OWAMP receiver MUST use the member link from which the Test pac= ket is received to correlate the micro OWAMP session. If there is no such a= session, the Test packet MUST be discarded. "=20 2) For the newly defined Session-Sender Packet/Session-Reflector Packet, ho= w to assure the backward compatibility? What I have seen is that you add tw= o additional fields within the existing Packet?=20 ZTR> I am not aware of the compatibility problem. If a node supports micro = session, it can understand the new packet extension. If a node does not sup= port micro session, it just ignores the new fields. Because the new fields = is in the reserved zone. Moreover, the validation mechanism can figure out if the reflector can supp= ort the micro session.=20 Best Regards Aijun Wang China Telecom -----Original Message----- From: ippm On Behalf Of Tianran Zhou Sent: Monday, January 24, 2022 2:23 PM To: IETF IPPM WG (ippm@ietf.org) Subject: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-la= g-02.txt Hi WG, We think this is an useful work on adapting OWAMP/TWAMP in LAG performance = measurement. We updated this draft based on the comments from the meeting discussion and= mailing list. Thanks for all the suggestions. More reviews and comments are welcome. Cheers, Tianran -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, January 24, 2022 2:17 PM To: Greg Mirsky ; Guo Jun ; Jun= Guo ; Rakesh Gandhi ; Tianran Zhou= ; Zhenqiang Li Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt A new version of I-D, draft-li-ippm-otwamp-on-lag-02.txt has been successfully submitted by Tianran Zhou and posted to the IETF repo= sitory. Name: draft-li-ippm-otwamp-on-lag Revision: 02 Title: One-way/Two-way Active Measurement Protocol Extensions for Performance Measurement on LAG Document date: 2022-01-24 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/archive/id/draft-li-ippm-otwamp-on-lag-02.txt Status: https://datatracker.ietf.org/doc/draft-li-ippm-otwamp-on-lag/ Htmlized: https://datatracker.ietf.org/doc/html/draft-li-ippm-otwamp-on-lag Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-li-ippm-otwamp-on-lag-02 Abstract: This document defines extensions to One-way Active Measurement Protocol (OWAMP), and Two-way Active Measurement Protocol (TWAMP) to implement performance measurement on every member link of a Link Aggregation Group (LAG). Knowing the measured metrics of each member link of a LAG enables operators to enforce the performance based traffic steering policy across the member links. The IETF Secretariat _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From nobody Wed Jan 26 02:17:14 2022 Return-Path: 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 314C33A109C for ; Wed, 26 Jan 2022 02:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=accedian.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ud2p7dBsSU3 for ; Wed, 26 Jan 2022 02:17:07 -0800 (PST) Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 937A83A2EBE for ; Wed, 26 Jan 2022 02:17:07 -0800 (PST) Received: by mail-yb1-xb2f.google.com with SMTP id k31so68318540ybj.4 for ; Wed, 26 Jan 2022 02:17:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=accedian.com; s=corp1; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B/lV/IQMzH+IH8NjMyAsk/kXcb8XcenlUNTd2cvD5yk=; b=QxKPTf8hI4qz1utPuLmo8fT+PDsZZI7Ywk/eZZDu2eb5+127jcTADrLZK6KTBReuL/ BqD0TOUocdgHQ5Xfa0mYlerqwI3Rw/uhe5Jii8MziU8dzDWewpW34yYO9YEJyZAzwr7c A1/jl8+JXWIBg5EfGeBcAyzUHAXBBrTkQuCs5V9QLwuBSoapi+fA4FJLxrJJDK+6B21o BE+ShB1Xyw25ghIgbfS6lH79kujy8FQZfZ711aJXvvGpchZcJiroXOVcKC8Wfnf5oVEU BJfTlUTFUo/2BOz88AlFrC+2lNyF+8qsPM/47vPazEm3bysdyE7HYCBU4OQL4DVGN9Nf OiJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=B/lV/IQMzH+IH8NjMyAsk/kXcb8XcenlUNTd2cvD5yk=; b=tqRxOaZwi6kD8ceuD9Q3imx79DJIClG7Fjh27peiHwO+B7Sx+cmrtqe2gu7iKAiVxZ ES7k62YNe21xbGJOtwTbC50LXw86L5UvAWGhj5ir8ntQaHgPJQbl7D8LXGaPZumusy19 0v4TXW5s65sonvefw9W8vxGSlByKs7Bcin5yNbtKDprC0PL/KIknAB9jlAUnRHivpcOD 0BJnJCx1O5aYl3FO/x/ZFEFppCJaQ70MRpRrGVJFWGDXik1pqGdwlVE067bIKiR58jkU OdYe46Ek2tOaxO8GkmxK93sBil7r2AbL8j0DRXSuCkEcGcwwF0nFCOpGEWB5Zh94D/0p 0wQQ== X-Gm-Message-State: AOAM531fr/zvg6mov0rfDAhhHWjTrOTqpy5e2rGp8Fjij04m4lyca/c1 OGIhBBUEMfpIz9ekN0aPJFn7bhcuc560EYqlTRHSgHXhFnLekhsD3dy3kTAtFwAZb5P2ilDV/Jh XNV7BnmnBZQ== X-Google-Smtp-Source: ABdhPJyut5Do5nddSR/YwboDm/E7kW8sEKHT+LuYlWc3BOJzgXegFn1APDvLOoqLlp5R3eiDCpHpe4MMHR3/+NNTUGg= X-Received: by 2002:a25:ba01:: with SMTP id t1mr35501300ybg.474.1643192225520; Wed, 26 Jan 2022 02:17:05 -0800 (PST) MIME-Version: 1.0 References: <164300504281.12619.16642699818590435984@ietfa.amsl.com> <015a01d81295$fdd37370$f97a5a50$@chinatelecom.cn> <70c388c86215411796ef55d48711b216@huawei.com> In-Reply-To: <70c388c86215411796ef55d48711b216@huawei.com> From: Henrik Nydell Date: Wed, 26 Jan 2022 11:16:50 +0100 Message-ID: To: Tianran Zhou Cc: "wangaj3@chinatelecom.cn" , IETF IPPM WG Content-Type: multipart/alternative; boundary="000000000000e673cd05d67980ad" Archived-At: Subject: Re: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 26 Jan 2022 10:17:13 -0000 --000000000000e673cd05d67980ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I had a brief review but failed to find details on how the TWAMP sessions would be "guaranteed" to travel on a certain LAG segment. As far as I know the LAG implementation may be different between vendors and as such I know of no "one method fits all" to actually accomplish the measurement. So this draft does not actually provide any solution to the problem of being able to measure LAG segments separately and deterministically. On Wed, Jan 26, 2022 at 11:03 AM Tianran Zhou wrote: > Hi Anjun, > > Thanks very much for your interest and comments. > Both are good questions. > Please see in line. > > Cheers, > Tianran > > -----Original Message----- > From: wangaj3@chinatelecom.cn [mailto:wangaj3@chinatelecom.cn] > Sent: Wednesday, January 26, 2022 5:21 PM > To: Tianran Zhou ; 'IETF IPPM WG' > Subject: RE: [ippm] FW: New Version Notification for > draft-li-ippm-otwamp-on-lag-02.txt > > Hi, Tianran: > > Have a brief review of this draft. I think its aim is straightforward and > will be useful to utilize the member link within the LAG. > Some comments are below: > 1) It seems there is no Sender/Reflector behavior description for the > Mirco OWAMP session and the packet format? > > > ZTR> OWAMP is simple and there is no reflector. The sender cannot get the > ack from the receiver. So we are not going to extend the OWAMP test packe= t. > The behavior is described in section 3.2: > " The micro OWAMP Sender MUST send the micro OWAMP-Test packets over the > member link with which the session is associated. When receives a Test > packet, the micro OWAMP receiver MUST use the member link from which the > Test packet is received to correlate the micro OWAMP session. If there is > no such a session, the Test packet MUST be discarded. " > > 2) For the newly defined Session-Sender Packet/Session-Reflector Packet, > how to assure the backward compatibility? What I have seen is that you ad= d > two additional fields within the existing Packet? > > ZTR> I am not aware of the compatibility problem. If a node supports micr= o > session, it can understand the new packet extension. If a node does not > support micro session, it just ignores the new fields. Because the new > fields is in the reserved zone. > Moreover, the validation mechanism can figure out if the reflector can > support the micro session. > > Best Regards > > Aijun Wang > China Telecom > > -----Original Message----- > From: ippm On Behalf Of Tianran Zhou > Sent: Monday, January 24, 2022 2:23 PM > To: IETF IPPM WG (ippm@ietf.org) > Subject: [ippm] FW: New Version Notification for > draft-li-ippm-otwamp-on-lag-02.txt > > Hi WG, > > We think this is an useful work on adapting OWAMP/TWAMP in LAG performanc= e > measurement. > We updated this draft based on the comments from the meeting discussion > and mailing list. > Thanks for all the suggestions. > More reviews and comments are welcome. > > Cheers, > Tianran > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, January 24, 2022 2:17 PM > To: Greg Mirsky ; Guo Jun ; > Jun Guo ; Rakesh Gandhi ; Tianran > Zhou ; Zhenqiang Li > Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt > > > A new version of I-D, draft-li-ippm-otwamp-on-lag-02.txt > has been successfully submitted by Tianran Zhou and posted to the IETF > repository. > > Name: draft-li-ippm-otwamp-on-lag > Revision: 02 > Title: One-way/Two-way Active Measurement Protocol Extensions fo= r > Performance Measurement on LAG > Document date: 2022-01-24 > Group: Individual Submission > Pages: 13 > URL: > https://www.ietf.org/archive/id/draft-li-ippm-otwamp-on-lag-02.txt > Status: > https://datatracker.ietf.org/doc/draft-li-ippm-otwamp-on-lag/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-li-ippm-otwamp-on-lag > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-li-ippm-otwamp-on-lag-02 > > Abstract: > This document defines extensions to One-way Active Measurement > Protocol (OWAMP), and Two-way Active Measurement Protocol (TWAMP) to > implement performance measurement on every member link of a Link > Aggregation Group (LAG). Knowing the measured metrics of each member > link of a LAG enables operators to enforce the performance based > traffic steering policy across the member links. > > > > > > The IETF Secretariat > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --=20 *Henrik Nydell* *Sr Product Manager* 1.866.685.8181 hnydell@accedian.com *accedian.com * --=20 Avis de confidentialit=C3=A9 Les informations contenues dans le pr=C3=A9sent=20 message et dans toute pi=C3=A8ce qui=20 lui est jointe sont confidentielles et=20 peuvent =C3=AAtre prot=C3=A9g=C3=A9es par le=20 secret professionnel. Ces informations sont=20 =C3=A0 l=E2=80=99usage exclusif de son ou de ses destinataires. Si vous recevez ce=20 message par erreur, veuillez=20 s=E2=80=99il vous plait communiquer imm=C3=A9diatement=20 avec l=E2=80=99exp=C3=A9diteur et en=20 d=C3=A9truire tout exemplaire. De plus, il vous est=20 strictement interdit de=20 le divulguer, de le distribuer ou de le reproduire=20 sans l=E2=80=99autorisation=20 de l=E2=80=99exp=C3=A9diteur. Merci. Confidentiality notice This e-mail message and any attachment hereto contain confidential=20 information=20 which may be privileged and which is intended for the=20 exclusive use of its=20 addressee(s). If you receive this message in error, please inform sender=20 immediately and destroy any copy thereof.=20 Furthermore, any disclosure,=20 distribution or copying of this message=20 and/or any attachment hereto=20 without the consent of the sender is=20 strictly prohibited. Thank you. --000000000000e673cd05d67980ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
        I h= ad a brief review but failed to find details on how the TWAMP sessions woul= d be "guaranteed" to travel on a certain LAG segment. As far as I= know the LAG implementation may be different between vendors and as such I= know of no "one method fits all" to actually accomplish the meas= urement.

        So this draft do= es not actually provide any solution to the problem of being able to measur= e LAG segments separately and deterministically.

        On Wed, Jan 26, 2022= at 11:03 AM Tianran Zhou <zhoutianran=3D40huawei.com@dmarc.ietf.org> wrote:
        Hi Anjun,

        Thanks very much for your interest and comments.
        Both are good questions.
        Please see in line.

        Cheers,
        Tianran

        -----Original Message-----
        From: wangaj3@= chinatelecom.cn [mailto:wangaj3@chinatelecom.cn]
        Sent: Wednesday, January 26, 2022 5:21 PM
        To: Tianran Zhou <zhoutianran@huawei.com>; 'IETF IPPM WG' <ippm@ietf.org>
        Subject: RE: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-o= n-lag-02.txt

        Hi, Tianran:

        Have a brief review of this draft. I think its aim is straightforward and w= ill be useful to utilize the member link within the LAG.
        Some comments are below:
        1) It seems there is no Sender/Reflector behavior description for the Mirco= OWAMP session and the packet format?


        ZTR> OWAMP is simple and there is no reflector. The sender cannot get th= e ack from the receiver. So we are not going to extend the OWAMP test packe= t.
        The behavior is described in section 3.2:
        " The micro OWAMP Sender MUST send the micro OWAMP-Test packets over t= he member link with which the session is associated. When receives a Test p= acket, the micro OWAMP receiver MUST use the member link from which the Tes= t packet is received to correlate the micro OWAMP session. If there is no s= uch a session, the Test packet MUST be discarded. "

        2) For the newly defined Session-Sender Packet/Session-Reflector Packet, ho= w to assure the backward compatibility? What I have seen is that you add tw= o additional fields within the existing Packet?

        ZTR> I am not aware of the compatibility problem. If a node supports mic= ro session, it can understand the new packet extension. If a node does not = support micro session, it just ignores the new fields. Because the new fiel= ds is in the reserved zone.
        Moreover, the validation mechanism can figure out if the reflector can supp= ort the micro session.

        Best Regards

        Aijun Wang
        China Telecom

        -----Original Message-----
        From: ippm <i= ppm-bounces@ietf.org> On Behalf Of Tianran Zhou
        Sent: Monday, January 24, 2022 2:23 PM
        To: IETF IPPM WG (ippm@i= etf.org) <ippm@ie= tf.org>
        Subject: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-la= g-02.txt

        Hi WG,

        We think this is an useful work on adapting OWAMP/TWAMP in LAG performance = measurement.
        We updated this draft based on the comments from the meeting discussion and= mailing list.
        Thanks for all the suggestions.
        More reviews and comments are welcome.

        Cheers,
        Tianran

        -----Original Message-----
        From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
        Sent: Monday, January 24, 2022 2:17 PM
        To: Greg Mirsky <gregimirsky@gmail.com>; Guo Jun <guo.jun2@zte.com.cn>; Jun Guo <guo.jun2@zte.com.cn= >; Rakesh Gandhi <rgandhi@cisco.com>; Tianran Zhou <zhoutianran@huawei.com>; Zhenqiang = Li <li_zhe= nqiang@hotmail.com>
        Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

        A new version of I-D, draft-li-ippm-otwamp-on-lag-02.txt
        has been successfully submitted by Tianran Zhou and posted to the IETF repo= sitory.

        Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-li-ippm-otwamp-on-lag Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
        Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 One-way/Two-way Active Measurement= Protocol Extensions for
        Performance Measurement on LAG
        Document date:=C2=A0 2022-01-24
        Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
        Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 13
        URL:
        https://www.ietf.org/archive/id/dr= aft-li-ippm-otwamp-on-lag-02.txt
        Status:
        https://datatracker.ietf.org/doc/draft-= li-ippm-otwamp-on-lag/
        Htmlized:
        https://datatracker.ietf.org/doc/ht= ml/draft-li-ippm-otwamp-on-lag
        Diff:
        https://www.ietf.org/rfcdiff?url2= =3Ddraft-li-ippm-otwamp-on-lag-02

        Abstract:
        =C2=A0 =C2=A0This document defines extensions to One-way Active Measurement=
        =C2=A0 =C2=A0Protocol (OWAMP), and Two-way Active Measurement Protocol (TWA= MP) to
        =C2=A0 =C2=A0implement performance measurement on every member link of a Li= nk
        =C2=A0 =C2=A0Aggregation Group (LAG).=C2=A0 Knowing the measured metrics of= each member
        =C2=A0 =C2=A0link of a LAG enables operators to enforce the performance bas= ed
        =C2=A0 =C2=A0traffic steering policy across the member links.





        The IETF Secretariat


        _______________________________________________
        ippm mailing list
        ippm@ietf.org
        https://www.ietf.org/mailman/listinfo/ippm

        _______________________________________________
        ippm mailing list
        ippm@ietf.org
        https://www.ietf.org/mailman/listinfo/ippm


        --

        Henrik Nydell
        Sr Product Manager
        1.866.685.8181
        hnydell@accedian.= com
        3D""
        =3D""=C2=A03D""=C2=A03D""
        3D""
        accedian.com=

        Avis de confidentialit=C3=A9

        Les informations contenues dans le pr=C3=A9sent message et dans toute pi=C3=A8= ce qui=20 lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9e= s par le=20 secret professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif= de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez=20 s=E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp= =C3=A9diteur et en=20 d=C3=A9truire tout exemplaire. De plus, il vous est strictement interdit de= =20 le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisat= ion=20 de l=E2=80=99exp=C3=A9diteur. Merci.

        Confidentiality notice

        This e-mail message and any attachment hereto contain confidential=20 information which may be privileged and which is intended for the=20 exclusive use of its addressee(s). If you receive this message in error, please inform sender immediately and destroy any copy thereof.=20 Furthermore, any disclosure, distribution or copying of this message=20 and/or any attachment hereto without the consent of the sender is=20 strictly prohibited. Thank you.

        --000000000000e673cd05d67980ad-- From nobody Wed Jan 26 10:04:06 2022 Return-Path: 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 D706B3A19FE; Wed, 26 Jan 2022 10:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jRwxQnF6kqh; Wed, 26 Jan 2022 10:04:00 -0800 (PST) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DE453A1A00; Wed, 26 Jan 2022 10:04:00 -0800 (PST) Received: by mail-ej1-x62f.google.com with SMTP id me13so186562ejb.12; Wed, 26 Jan 2022 10:04:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=fzCHx2opb2O6HC+d2Qc2c4sHALG+w31icBr4VBTMpSI=; b=pT5jVLqJW99GcMNYOMgRx5FeS1HRCNQPqzGoyg+sQ987igGrACZjJv5MgREJUKISR2 2casCpzjeaiCh6vkLXAF/Zcbb/4ZssrT+Z1jjt7qJjjjf1X3++AHx1SL4MI/QfMUwK9T KKiS7CW26gS9CJC+v6hZTofg8RVed8Xs7u3I85zZyh9LcrWIKcpxEXG21Hroz6ClsmmG OppS1M3md8HbDgCA/cQGSdDG+A03TwrlchI/RiheDQ8p47hHTLc6sYy4m0UahIEgdLRU An6UULu+JmmsvT+gRjPNkvl8B4T8cag/7iRRQE3xIbr9E6Z6ZydI49qNy7VBGzT0iOn5 Jnsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=fzCHx2opb2O6HC+d2Qc2c4sHALG+w31icBr4VBTMpSI=; b=yPKCa8BeyZJq98F5cRXaKTBmS9V23JjUU4hvGulvmj2Wnpj9KMlMTyvotdWBfmYENA xiIbGjttOCeRrJ7bb8x6nxHexLSoOurv70qGB5Rrx6pKiOF17SeZ3LdNfdZSLWogWBsL swXc5X7OIyWn7SXVL6AZ6ZgkHKs6iv7KvJ10BYOtUfIGPghqLiRDPrl6AYgNs3VJNhvX J4CO5jVY9d2UtkggVYa7V/ZDadVw4NdqabKdjHMYI+Q+2p+0WDeL5uEvNQMKVwSO/iXc tVWXEM3Y27njE6bcjU/SAH/PMMfu1eIbr9CRFcaTN22lY7Wo2tstDx4Ji00gFdSKnYrj yRYw== X-Gm-Message-State: AOAM532GNdxQPoFbMWkDId0pUreJ2FOnN1ZGodYaaw4wM8QBpTIH+CEa zXDrVZT0LySQOBjMDXr4g+X0Xl1EvcZ5dTJDXF/T4hD7lb4= X-Google-Smtp-Source: ABdhPJx2AQ9S2KWDPhlvzNgswlhFEoCcGlCKwtQf5SpOMq7j1XSDcywXMnbreSu8FTgSDS4yiTGMab7WGemrmHO680s= X-Received: by 2002:a17:907:2cc7:: with SMTP id hg7mr21278450ejc.235.1643220235632; Wed, 26 Jan 2022 10:03:55 -0800 (PST) MIME-Version: 1.0 References: <164321971010.17176.2067294042064480102@ietfa.amsl.com> In-Reply-To: <164321971010.17176.2067294042064480102@ietfa.amsl.com> From: Greg Mirsky Date: Wed, 26 Jan 2022 10:03:44 -0800 Message-ID: To: IETF IPPM WG , IPPM Chairs Content-Type: multipart/alternative; boundary="0000000000006ec48905d68006b8" Archived-At: Subject: [ippm] Fwd: New Version Notification for draft-mirsky-ippm-hybrid-two-step-12.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 26 Jan 2022 18:04:05 -0000 --0000000000006ec48905d68006b8 Content-Type: text/plain; charset="UTF-8" Dear All, this is version includes a minor non-technical update. The draft has been stable and the authors believe that it is ready for the WG AP. The Hybrid Two-Step method of collecting and transporting telemetry information can be used as in-band or out-of-band information bus by on-path telemetry protocol. For example, the Hybrid Two-step can be used as the optional IOAM Trace Option complementing the Direct Export Trace Option. We always welcome your comments, questions, and suggestions. Greatly appreciate the consideration of adopting the draft by the IPPM WG. Regards, Greg ---------- Forwarded message --------- From: Date: Wed, Jan 26, 2022 at 9:55 AM Subject: New Version Notification for draft-mirsky-ippm-hybrid-two-step-12.txt To: Greg Mirsky , Guo Zhui , Haoyu Song , Wang Lingqiang A new version of I-D, draft-mirsky-ippm-hybrid-two-step-12.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-mirsky-ippm-hybrid-two-step Revision: 12 Title: Hybrid Two-Step Performance Measurement Method Document date: 2022-01-26 Group: Individual Submission Pages: 19 URL: https://www.ietf.org/archive/id/draft-mirsky-ippm-hybrid-two-step-12.txt Status: https://datatracker.ietf.org/doc/draft-mirsky-ippm-hybrid-two-step/ Html: https://www.ietf.org/archive/id/draft-mirsky-ippm-hybrid-two-step-12.html Htmlized: https://datatracker.ietf.org/doc/html/draft-mirsky-ippm-hybrid-two-step Diff: https://www.ietf.org/rfcdiff?url2=draft-mirsky-ippm-hybrid-two-step-12 Abstract: Development of, and advancements in, automation of network operations brought new requirements for measurement methodology. Among them is the ability to collect instant network state as the packet being processed by the networking elements along its path through the domain. This document introduces a new hybrid measurement method, referred to as hybrid two-step, as it separates the act of measuring and/or calculating the performance metric from the act of collecting and transporting network state. The IETF Secretariat --0000000000006ec48905d68006b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
        Dear All,
        this is version includes a = minor non-technical update. The draft has been stable and the authors belie= ve that it is ready for the WG AP. The Hybrid Two-Step method of collecting= and transporting telemetry information can be used as in-band or out-of-ba= nd information bus by on-path telemetry protocol. For example, the Hybrid T= wo-step can be used as the optional IOAM Trace Option complementing the Dir= ect Export Trace Option.=C2=A0

        We always welcome y= our comments, questions, and suggestions. Greatly appreciate the considerat= ion of adopting the draft by the IPPM WG.

        Regards,=
        Greg

        ---------- Forwarded message ---------
        From: <internet-drafts@ietf.o= rg>
        Date: Wed, Jan 26, 2022 at 9:55 AM
        Subject: New Ver= sion Notification for draft-mirsky-ippm-hybrid-two-step-12.txt
        To: Greg = Mirsky <gregimirsky@gmail.com>, Guo Zhui <guo.zhui@zte.co= m.cn>, Haoyu Song <hsong@f= uturewei.com>, Wang Lingqiang <wang.lingqiang@zte.com.cn>



        A new version of I-D, draft-mirsky-ippm-hybrid-two-step-12.txt
        has been successfully submitted by Greg Mirsky and posted to the
        IETF repository.

        Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mirsky-ippm-hybrid-two-= step
        Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A012
        Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hybrid Two-Step Performance Measur= ement Method
        Document date:=C2=A0 2022-01-26
        Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
        Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 19
        URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/archive/id/draft-mirsky-ippm-hybrid-= two-step-12.txt
        Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-mirsky-ippm-hybrid-two-step/=
        Html:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/archive/id/draft-mirsky-ippm-hybrid= -two-step-12.html
        Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-mirsky-ippm-hybrid-two-s= tep
        Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-mirsky-ippm-hyb= rid-two-step-12

        Abstract:
        =C2=A0 =C2=A0Development of, and advancements in, automation of network ope= rations
        =C2=A0 =C2=A0brought new requirements for measurement methodology.=C2=A0 Am= ong them is
        =C2=A0 =C2=A0the ability to collect instant network state as the packet bei= ng
        =C2=A0 =C2=A0processed by the networking elements along its path through th= e
        =C2=A0 =C2=A0domain.=C2=A0 This document introduces a new hybrid measuremen= t method,
        =C2=A0 =C2=A0referred to as hybrid two-step, as it separates the act of mea= suring
        =C2=A0 =C2=A0and/or calculating the performance metric from the act of coll= ecting
        =C2=A0 =C2=A0and transporting network state.




        The IETF Secretariat


        --0000000000006ec48905d68006b8-- From nobody Wed Jan 26 15:01:50 2022 Return-Path: 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 73F513A2650; Wed, 26 Jan 2022 15:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1swDdEhT6WHT; Wed, 26 Jan 2022 15:01:34 -0800 (PST) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06CD93A2652; Wed, 26 Jan 2022 15:01:33 -0800 (PST) Received: by mail-ej1-x636.google.com with SMTP id me13so1668898ejb.12; Wed, 26 Jan 2022 15:01:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pj3dNI1qMy2keLgxu00MDWPnSRn2sjJniUSCLUA2ito=; b=L/zWoHB/WhSSOhBdiEIq5lCljoCr2mgVYtUT/Y8HPGST9/y8epNCszfgFgqsrjJHpE 1j7XWLWkkATAg9KIszzzZKLMT/WFTCkhO6pcnJXQYja//bI7Mn0iE2ZuNP/IJhMzrwGx H5gVsc9i3dOxvQxVlHy3K4Qp5zE4ZuXyBphaZisF6BlNuMASNAVWqOSxMWPtlpunc0JI cZCw05/i99uXW9N6WNxZGZ+6VhJiD8tCvMJ6lmcgPXqu4SuQ5m4PcJPMbmQNzFE2RQCz w1vUpdyIIkG3k6azVSBISj8/FrVyuo60yR/DBWPV/2jHQEjRjJiJp2ze/xXZ6LUstKAZ Y7yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pj3dNI1qMy2keLgxu00MDWPnSRn2sjJniUSCLUA2ito=; b=FKPl0h9CkSKUCp8CEq6eFOBdg16olT+F2pxB95fMOd1AUmac4N8B+fc7/z/Ld3xmx6 T1za7HBc/xUD9r8uWYraEIesL0Cw1VM7OvcrPsIS2dHI9/z4Yrs9mQ77aov16QTUY5NF ooqHYibplVBTSMbrqN2rLVLaRaw23ueN6TQW7yldDiU9ANMVoL/vJvtN+PoN1iUub/AP vJ4laaevK8hJzFOC9FFowmSvEgoxEJ2Bb0k4n9RiGbmxjGBuLbKcYp+MQG4CPgG9edtS fMz0GvkKJFKzaIeZVJElGHyUbg02+/p8nO8qtHtj7XRGipVQ8zAErnYT2bKn/J46QEKZ 5gGQ== X-Gm-Message-State: AOAM533qxOBAG8Pf3U8KzeVkHnWCHJgjFdrMFWwGmPgZbSwgiJ2OBjIf mQyapc3rPz/dW+VlWM3xeo7onbSBYTDy9DFj/1px6ZdVR9M= X-Google-Smtp-Source: ABdhPJxFeylXyTRO1ckOwpLAov+gr+NkJoW17qp8CP1jZnDDXdnb9ph9vla0MZtLr1rtyUk6NRGMPY5mojAAAXhDSJk= X-Received: by 2002:a17:907:1614:: with SMTP id hb20mr725670ejc.255.1643238091099; Wed, 26 Jan 2022 15:01:31 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Wed, 26 Jan 2022 15:01:19 -0800 Message-ID: To: Haoyu Song Cc: "spring@ietf.org" , IETF IPPM WG Content-Type: multipart/alternative; boundary="000000000000b3b81505d6842e52" Archived-At: Subject: Re: [ippm] [spring] Active OAM in SRv6 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 26 Jan 2022 23:01:39 -0000 --000000000000b3b81505d6842e52 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Haoyu, thank you for bringing the topic of Active OAM to the discussion. As the concept of Active IOAM is introduced in the IPPM WG draft it seems to me like adding the IPPM WG community to the discussion is the right thing to do. Please find my notes in-lined below under the GIM>> tag. Regards, Greg On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song wrote= : > Hi SPRING WG, > > > > Real time monitor on every node and every link on a network is necessary > to detect gray failures, which are the key culprit for poor QoS but hard > to catch. SR provides an ideal mechanism, when working with some efficien= t > planning algorithm, to achieve that with low cost. Our proposal SRv6 > In-situ Active Measurement (SIAM) suggests a simple active measurement > approach which can support different > GIM>> I wonder what gaps you find in the existing active measurement protocols, e.g., STAMP and RFC 6734 (would be more convenient to use an acronym). It appears to me that, for example, STAMP and its extensions, including the SRPM draft , comprehensively address the PM OAM requirements for SRv6. > options of IOAM and other OAM methods in SRv6, without needing to worry > about the extension header issue. > GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows: In terms of the classification given in [RFC7799] IOAM could be portrayed as Hybrid Type 1. Does your proposal change that? > > > Your comments, questions, and suggestions are very welcome. I=E2=80=99d l= ike to > know your opinion if you think this work is in scope and should be adopte= d > by the working group. If you are interested in contributing to this work= , > please also let me know. > https://datatracker.ietf.org/doc/draft-song-spring-siam/ > > > > Thank you very much! > > > > Best regards, > > Haoyu > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --000000000000b3b81505d6842e52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
        Hi Haoyu,
        thank you = for bringing the topic of Active OAM to the discussion. As the concept of A= ctive IOAM is introduced in the IPPM WG draft=C2=A0it seems to me lik= e adding the IPPM WG community to the discussion is the right thing to do.= =C2=A0
        Please find my notes in-lined below under the GIM>> = tag.

        Regards,
        Greg

        On Wed, Jan 26, = 2022 at 2:37 PM Haoyu Song <= haoyu.song@futurewei.com> wrote:

        Hi SPRING WG,

        =C2=A0

        Real time monitor on every node and every link on a = network is necessary to detect =C2=A0gray failures, which are the key culpr= it for poor QoS but hard to catch. SR provides an ideal mechanism, when wor= king with some efficient planning algorithm, to achieve that with low cost. =C2=A0=C2=A0Our proposal SRv6 In-situ Activ= e Measurement (SIAM) suggests a simple =C2=A0active measurement approach wh= ich can support different

        GIM>> I wo= nder what gaps you find in the existing active measurement protocols, e.g.,= STAMP and RFC 6734 (would be more convenient to use an acronym). It appear= s to me that, for example, STAMP and its extensions, including the SRPM = draft, comprehensively address the PM OAM requirements for SRv6.=C2=A0<= /div>

        options of IOAM and other OAM meth= ods in SRv6, without needing to worry about the extension header issue. =C2=A0

        GIM>> draft-ietf-ippm= -ioam-data classifies IOAM as follows:
        =C2=A0 =C2=A0In terms= of the classification given
        =C2=A0 =C2=A0in [RFC7799] IOAM could= be portrayed as Hybrid Type 1.
        Does your proposal change= =C2=A0that?

        =C2=A0

        Your comments, questions, and suggestions are very w= elcome. I=E2=80=99d like to know your opinion if you think this work is in = scope and should be adopted by the working group.=C2=A0 If you are interest= ed in contributing to this work, please also let me know. https://datatracker.ietf.org/doc/draft-song-spring-si= am/

        =C2=A0

        Thank you very much!

        =C2=A0

        Best regards,

        Haoyu

        _______________________________________________
        spring mailing list
        spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
        --000000000000b3b81505d6842e52-- From nobody Wed Jan 26 17:37:39 2022 Return-Path: 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 14C653A1136 for ; Wed, 26 Jan 2022 17:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.885 X-Spam-Level: X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLJjXnr5qSeQ for ; Wed, 26 Jan 2022 17:37:31 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFA393A1130 for ; Wed, 26 Jan 2022 17:37:30 -0800 (PST) Received: from fraeml711-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JkjlQ5S5Jz6FCnV for ; Thu, 27 Jan 2022 09:33:06 +0800 (CST) Received: from kwepeml100006.china.huawei.com (7.221.188.192) by fraeml711-chm.china.huawei.com (10.206.15.60) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Thu, 27 Jan 2022 02:37:26 +0100 Received: from kwepeml500004.china.huawei.com (7.221.188.141) by kwepeml100006.china.huawei.com (7.221.188.192) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Thu, 27 Jan 2022 09:37:25 +0800 Received: from kwepeml500004.china.huawei.com ([7.221.188.141]) by kwepeml500004.china.huawei.com ([7.221.188.141]) with mapi id 15.01.2308.021; Thu, 27 Jan 2022 09:37:25 +0800 From: Tianran Zhou To: Henrik Nydell CC: "wangaj3@chinatelecom.cn" , IETF IPPM WG Thread-Topic: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt Thread-Index: AQHYEOoOM8BWGUje9EistfVjjUvI2qxxspuggALRbQCAAI1nUP//gkoAgAF/fcA= Date: Thu, 27 Jan 2022 01:37:24 +0000 Message-ID: <3a33416375314462af22d1837e8472dc@huawei.com> References: <164300504281.12619.16642699818590435984@ietfa.amsl.com> <015a01d81295$fdd37370$f97a5a50$@chinatelecom.cn> <70c388c86215411796ef55d48711b216@huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.112.40.195] Content-Type: multipart/alternative; boundary="_000_3a33416375314462af22d1837e8472dchuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2022 01:37:36 -0000 --_000_3a33416375314462af22d1837e8472dchuaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSGVucmlrLA0KDQpUaGFua3MgdmVyeSBtdWNoIGZvciB5b3VyIHJldmlldy4NCllvdXIgcGVy c3BlY3RpdmUgaXMgYWJzb2x1dGVseSBjb3JyZWN0Lg0KVGhpcyBkcmFmdCBpcyBub3QgYWJsZSB0 byDigJxndWFyYW50ZWXigJ0gYSBzcGVjaWZpYyBMQUcgcGF0aC4gRm9yIGV4YW1wbGUsIHRoZXJl IGlzIGEgc3dpdGNoIGJldHdlZW4gdGhlIHR3byBlbmQgcG9pbnRzLCBvciBpbiB0aGUgY2FzZSB0 aGUgcmVmbGVjdG9yIGlzIG5vdCBjYXBhYmxlLg0KSS5lLiwgYXMgeW91IHNhaWQsIHRoZXJlIGlz IG5vICJvbmUgbWV0aG9kIGZpdHMgYWxsIiB0byBndWFyYW50ZWUgdGhlIHBhdGguDQoNCkhvd2V2 ZXIsIHRoaXMgZHJhZnQgc2VlayBhbm90aGVyIHdheSByb3VuZCwgdGhlIG1lbWJlciBsaW5rIHZh bGlkYXRpb24gbWVjaGFuaXNtLg0KVGhlcmUgaXMgYW4gYXNzdW1wdGlvbiBpbiB0aGUgaW50cm9k dWN0aW9uIOKAnFRoaXMgZG9jdW1lbnQgaW50ZW5kcyB0byBhZGRyZXNzIHRoZSBzY2VuYXJpbyB3 aGVyZSBhIExBRyBkaXJlY3RseSBjb25uZWN0cyB0d28gbm9kZXMgKEEgYW5kIEIpLuKAnQ0KV2l0 aCB0aGUgbWVtYmVyIGxpbmsgdmFsaWRhdGlvbiwgc2VuZGVyL3JlZmxlY3RvciB3aWxsIGRyb3Ag bWVhc3VyZW1lbnQgZGF0YSwgd2hlbiB0aGUgdGVzdCBwYWNrZXQgaXMgbm90IGZyb20gdGhlIGV4 cGVjdGVkIG1lbWJlciBsaW5rLg0KSW4gdGhpcyB3YXksIHRoZSBtZWFzdXJlbWVudCBjb3VsZCBh bHdheXMgYmUgY29ycmVjdC4NCg0KVGhpcyBpcyBzb21ld2hhdCBzaW1pbGFyIHRvIFBhcmlzIFRy YWNlcm91dGUgKGh0dHBzOi8vcGFyaXMtdHJhY2Vyb3V0ZS5uZXQvYWJvdXQvKSwgSU1ITy4NCg0K Q2hlZXJzLA0KVGlhbnJhbg0KDQpGcm9tOiBIZW5yaWsgTnlkZWxsIFttYWlsdG86aG55ZGVsbEBh Y2NlZGlhbi5jb21dDQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMjYsIDIwMjIgNjoxNyBQTQ0K VG86IFRpYW5yYW4gWmhvdSA8emhvdXRpYW5yYW5AaHVhd2VpLmNvbT4NCkNjOiB3YW5nYWozQGNo aW5hdGVsZWNvbS5jbjsgSUVURiBJUFBNIFdHIDxpcHBtQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFtpcHBtXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saS1pcHBtLW90 d2FtcC1vbi1sYWctMDIudHh0DQoNCkkgaGFkIGEgYnJpZWYgcmV2aWV3IGJ1dCBmYWlsZWQgdG8g ZmluZCBkZXRhaWxzIG9uIGhvdyB0aGUgVFdBTVAgc2Vzc2lvbnMgd291bGQgYmUgImd1YXJhbnRl ZWQiIHRvIHRyYXZlbCBvbiBhIGNlcnRhaW4gTEFHIHNlZ21lbnQuIEFzIGZhciBhcyBJIGtub3cg dGhlIExBRyBpbXBsZW1lbnRhdGlvbiBtYXkgYmUgZGlmZmVyZW50IGJldHdlZW4gdmVuZG9ycyBh bmQgYXMgc3VjaCBJIGtub3cgb2Ygbm8gIm9uZSBtZXRob2QgZml0cyBhbGwiIHRvIGFjdHVhbGx5 IGFjY29tcGxpc2ggdGhlIG1lYXN1cmVtZW50Lg0KDQpTbyB0aGlzIGRyYWZ0IGRvZXMgbm90IGFj dHVhbGx5IHByb3ZpZGUgYW55IHNvbHV0aW9uIHRvIHRoZSBwcm9ibGVtIG9mIGJlaW5nIGFibGUg dG8gbWVhc3VyZSBMQUcgc2VnbWVudHMgc2VwYXJhdGVseSBhbmQgZGV0ZXJtaW5pc3RpY2FsbHku DQoNCk9uIFdlZCwgSmFuIDI2LCAyMDIyIGF0IDExOjAzIEFNIFRpYW5yYW4gWmhvdSA8emhvdXRp YW5yYW49NDBodWF3ZWkuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGh1YXdlaS5jb21AZG1h cmMuaWV0Zi5vcmc+PiB3cm90ZToNCkhpIEFuanVuLA0KDQpUaGFua3MgdmVyeSBtdWNoIGZvciB5 b3VyIGludGVyZXN0IGFuZCBjb21tZW50cy4NCkJvdGggYXJlIGdvb2QgcXVlc3Rpb25zLg0KUGxl YXNlIHNlZSBpbiBsaW5lLg0KDQpDaGVlcnMsDQpUaWFucmFuDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiB3YW5nYWozQGNoaW5hdGVsZWNvbS5jbjxtYWlsdG86d2FuZ2FqM0Bj aGluYXRlbGVjb20uY24+IFttYWlsdG86d2FuZ2FqM0BjaGluYXRlbGVjb20uY248bWFpbHRvOndh bmdhajNAY2hpbmF0ZWxlY29tLmNuPl0NClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyNiwgMjAy MiA1OjIxIFBNDQpUbzogVGlhbnJhbiBaaG91IDx6aG91dGlhbnJhbkBodWF3ZWkuY29tPG1haWx0 bzp6aG91dGlhbnJhbkBodWF3ZWkuY29tPj47ICdJRVRGIElQUE0gV0cnIDxpcHBtQGlldGYub3Jn PG1haWx0bzppcHBtQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBbaXBwbV0gRlc6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGktaXBwbS1vdHdhbXAtb24tbGFnLTAyLnR4dA0K DQpIaSwgVGlhbnJhbjoNCg0KSGF2ZSBhIGJyaWVmIHJldmlldyBvZiB0aGlzIGRyYWZ0LiBJIHRo aW5rIGl0cyBhaW0gaXMgc3RyYWlnaHRmb3J3YXJkIGFuZCB3aWxsIGJlIHVzZWZ1bCB0byB1dGls aXplIHRoZSBtZW1iZXIgbGluayB3aXRoaW4gdGhlIExBRy4NClNvbWUgY29tbWVudHMgYXJlIGJl bG93Og0KMSkgSXQgc2VlbXMgdGhlcmUgaXMgbm8gU2VuZGVyL1JlZmxlY3RvciBiZWhhdmlvciBk ZXNjcmlwdGlvbiBmb3IgdGhlIE1pcmNvIE9XQU1QIHNlc3Npb24gYW5kIHRoZSBwYWNrZXQgZm9y bWF0Pw0KDQoNClpUUj4gT1dBTVAgaXMgc2ltcGxlIGFuZCB0aGVyZSBpcyBubyByZWZsZWN0b3Iu IFRoZSBzZW5kZXIgY2Fubm90IGdldCB0aGUgYWNrIGZyb20gdGhlIHJlY2VpdmVyLiBTbyB3ZSBh cmUgbm90IGdvaW5nIHRvIGV4dGVuZCB0aGUgT1dBTVAgdGVzdCBwYWNrZXQuDQpUaGUgYmVoYXZp b3IgaXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gMy4yOg0KIiBUaGUgbWljcm8gT1dBTVAgU2VuZGVy IE1VU1Qgc2VuZCB0aGUgbWljcm8gT1dBTVAtVGVzdCBwYWNrZXRzIG92ZXIgdGhlIG1lbWJlciBs aW5rIHdpdGggd2hpY2ggdGhlIHNlc3Npb24gaXMgYXNzb2NpYXRlZC4gV2hlbiByZWNlaXZlcyBh IFRlc3QgcGFja2V0LCB0aGUgbWljcm8gT1dBTVAgcmVjZWl2ZXIgTVVTVCB1c2UgdGhlIG1lbWJl ciBsaW5rIGZyb20gd2hpY2ggdGhlIFRlc3QgcGFja2V0IGlzIHJlY2VpdmVkIHRvIGNvcnJlbGF0 ZSB0aGUgbWljcm8gT1dBTVAgc2Vzc2lvbi4gSWYgdGhlcmUgaXMgbm8gc3VjaCBhIHNlc3Npb24s IHRoZSBUZXN0IHBhY2tldCBNVVNUIGJlIGRpc2NhcmRlZC4gIg0KDQoyKSBGb3IgdGhlIG5ld2x5 IGRlZmluZWQgU2Vzc2lvbi1TZW5kZXIgUGFja2V0L1Nlc3Npb24tUmVmbGVjdG9yIFBhY2tldCwg aG93IHRvIGFzc3VyZSB0aGUgYmFja3dhcmQgY29tcGF0aWJpbGl0eT8gV2hhdCBJIGhhdmUgc2Vl biBpcyB0aGF0IHlvdSBhZGQgdHdvIGFkZGl0aW9uYWwgZmllbGRzIHdpdGhpbiB0aGUgZXhpc3Rp bmcgUGFja2V0Pw0KDQpaVFI+IEkgYW0gbm90IGF3YXJlIG9mIHRoZSBjb21wYXRpYmlsaXR5IHBy b2JsZW0uIElmIGEgbm9kZSBzdXBwb3J0cyBtaWNybyBzZXNzaW9uLCBpdCBjYW4gdW5kZXJzdGFu ZCB0aGUgbmV3IHBhY2tldCBleHRlbnNpb24uIElmIGEgbm9kZSBkb2VzIG5vdCBzdXBwb3J0IG1p Y3JvIHNlc3Npb24sIGl0IGp1c3QgaWdub3JlcyB0aGUgbmV3IGZpZWxkcy4gQmVjYXVzZSB0aGUg bmV3IGZpZWxkcyBpcyBpbiB0aGUgcmVzZXJ2ZWQgem9uZS4NCk1vcmVvdmVyLCB0aGUgdmFsaWRh dGlvbiBtZWNoYW5pc20gY2FuIGZpZ3VyZSBvdXQgaWYgdGhlIHJlZmxlY3RvciBjYW4gc3VwcG9y dCB0aGUgbWljcm8gc2Vzc2lvbi4NCg0KQmVzdCBSZWdhcmRzDQoNCkFpanVuIFdhbmcNCkNoaW5h IFRlbGVjb20NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlwcG0gPGlwcG0t Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86aXBwbS1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxm IE9mIFRpYW5yYW4gWmhvdQ0KU2VudDogTW9uZGF5LCBKYW51YXJ5IDI0LCAyMDIyIDI6MjMgUE0N ClRvOiBJRVRGIElQUE0gV0cgKGlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+KSA8 aXBwbUBpZXRmLm9yZzxtYWlsdG86aXBwbUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBbaXBwbV0gRlc6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGktaXBwbS1vdHdhbXAtb24tbGFn LTAyLnR4dA0KDQpIaSBXRywNCg0KV2UgdGhpbmsgdGhpcyBpcyBhbiB1c2VmdWwgd29yayBvbiBh ZGFwdGluZyBPV0FNUC9UV0FNUCBpbiBMQUcgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQuDQpXZSB1 cGRhdGVkIHRoaXMgZHJhZnQgYmFzZWQgb24gdGhlIGNvbW1lbnRzIGZyb20gdGhlIG1lZXRpbmcg ZGlzY3Vzc2lvbiBhbmQgbWFpbGluZyBsaXN0Lg0KVGhhbmtzIGZvciBhbGwgdGhlIHN1Z2dlc3Rp b25zLg0KTW9yZSByZXZpZXdzIGFuZCBjb21tZW50cyBhcmUgd2VsY29tZS4NCg0KQ2hlZXJzLA0K VGlhbnJhbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IFttYWlsdG86aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+XQ0K U2VudDogTW9uZGF5LCBKYW51YXJ5IDI0LCAyMDIyIDI6MTcgUE0NClRvOiBHcmVnIE1pcnNreSA8 Z3JlZ2ltaXJza3lAZ21haWwuY29tPG1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20+PjsgR3Vv IEp1biA8Z3VvLmp1bjJAenRlLmNvbS5jbjxtYWlsdG86Z3VvLmp1bjJAenRlLmNvbS5jbj4+OyBK dW4gR3VvIDxndW8uanVuMkB6dGUuY29tLmNuPG1haWx0bzpndW8uanVuMkB6dGUuY29tLmNuPj47 IFJha2VzaCBHYW5kaGkgPHJnYW5kaGlAY2lzY28uY29tPG1haWx0bzpyZ2FuZGhpQGNpc2NvLmNv bT4+OyBUaWFucmFuIFpob3UgPHpob3V0aWFucmFuQGh1YXdlaS5jb208bWFpbHRvOnpob3V0aWFu cmFuQGh1YXdlaS5jb20+PjsgWmhlbnFpYW5nIExpIDxsaV96aGVucWlhbmdAaG90bWFpbC5jb208 bWFpbHRvOmxpX3poZW5xaWFuZ0Bob3RtYWlsLmNvbT4+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpLWlwcG0tb3R3YW1wLW9uLWxhZy0wMi50eHQNCg0KDQpB IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGktaXBwbS1vdHdhbXAtb24tbGFnLTAyLnR4dA0K aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBUaWFucmFuIFpob3UgYW5kIHBvc3Rl ZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgICAgZHJhZnQtbGktaXBw bS1vdHdhbXAtb24tbGFnDQpSZXZpc2lvbjogICAgICAgMDINClRpdGxlOiAgICAgICAgICBPbmUt d2F5L1R3by13YXkgQWN0aXZlIE1lYXN1cmVtZW50IFByb3RvY29sIEV4dGVuc2lvbnMgZm9yDQpQ ZXJmb3JtYW5jZSBNZWFzdXJlbWVudCBvbiBMQUcNCkRvY3VtZW50IGRhdGU6ICAyMDIyLTAxLTI0 DQpHcm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAgICAg MTMNClVSTDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtbGktaXBwbS1v dHdhbXAtb24tbGFnLTAyLnR4dA0KU3RhdHVzOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtbGktaXBwbS1vdHdhbXAtb24tbGFnLw0KSHRtbGl6ZWQ6DQpodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWxpLWlwcG0tb3R3YW1wLW9uLWxhZw0K RGlmZjoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1saS1pcHBtLW90 d2FtcC1vbi1sYWctMDINCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgZXh0 ZW5zaW9ucyB0byBPbmUtd2F5IEFjdGl2ZSBNZWFzdXJlbWVudA0KICAgUHJvdG9jb2wgKE9XQU1Q KSwgYW5kIFR3by13YXkgQWN0aXZlIE1lYXN1cmVtZW50IFByb3RvY29sIChUV0FNUCkgdG8NCiAg IGltcGxlbWVudCBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudCBvbiBldmVyeSBtZW1iZXIgbGluayBv ZiBhIExpbmsNCiAgIEFnZ3JlZ2F0aW9uIEdyb3VwIChMQUcpLiAgS25vd2luZyB0aGUgbWVhc3Vy ZWQgbWV0cmljcyBvZiBlYWNoIG1lbWJlcg0KICAgbGluayBvZiBhIExBRyBlbmFibGVzIG9wZXJh dG9ycyB0byBlbmZvcmNlIHRoZSBwZXJmb3JtYW5jZSBiYXNlZA0KICAgdHJhZmZpYyBzdGVlcmlu ZyBwb2xpY3kgYWNyb3NzIHRoZSBtZW1iZXIgbGlua3MuDQoNCg0KDQoNCg0KVGhlIElFVEYgU2Vj cmV0YXJpYXQNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KaXBwbSBtYWlsaW5nIGxpc3QNCmlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0NCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmlwcG0gbWFpbGluZyBs aXN0DQppcHBtQGlldGYub3JnPG1haWx0bzppcHBtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtDQoNCg0KLS0NCg0KSGVucmlrIE55ZGVsbA0KU3Ig UHJvZHVjdCBNYW5hZ2VyDQoxLjg2Ni42ODUuODE4MQ0KaG55ZGVsbEBhY2NlZGlhbi5jb208bWFp bHRvOmhueWRlbGxAYWNjZWRpYW4uY29tPg0KW2h0dHBzOi8vaS54aW5rLmlvL0ltYWdlcy9HZXQv TjYzODMyL2E2NS5wbmddPGh0dHA6Ly9hY2NlZGlhbi5jb20+DQpbaHR0cHM6Ly9pLnhpbmsuaW8v SW1hZ2VzL0dldC9ONjM4MzIvZjk3LnBuZ108aHR0cHM6Ly93d3cuZmFjZWJvb2suY29tL2FjY2Vk aWFuLz4gW2h0dHBzOi8vaS54aW5rLmlvL0ltYWdlcy9HZXQvTjYzODMyL3Q5OS5wbmddIDxodHRw czovL3R3aXR0ZXIuY29tL0FjY2VkaWFuPiAgW2h0dHBzOi8vaS54aW5rLmlvL0ltYWdlcy9HZXQv TjYzODMyL2w1NC5wbmddIDxodHRwczovL2NhLmxpbmtlZGluLmNvbS9jb21wYW55L2FjY2VkaWFu Pg0KPGh0dHA6Ly93d3cuYWNjZWRpYW4uY29tPg0KYWNjZWRpYW4uY29tPGh0dHA6Ly9hY2NlZGlh bi5jb20+DQoNCg0KQXZpcyBkZSBjb25maWRlbnRpYWxpdMOpDQoNCkxlcyBpbmZvcm1hdGlvbnMg Y29udGVudWVzIGRhbnMgbGUgcHLDqXNlbnQgbWVzc2FnZSBldCBkYW5zIHRvdXRlIHBpw6hjZSBx dWkgbHVpIGVzdCBqb2ludGUgc29udCBjb25maWRlbnRpZWxsZXMgZXQgcGV1dmVudCDDqnRyZSBw cm90w6lnw6llcyBwYXIgbGUgc2VjcmV0IHByb2Zlc3Npb25uZWwuIENlcyBpbmZvcm1hdGlvbnMg c29udCDDoCBs4oCZdXNhZ2UgZXhjbHVzaWYgZGUgc29uIG91IGRlIHNlcyBkZXN0aW5hdGFpcmVz LiBTaSB2b3VzIHJlY2V2ZXogY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBz4oCZaWwg dm91cyBwbGFpdCBjb21tdW5pcXVlciBpbW3DqWRpYXRlbWVudCBhdmVjIGzigJlleHDDqWRpdGV1 ciBldCBlbiBkw6l0cnVpcmUgdG91dCBleGVtcGxhaXJlLiBEZSBwbHVzLCBpbCB2b3VzIGVzdCBz dHJpY3RlbWVudCBpbnRlcmRpdCBkZSBsZSBkaXZ1bGd1ZXIsIGRlIGxlIGRpc3RyaWJ1ZXIgb3Ug ZGUgbGUgcmVwcm9kdWlyZSBzYW5zIGzigJlhdXRvcmlzYXRpb24gZGUgbOKAmWV4cMOpZGl0ZXVy LiBNZXJjaS4NCg0KQ29uZmlkZW50aWFsaXR5IG5vdGljZQ0KDQpUaGlzIGUtbWFpbCBtZXNzYWdl IGFuZCBhbnkgYXR0YWNobWVudCBoZXJldG8gY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRp b24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgYW5kIHdoaWNoIGlzIGludGVuZGVkIGZvciB0aGUg ZXhjbHVzaXZlIHVzZSBvZiBpdHMgYWRkcmVzc2VlKHMpLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIG1l c3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBpbmZvcm0gc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkZXN0 cm95IGFueSBjb3B5IHRoZXJlb2YuIEZ1cnRoZXJtb3JlLCBhbnkgZGlzY2xvc3VyZSwgZGlzdHJp YnV0aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBtZXNzYWdlIGFuZC9vciBhbnkgYXR0YWNobWVudCBo ZXJldG8gd2l0aG91dCB0aGUgY29uc2VudCBvZiB0aGUgc2VuZGVyIGlzIHN0cmljdGx5IHByb2hp Yml0ZWQuIFRoYW5rIHlvdS4NCg== --_000_3a33416375314462af22d1837e8472dchuaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkhpIEhlbnJpayw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRo YW5rcyB2ZXJ5IG11Y2ggZm9yIHlvdXIgcmV2aWV3LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Zb3VyIHBl cnNwZWN0aXZlIGlzIGFic29sdXRlbHkgY29ycmVjdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhpcyBk cmFmdCBpcyBub3QgYWJsZSB0byDigJxndWFyYW50ZWXigJ0gYSBzcGVjaWZpYyBMQUcgcGF0aC4g Rm9yIGV4YW1wbGUsIHRoZXJlIGlzIGEgc3dpdGNoIGJldHdlZW4gdGhlIHR3byBlbmQgcG9pbnRz LCBvciBpbiB0aGUgY2FzZSB0aGUgcmVmbGVjdG9yIGlzIG5vdCBjYXBhYmxlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5JLmUuLCBhcyB5b3Ugc2FpZCwgdGhlcmUgaXMgbm8gJnF1b3Q7b25lIG1ldGhvZCBm aXRzIGFsbCZxdW90OyB0byBndWFyYW50ZWUgdGhlIHBhdGguPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Ib3dldmVyLCB0aGlzIGRyYWZ0IHNlZWsgYW5vdGhlciB3 YXkgcm91bmQsIHRoZSBtZW1iZXIgbGluayB2YWxpZGF0aW9uIG1lY2hhbmlzbS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+VGhlcmUgaXMgYW4gYXNzdW1wdGlvbiBpbiB0aGUgaW50cm9kdWN0aW9uIOKAnFRo aXMgZG9jdW1lbnQgaW50ZW5kcyB0byBhZGRyZXNzIHRoZSBzY2VuYXJpbyB3aGVyZSBhIExBRyBk aXJlY3RseSBjb25uZWN0cyB0d28gbm9kZXMgKEEgYW5kIEIpLuKAnTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5XaXRoIHRoZSBtZW1iZXIgbGluayB2YWxpZGF0aW9uLCBzZW5kZXIvcmVmbGVjdG9yIHdpbGwg ZHJvcCBtZWFzdXJlbWVudCBkYXRhLCB3aGVuIHRoZSB0ZXN0IHBhY2tldCBpcyBub3QgZnJvbSB0 aGUgZXhwZWN0ZWQgbWVtYmVyIGxpbmsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkluIHRoaXMgd2F5LCB0 aGUgbWVhc3VyZW1lbnQgY291bGQgYWx3YXlzIGJlIGNvcnJlY3QuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGlzIGlzIHNvbWV3aGF0IHNpbWlsYXIgdG8gUGFy aXMgVHJhY2Vyb3V0ZSAoPGEgaHJlZj0iaHR0cHM6Ly9wYXJpcy10cmFjZXJvdXRlLm5ldC9hYm91 dC8iPmh0dHBzOi8vcGFyaXMtdHJhY2Vyb3V0ZS5uZXQvYWJvdXQvPC9hPiksIElNSE8uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaGVlcnMsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPlRpYW5yYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gSGVucmlrIE55ZGVsbCBbbWFpbHRvOmhueWRlbGxAYWNj ZWRpYW4uY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSmFudWFyeSAyNiwgMjAy MiA2OjE3IFBNPGJyPg0KPGI+VG86PC9iPiBUaWFucmFuIFpob3UgJmx0O3pob3V0aWFucmFuQGh1 YXdlaS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiB3YW5nYWozQGNoaW5hdGVsZWNvbS5jbjsgSUVU RiBJUFBNIFdHICZsdDtpcHBtQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W2lwcG1dIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpLWlwcG0tb3R3 YW1wLW9uLWxhZy0wMi50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSBoYWQgYSBicmllZiByZXZpZXcgYnV0IGZhaWxlZCB0byBmaW5kIGRldGFpbHMgb24g aG93IHRoZSBUV0FNUCBzZXNzaW9ucyB3b3VsZCBiZSAmcXVvdDtndWFyYW50ZWVkJnF1b3Q7IHRv IHRyYXZlbCBvbiBhIGNlcnRhaW4gTEFHIHNlZ21lbnQuIEFzIGZhciBhcyBJIGtub3cgdGhlIExB RyBpbXBsZW1lbnRhdGlvbiBtYXkgYmUgZGlmZmVyZW50IGJldHdlZW4gdmVuZG9ycyBhbmQgYXMg c3VjaCBJIGtub3cgb2Ygbm8gJnF1b3Q7b25lIG1ldGhvZA0KIGZpdHMgYWxsJnF1b3Q7IHRvIGFj dHVhbGx5IGFjY29tcGxpc2ggdGhlIG1lYXN1cmVtZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyB0aGlzIGRyYWZ0IGRvZXMgbm90IGFj dHVhbGx5IHByb3ZpZGUgYW55IHNvbHV0aW9uIHRvIHRoZSBwcm9ibGVtIG9mIGJlaW5nIGFibGUg dG8gbWVhc3VyZSBMQUcgc2VnbWVudHMgc2VwYXJhdGVseSBhbmQgZGV0ZXJtaW5pc3RpY2FsbHku PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IFdlZCwgSmFuIDI2LCAyMDIyIGF0IDExOjAzIEFNIFRpYW5yYW4gWmhvdSAmbHQ7emhvdXRpYW5y YW49PGEgaHJlZj0ibWFpbHRvOjQwaHVhd2VpLmNvbUBkbWFyYy5pZXRmLm9yZyI+NDBodWF3ZWku Y29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBBbmp1biw8YnI+DQo8YnI+DQpU aGFua3MgdmVyeSBtdWNoIGZvciB5b3VyIGludGVyZXN0IGFuZCBjb21tZW50cy48YnI+DQpCb3Ro IGFyZSBnb29kIHF1ZXN0aW9ucy48YnI+DQpQbGVhc2Ugc2VlIGluIGxpbmUuPGJyPg0KPGJyPg0K Q2hlZXJzLDxicj4NClRpYW5yYW48YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LTxicj4NCkZyb206IDxhIGhyZWY9Im1haWx0bzp3YW5nYWozQGNoaW5hdGVsZWNvbS5jbiIgdGFy Z2V0PSJfYmxhbmsiPndhbmdhajNAY2hpbmF0ZWxlY29tLmNuPC9hPiBbbWFpbHRvOjxhIGhyZWY9 Im1haWx0bzp3YW5nYWozQGNoaW5hdGVsZWNvbS5jbiIgdGFyZ2V0PSJfYmxhbmsiPndhbmdhajNA Y2hpbmF0ZWxlY29tLmNuPC9hPl0NCjxicj4NClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyNiwg MjAyMiA1OjIxIFBNPGJyPg0KVG86IFRpYW5yYW4gWmhvdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnpo b3V0aWFucmFuQGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj56aG91dGlhbnJhbkBodWF3ZWku Y29tPC9hPiZndDs7ICdJRVRGIElQUE0gV0cnICZsdDs8YSBocmVmPSJtYWlsdG86aXBwbUBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlwcG1AaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NClN1YmplY3Q6 IFJFOiBbaXBwbV0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGktaXBw bS1vdHdhbXAtb24tbGFnLTAyLnR4dDxicj4NCjxicj4NCkhpLCBUaWFucmFuOjxicj4NCjxicj4N CkhhdmUgYSBicmllZiByZXZpZXcgb2YgdGhpcyBkcmFmdC4gSSB0aGluayBpdHMgYWltIGlzIHN0 cmFpZ2h0Zm9yd2FyZCBhbmQgd2lsbCBiZSB1c2VmdWwgdG8gdXRpbGl6ZSB0aGUgbWVtYmVyIGxp bmsgd2l0aGluIHRoZSBMQUcuPGJyPg0KU29tZSBjb21tZW50cyBhcmUgYmVsb3c6PGJyPg0KMSkg SXQgc2VlbXMgdGhlcmUgaXMgbm8gU2VuZGVyL1JlZmxlY3RvciBiZWhhdmlvciBkZXNjcmlwdGlv biBmb3IgdGhlIE1pcmNvIE9XQU1QIHNlc3Npb24gYW5kIHRoZSBwYWNrZXQgZm9ybWF0Pw0KPGJy Pg0KPGJyPg0KPGJyPg0KWlRSJmd0OyBPV0FNUCBpcyBzaW1wbGUgYW5kIHRoZXJlIGlzIG5vIHJl ZmxlY3Rvci4gVGhlIHNlbmRlciBjYW5ub3QgZ2V0IHRoZSBhY2sgZnJvbSB0aGUgcmVjZWl2ZXIu IFNvIHdlIGFyZSBub3QgZ29pbmcgdG8gZXh0ZW5kIHRoZSBPV0FNUCB0ZXN0IHBhY2tldC48YnI+ DQpUaGUgYmVoYXZpb3IgaXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gMy4yOjxicj4NCiZxdW90OyBU aGUgbWljcm8gT1dBTVAgU2VuZGVyIE1VU1Qgc2VuZCB0aGUgbWljcm8gT1dBTVAtVGVzdCBwYWNr ZXRzIG92ZXIgdGhlIG1lbWJlciBsaW5rIHdpdGggd2hpY2ggdGhlIHNlc3Npb24gaXMgYXNzb2Np YXRlZC4gV2hlbiByZWNlaXZlcyBhIFRlc3QgcGFja2V0LCB0aGUgbWljcm8gT1dBTVAgcmVjZWl2 ZXIgTVVTVCB1c2UgdGhlIG1lbWJlciBsaW5rIGZyb20gd2hpY2ggdGhlIFRlc3QgcGFja2V0IGlz IHJlY2VpdmVkIHRvIGNvcnJlbGF0ZSB0aGUNCiBtaWNybyBPV0FNUCBzZXNzaW9uLiBJZiB0aGVy ZSBpcyBubyBzdWNoIGEgc2Vzc2lvbiwgdGhlIFRlc3QgcGFja2V0IE1VU1QgYmUgZGlzY2FyZGVk LiAmcXVvdDsNCjxicj4NCjxicj4NCjIpIEZvciB0aGUgbmV3bHkgZGVmaW5lZCBTZXNzaW9uLVNl bmRlciBQYWNrZXQvU2Vzc2lvbi1SZWZsZWN0b3IgUGFja2V0LCBob3cgdG8gYXNzdXJlIHRoZSBi YWNrd2FyZCBjb21wYXRpYmlsaXR5PyBXaGF0IEkgaGF2ZSBzZWVuIGlzIHRoYXQgeW91IGFkZCB0 d28gYWRkaXRpb25hbCBmaWVsZHMgd2l0aGluIHRoZSBleGlzdGluZyBQYWNrZXQ/DQo8YnI+DQo8 YnI+DQpaVFImZ3Q7IEkgYW0gbm90IGF3YXJlIG9mIHRoZSBjb21wYXRpYmlsaXR5IHByb2JsZW0u IElmIGEgbm9kZSBzdXBwb3J0cyBtaWNybyBzZXNzaW9uLCBpdCBjYW4gdW5kZXJzdGFuZCB0aGUg bmV3IHBhY2tldCBleHRlbnNpb24uIElmIGEgbm9kZSBkb2VzIG5vdCBzdXBwb3J0IG1pY3JvIHNl c3Npb24sIGl0IGp1c3QgaWdub3JlcyB0aGUgbmV3IGZpZWxkcy4gQmVjYXVzZSB0aGUgbmV3IGZp ZWxkcyBpcyBpbiB0aGUgcmVzZXJ2ZWQgem9uZS48YnI+DQpNb3Jlb3ZlciwgdGhlIHZhbGlkYXRp b24gbWVjaGFuaXNtIGNhbiBmaWd1cmUgb3V0IGlmIHRoZSByZWZsZWN0b3IgY2FuIHN1cHBvcnQg dGhlIG1pY3JvIHNlc3Npb24uDQo8YnI+DQo8YnI+DQpCZXN0IFJlZ2FyZHM8YnI+DQo8YnI+DQpB aWp1biBXYW5nPGJyPg0KQ2hpbmEgVGVsZWNvbTxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tPGJyPg0KRnJvbTogaXBwbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlwcG0tYm91bmNl c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlwcG0tYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7 IE9uIEJlaGFsZiBPZiBUaWFucmFuIFpob3U8YnI+DQpTZW50OiBNb25kYXksIEphbnVhcnkgMjQs IDIwMjIgMjoyMyBQTTxicj4NClRvOiBJRVRGIElQUE0gV0cgKDxhIGhyZWY9Im1haWx0bzppcHBt QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aXBwbUBpZXRmLm9yZzwvYT4pICZsdDs8YSBocmVm PSJtYWlsdG86aXBwbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlwcG1AaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NClN1YmplY3Q6IFtpcHBtXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC1saS1pcHBtLW90d2FtcC1vbi1sYWctMDIudHh0PGJyPg0KPGJyPg0KSGkgV0csPGJy Pg0KPGJyPg0KV2UgdGhpbmsgdGhpcyBpcyBhbiB1c2VmdWwgd29yayBvbiBhZGFwdGluZyBPV0FN UC9UV0FNUCBpbiBMQUcgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQuPGJyPg0KV2UgdXBkYXRlZCB0 aGlzIGRyYWZ0IGJhc2VkIG9uIHRoZSBjb21tZW50cyBmcm9tIHRoZSBtZWV0aW5nIGRpc2N1c3Np b24gYW5kIG1haWxpbmcgbGlzdC48YnI+DQpUaGFua3MgZm9yIGFsbCB0aGUgc3VnZ2VzdGlvbnMu PGJyPg0KTW9yZSByZXZpZXdzIGFuZCBjb21tZW50cyBhcmUgd2VsY29tZS48YnI+DQo8YnI+DQpD aGVlcnMsPGJyPg0KVGlhbnJhbjxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PGJyPg0KRnJvbTogPGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVm PSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnPC9hPl08YnI+DQpTZW50OiBNb25kYXksIEphbnVhcnkgMjQsIDIw MjIgMjoxNyBQTTxicj4NClRvOiBHcmVnIE1pcnNreSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdp bWlyc2t5QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwv YT4mZ3Q7OyBHdW8gSnVuICZsdDs8YSBocmVmPSJtYWlsdG86Z3VvLmp1bjJAenRlLmNvbS5jbiIg dGFyZ2V0PSJfYmxhbmsiPmd1by5qdW4yQHp0ZS5jb20uY248L2E+Jmd0OzsgSnVuIEd1byAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmd1by5qdW4yQHp0ZS5jb20uY24iIHRhcmdldD0iX2JsYW5rIj5ndW8u anVuMkB6dGUuY29tLmNuPC9hPiZndDs7DQogUmFrZXNoIEdhbmRoaSAmbHQ7PGEgaHJlZj0ibWFp bHRvOnJnYW5kaGlAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+cmdhbmRoaUBjaXNjby5jb208 L2E+Jmd0OzsgVGlhbnJhbiBaaG91ICZsdDs8YSBocmVmPSJtYWlsdG86emhvdXRpYW5yYW5AaHVh d2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnpob3V0aWFucmFuQGh1YXdlaS5jb208L2E+Jmd0Ozsg WmhlbnFpYW5nIExpICZsdDs8YSBocmVmPSJtYWlsdG86bGlfemhlbnFpYW5nQGhvdG1haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+bGlfemhlbnFpYW5nQGhvdG1haWwuY29tPC9hPiZndDs8YnI+DQpT dWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpLWlwcG0tb3R3YW1w LW9uLWxhZy0wMi50eHQ8YnI+DQo8YnI+DQo8YnI+DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtbGktaXBwbS1vdHdhbXAtb24tbGFnLTAyLnR4dDxicj4NCmhhcyBiZWVuIHN1Y2Nlc3NmdWxs eSBzdWJtaXR0ZWQgYnkgVGlhbnJhbiBaaG91IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3Np dG9yeS48YnI+DQo8YnI+DQpOYW1lOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ZHJhZnQtbGktaXBwbS1vdHdhbXAtb24tbGFnPGJyPg0KUmV2aXNpb246Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7MDI8YnI+DQpUaXRsZTombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IE9uZS13YXkvVHdvLXdheSBBY3RpdmUgTWVhc3VyZW1lbnQgUHJvdG9jb2wgRXh0 ZW5zaW9ucyBmb3I8YnI+DQpQZXJmb3JtYW5jZSBNZWFzdXJlbWVudCBvbiBMQUc8YnI+DQpEb2N1 bWVudCBkYXRlOiZuYnNwOyAyMDIyLTAxLTI0PGJyPg0KR3JvdXA6Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248YnI+DQpQYWdlczombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDEzPGJyPg0KVVJMOjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtbGktaXBwbS1vdHdhbXAtb24tbGFn LTAyLnR4dCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQv ZHJhZnQtbGktaXBwbS1vdHdhbXAtb24tbGFnLTAyLnR4dDwvYT48YnI+DQpTdGF0dXM6PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGktaXBwbS1v dHdhbXAtb24tbGFnLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWxpLWlwcG0tb3R3YW1wLW9uLWxhZy88L2E+PGJyPg0KSHRtbGl6ZWQ6PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1s aS1pcHBtLW90d2FtcC1vbi1sYWciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWxpLWlwcG0tb3R3YW1wLW9uLWxhZzwvYT48YnI+DQpE aWZmOjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1saS1pcHBtLW90d2FtcC1vbi1sYWctMDIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbGktaXBwbS1vdHdhbXAtb24tbGFnLTAyPC9hPjxi cj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiZuYnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50IGRlZmlu ZXMgZXh0ZW5zaW9ucyB0byBPbmUtd2F5IEFjdGl2ZSBNZWFzdXJlbWVudDxicj4NCiZuYnNwOyAm bmJzcDtQcm90b2NvbCAoT1dBTVApLCBhbmQgVHdvLXdheSBBY3RpdmUgTWVhc3VyZW1lbnQgUHJv dG9jb2wgKFRXQU1QKSB0bzxicj4NCiZuYnNwOyAmbmJzcDtpbXBsZW1lbnQgcGVyZm9ybWFuY2Ug bWVhc3VyZW1lbnQgb24gZXZlcnkgbWVtYmVyIGxpbmsgb2YgYSBMaW5rPGJyPg0KJm5ic3A7ICZu YnNwO0FnZ3JlZ2F0aW9uIEdyb3VwIChMQUcpLiZuYnNwOyBLbm93aW5nIHRoZSBtZWFzdXJlZCBt ZXRyaWNzIG9mIGVhY2ggbWVtYmVyPGJyPg0KJm5ic3A7ICZuYnNwO2xpbmsgb2YgYSBMQUcgZW5h YmxlcyBvcGVyYXRvcnMgdG8gZW5mb3JjZSB0aGUgcGVyZm9ybWFuY2UgYmFzZWQ8YnI+DQombmJz cDsgJm5ic3A7dHJhZmZpYyBzdGVlcmluZyBwb2xpY3kgYWNyb3NzIHRoZSBtZW1iZXIgbGlua3Mu PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8 YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCmlwcG0gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmlwcG1A aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pcHBtQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBwbSIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBwbTwvYT48YnI+DQo8 YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CmlwcG0gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmlwcG1AaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5pcHBtQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBwbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBwbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyIGNsZWFyPSJhbGwi Pg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxzdHJvbmc+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUEwODMyIj5IZW5yaWsgTnlkZWxsPC9zcGFuPjwvc3Ryb25nPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWYiPjxicj4NCjwvc3Bhbj48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6I0Y1OUQxNSI+ U3IgUHJvZHVjdCBNYW5hZ2VyPC9zcGFuPjwvc3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjxz cGFuIHN0eWxlPSJjb2xvcjojMUEwODMyIj4xLjg2Ni42ODUuODE4MTxicj4NCjxhIGhyZWY9Im1h aWx0bzpobnlkZWxsQGFjY2VkaWFuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmhueWRlbGxAYWNjZWRp YW4uY29tPC9hPjwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPGEgaHJlZj0iaHR0 cDovL2FjY2VkaWFuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29y YXRpb246bm9uZSI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIxNTciIGhlaWdodD0iNTAiIGlkPSJf eDAwMDBfaTEwMjUiIHNyYz0iaHR0cHM6Ly9pLnhpbmsuaW8vSW1hZ2VzL0dldC9ONjM4MzIvYTY1 LnBuZyI+PC9zcGFuPjwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5mYWNlYm9vay5jb20v YWNjZWRpYW4vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjpu b25lIj48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjI1IiBoZWlnaHQ9IjI1IiBpZD0iX3gwMDAwX2kx MDI2IiBzcmM9Imh0dHBzOi8vaS54aW5rLmlvL0ltYWdlcy9HZXQvTjYzODMyL2Y5Ny5wbmciPjwv c3Bhbj48L2E+Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90d2l0dGVyLmNvbS9BY2NlZGlhbiIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZSI+PGltZyBib3Jk ZXI9IjAiIHdpZHRoPSIyNSIgaGVpZ2h0PSIyNSIgaWQ9Il94MDAwMF9pMTAyNyIgc3JjPSJodHRw czovL2kueGluay5pby9JbWFnZXMvR2V0L042MzgzMi90OTkucG5nIj48L3NwYW4+PC9hPiZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vY2EubGlua2VkaW4uY29tL2NvbXBhbnkvYWNjZWRpYW4iIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVy PSIwIiB3aWR0aD0iMjUiIGhlaWdodD0iMjUiIGlkPSJfeDAwMDBfaTEwMjgiIHNyYz0iaHR0cHM6 Ly9pLnhpbmsuaW8vSW1hZ2VzL0dldC9ONjM4MzIvbDU0LnBuZyI+PC9zcGFuPjwvYT48YnI+DQo8 YSBocmVmPSJodHRwOi8vd3d3LmFjY2VkaWFuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZSI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIyOTQiIGhl aWdodD0iMSIgaWQ9Il94MDAwMF9pMTAyOSIgc3JjPSJodHRwczovL2kueGluay5pby9JbWFnZXMv R2V0L042MzgzMi9sLmpwZyI+PC9zcGFuPjwvYT48YnI+DQo8L3NwYW4+PHN0cm9uZz48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiNGNTlEMTUiPjxhIGhyZWY9Imh0dHA6Ly9hY2NlZGlhbi5jb20iIHRhcmdl dD0iX2JsYW5rIj5hY2NlZGlhbi5jb208L2E+PC9zcGFuPjwvc3Ryb25nPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw PjxzcGFuIGxhbmc9IkZSLUNBIiBzdHlsZT0iZm9udC1zaXplOjcuNXB0Ij5BdmlzIGRlIGNvbmZp ZGVudGlhbGl0w6k8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJGUi1DQSIg c3R5bGU9ImZvbnQtc2l6ZTo3LjVwdCI+TGVzIGluZm9ybWF0aW9ucyBjb250ZW51ZXMgZGFucyBs ZSBwcsOpc2VudCBtZXNzYWdlIGV0IGRhbnMgdG91dGUgcGnDqGNlIHF1aSBsdWkgZXN0IGpvaW50 ZSBzb250IGNvbmZpZGVudGllbGxlcyBldCBwZXV2ZW50IMOqdHJlIHByb3TDqWfDqWVzIHBhciBs ZSBzZWNyZXQgcHJvZmVzc2lvbm5lbC4gQ2VzIGluZm9ybWF0aW9ucyBzb250IMOgIGzigJl1c2Fn ZSBleGNsdXNpZiBkZSBzb24NCiBvdSBkZSBzZXMgZGVzdGluYXRhaXJlcy4gU2kgdm91cyByZWNl dmV6IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogc+KAmWlsIHZvdXMgcGxhaXQgY29t bXVuaXF1ZXIgaW1tw6lkaWF0ZW1lbnQgYXZlYyBs4oCZZXhww6lkaXRldXIgZXQgZW4gZMOpdHJ1 aXJlIHRvdXQgZXhlbXBsYWlyZS4gRGUgcGx1cywgaWwgdm91cyBlc3Qgc3RyaWN0ZW1lbnQgaW50 ZXJkaXQgZGUgbGUgZGl2dWxndWVyLCBkZSBsZSBkaXN0cmlidWVyIG91IGRlIGxlIHJlcHJvZHVp cmUNCiBzYW5zIGzigJlhdXRvcmlzYXRpb24gZGUgbOKAmWV4cMOpZGl0ZXVyLiBNZXJjaS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJGUi1DQSIgc3R5bGU9ImZvbnQtc2l6 ZTo3LjVwdCI+Q29uZmlkZW50aWFsaXR5IG5vdGljZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw PjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQiPlRoaXMgZS1tYWlsIG1lc3NhZ2UgYW5kIGFu eSBhdHRhY2htZW50IGhlcmV0byBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiB3aGlj aCBtYXkgYmUgcHJpdmlsZWdlZCBhbmQgd2hpY2ggaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNp dmUgdXNlIG9mIGl0cyBhZGRyZXNzZWUocykuIElmIHlvdSByZWNlaXZlIHRoaXMgbWVzc2FnZSBp biBlcnJvciwgcGxlYXNlIGluZm9ybSBzZW5kZXINCiBpbW1lZGlhdGVseSBhbmQgZGVzdHJveSBh bnkgY29weSB0aGVyZW9mLiBGdXJ0aGVybW9yZSwgYW55IGRpc2Nsb3N1cmUsIGRpc3RyaWJ1dGlv biBvciBjb3B5aW5nIG9mIHRoaXMgbWVzc2FnZSBhbmQvb3IgYW55IGF0dGFjaG1lbnQgaGVyZXRv IHdpdGhvdXQgdGhlIGNvbnNlbnQgb2YgdGhlIHNlbmRlciBpcyBzdHJpY3RseSBwcm9oaWJpdGVk LiBUaGFuayB5b3UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_3a33416375314462af22d1837e8472dchuaweicom_-- From nobody Wed Jan 26 18:35:34 2022 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 70AD63A13DC; Wed, 26 Jan 2022 18:35:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.43.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ippm@ietf.org Message-ID: <164325092739.4500.10411742864654520528@ietfa.amsl.com> Date: Wed, 26 Jan 2022 18:35:27 -0800 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-ioam-conf-state-03.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2022 02:35:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Measurement WG of the IETF. Title : Echo Request/Reply for Enabled In-situ OAM Capabilities Authors : Xiao Min Greg Mirsky Lei Bo Filename : draft-ietf-ippm-ioam-conf-state-03.txt Pages : 18 Date : 2022-01-26 Abstract: This document describes an extension to the echo request/reply mechanisms used in IPv6 (including SRv6), MPLS (including SR-MPLS), SFC and BIER environments, which can be used within the IOAM domain, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-conf-state/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-conf-state-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-ioam-conf-state-03 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Wed Jan 26 18:48:27 2022 Return-Path: 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 0F98D3A1460 for ; Wed, 26 Jan 2022 18:48:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFXttuVPJjY1 for ; Wed, 26 Jan 2022 18:48:21 -0800 (PST) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE9543A1463 for ; Wed, 26 Jan 2022 18:48:20 -0800 (PST) Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4JklQC1vwZz8PxD5 for ; Thu, 27 Jan 2022 10:48:19 +0800 (CST) Received: from njxapp05.zte.com.cn ([10.41.132.204]) by mse-fl2.zte.com.cn with SMTP id 20R2mBNw085013 for ; Thu, 27 Jan 2022 10:48:11 +0800 (GMT-8) (envelope-from xiao.min2@zte.com.cn) Received: from mapi (njxapp01[null]) by mapi (Zmail) with MAPI id mid201; Thu, 27 Jan 2022 10:48:11 +0800 (CST) Date: Thu, 27 Jan 2022 10:48:11 +0800 (CST) X-Zmail-TransId: 2af961f207eb3e483cee X-Mailer: Zmail v1.0 Message-ID: <202201271048115742939@zte.com.cn> References: 164325092739.4500.10411742864654520528@ietfa.amsl.com Mime-Version: 1.0 From: To: Content-Type: text/plain; charset="UTF-8" X-MAIL: mse-fl2.zte.com.cn 20R2mBNw085013 X-Fangmail-Gw-Spam-Type: 0 X-FangMail-Miltered: at cgslv5.04-192.168.250.137.novalocal with ID 61F207F3.000 by FangMail milter! X-FangMail-Envelope: 1643251699/4JklQC1vwZz8PxD5/61F207F3.000/10.30.14.239/[10.30.14.239]/mse-fl2.zte.com.cn/ X-Fangmail-Anti-Spam-Filtered: true X-Fangmail-MID-QID: 61F207F3.000/4JklQC1vwZz8PxD5 Archived-At: Subject: [ippm] =?utf-8?q?Fw=3A_I-D_Action=3A_draft-ietf-ippm-ioam-conf-s?= =?utf-8?q?tate-03=2Etxt?= X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2022 02:48:26 -0000 IPPM WG, The 03 revision attempts to address comments from Frank Brockners. Thanks to Frank for the very helpful discussion. More review and comments are appreciated. Best Regards, Xiao Min ------------------原始邮件------------------ å‘件人：internet-drafts@ietf.org 收件人：i-d-announce@ietf.org ; 抄é€äººï¼šippm@ietf.org; æ—¥ 期 ：2022å¹´01月27æ—¥ 10:36 主 题 ：[ippm] I-D Action: draft-ietf-ippm-ioam-conf-state-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Measurement WG of the IETF. Title : Echo Request/Reply for Enabled In-situ OAM Capabilities Authors : Xiao Min Greg Mirsky Lei Bo Filename : draft-ietf-ippm-ioam-conf-state-03.txt Pages : 18 Date : 2022-01-26 Abstract: This document describes an extension to the echo request/reply mechanisms used in IPv6 (including SRv6), MPLS (including SR-MPLS), SFC and BIER environments, which can be used within the IOAM domain, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-conf-state/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-conf-state-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-ioam-conf-state-03 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From nobody Wed Jan 26 19:19:16 2022 Return-Path: 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 B98D03A15DE; Wed, 26 Jan 2022 19:19:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufs2RxR492UP; Wed, 26 Jan 2022 19:19:11 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 113BC3A15DD; Wed, 26 Jan 2022 19:19:11 -0800 (PST) Received: from fraeml710-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Jkm0l0w05z67vqk; Thu, 27 Jan 2022 11:14:47 +0800 (CST) Received: from kwepeml100006.china.huawei.com (7.221.188.192) by fraeml710-chm.china.huawei.com (10.206.15.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Thu, 27 Jan 2022 04:19:07 +0100 Received: from kwepeml500004.china.huawei.com (7.221.188.141) by kwepeml100006.china.huawei.com (7.221.188.192) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Thu, 27 Jan 2022 11:19:05 +0800 Received: from kwepeml500004.china.huawei.com ([7.221.188.141]) by kwepeml500004.china.huawei.com ([7.221.188.141]) with mapi id 15.01.2308.021; Thu, 27 Jan 2022 11:19:05 +0800 From: Tianran Zhou To: Greg Mirsky , Haoyu Song CC: "spring@ietf.org" , IETF IPPM WG Thread-Topic: [ippm] [spring] Active OAM in SRv6 Thread-Index: AdgTBAVv6vallEwgQVCAy2m6n5m7fP//gxqA//8zIPA= Date: Thu, 27 Jan 2022 03:19:05 +0000 Message-ID: <97ee51feb17c4bcc84bc575768c06c3e@huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.112.40.195] Content-Type: multipart/alternative; boundary="_000_97ee51feb17c4bcc84bc575768c06c3ehuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] [spring] Active OAM in SRv6 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2022 03:19:16 -0000 --_000_97ee51feb17c4bcc84bc575768c06c3ehuaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSGFveXUsDQoNClRoZSBhcHBsaWNhdGlvbiBpcyByZWFsbHkgaW50ZXJlc3RpbmcgYW5kIHVz ZWZ1bC4NCkkgYW0gbm90IHN1cmUgaWYgaXQgaXMgbmVjZXNzYXJ5IHRvIGNyZWF0ZSBhIG5ldyBP QU0gcHJvdG9jb2wgYXQgdHJhbnNwb3J0IGxheWVyLg0KSU1ITywgYSBwZXIgaG9wL3BlciBzZWdt ZW50IGV4dGVuc2lvbiBiYXNlZCBvbiBTVEFNUCBjb3VsZCBiZSBtb3JlIHByYWN0aWNhbC4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtd2FuZy1pcHBtLXN0YW1wLWhiaC1l eHRlbnNpb25zLTAzLnR4dA0KDQpCZXN0LA0KVGlhbnJhbg0KDQpGcm9tOiBpcHBtIFttYWlsdG86 aXBwbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR3JlZyBNaXJza3kNClNlbnQ6IFRo dXJzZGF5LCBKYW51YXJ5IDI3LCAyMDIyIDc6MDEgQU0NClRvOiBIYW95dSBTb25nIDxoYW95dS5z b25nQGZ1dHVyZXdlaS5jb20+DQpDYzogc3ByaW5nQGlldGYub3JnOyBJRVRGIElQUE0gV0cgPGlw cG1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2lwcG1dIFtzcHJpbmddIEFjdGl2ZSBPQU0gaW4g U1J2Ng0KDQpIaSBIYW95dSwNCnRoYW5rIHlvdSBmb3IgYnJpbmdpbmcgdGhlIHRvcGljIG9mIEFj dGl2ZSBPQU0gdG8gdGhlIGRpc2N1c3Npb24uIEFzIHRoZSBjb25jZXB0IG9mIEFjdGl2ZSBJT0FN IGlzIGludHJvZHVjZWQgaW4gdGhlIElQUE0gV0cgZHJhZnQ8aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWlwcG0taW9hbS1mbGFncz4gaXQgc2VlbXMgdG8g bWUgbGlrZSBhZGRpbmcgdGhlIElQUE0gV0cgY29tbXVuaXR5IHRvIHRoZSBkaXNjdXNzaW9uIGlz IHRoZSByaWdodCB0aGluZyB0byBkby4NClBsZWFzZSBmaW5kIG15IG5vdGVzIGluLWxpbmVkIGJl bG93IHVuZGVyIHRoZSBHSU0+PiB0YWcuDQoNClJlZ2FyZHMsDQpHcmVnDQoNCk9uIFdlZCwgSmFu IDI2LCAyMDIyIGF0IDI6MzcgUE0gSGFveXUgU29uZyA8aGFveXUuc29uZ0BmdXR1cmV3ZWkuY29t PG1haWx0bzpoYW95dS5zb25nQGZ1dHVyZXdlaS5jb20+PiB3cm90ZToNCkhpIFNQUklORyBXRywN Cg0KUmVhbCB0aW1lIG1vbml0b3Igb24gZXZlcnkgbm9kZSBhbmQgZXZlcnkgbGluayBvbiBhIG5l dHdvcmsgaXMgbmVjZXNzYXJ5IHRvIGRldGVjdCAgZ3JheSBmYWlsdXJlcywgd2hpY2ggYXJlIHRo ZSBrZXkgY3VscHJpdCBmb3IgcG9vciBRb1MgYnV0IGhhcmQgdG8gY2F0Y2guIFNSIHByb3ZpZGVz IGFuIGlkZWFsIG1lY2hhbmlzbSwgd2hlbiB3b3JraW5nIHdpdGggc29tZSBlZmZpY2llbnQgcGxh bm5pbmcgYWxnb3JpdGhtLCB0byBhY2hpZXZlIHRoYXQgd2l0aCBsb3cgY29zdC4gICBPdXIgcHJv cG9zYWwgU1J2NiBJbi1zaXR1IEFjdGl2ZSBNZWFzdXJlbWVudCAoU0lBTSkgc3VnZ2VzdHMgYSBz aW1wbGUgIGFjdGl2ZSBtZWFzdXJlbWVudCBhcHByb2FjaCB3aGljaCBjYW4gc3VwcG9ydCBkaWZm ZXJlbnQNCkdJTT4+IEkgd29uZGVyIHdoYXQgZ2FwcyB5b3UgZmluZCBpbiB0aGUgZXhpc3Rpbmcg YWN0aXZlIG1lYXN1cmVtZW50IHByb3RvY29scywgZS5nLiwgU1RBTVAgYW5kIFJGQyA2NzM0ICh3 b3VsZCBiZSBtb3JlIGNvbnZlbmllbnQgdG8gdXNlIGFuIGFjcm9ueW0pLiBJdCBhcHBlYXJzIHRv IG1lIHRoYXQsIGZvciBleGFtcGxlLCBTVEFNUCBhbmQgaXRzIGV4dGVuc2lvbnMsIGluY2x1ZGlu ZyB0aGUgU1JQTSBkcmFmdDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2Ry YWZ0LWlldGYtaXBwbS1zdGFtcC1zcnBtPiwgY29tcHJlaGVuc2l2ZWx5IGFkZHJlc3MgdGhlIFBN IE9BTSByZXF1aXJlbWVudHMgZm9yIFNSdjYuDQpvcHRpb25zIG9mIElPQU0gYW5kIG90aGVyIE9B TSBtZXRob2RzIGluIFNSdjYsIHdpdGhvdXQgbmVlZGluZyB0byB3b3JyeSBhYm91dCB0aGUgZXh0 ZW5zaW9uIGhlYWRlciBpc3N1ZS4NCkdJTT4+IGRyYWZ0LWlldGYtaXBwbS1pb2FtLWRhdGEgY2xh c3NpZmllcyBJT0FNIGFzIGZvbGxvd3M6DQogICBJbiB0ZXJtcyBvZiB0aGUgY2xhc3NpZmljYXRp b24gZ2l2ZW4NCiAgIGluIFtSRkM3Nzk5XSBJT0FNIGNvdWxkIGJlIHBvcnRyYXllZCBhcyBIeWJy aWQgVHlwZSAxLg0KRG9lcyB5b3VyIHByb3Bvc2FsIGNoYW5nZSB0aGF0Pw0KDQpZb3VyIGNvbW1l bnRzLCBxdWVzdGlvbnMsIGFuZCBzdWdnZXN0aW9ucyBhcmUgdmVyeSB3ZWxjb21lLiBJ4oCZZCBs aWtlIHRvIGtub3cgeW91ciBvcGluaW9uIGlmIHlvdSB0aGluayB0aGlzIHdvcmsgaXMgaW4gc2Nv cGUgYW5kIHNob3VsZCBiZSBhZG9wdGVkIGJ5IHRoZSB3b3JraW5nIGdyb3VwLiAgSWYgeW91IGFy ZSBpbnRlcmVzdGVkIGluIGNvbnRyaWJ1dGluZyB0byB0aGlzIHdvcmssIHBsZWFzZSBhbHNvIGxl dCBtZSBrbm93LiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zb25nLXNw cmluZy1zaWFtLw0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIQ0KDQpCZXN0IHJlZ2FyZHMsDQpIYW95 dQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNwcmlu ZyBtYWlsaW5nIGxpc3QNCnNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCg== --_000_97ee51feb17c4bcc84bc575768c06c3ehuaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPkhpIEhhb3l1LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+VGhlIGFwcGxpY2F0aW9uIGlzIHJlYWxseSBpbnRlcmVzdGluZyBhbmQgdXNlZnVsLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5JIGFtIG5vdCBzdXJlIGlmIGl0IGlzIG5lY2Vzc2FyeSB0byBjcmVhdGUg YSBuZXcgT0FNIHByb3RvY29sIGF0IHRyYW5zcG9ydCBsYXllci48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ SU1ITywgYSBwZXIgaG9wL3BlciBzZWdtZW50IGV4dGVuc2lvbiBiYXNlZCBvbiBTVEFNUCBjb3Vs ZCBiZSBtb3JlIHByYWN0aWNhbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC13YW5nLWlwcG0tc3RhbXAtaGJoLWV4dGVuc2lv bnMtMDMudHh0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LXdhbmctaXBw bS1zdGFtcC1oYmgtZXh0ZW5zaW9ucy0wMy50eHQ8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5CZXN0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaWFucmFuICZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiBpcHBtIFttYWlsdG86aXBwbS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5HcmVnIE1pcnNreTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSmFudWFy eSAyNywgMjAyMiA3OjAxIEFNPGJyPg0KPGI+VG86PC9iPiBIYW95dSBTb25nICZsdDtoYW95dS5z b25nQGZ1dHVyZXdlaS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBzcHJpbmdAaWV0Zi5vcmc7IElF VEYgSVBQTSBXRyAmbHQ7aXBwbUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtpcHBtXSBbc3ByaW5nXSBBY3RpdmUgT0FNIGluIFNSdjY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEhhb3l1LDxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoYW5rIHlvdSBmb3IgYnJpbmdpbmcgdGhlIHRv cGljIG9mIEFjdGl2ZSBPQU0gdG8gdGhlIGRpc2N1c3Npb24uIEFzIHRoZSBjb25jZXB0IG9mIEFj dGl2ZSBJT0FNIGlzIGludHJvZHVjZWQgaW4gdGhlDQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtaXBwbS1pb2FtLWZsYWdzIj5JUFBNIFdH IGRyYWZ0PC9hPiZuYnNwO2l0IHNlZW1zIHRvIG1lIGxpa2UgYWRkaW5nIHRoZSBJUFBNIFdHIGNv bW11bml0eSB0byB0aGUgZGlzY3Vzc2lvbiBpcyB0aGUgcmlnaHQgdGhpbmcgdG8gZG8uJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVh c2UgZmluZCBteSBub3RlcyBpbi1saW5lZCBiZWxvdyB1bmRlciB0aGUgR0lNJmd0OyZndDsgdGFn LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5S ZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+R3JlZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBXZWQsIEphbiAyNiwgMjAyMiBhdCAyOjM3IFBNIEhhb3l1IFNvbmcgJmx0OzxhIGhy ZWY9Im1haWx0bzpoYW95dS5zb25nQGZ1dHVyZXdlaS5jb20iPmhhb3l1LnNvbmdAZnV0dXJld2Vp LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIFNQUklORyBXRyw8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlYWwgdGltZSBtb25pdG9yIG9uIGV2ZXJ5IG5vZGUgYW5k IGV2ZXJ5IGxpbmsgb24gYSBuZXR3b3JrIGlzIG5lY2Vzc2FyeSB0byBkZXRlY3QgJm5ic3A7Z3Jh eSBmYWlsdXJlcywgd2hpY2ggYXJlIHRoZSBrZXkgY3VscHJpdCBmb3IgcG9vciBRb1MgYnV0IGhh cmQgdG8gY2F0Y2guIFNSIHByb3ZpZGVzIGFuIGlkZWFsDQogbWVjaGFuaXNtLCB3aGVuIHdvcmtp bmcgd2l0aCBzb21lIGVmZmljaWVudCBwbGFubmluZyBhbGdvcml0aG0sIHRvIGFjaGlldmUgdGhh dCB3aXRoIGxvdyBjb3N0LiAmbmJzcDsmbmJzcDtPdXIgcHJvcG9zYWwgU1J2NiBJbi1zaXR1IEFj dGl2ZSBNZWFzdXJlbWVudCAoU0lBTSkgc3VnZ2VzdHMgYSBzaW1wbGUgJm5ic3A7YWN0aXZlIG1l YXN1cmVtZW50IGFwcHJvYWNoIHdoaWNoIGNhbiBzdXBwb3J0IGRpZmZlcmVudDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5HSU0mZ3Q7Jmd0OyBJIHdvbmRlciB3aGF0IGdhcHMgeW91IGZpbmQgaW4gdGhlIGV4 aXN0aW5nIGFjdGl2ZSBtZWFzdXJlbWVudCBwcm90b2NvbHMsIGUuZy4sIFNUQU1QIGFuZCBSRkMg NjczNCAod291bGQgYmUgbW9yZSBjb252ZW5pZW50IHRvIHVzZSBhbiBhY3JvbnltKS4gSXQgYXBw ZWFycyB0byBtZSB0aGF0LCBmb3IgZXhhbXBsZSwgU1RBTVAgYW5kIGl0cyBleHRlbnNpb25zLCBp bmNsdWRpbmcgdGhlDQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9o dG1sL2RyYWZ0LWlldGYtaXBwbS1zdGFtcC1zcnBtIj5TUlBNIGRyYWZ0PC9hPiwgY29tcHJlaGVu c2l2ZWx5IGFkZHJlc3MgdGhlIFBNIE9BTSByZXF1aXJlbWVudHMgZm9yIFNSdjYuJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+b3B0aW9ucyBvZiBJT0FNIGFuZCBvdGhlciBPQU0gbWV0aG9kcyBpbiBT UnY2LCB3aXRob3V0IG5lZWRpbmcgdG8gd29ycnkgYWJvdXQgdGhlIGV4dGVuc2lvbiBoZWFkZXIg aXNzdWUuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HSU0mZ3Q7Jmd0OyBkcmFmdC1pZXRmLWlw cG0taW9hbS1kYXRhIGNsYXNzaWZpZXMgSU9BTSBhcyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtJ biB0ZXJtcyBvZiB0aGUgY2xhc3NpZmljYXRpb24gZ2l2ZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtpbiBbUkZDNzc5OV0g SU9BTSBjb3VsZCBiZSBwb3J0cmF5ZWQgYXMgSHlicmlkIFR5cGUgMS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG9lcyB5b3VyIHBy b3Bvc2FsIGNoYW5nZSZuYnNwO3RoYXQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBj bSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPllvdXIgY29tbWVudHMsIHF1ZXN0aW9ucywg YW5kIHN1Z2dlc3Rpb25zIGFyZSB2ZXJ5IHdlbGNvbWUuIEnigJlkIGxpa2UgdG8ga25vdyB5b3Vy IG9waW5pb24gaWYgeW91IHRoaW5rIHRoaXMgd29yayBpcyBpbiBzY29wZSBhbmQgc2hvdWxkIGJl IGFkb3B0ZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAuJm5ic3A7IElmIHlvdQ0KIGFyZSBpbnRlcmVz dGVkIGluIGNvbnRyaWJ1dGluZyB0byB0aGlzIHdvcmssIHBsZWFzZSBhbHNvIGxldCBtZSBrbm93 LiA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zb25nLXNw cmluZy1zaWFtLyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtc29uZy1zcHJpbmctc2lhbS88L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5UaGFuayB5b3UgdmVyeSBtdWNoITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QmVz dCByZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IYW95dTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc3ByaW5nIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_97ee51feb17c4bcc84bc575768c06c3ehuaweicom_-- From nobody Wed Jan 26 21:03:40 2022 Return-Path: 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 A62CE3A0E11; Wed, 26 Jan 2022 21:03:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.087 X-Spam-Level: X-Spam-Status: No, score=-7.087 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_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6y_sYAW5ZCR; Wed, 26 Jan 2022 21:03:26 -0800 (PST) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E65C03A0E0D; Wed, 26 Jan 2022 21:03:25 -0800 (PST) Received: by mail-pf1-x436.google.com with SMTP id d187so1605732pfa.10; Wed, 26 Jan 2022 21:03:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dJbK6In1iGONxpEluCIRDpFYMhKDzS2pmPlclWWPC7A=; b=qCpyxOEFjpu5M8ZG0aYfrhegFBh1r0LRyP6p4g+dh/unmLTzgBZqWGuguoCI3KresG /uyJQCJLPhvZm3ZsDXuEztK4lO5IzSoSOXXiHayv/tPStWU4S5f/AVC+R21NPyHOd/hh nHckKK5edFvQtzfgvUdmuXO0RiCl0QCJx2NeF9oe1WZ2VJHrKMO7rb+0+DdaLpFA2O2e wv3PurOEzafw14drW+wv+D3hofCDNDZCckRunO5UU/S0L5ULWwn6BMPslL9hGzgIuSFZ kE++1cAJf4qdOixGxv8n4e6myAbWkQIUfqel2+wbXi/YbAM3ARd5ECOv1gx4DDZbb79A ft0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dJbK6In1iGONxpEluCIRDpFYMhKDzS2pmPlclWWPC7A=; b=lawYk6QF/NrpFVP3lKxYq5yvQKisAScYBtAu8MN/2ASuZZFAiPylHpcD820scTnc9A 2JaUiFdfUH5QWzL30ROpN/b72AMgmDzHkNAtMWmYhwgQq1gTDPkeB3+55ocYlb+sVDbJ Ys47/3KwzqWzXr2G6mSOn4v9lSPL5rNIm92TvVov3ep8RFmOVvsqujCzoGlFa/ptPHa5 tIb+QZrQFEKgHvcyhqJqx7TBBFf6B/nlkyia77BDIupBmsjD1jekoyN3dgnmkDsW0RZ8 tVEWHquJiVXZA8srntWYzM1bSKDZHv/82ufsHq+QKdNuAHEY2eiUVbmgS5+ihfso5q82 d1Cw== X-Gm-Message-State: AOAM533L/grW8jHSw4D0AQIjTgH/otdIchmevqzyJCOP/UJv+vJ3W/hK aHWhRWOJOjJL+V4csW2bC5NTZog2EyNalRM4kho= X-Google-Smtp-Source: ABdhPJxa0SHoLPOJJP64Ikf9ZZW/eVIkvyNFe76vDPwjRfodZbrI4yoBORMnKgrEB8I/OXDJV8Gw/tHngRBwGcxi+1s= X-Received: by 2002:aa7:88c6:: with SMTP id k6mr1965827pff.68.1643259804366; Wed, 26 Jan 2022 21:03:24 -0800 (PST) MIME-Version: 1.0 References: <97ee51feb17c4bcc84bc575768c06c3e@huawei.com> In-Reply-To: <97ee51feb17c4bcc84bc575768c06c3e@huawei.com> From: Gyan Mishra Date: Thu, 27 Jan 2022 00:03:13 -0500 Message-ID: To: Tianran Zhou Cc: Greg Mirsky , Haoyu Song , IETF IPPM WG , "spring@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e9bd3605d6893c67" Archived-At: Subject: Re: [ippm] [spring] Active OAM in SRv6 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2022 05:03:31 -0000 --000000000000e9bd3605d6893c67 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Haoyu I think it would be good to identify the problem statement and gap with existing IPPM WG STAMP, TWAMP PM technologies and why they cannot be utilized or fall short in what you are trying to achieve with Active OAM in SRv6. In-situ IOAM data packets is already possible with SRv6 as mentioned as this draft mentions below as normative reference. https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-data-16 This draft as well mentioned as normative reference draft below provides OAM ping and traceroute with SRH O flag to SRv6 PGM endpoints and SID list tracing capabilities very handy for troubleshooting. https://datatracker.ietf.org/doc/html/draft-ietf-6man-spring-srv6-oam-1 3 This draft as well also mentioned as normative reference draft below provides in-situ IOAM for OAM and PM information can be piggybacked in data packets in SRH TLV SRv6 PGM SIF function SRv6.TLV recording the operational and telemetry info in the data packets. https://datatracker.ietf.org/doc/html/draft-ali-spring-ioam-srv6-05 Thanks Gyan On Wed, Jan 26, 2022 at 10:19 PM Tianran Zhou wrote: > Hi Haoyu, > > > > The application is really interesting and useful. > > I am not sure if it is necessary to create a new OAM protocol at transpor= t > layer. > > IMHO, a per hop/per segment extension based on STAMP could be more > practical. > > https://www.ietf.org/archive/id/draft-wang-ippm-stamp-hbh-extensions-03.t= xt > > > > Best, > > Tianran > > > > *From:* ippm [mailto:ippm-bounces@ietf.org] *On Behalf Of *Greg Mirsky > *Sent:* Thursday, January 27, 2022 7:01 AM > *To:* Haoyu Song > *Cc:* spring@ietf.org; IETF IPPM WG > *Subject:* Re: [ippm] [spring] Active OAM in SRv6 > > > > Hi Haoyu, > > thank you for bringing the topic of Active OAM to the discussion. As the > concept of Active IOAM is introduced in the IPPM WG draft > it > seems to me like adding the IPPM WG community to the discussion is the > right thing to do. > > Please find my notes in-lined below under the GIM>> tag. > > > > Regards, > > Greg > > > > On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song > wrote: > > Hi SPRING WG, > > > > Real time monitor on every node and every link on a network is necessary > to detect gray failures, which are the key culprit for poor QoS but hard > to catch. SR provides an ideal mechanism, when working with some efficien= t > planning algorithm, to achieve that with low cost. Our proposal SRv6 > In-situ Active Measurement (SIAM) suggests a simple active measurement > approach which can support different > > GIM>> I wonder what gaps you find in the existing active measurement > protocols, e.g., STAMP and RFC 6734 (would be more convenient to use an > acronym). It appears to me that, for example, STAMP and its extensions, > including the SRPM draft > , > comprehensively address the PM OAM requirements for SRv6. > > options of IOAM and other OAM methods in SRv6, without needing to worry > about the extension header issue. > > GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows: > > In terms of the classification given > > in [RFC7799] IOAM could be portrayed as Hybrid Type 1. > > Does your proposal change that? > > > > Your comments, questions, and suggestions are very welcome. I=E2=80=99d l= ike to > know your opinion if you think this work is in scope and should be adopte= d > by the working group. If you are interested in contributing to this work= , > please also let me know. > https://datatracker.ietf.org/doc/draft-song-spring-siam/ > > > > Thank you very much! > > > > Best regards, > > Haoyu > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --000000000000e9bd3605d6893c67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
        Hi Haoyu=C2=A0

        I think it would be good to identify the problem statement an= d gap with existing IPPM WG STAMP, TWAMP PM technologies and why they canno= t be utilized or fall short in what you are trying to=C2=A0achieve with Act= ive OAM in SRv6.=C2=A0

        I= n-situ IOAM data packets is already possible with SRv6 as mentioned as this= draft mentions below as normative reference.

        This draft as well mentioned as normative reference draft below provides= OAM ping and traceroute with SRH O flag to SRv6 PGM endpoints and SID list= tracing capabilities very handy for troubleshooting.

        <= /div>

        This d= raft as well also mentioned as normative reference draft below provides in-= situ IOAM for OAM and PM information can be piggybacked in data packets in = SRH TLV SRv6 PGM SIF function SRv6.TLV recording the operational and teleme= try info in the data packets.


        Thanks=C2=A0

        Gyan=C2=A0

        On Wed, Jan 26, 2022 at 10:= 19 PM Tianran Zhou <zhoutianran=3D40huawei.com@dmarc.ietf.org> wrote:

        Hi Haoyu,

        = =C2=A0

        The application is really interesting and us= eful.

        I am not sure if it is necessary to create a= new OAM protocol at transport layer.

        IMHO, a per hop/per segment extension based = on STAMP could be more practical.

        https://www.ietf.org/archive/id/draft-wang-ippm= -stamp-hbh-extensions-03.txt

        = =C2=A0

        Best,

        Tianran =C2=A0

        = =C2=A0

        From: ippm [mailto:ippm-bounces@ietf.or= g] On Behalf Of Greg Mirsky Sent: Thursday, January 27,= 2022 7:01 AM
        To: Haoyu Song <haoyu.song@futurewei.com>
        Cc: spri= ng@ietf.org; IETF IPPM WG <ippm@ietf.org> Subject: Re: [ippm] [spring= ] Active OAM in SRv6

        =C2=A0

        Hi Haoyu,

        thank you for bringing the topic of Active OAM to th= e discussion. As the concept of Active IOAM is introduced in the IPPM WG draft=C2=A0it seems to me like adding the I= PPM WG community to the discussion is the right thing to do.=C2=A0

        Please find my notes in-lined below under the GIM>= ;> tag.

        =C2=A0

        Regards,

        Greg

        =C2=A0

        On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song <haoyu.song@futurew= ei.com> wrote:

        Hi SPRING WG,

        =C2=A0

        Real time monitor on every node and every link on a = network is necessary to detect =C2=A0gray failures, which are the key culpr= it for poor QoS but hard to catch. SR provides an ideal mechanism, when working with some efficient planning algorithm, to achieve= that with low cost. =C2=A0=C2=A0Our proposal SRv6 In-situ Active Measureme= nt (SIAM) suggests a simple =C2=A0active measurement approach which can sup= port different

        GIM>> I wonder what gaps you find in the exist= ing active measurement protocols, e.g., STAMP and RFC 6734 (would be more c= onvenient to use an acronym). It appears to me that, for example, STAMP and= its extensions, including the SRPM draft, comprehensively address the PM OAM requ= irements for SRv6.=C2=A0

        options of IOAM and other OAM methods in SRv6, witho= ut needing to worry about the extension header issue. =C2=A0<= /p>

        GIM>> draft-ietf-ippm-ioam-data classifies IOA= M as follows:

        =C2=A0 =C2=A0In terms of the classification given=

        =C2=A0 =C2=A0in [RFC7799] IOAM could be portrayed as= Hybrid Type 1.

        Does your proposal change=C2=A0that?

        =C2=A0

        Your comments, questions, and suggestions are very w= elcome. I=E2=80=99d like to know your opinion if you think this work is in = scope and should be adopted by the working group.=C2=A0 If you are interested in contributing to this work, please also let me know. https://datatracker.ietf.org/doc/draft-song-spring-siam/<= /p>

        =C2=A0

        Thank you very much!

        =C2=A0

        Best regards,

        Haoyu

        _______________________________________________
        spring mailing list
        spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring

        _______________________________________________
        ippm mailing list
        ippm@ietf.org
        https://www.ietf.org/mailman/listinfo/ippm
        --

        =

        Gyan Mishra

        Network Solutions Architect=C2=A0<= /p>

        Email gyan.s.mishra@ver= izon.com<= br>

        M 301 502-1347


        --000000000000e9bd3605d6893c67-- From nobody Thu Jan 27 01:29:06 2022 Return-Path: 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 DA9AF3A1B36 for ; Thu, 27 Jan 2022 01:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=accedian.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUbbQ5H9VE25 for ; Thu, 27 Jan 2022 01:28:59 -0800 (PST) Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360A73A1B9A for ; Thu, 27 Jan 2022 01:28:53 -0800 (PST) Received: by mail-yb1-xb2c.google.com with SMTP id 23so6743947ybf.7 for ; Thu, 27 Jan 2022 01:28:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=accedian.com; s=corp1; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Wu5+8rXRXimXit5rwWHcLysWhl0r/qmNajOAK2EpxoM=; b=O6XmBxoOuCpwsSG+UyNFkoyE9U1QCx73JKYOkrBLW9Q9Ot6hpkjL8BRc9I1kTXO0Hj 8yHAnMhBhFuq/CVkHg3+zJR8AQwvhAibPC8vcbqcpaI6hAF8NhQn7hM++1aiXJiEOtWJ lVcgTm0ZxqKb5y2hgOFgymfzxNTCXyqg592uIp7gM7WbqXpby5dGeCZmbn7nhI1R7b0c 4UFjV/e6jtj8ozSPz/O7r2q/DO1jcI6ncqqFZATL4hTpsRTJ0DTicSqMXBN+4j5ROC6W xXIVFYD974cn2AmepMHE5YIfrEjAR3g5X+P/0+6d6dzThQZu41EaykFT17D/tghPp4x4 KCLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Wu5+8rXRXimXit5rwWHcLysWhl0r/qmNajOAK2EpxoM=; b=H1hx2KvkECI/HrIaEdxBtUoOKNAXLm+Jajf8cP668KvL/SX97fBvUuumfG3xjVeRlt vAxH10jWoGd4pyA3yrnq0vv03LVYqiQUZpZ0vwIBFJkm2pxG6b/2SXW6wGXqVqcyH8lz 6AGjBFNBnda705TtQ2VXAfxmTkVYtJ6ZqoAEp1CMKdNZoi7qFl/TURErJDm+sQUfCDvK lT1NQIsXwQPykKDIz//T5sZgbtRimkdLjhi+SHydjsAylznoqcdjDN5ht2O+dPbXuc65 nFM7qBpP9+6npVpahYTz7so4aefQMw81f9uCbEwLOnxpxF4j8z2gTwmFKM/lLlXJWH/8 DsvA== X-Gm-Message-State: AOAM533W5ixiB2N/fZaq+oogxmVeTi28jDjNUCpgit8Egj4Hw91vznI2 rFg/GJ9Hg1cRnKc3IE48j1tQKqXhXnu5631a8ZTWMItLiNqxJ/pp8ITO650zzfBqqiQXYqaM1wg gdLOB7dpm/CiDeCh+Ww== X-Google-Smtp-Source: ABdhPJzFhNlblwAQekhf3SRFEB+2tgIsHRyIbFN7FdPxGcJPDn4ZhsxhEjFB1KeHyJ10E/WLzzblx3myRmaoJZpxAL4= X-Received: by 2002:a05:6902:1028:: with SMTP id x8mr2061702ybt.716.1643275731325; Thu, 27 Jan 2022 01:28:51 -0800 (PST) MIME-Version: 1.0 References: <164300504281.12619.16642699818590435984@ietfa.amsl.com> <015a01d81295$fdd37370$f97a5a50$@chinatelecom.cn> <70c388c86215411796ef55d48711b216@huawei.com> <3a33416375314462af22d1837e8472dc@huawei.com> In-Reply-To: <3a33416375314462af22d1837e8472dc@huawei.com> From: Henrik Nydell Date: Thu, 27 Jan 2022 10:28:34 +0100 Message-ID: To: Tianran Zhou Cc: "wangaj3@chinatelecom.cn" , IETF IPPM WG Content-Type: multipart/alternative; boundary="0000000000003bee0a05d68cf297" Archived-At: Subject: Re: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2022 09:29:04 -0000 --0000000000003bee0a05d68cf297 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the clarification, but this "member link validation mechanism" depends fully on configuration between the session sender and the session reflector right? So even if they have agreed that a certain session ID belongs to lag link A, there is no way to be sure that this is the case, the intermediate switches may place these packets randomly over links A-C and the TWAMP/OWAMP sender/reflectors will have no knowledge of this. So I dont know if this addition adds much usefulnes over the already existing capabilities of TWAMP, where you can use the 5-tuple of port-pair, IP-pair and TOS to differentiate session from each other. On Thu, Jan 27, 2022 at 2:37 AM Tianran Zhou wrote= : > Hi Henrik, > > > > Thanks very much for your review. > > Your perspective is absolutely correct. > > This draft is not able to =E2=80=9Cguarantee=E2=80=9D a specific LAG path= . For example, > there is a switch between the two end points, or in the case the reflecto= r > is not capable. > > I.e., as you said, there is no "one method fits all" to guarantee the pat= h. > > > > However, this draft seek another way round, the member link validation > mechanism. > > There is an assumption in the introduction =E2=80=9CThis document intends= to > address the scenario where a LAG directly connects two nodes (A and B).= =E2=80=9D > > With the member link validation, sender/reflector will drop measurement > data, when the test packet is not from the expected member link. > > In this way, the measurement could always be correct. > > > > This is somewhat similar to Paris Traceroute ( > https://paris-traceroute.net/about/), IMHO. > > > > Cheers, > > Tianran > > > > *From:* Henrik Nydell [mailto:hnydell@accedian.com] > *Sent:* Wednesday, January 26, 2022 6:17 PM > *To:* Tianran Zhou > *Cc:* wangaj3@chinatelecom.cn; IETF IPPM WG > *Subject:* Re: [ippm] FW: New Version Notification for > draft-li-ippm-otwamp-on-lag-02.txt > > > > I had a brief review but failed to find details on how the TWAMP sessions > would be "guaranteed" to travel on a certain LAG segment. As far as I kno= w > the LAG implementation may be different between vendors and as such I kno= w > of no "one method fits all" to actually accomplish the measurement. > > > > So this draft does not actually provide any solution to the problem of > being able to measure LAG segments separately and deterministically. > > > > On Wed, Jan 26, 2022 at 11:03 AM Tianran Zhou 40huawei.com@dmarc.ietf.org> wrote: > > Hi Anjun, > > Thanks very much for your interest and comments. > Both are good questions. > Please see in line. > > Cheers, > Tianran > > -----Original Message----- > From: wangaj3@chinatelecom.cn [mailto:wangaj3@chinatelecom.cn] > Sent: Wednesday, January 26, 2022 5:21 PM > To: Tianran Zhou ; 'IETF IPPM WG' > Subject: RE: [ippm] FW: New Version Notification for > draft-li-ippm-otwamp-on-lag-02.txt > > Hi, Tianran: > > Have a brief review of this draft. I think its aim is straightforward and > will be useful to utilize the member link within the LAG. > Some comments are below: > 1) It seems there is no Sender/Reflector behavior description for the > Mirco OWAMP session and the packet format? > > > ZTR> OWAMP is simple and there is no reflector. The sender cannot get the > ack from the receiver. So we are not going to extend the OWAMP test packe= t. > The behavior is described in section 3.2: > " The micro OWAMP Sender MUST send the micro OWAMP-Test packets over the > member link with which the session is associated. When receives a Test > packet, the micro OWAMP receiver MUST use the member link from which the > Test packet is received to correlate the micro OWAMP session. If there is > no such a session, the Test packet MUST be discarded. " > > 2) For the newly defined Session-Sender Packet/Session-Reflector Packet, > how to assure the backward compatibility? What I have seen is that you ad= d > two additional fields within the existing Packet? > > ZTR> I am not aware of the compatibility problem. If a node supports micr= o > session, it can understand the new packet extension. If a node does not > support micro session, it just ignores the new fields. Because the new > fields is in the reserved zone. > Moreover, the validation mechanism can figure out if the reflector can > support the micro session. > > Best Regards > > Aijun Wang > China Telecom > > -----Original Message----- > From: ippm On Behalf Of Tianran Zhou > Sent: Monday, January 24, 2022 2:23 PM > To: IETF IPPM WG (ippm@ietf.org) > Subject: [ippm] FW: New Version Notification for > draft-li-ippm-otwamp-on-lag-02.txt > > Hi WG, > > We think this is an useful work on adapting OWAMP/TWAMP in LAG performanc= e > measurement. > We updated this draft based on the comments from the meeting discussion > and mailing list. > Thanks for all the suggestions. > More reviews and comments are welcome. > > Cheers, > Tianran > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, January 24, 2022 2:17 PM > To: Greg Mirsky ; Guo Jun ; > Jun Guo ; Rakesh Gandhi ; Tianran > Zhou ; Zhenqiang Li > Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt > > > A new version of I-D, draft-li-ippm-otwamp-on-lag-02.txt > has been successfully submitted by Tianran Zhou and posted to the IETF > repository. > > Name: draft-li-ippm-otwamp-on-lag > Revision: 02 > Title: One-way/Two-way Active Measurement Protocol Extensions fo= r > Performance Measurement on LAG > Document date: 2022-01-24 > Group: Individual Submission > Pages: 13 > URL: > https://www.ietf.org/archive/id/draft-li-ippm-otwamp-on-lag-02.txt > Status: > https://datatracker.ietf.org/doc/draft-li-ippm-otwamp-on-lag/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-li-ippm-otwamp-on-lag > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-li-ippm-otwamp-on-lag-02 > > Abstract: > This document defines extensions to One-way Active Measurement > Protocol (OWAMP), and Two-way Active Measurement Protocol (TWAMP) to > implement performance measurement on every member link of a Link > Aggregation Group (LAG). Knowing the measured metrics of each member > link of a LAG enables operators to enforce the performance based > traffic steering policy across the member links. > > > > > > The IETF Secretariat > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > > > > -- > > > *Henrik Nydell* > *Sr Product Manager* > 1.866.685.8181 > hnydell@accedian.com > > > > > *accedian.com * > > > > Avis de confidentialit=C3=A9 > > Les informations contenues dans le pr=C3=A9sent message et dans toute pi= =C3=A8ce qui > lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3= =A9es par le secret > professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de s= on ou de ses > destinataires. Si vous recevez ce message par erreur, veuillez s=E2=80=99= il vous > plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3=A9diteur et en= d=C3=A9truire tout > exemplaire. De plus, il vous est strictement interdit de le divulguer, de > le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80= =99exp=C3=A9diteur. > Merci. > > Confidentiality notice > > This e-mail message and any attachment hereto contain confidential > information which may be privileged and which is intended for the exclusi= ve > use of its addressee(s). If you receive this message in error, please > inform sender immediately and destroy any copy thereof. Furthermore, any > disclosure, distribution or copying of this message and/or any attachment > hereto without the consent of the sender is strictly prohibited. Thank yo= u. > --=20 *Henrik Nydell* *Sr Product Manager* 1.866.685.8181 hnydell@accedian.com *accedian.com * --=20 Avis de confidentialit=C3=A9 Les informations contenues dans le pr=C3=A9sent=20 message et dans toute pi=C3=A8ce qui=20 lui est jointe sont confidentielles et=20 peuvent =C3=AAtre prot=C3=A9g=C3=A9es par le=20 secret professionnel. Ces informations sont=20 =C3=A0 l=E2=80=99usage exclusif de son ou de ses destinataires. Si vous recevez ce=20 message par erreur, veuillez=20 s=E2=80=99il vous plait communiquer imm=C3=A9diatement=20 avec l=E2=80=99exp=C3=A9diteur et en=20 d=C3=A9truire tout exemplaire. De plus, il vous est=20 strictement interdit de=20 le divulguer, de le distribuer ou de le reproduire=20 sans l=E2=80=99autorisation=20 de l=E2=80=99exp=C3=A9diteur. Merci. Confidentiality notice This e-mail message and any attachment hereto contain confidential=20 information=20 which may be privileged and which is intended for the=20 exclusive use of its=20 addressee(s). If you receive this message in error, please inform sender=20 immediately and destroy any copy thereof.=20 Furthermore, any disclosure,=20 distribution or copying of this message=20 and/or any attachment hereto=20 without the consent of the sender is=20 strictly prohibited. Thank you. --0000000000003bee0a05d68cf297 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
        Tha= nks for the clarification, but this "member link validation mechanism&= quot; depends fully on configuration between the session sender and the ses= sion reflector right? So even if they have agreed that a certain session ID= belongs=C2=A0to lag link A, there is no way to be sure that this is the ca= se, the intermediate switches may place these packets randomly over links A= -C and the TWAMP/OWAMP sender/reflectors will have no knowledge of this. So= I dont know if this addition adds much usefulnes over the already existing= capabilities of TWAMP, where you can use the 5-tuple of port-pair, IP-pair= and TOS to differentiate session from each other.
        =C2=A0

        On Thu, Jan 27, 2022 at 2:3= 7 AM Tianran Zhou <zhoutianran= @huawei.com> wrote:

        Hi Henrik,

        =C2=A0

        Thanks very much for your review.<= /u>

        Your perspective is absolutely correct.

        This draft is not able to =E2=80=9Cguarantee= =E2=80=9D a specific LAG path. For example, there is a switch between the t= wo end points, or in the case the reflector is not capable.

        I.e., as you said, there is no "one met= hod fits all" to guarantee the path.

        =C2=A0

        However, this draft seek another way round, = the member link validation mechanism.

        There is an assumption in the introduction = =E2=80=9CThis document intends to address the scenario where a LAG directly= connects two nodes (A and B).=E2=80=9D

        With the member link validation, sender/refl= ector will drop measurement data, when the test packet is not from the expe= cted member link.

        In this way, the measurement could always be= correct.

        =C2=A0

        This is somewhat similar to Paris Traceroute= (https:/= /paris-traceroute.net/about/), IMHO.

        =C2=A0

        Cheers,

        Tianran

        =C2=A0

        From: Henrik Nydell [mailto:hnydell@accedian.com]
        Sent: Wednesday, January 26, 2022 6:17 PM
        To: Tianran Zhou <zhoutianran@huawei.com>
        Cc: wan= gaj3@chinatelecom.cn; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [ippm] FW: New Version Notification for draft-li-ippm-o= twamp-on-lag-02.txt

        =C2=A0

        I had a brief review but failed to find details on h= ow the TWAMP sessions would be "guaranteed" to travel on a certai= n LAG segment. As far as I know the LAG implementation may be different bet= ween vendors and as such I know of no "one method fits all" to actually accomplish the measurement.

        =C2=A0

        So this draft does not actually provide any solution= to the problem of being able to measure LAG segments separately and determ= inistically.

        =C2=A0

        On Wed, Jan 26, 2022 at 11:03 AM Tianran Zhou <zh= outianran=3D40huawei.com@dmarc.ietf.org> wrote:

        Hi Anjun,

        Thanks very much for your interest and comments.
        Both are good questions.
        Please see in line.

        Cheers,
        Tianran

        -----Original Message-----
        From: wangaj3@= chinatelecom.cn [mailto:wangaj3@chinatelecom.cn]
        Sent: Wednesday, January 26, 2022 5:21 PM
        To: Tianran Zhou <zhoutianran@huawei.com>; 'IETF IPPM WG' <ippm@ietf.org>
        Subject: RE: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-o= n-lag-02.txt

        Hi, Tianran:

        Have a brief review of this draft. I think its aim is straightforward and w= ill be useful to utilize the member link within the LAG.
        Some comments are below:
        1) It seems there is no Sender/Reflector behavior description for the Mirco= OWAMP session and the packet format?


        ZTR> OWAMP is simple and there is no reflector. The sender cannot get th= e ack from the receiver. So we are not going to extend the OWAMP test packe= t.
        The behavior is described in section 3.2:
        " The micro OWAMP Sender MUST send the micro OWAMP-Test packets over t= he member link with which the session is associated. When receives a Test p= acket, the micro OWAMP receiver MUST use the member link from which the Tes= t packet is received to correlate the micro OWAMP session. If there is no such a session, the Test packet MUST b= e discarded. "

        2) For the newly defined Session-Sender Packet/Session-Reflector Packet, ho= w to assure the backward compatibility? What I have seen is that you add tw= o additional fields within the existing Packet?

        ZTR> I am not aware of the compatibility problem. If a node supports mic= ro session, it can understand the new packet extension. If a node does not = support micro session, it just ignores the new fields. Because the new fiel= ds is in the reserved zone.
        Moreover, the validation mechanism can figure out if the reflector can supp= ort the micro session.

        Best Regards

        Aijun Wang
        China Telecom

        -----Original Message-----
        From: ippm <i= ppm-bounces@ietf.org> On Behalf Of Tianran Zhou
        Sent: Monday, January 24, 2022 2:23 PM
        To: IETF IPPM WG (ippm@i= etf.org) <ippm@ie= tf.org>
        Subject: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-la= g-02.txt

        Hi WG,

        We think this is an useful work on adapting OWAMP/TWAMP in LAG performance = measurement.
        We updated this draft based on the comments from the meeting discussion and= mailing list.
        Thanks for all the suggestions.
        More reviews and comments are welcome.

        Cheers,
        Tianran

        -----Original Message-----
        From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
        Sent: Monday, January 24, 2022 2:17 PM
        To: Greg Mirsky <gregimirsky@gmail.com>; Guo Jun <guo.jun2@zte.com.cn>; Jun Guo <guo.jun2@zte.com.cn= >; Rakesh Gandhi <r= gandhi@cisco.com>; Tianran Zhou <zhoutianran@huawei.com>; Zhenqiang Li &l= t;li_zhenqian= g@hotmail.com>
        Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

        A new version of I-D, draft-li-ippm-otwamp-on-lag-02.txt
        has been successfully submitted by Tianran Zhou and posted to the IETF repo= sitory.

        Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-li-ippm-otwamp-on-lag Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
        Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 One-way/Two-way Active Measurement= Protocol Extensions for
        Performance Measurement on LAG
        Document date:=C2=A0 2022-01-24
        Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
        Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 13
        URL:
        https://www.ietf.org/archive/id/draft-li-ippm-otwamp-= on-lag-02.txt
        Status:
        https://datatracker.ietf.org/doc/draft-li-ippm-otwamp-on-l= ag/
        Htmlized:
        https://datatracker.ietf.org/doc/html/draft-li-ippm-ot= wamp-on-lag
        Diff:
        https://www.ietf.org/rfcdiff?url2=3Ddraft-li-ippm-otw= amp-on-lag-02

        Abstract:
        =C2=A0 =C2=A0This document defines extensions to One-way Active Measurement=
        =C2=A0 =C2=A0Protocol (OWAMP), and Two-way Active Measurement Protocol (TWA= MP) to
        =C2=A0 =C2=A0implement performance measurement on every member link of a Li= nk
        =C2=A0 =C2=A0Aggregation Group (LAG).=C2=A0 Knowing the measured metrics of= each member
        =C2=A0 =C2=A0link of a LAG enables operators to enforce the performance bas= ed
        =C2=A0 =C2=A0traffic steering policy across the member links.





        The IETF Secretariat


        _______________________________________________
        ippm mailing list
        ippm@ietf.org
        ht= tps://www.ietf.org/mailman/listinfo/ippm

        _______________________________________________
        ippm mailing list
        ippm@ietf.org
        ht= tps://www.ietf.org/mailman/listinfo/ippm


        =C2=A0

        --


        Henrik Nydell
        Sr Product Manager
        1.866.685.8181
        hnydell@accedian.= com

        =C2=A0=C2=A0

        acc= edian.com

        =C2=A0

        Avis de confidentialit=C3= =A9

        Les informations contenue= s dans le pr=C3=A9sent message et dans toute pi=C3=A8ce qui lui est jointe = sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9es par le secret= professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de so= n ou de ses destinataires. Si vous recevez ce message par erreur, veuillez s= =E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3= =A9diteur et en d=C3=A9truire tout exemplaire. De plus, il vous est stricte= ment interdit de le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80=99exp=C3=A9diteur. Merci.=

        Confidentiality notice

        This e-mail message and any attachment h= ereto contain confidential information which may be privileged and which is= intended for the exclusive use of its addressee(s). If you receive this me= ssage in error, please inform sender immediately and destroy any copy thereof. Furthermore, any disclosure, dis= tribution or copying of this message and/or any attachment hereto without t= he consent of the sender is strictly prohibited. Thank you.



        --

        Henrik Nydell
        Sr Product Manager
        1.866.685.8181
        hnydell@accedian.= com
        3D""
        =3D""=C2=A03D""=C2=A03D""
        3D""
        accedian.com=

        Avis de confidentialit=C3=A9

        Les informations contenues dans le pr=C3=A9sent message et dans toute pi=C3=A8= ce qui=20 lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9e= s par le=20 secret professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif= de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez=20 s=E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp= =C3=A9diteur et en=20 d=C3=A9truire tout exemplaire. De plus, il vous est strictement interdit de= =20 le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisat= ion=20 de l=E2=80=99exp=C3=A9diteur. Merci.

        Confidentiality notice

        This e-mail message and any attachment hereto contain confidential=20 information which may be privileged and which is intended for the=20 exclusive use of its addressee(s). If you receive this message in error, please inform sender immediately and destroy any copy thereof.=20 Furthermore, any disclosure, distribution or copying of this message=20 and/or any attachment hereto without the consent of the sender is=20 strictly prohibited. Thank you.

        --0000000000003bee0a05d68cf297-- From nobody Thu Jan 27 01:48:58 2022 Return-Path: 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 5379B3A1C23 for ; Thu, 27 Jan 2022 01:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.886 X-Spam-Level: X-Spam-Status: No, score=-6.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOx08aehqpoY for ; Thu, 27 Jan 2022 01:48:52 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F04823A1C21 for ; Thu, 27 Jan 2022 01:48:51 -0800 (PST) Received: from fraeml737-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JkwgL6gwVz6GDHF for ; Thu, 27 Jan 2022 17:45:18 +0800 (CST) Received: from kwepeml500003.china.huawei.com (7.221.188.182) by fraeml737-chm.china.huawei.com (10.206.15.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Thu, 27 Jan 2022 10:48:49 +0100 Received: from kwepeml500004.china.huawei.com (7.221.188.141) by kwepeml500003.china.huawei.com (7.221.188.182) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Thu, 27 Jan 2022 17:48:47 +0800 Received: from kwepeml500004.china.huawei.com ([7.221.188.141]) by kwepeml500004.china.huawei.com ([7.221.188.141]) with mapi id 15.01.2308.021; Thu, 27 Jan 2022 17:48:47 +0800 From: Tianran Zhou To: Henrik Nydell CC: "wangaj3@chinatelecom.cn" , IETF IPPM WG Thread-Topic: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt Thread-Index: AQHYEOoOM8BWGUje9EistfVjjUvI2qxxspuggALRbQCAAI1nUP//gkoAgAF/fcCAAAVcAIAAidVA Date: Thu, 27 Jan 2022 09:48:47 +0000 Message-ID: <26d83b5f046a439785f52d9599209c95@huawei.com> References: <164300504281.12619.16642699818590435984@ietfa.amsl.com> <015a01d81295$fdd37370$f97a5a50$@chinatelecom.cn> <70c388c86215411796ef55d48711b216@huawei.com> <3a33416375314462af22d1837e8472dc@huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.112.40.195] Content-Type: multipart/alternative; boundary="_000_26d83b5f046a439785f52d9599209c95huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2022 09:48:57 -0000 --_000_26d83b5f046a439785f52d9599209c95huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSGVucmlrLA0KDQpCb3RoIHNlbmRlciBhbmQgcmVmbGVjdG9yIGtlZXAgdGhlIG1hcHBpbmcg YmV0d2VlbiBtZW1iZXIgbGluayBhbmQgdGhlIG1pY3JvIHNlc3Npb24uIEVpdGhlciBieSBjb25m aWd1cmF0aW9uIG9yIG5lZ290aWF0aW9uIG9yIGF1dG8tbGVhcm5pbmcuDQpTbywgaW4geW91ciBz d2l0Y2ggY2FzZSwgaWYgdGhlIHNlbmRlciByZWNlaXZlcyB0aGUgcGFja2V0IGZyb20gQywgbm90 IEEsIHRoZSBzZW5kZXIga25vdyBpdOKAmXMgd3JvbmcuIFRoZSB0ZXN0IHBhY2tldCBzaG91bGQg YmUgZHJvcHBlZCBhbmQgbm90IGNvdW50ZWQuDQoNCkJlc3QsDQpUaWFucmFuDQpGcm9tOiBIZW5y aWsgTnlkZWxsIFttYWlsdG86aG55ZGVsbEBhY2NlZGlhbi5jb21dDQpTZW50OiBUaHVyc2RheSwg SmFudWFyeSAyNywgMjAyMiA1OjI5IFBNDQpUbzogVGlhbnJhbiBaaG91IDx6aG91dGlhbnJhbkBo dWF3ZWkuY29tPg0KQ2M6IHdhbmdhajNAY2hpbmF0ZWxlY29tLmNuOyBJRVRGIElQUE0gV0cgPGlw cG1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2lwcG1dIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LWxpLWlwcG0tb3R3YW1wLW9uLWxhZy0wMi50eHQNCg0KVGhhbmtzIGZv ciB0aGUgY2xhcmlmaWNhdGlvbiwgYnV0IHRoaXMgIm1lbWJlciBsaW5rIHZhbGlkYXRpb24gbWVj aGFuaXNtIiBkZXBlbmRzIGZ1bGx5IG9uIGNvbmZpZ3VyYXRpb24gYmV0d2VlbiB0aGUgc2Vzc2lv biBzZW5kZXIgYW5kIHRoZSBzZXNzaW9uIHJlZmxlY3RvciByaWdodD8gU28gZXZlbiBpZiB0aGV5 IGhhdmUgYWdyZWVkIHRoYXQgYSBjZXJ0YWluIHNlc3Npb24gSUQgYmVsb25ncyB0byBsYWcgbGlu ayBBLCB0aGVyZSBpcyBubyB3YXkgdG8gYmUgc3VyZSB0aGF0IHRoaXMgaXMgdGhlIGNhc2UsIHRo ZSBpbnRlcm1lZGlhdGUgc3dpdGNoZXMgbWF5IHBsYWNlIHRoZXNlIHBhY2tldHMgcmFuZG9tbHkg b3ZlciBsaW5rcyBBLUMgYW5kIHRoZSBUV0FNUC9PV0FNUCBzZW5kZXIvcmVmbGVjdG9ycyB3aWxs IGhhdmUgbm8ga25vd2xlZGdlIG9mIHRoaXMuIFNvIEkgZG9udCBrbm93IGlmIHRoaXMgYWRkaXRp b24gYWRkcyBtdWNoIHVzZWZ1bG5lcyBvdmVyIHRoZSBhbHJlYWR5IGV4aXN0aW5nIGNhcGFiaWxp dGllcyBvZiBUV0FNUCwgd2hlcmUgeW91IGNhbiB1c2UgdGhlIDUtdHVwbGUgb2YgcG9ydC1wYWly LCBJUC1wYWlyIGFuZCBUT1MgdG8gZGlmZmVyZW50aWF0ZSBzZXNzaW9uIGZyb20gZWFjaCBvdGhl ci4NCg0KDQpPbiBUaHUsIEphbiAyNywgMjAyMiBhdCAyOjM3IEFNIFRpYW5yYW4gWmhvdSA8emhv dXRpYW5yYW5AaHVhd2VpLmNvbTxtYWlsdG86emhvdXRpYW5yYW5AaHVhd2VpLmNvbT4+IHdyb3Rl Og0KSGkgSGVucmlrLA0KDQpUaGFua3MgdmVyeSBtdWNoIGZvciB5b3VyIHJldmlldy4NCllvdXIg cGVyc3BlY3RpdmUgaXMgYWJzb2x1dGVseSBjb3JyZWN0Lg0KVGhpcyBkcmFmdCBpcyBub3QgYWJs ZSB0byDigJxndWFyYW50ZWXigJ0gYSBzcGVjaWZpYyBMQUcgcGF0aC4gRm9yIGV4YW1wbGUsIHRo ZXJlIGlzIGEgc3dpdGNoIGJldHdlZW4gdGhlIHR3byBlbmQgcG9pbnRzLCBvciBpbiB0aGUgY2Fz ZSB0aGUgcmVmbGVjdG9yIGlzIG5vdCBjYXBhYmxlLg0KSS5lLiwgYXMgeW91IHNhaWQsIHRoZXJl IGlzIG5vICJvbmUgbWV0aG9kIGZpdHMgYWxsIiB0byBndWFyYW50ZWUgdGhlIHBhdGguDQoNCkhv d2V2ZXIsIHRoaXMgZHJhZnQgc2VlayBhbm90aGVyIHdheSByb3VuZCwgdGhlIG1lbWJlciBsaW5r IHZhbGlkYXRpb24gbWVjaGFuaXNtLg0KVGhlcmUgaXMgYW4gYXNzdW1wdGlvbiBpbiB0aGUgaW50 cm9kdWN0aW9uIOKAnFRoaXMgZG9jdW1lbnQgaW50ZW5kcyB0byBhZGRyZXNzIHRoZSBzY2VuYXJp byB3aGVyZSBhIExBRyBkaXJlY3RseSBjb25uZWN0cyB0d28gbm9kZXMgKEEgYW5kIEIpLuKAnQ0K V2l0aCB0aGUgbWVtYmVyIGxpbmsgdmFsaWRhdGlvbiwgc2VuZGVyL3JlZmxlY3RvciB3aWxsIGRy b3AgbWVhc3VyZW1lbnQgZGF0YSwgd2hlbiB0aGUgdGVzdCBwYWNrZXQgaXMgbm90IGZyb20gdGhl IGV4cGVjdGVkIG1lbWJlciBsaW5rLg0KSW4gdGhpcyB3YXksIHRoZSBtZWFzdXJlbWVudCBjb3Vs ZCBhbHdheXMgYmUgY29ycmVjdC4NCg0KVGhpcyBpcyBzb21ld2hhdCBzaW1pbGFyIHRvIFBhcmlz IFRyYWNlcm91dGUgKGh0dHBzOi8vcGFyaXMtdHJhY2Vyb3V0ZS5uZXQvYWJvdXQvKSwgSU1ITy4N Cg0KQ2hlZXJzLA0KVGlhbnJhbg0KDQpGcm9tOiBIZW5yaWsgTnlkZWxsIFttYWlsdG86aG55ZGVs bEBhY2NlZGlhbi5jb208bWFpbHRvOmhueWRlbGxAYWNjZWRpYW4uY29tPl0NClNlbnQ6IFdlZG5l c2RheSwgSmFudWFyeSAyNiwgMjAyMiA2OjE3IFBNDQpUbzogVGlhbnJhbiBaaG91IDx6aG91dGlh bnJhbkBodWF3ZWkuY29tPG1haWx0bzp6aG91dGlhbnJhbkBodWF3ZWkuY29tPj4NCkNjOiB3YW5n YWozQGNoaW5hdGVsZWNvbS5jbjxtYWlsdG86d2FuZ2FqM0BjaGluYXRlbGVjb20uY24+OyBJRVRG IElQUE0gV0cgPGlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+Pg0KU3ViamVjdDog UmU6IFtpcHBtXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saS1pcHBt LW90d2FtcC1vbi1sYWctMDIudHh0DQoNCkkgaGFkIGEgYnJpZWYgcmV2aWV3IGJ1dCBmYWlsZWQg dG8gZmluZCBkZXRhaWxzIG9uIGhvdyB0aGUgVFdBTVAgc2Vzc2lvbnMgd291bGQgYmUgImd1YXJh bnRlZWQiIHRvIHRyYXZlbCBvbiBhIGNlcnRhaW4gTEFHIHNlZ21lbnQuIEFzIGZhciBhcyBJIGtu b3cgdGhlIExBRyBpbXBsZW1lbnRhdGlvbiBtYXkgYmUgZGlmZmVyZW50IGJldHdlZW4gdmVuZG9y cyBhbmQgYXMgc3VjaCBJIGtub3cgb2Ygbm8gIm9uZSBtZXRob2QgZml0cyBhbGwiIHRvIGFjdHVh bGx5IGFjY29tcGxpc2ggdGhlIG1lYXN1cmVtZW50Lg0KDQpTbyB0aGlzIGRyYWZ0IGRvZXMgbm90 IGFjdHVhbGx5IHByb3ZpZGUgYW55IHNvbHV0aW9uIHRvIHRoZSBwcm9ibGVtIG9mIGJlaW5nIGFi bGUgdG8gbWVhc3VyZSBMQUcgc2VnbWVudHMgc2VwYXJhdGVseSBhbmQgZGV0ZXJtaW5pc3RpY2Fs bHkuDQoNCk9uIFdlZCwgSmFuIDI2LCAyMDIyIGF0IDExOjAzIEFNIFRpYW5yYW4gWmhvdSA8emhv dXRpYW5yYW49NDBodWF3ZWkuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGh1YXdlaS5jb21A ZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCkhpIEFuanVuLA0KDQpUaGFua3MgdmVyeSBtdWNoIGZv ciB5b3VyIGludGVyZXN0IGFuZCBjb21tZW50cy4NCkJvdGggYXJlIGdvb2QgcXVlc3Rpb25zLg0K UGxlYXNlIHNlZSBpbiBsaW5lLg0KDQpDaGVlcnMsDQpUaWFucmFuDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiB3YW5nYWozQGNoaW5hdGVsZWNvbS5jbjxtYWlsdG86d2FuZ2Fq M0BjaGluYXRlbGVjb20uY24+IFttYWlsdG86d2FuZ2FqM0BjaGluYXRlbGVjb20uY248bWFpbHRv OndhbmdhajNAY2hpbmF0ZWxlY29tLmNuPl0NClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyNiwg MjAyMiA1OjIxIFBNDQpUbzogVGlhbnJhbiBaaG91IDx6aG91dGlhbnJhbkBodWF3ZWkuY29tPG1h aWx0bzp6aG91dGlhbnJhbkBodWF3ZWkuY29tPj47ICdJRVRGIElQUE0gV0cnIDxpcHBtQGlldGYu b3JnPG1haWx0bzppcHBtQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBbaXBwbV0gRlc6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGktaXBwbS1vdHdhbXAtb24tbGFnLTAyLnR4 dA0KDQpIaSwgVGlhbnJhbjoNCg0KSGF2ZSBhIGJyaWVmIHJldmlldyBvZiB0aGlzIGRyYWZ0LiBJ IHRoaW5rIGl0cyBhaW0gaXMgc3RyYWlnaHRmb3J3YXJkIGFuZCB3aWxsIGJlIHVzZWZ1bCB0byB1 dGlsaXplIHRoZSBtZW1iZXIgbGluayB3aXRoaW4gdGhlIExBRy4NClNvbWUgY29tbWVudHMgYXJl IGJlbG93Og0KMSkgSXQgc2VlbXMgdGhlcmUgaXMgbm8gU2VuZGVyL1JlZmxlY3RvciBiZWhhdmlv ciBkZXNjcmlwdGlvbiBmb3IgdGhlIE1pcmNvIE9XQU1QIHNlc3Npb24gYW5kIHRoZSBwYWNrZXQg Zm9ybWF0Pw0KDQoNClpUUj4gT1dBTVAgaXMgc2ltcGxlIGFuZCB0aGVyZSBpcyBubyByZWZsZWN0 b3IuIFRoZSBzZW5kZXIgY2Fubm90IGdldCB0aGUgYWNrIGZyb20gdGhlIHJlY2VpdmVyLiBTbyB3 ZSBhcmUgbm90IGdvaW5nIHRvIGV4dGVuZCB0aGUgT1dBTVAgdGVzdCBwYWNrZXQuDQpUaGUgYmVo YXZpb3IgaXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gMy4yOg0KIiBUaGUgbWljcm8gT1dBTVAgU2Vu ZGVyIE1VU1Qgc2VuZCB0aGUgbWljcm8gT1dBTVAtVGVzdCBwYWNrZXRzIG92ZXIgdGhlIG1lbWJl ciBsaW5rIHdpdGggd2hpY2ggdGhlIHNlc3Npb24gaXMgYXNzb2NpYXRlZC4gV2hlbiByZWNlaXZl cyBhIFRlc3QgcGFja2V0LCB0aGUgbWljcm8gT1dBTVAgcmVjZWl2ZXIgTVVTVCB1c2UgdGhlIG1l bWJlciBsaW5rIGZyb20gd2hpY2ggdGhlIFRlc3QgcGFja2V0IGlzIHJlY2VpdmVkIHRvIGNvcnJl bGF0ZSB0aGUgbWljcm8gT1dBTVAgc2Vzc2lvbi4gSWYgdGhlcmUgaXMgbm8gc3VjaCBhIHNlc3Np b24sIHRoZSBUZXN0IHBhY2tldCBNVVNUIGJlIGRpc2NhcmRlZC4gIg0KDQoyKSBGb3IgdGhlIG5l d2x5IGRlZmluZWQgU2Vzc2lvbi1TZW5kZXIgUGFja2V0L1Nlc3Npb24tUmVmbGVjdG9yIFBhY2tl dCwgaG93IHRvIGFzc3VyZSB0aGUgYmFja3dhcmQgY29tcGF0aWJpbGl0eT8gV2hhdCBJIGhhdmUg c2VlbiBpcyB0aGF0IHlvdSBhZGQgdHdvIGFkZGl0aW9uYWwgZmllbGRzIHdpdGhpbiB0aGUgZXhp c3RpbmcgUGFja2V0Pw0KDQpaVFI+IEkgYW0gbm90IGF3YXJlIG9mIHRoZSBjb21wYXRpYmlsaXR5 IHByb2JsZW0uIElmIGEgbm9kZSBzdXBwb3J0cyBtaWNybyBzZXNzaW9uLCBpdCBjYW4gdW5kZXJz dGFuZCB0aGUgbmV3IHBhY2tldCBleHRlbnNpb24uIElmIGEgbm9kZSBkb2VzIG5vdCBzdXBwb3J0 IG1pY3JvIHNlc3Npb24sIGl0IGp1c3QgaWdub3JlcyB0aGUgbmV3IGZpZWxkcy4gQmVjYXVzZSB0 aGUgbmV3IGZpZWxkcyBpcyBpbiB0aGUgcmVzZXJ2ZWQgem9uZS4NCk1vcmVvdmVyLCB0aGUgdmFs aWRhdGlvbiBtZWNoYW5pc20gY2FuIGZpZ3VyZSBvdXQgaWYgdGhlIHJlZmxlY3RvciBjYW4gc3Vw cG9ydCB0aGUgbWljcm8gc2Vzc2lvbi4NCg0KQmVzdCBSZWdhcmRzDQoNCkFpanVuIFdhbmcNCkNo aW5hIFRlbGVjb20NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlwcG0gPGlw cG0tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aXBwbS1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVo YWxmIE9mIFRpYW5yYW4gWmhvdQ0KU2VudDogTW9uZGF5LCBKYW51YXJ5IDI0LCAyMDIyIDI6MjMg UE0NClRvOiBJRVRGIElQUE0gV0cgKGlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+ KSA8aXBwbUBpZXRmLm9yZzxtYWlsdG86aXBwbUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBbaXBwbV0g Rlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGktaXBwbS1vdHdhbXAtb24t bGFnLTAyLnR4dA0KDQpIaSBXRywNCg0KV2UgdGhpbmsgdGhpcyBpcyBhbiB1c2VmdWwgd29yayBv biBhZGFwdGluZyBPV0FNUC9UV0FNUCBpbiBMQUcgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQuDQpX ZSB1cGRhdGVkIHRoaXMgZHJhZnQgYmFzZWQgb24gdGhlIGNvbW1lbnRzIGZyb20gdGhlIG1lZXRp bmcgZGlzY3Vzc2lvbiBhbmQgbWFpbGluZyBsaXN0Lg0KVGhhbmtzIGZvciBhbGwgdGhlIHN1Z2dl c3Rpb25zLg0KTW9yZSByZXZpZXdzIGFuZCBjb21tZW50cyBhcmUgd2VsY29tZS4NCg0KQ2hlZXJz LA0KVGlhbnJhbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IFttYWlsdG86 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+ XQ0KU2VudDogTW9uZGF5LCBKYW51YXJ5IDI0LCAyMDIyIDI6MTcgUE0NClRvOiBHcmVnIE1pcnNr eSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPG1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20+Pjsg R3VvIEp1biA8Z3VvLmp1bjJAenRlLmNvbS5jbjxtYWlsdG86Z3VvLmp1bjJAenRlLmNvbS5jbj4+ OyBKdW4gR3VvIDxndW8uanVuMkB6dGUuY29tLmNuPG1haWx0bzpndW8uanVuMkB6dGUuY29tLmNu Pj47IFJha2VzaCBHYW5kaGkgPHJnYW5kaGlAY2lzY28uY29tPG1haWx0bzpyZ2FuZGhpQGNpc2Nv LmNvbT4+OyBUaWFucmFuIFpob3UgPHpob3V0aWFucmFuQGh1YXdlaS5jb208bWFpbHRvOnpob3V0 aWFucmFuQGh1YXdlaS5jb20+PjsgWmhlbnFpYW5nIExpIDxsaV96aGVucWlhbmdAaG90bWFpbC5j b208bWFpbHRvOmxpX3poZW5xaWFuZ0Bob3RtYWlsLmNvbT4+DQpTdWJqZWN0OiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpLWlwcG0tb3R3YW1wLW9uLWxhZy0wMi50eHQNCg0K DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGktaXBwbS1vdHdhbXAtb24tbGFnLTAyLnR4 dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBUaWFucmFuIFpob3UgYW5kIHBv c3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgICAgZHJhZnQtbGkt aXBwbS1vdHdhbXAtb24tbGFnDQpSZXZpc2lvbjogICAgICAgMDINClRpdGxlOiAgICAgICAgICBP bmUtd2F5L1R3by13YXkgQWN0aXZlIE1lYXN1cmVtZW50IFByb3RvY29sIEV4dGVuc2lvbnMgZm9y DQpQZXJmb3JtYW5jZSBNZWFzdXJlbWVudCBvbiBMQUcNCkRvY3VtZW50IGRhdGU6ICAyMDIyLTAx LTI0DQpHcm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAg ICAgMTMNClVSTDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtbGktaXBw bS1vdHdhbXAtb24tbGFnLTAyLnR4dA0KU3RhdHVzOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtbGktaXBwbS1vdHdhbXAtb24tbGFnLw0KSHRtbGl6ZWQ6DQpodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWxpLWlwcG0tb3R3YW1wLW9uLWxh Zw0KRGlmZjoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1saS1pcHBt LW90d2FtcC1vbi1sYWctMDINCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMg ZXh0ZW5zaW9ucyB0byBPbmUtd2F5IEFjdGl2ZSBNZWFzdXJlbWVudA0KICAgUHJvdG9jb2wgKE9X QU1QKSwgYW5kIFR3by13YXkgQWN0aXZlIE1lYXN1cmVtZW50IFByb3RvY29sIChUV0FNUCkgdG8N CiAgIGltcGxlbWVudCBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudCBvbiBldmVyeSBtZW1iZXIgbGlu ayBvZiBhIExpbmsNCiAgIEFnZ3JlZ2F0aW9uIEdyb3VwIChMQUcpLiAgS25vd2luZyB0aGUgbWVh c3VyZWQgbWV0cmljcyBvZiBlYWNoIG1lbWJlcg0KICAgbGluayBvZiBhIExBRyBlbmFibGVzIG9w ZXJhdG9ycyB0byBlbmZvcmNlIHRoZSBwZXJmb3JtYW5jZSBiYXNlZA0KICAgdHJhZmZpYyBzdGVl cmluZyBwb2xpY3kgYWNyb3NzIHRoZSBtZW1iZXIgbGlua3MuDQoNCg0KDQoNCg0KVGhlIElFVEYg U2VjcmV0YXJpYXQNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KaXBwbSBtYWlsaW5nIGxpc3QNCmlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0NCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmlwcG0gbWFpbGlu ZyBsaXN0DQppcHBtQGlldGYub3JnPG1haWx0bzppcHBtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtDQoNCg0KLS0NCg0KSGVucmlrIE55ZGVsbA0K U3IgUHJvZHVjdCBNYW5hZ2VyDQoxLjg2Ni42ODUuODE4MQ0KaG55ZGVsbEBhY2NlZGlhbi5jb208 bWFpbHRvOmhueWRlbGxAYWNjZWRpYW4uY29tPg0KW2h0dHBzOi8vaS54aW5rLmlvL0ltYWdlcy9H ZXQvTjYzODMyL2E2NS5wbmddPGh0dHA6Ly9hY2NlZGlhbi5jb20+DQpbaHR0cHM6Ly9pLnhpbmsu aW8vSW1hZ2VzL0dldC9ONjM4MzIvZjk3LnBuZ108aHR0cHM6Ly93d3cuZmFjZWJvb2suY29tL2Fj Y2VkaWFuLz4gW2h0dHBzOi8vaS54aW5rLmlvL0ltYWdlcy9HZXQvTjYzODMyL3Q5OS5wbmddIDxo dHRwczovL3R3aXR0ZXIuY29tL0FjY2VkaWFuPiAgW2h0dHBzOi8vaS54aW5rLmlvL0ltYWdlcy9H ZXQvTjYzODMyL2w1NC5wbmddIDxodHRwczovL2NhLmxpbmtlZGluLmNvbS9jb21wYW55L2FjY2Vk aWFuPg0KPGh0dHA6Ly93d3cuYWNjZWRpYW4uY29tPg0KYWNjZWRpYW4uY29tPGh0dHA6Ly9hY2Nl ZGlhbi5jb20+DQoNCg0KQXZpcyBkZSBjb25maWRlbnRpYWxpdMOpDQoNCkxlcyBpbmZvcm1hdGlv bnMgY29udGVudWVzIGRhbnMgbGUgcHLDqXNlbnQgbWVzc2FnZSBldCBkYW5zIHRvdXRlIHBpw6hj ZSBxdWkgbHVpIGVzdCBqb2ludGUgc29udCBjb25maWRlbnRpZWxsZXMgZXQgcGV1dmVudCDDqnRy ZSBwcm90w6lnw6llcyBwYXIgbGUgc2VjcmV0IHByb2Zlc3Npb25uZWwuIENlcyBpbmZvcm1hdGlv bnMgc29udCDDoCBs4oCZdXNhZ2UgZXhjbHVzaWYgZGUgc29uIG91IGRlIHNlcyBkZXN0aW5hdGFp cmVzLiBTaSB2b3VzIHJlY2V2ZXogY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBz4oCZ aWwgdm91cyBwbGFpdCBjb21tdW5pcXVlciBpbW3DqWRpYXRlbWVudCBhdmVjIGzigJlleHDDqWRp dGV1ciBldCBlbiBkw6l0cnVpcmUgdG91dCBleGVtcGxhaXJlLiBEZSBwbHVzLCBpbCB2b3VzIGVz dCBzdHJpY3RlbWVudCBpbnRlcmRpdCBkZSBsZSBkaXZ1bGd1ZXIsIGRlIGxlIGRpc3RyaWJ1ZXIg b3UgZGUgbGUgcmVwcm9kdWlyZSBzYW5zIGzigJlhdXRvcmlzYXRpb24gZGUgbOKAmWV4cMOpZGl0 ZXVyLiBNZXJjaS4NCg0KQ29uZmlkZW50aWFsaXR5IG5vdGljZQ0KDQpUaGlzIGUtbWFpbCBtZXNz YWdlIGFuZCBhbnkgYXR0YWNobWVudCBoZXJldG8gY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3Jt YXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgYW5kIHdoaWNoIGlzIGludGVuZGVkIGZvciB0 aGUgZXhjbHVzaXZlIHVzZSBvZiBpdHMgYWRkcmVzc2VlKHMpLiBJZiB5b3UgcmVjZWl2ZSB0aGlz IG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBpbmZvcm0gc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBk ZXN0cm95IGFueSBjb3B5IHRoZXJlb2YuIEZ1cnRoZXJtb3JlLCBhbnkgZGlzY2xvc3VyZSwgZGlz dHJpYnV0aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBtZXNzYWdlIGFuZC9vciBhbnkgYXR0YWNobWVu dCBoZXJldG8gd2l0aG91dCB0aGUgY29uc2VudCBvZiB0aGUgc2VuZGVyIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQuIFRoYW5rIHlvdS4NCg0KDQotLQ0KDQpIZW5yaWsgTnlkZWxsDQpTciBQcm9kdWN0 IE1hbmFnZXINCjEuODY2LjY4NS44MTgxDQpobnlkZWxsQGFjY2VkaWFuLmNvbTxtYWlsdG86aG55 ZGVsbEBhY2NlZGlhbi5jb20+DQpbaHR0cHM6Ly9pLnhpbmsuaW8vSW1hZ2VzL0dldC9ONjM4MzIv YTY1LnBuZ108aHR0cDovL2FjY2VkaWFuLmNvbT4NCltodHRwczovL2kueGluay5pby9JbWFnZXMv R2V0L042MzgzMi9mOTcucG5nXTxodHRwczovL3d3dy5mYWNlYm9vay5jb20vYWNjZWRpYW4vPiBb aHR0cHM6Ly9pLnhpbmsuaW8vSW1hZ2VzL0dldC9ONjM4MzIvdDk5LnBuZ10gPGh0dHBzOi8vdHdp dHRlci5jb20vQWNjZWRpYW4+ICBbaHR0cHM6Ly9pLnhpbmsuaW8vSW1hZ2VzL0dldC9ONjM4MzIv bDU0LnBuZ10gPGh0dHBzOi8vY2EubGlua2VkaW4uY29tL2NvbXBhbnkvYWNjZWRpYW4+DQo8aHR0 cDovL3d3dy5hY2NlZGlhbi5jb20+DQphY2NlZGlhbi5jb208aHR0cDovL2FjY2VkaWFuLmNvbT4N Cg0KDQpBdmlzIGRlIGNvbmZpZGVudGlhbGl0w6kNCg0KTGVzIGluZm9ybWF0aW9ucyBjb250ZW51 ZXMgZGFucyBsZSBwcsOpc2VudCBtZXNzYWdlIGV0IGRhbnMgdG91dGUgcGnDqGNlIHF1aSBsdWkg ZXN0IGpvaW50ZSBzb250IGNvbmZpZGVudGllbGxlcyBldCBwZXV2ZW50IMOqdHJlIHByb3TDqWfD qWVzIHBhciBsZSBzZWNyZXQgcHJvZmVzc2lvbm5lbC4gQ2VzIGluZm9ybWF0aW9ucyBzb250IMOg IGzigJl1c2FnZSBleGNsdXNpZiBkZSBzb24gb3UgZGUgc2VzIGRlc3RpbmF0YWlyZXMuIFNpIHZv dXMgcmVjZXZleiBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IHPigJlpbCB2b3VzIHBs YWl0IGNvbW11bmlxdWVyIGltbcOpZGlhdGVtZW50IGF2ZWMgbOKAmWV4cMOpZGl0ZXVyIGV0IGVu IGTDqXRydWlyZSB0b3V0IGV4ZW1wbGFpcmUuIERlIHBsdXMsIGlsIHZvdXMgZXN0IHN0cmljdGVt ZW50IGludGVyZGl0IGRlIGxlIGRpdnVsZ3VlciwgZGUgbGUgZGlzdHJpYnVlciBvdSBkZSBsZSBy ZXByb2R1aXJlIHNhbnMgbOKAmWF1dG9yaXNhdGlvbiBkZSBs4oCZZXhww6lkaXRldXIuIE1lcmNp Lg0KDQpDb25maWRlbnRpYWxpdHkgbm90aWNlDQoNClRoaXMgZS1tYWlsIG1lc3NhZ2UgYW5kIGFu eSBhdHRhY2htZW50IGhlcmV0byBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiB3aGlj aCBtYXkgYmUgcHJpdmlsZWdlZCBhbmQgd2hpY2ggaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNp dmUgdXNlIG9mIGl0cyBhZGRyZXNzZWUocykuIElmIHlvdSByZWNlaXZlIHRoaXMgbWVzc2FnZSBp biBlcnJvciwgcGxlYXNlIGluZm9ybSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRlc3Ryb3kgYW55 IGNvcHkgdGhlcmVvZi4gRnVydGhlcm1vcmUsIGFueSBkaXNjbG9zdXJlLCBkaXN0cmlidXRpb24g b3IgY29weWluZyBvZiB0aGlzIG1lc3NhZ2UgYW5kL29yIGFueSBhdHRhY2htZW50IGhlcmV0byB3 aXRob3V0IHRoZSBjb25zZW50IG9mIHRoZSBzZW5kZXIgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4g VGhhbmsgeW91Lg0K --_000_26d83b5f046a439785f52d9599209c95huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4w cHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEhlbnJpayw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJvdGggc2VuZGVyIGFuZCByZWZsZWN0 b3Iga2VlcCB0aGUgbWFwcGluZyBiZXR3ZWVuIG1lbWJlciBsaW5rIGFuZCB0aGUgbWljcm8gc2Vz c2lvbi4gRWl0aGVyIGJ5IGNvbmZpZ3VyYXRpb24gb3IgbmVnb3RpYXRpb24gb3IgYXV0by1sZWFy bmluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U28sIGluIHlvdXIgc3dpdGNoIGNhc2UsIGlmIHRoZSBz ZW5kZXIgcmVjZWl2ZXMgdGhlIHBhY2tldCBmcm9tIEMsIG5vdCBBLCB0aGUgc2VuZGVyIGtub3cg aXTigJlzIHdyb25nLiBUaGUgdGVzdCBwYWNrZXQgc2hvdWxkIGJlIGRyb3BwZWQgYW5kIG5vdCBj b3VudGVkLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CZXN0 LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5UaWFucmFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4gSGVucmlrIE55ZGVsbCBbbWFpbHRvOmhueWRlbGxAYWNjZWRpYW4uY29tXQ0K PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKYW51YXJ5IDI3LCAyMDIyIDU6MjkgUE08YnI+ DQo8Yj5Ubzo8L2I+IFRpYW5yYW4gWmhvdSAmbHQ7emhvdXRpYW5yYW5AaHVhd2VpLmNvbSZndDs8 YnI+DQo8Yj5DYzo8L2I+IHdhbmdhajNAY2hpbmF0ZWxlY29tLmNuOyBJRVRGIElQUE0gV0cgJmx0 O2lwcG1AaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbaXBwbV0gRlc6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGktaXBwbS1vdHdhbXAtb24tbGFnLTAy LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3Mg Zm9yIHRoZSBjbGFyaWZpY2F0aW9uLCBidXQgdGhpcyAmcXVvdDttZW1iZXIgbGluayB2YWxpZGF0 aW9uIG1lY2hhbmlzbSZxdW90OyBkZXBlbmRzIGZ1bGx5IG9uIGNvbmZpZ3VyYXRpb24gYmV0d2Vl biB0aGUgc2Vzc2lvbiBzZW5kZXIgYW5kIHRoZSBzZXNzaW9uIHJlZmxlY3RvciByaWdodD8gU28g ZXZlbiBpZiB0aGV5IGhhdmUgYWdyZWVkIHRoYXQgYSBjZXJ0YWluIHNlc3Npb24gSUQgYmVsb25n cyZuYnNwO3RvIGxhZyBsaW5rDQogQSwgdGhlcmUgaXMgbm8gd2F5IHRvIGJlIHN1cmUgdGhhdCB0 aGlzIGlzIHRoZSBjYXNlLCB0aGUgaW50ZXJtZWRpYXRlIHN3aXRjaGVzIG1heSBwbGFjZSB0aGVz ZSBwYWNrZXRzIHJhbmRvbWx5IG92ZXIgbGlua3MgQS1DIGFuZCB0aGUgVFdBTVAvT1dBTVAgc2Vu ZGVyL3JlZmxlY3RvcnMgd2lsbCBoYXZlIG5vIGtub3dsZWRnZSBvZiB0aGlzLiBTbyBJIGRvbnQg a25vdyBpZiB0aGlzIGFkZGl0aW9uIGFkZHMgbXVjaCB1c2VmdWxuZXMgb3ZlciB0aGUNCiBhbHJl YWR5IGV4aXN0aW5nIGNhcGFiaWxpdGllcyBvZiBUV0FNUCwgd2hlcmUgeW91IGNhbiB1c2UgdGhl IDUtdHVwbGUgb2YgcG9ydC1wYWlyLCBJUC1wYWlyIGFuZCBUT1MgdG8gZGlmZmVyZW50aWF0ZSBz ZXNzaW9uIGZyb20gZWFjaCBvdGhlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEphbiAyNywgMjAyMiBhdCAyOjM3IEFNIFRp YW5yYW4gWmhvdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnpob3V0aWFucmFuQGh1YXdlaS5jb20iPnpo b3V0aWFucmFuQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgSGVucmlrLDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyB2ZXJ5IG11Y2ggZm9yIHlvdXIgcmV2 aWV3Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPllvdXIgcGVyc3BlY3RpdmUgaXMgYWJzb2x1dGVseSBj b3JyZWN0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoaXMgZHJhZnQgaXMgbm90IGFibGUgdG8g4oCc Z3VhcmFudGVl4oCdIGEgc3BlY2lmaWMgTEFHIHBhdGguIEZvciBleGFtcGxlLCB0aGVyZSBpcyBh IHN3aXRjaCBiZXR3ZWVuIHRoZQ0KIHR3byBlbmQgcG9pbnRzLCBvciBpbiB0aGUgY2FzZSB0aGUg cmVmbGVjdG9yIGlzIG5vdCBjYXBhYmxlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkuZS4sIGFzIHlv dSBzYWlkLCB0aGVyZSBpcyBubyAmcXVvdDtvbmUgbWV0aG9kIGZpdHMgYWxsJnF1b3Q7IHRvIGd1 YXJhbnRlZSB0aGUgcGF0aC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5Ib3dldmVyLCB0aGlzIGRyYWZ0IHNlZWsgYW5vdGhlciB3YXkgcm91bmQsIHRoZSBt ZW1iZXIgbGluayB2YWxpZGF0aW9uIG1lY2hhbmlzbS48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGVy ZSBpcyBhbiBhc3N1bXB0aW9uIGluIHRoZSBpbnRyb2R1Y3Rpb24g4oCcVGhpcyBkb2N1bWVudCBp bnRlbmRzIHRvIGFkZHJlc3MgdGhlIHNjZW5hcmlvIHdoZXJlIGEgTEFHDQogZGlyZWN0bHkgY29u bmVjdHMgdHdvIG5vZGVzIChBIGFuZCBCKS7igJ08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XaXRoIHRo ZSBtZW1iZXIgbGluayB2YWxpZGF0aW9uLCBzZW5kZXIvcmVmbGVjdG9yIHdpbGwgZHJvcCBtZWFz dXJlbWVudCBkYXRhLCB3aGVuIHRoZSB0ZXN0IHBhY2tldA0KIGlzIG5vdCBmcm9tIHRoZSBleHBl Y3RlZCBtZW1iZXIgbGluay48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JbiB0aGlzIHdheSwgdGhlIG1l YXN1cmVtZW50IGNvdWxkIGFsd2F5cyBiZSBjb3JyZWN0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoaXMgaXMgc29tZXdoYXQgc2ltaWxhciB0byBQYXJp cyBUcmFjZXJvdXRlICg8YSBocmVmPSJodHRwczovL3BhcmlzLXRyYWNlcm91dGUubmV0L2Fib3V0 LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vcGFyaXMtdHJhY2Vyb3V0ZS5uZXQvYWJvdXQvPC9h PiksDQogSU1ITy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5DaGVlcnMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGlhbnJhbjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gSGVucmlr IE55ZGVsbCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpobnlkZWxsQGFjY2VkaWFuLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmhueWRlbGxAYWNjZWRpYW4uY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9i PiBXZWRuZXNkYXksIEphbnVhcnkgMjYsIDIwMjIgNjoxNyBQTTxicj4NCjxiPlRvOjwvYj4gVGlh bnJhbiBaaG91ICZsdDs8YSBocmVmPSJtYWlsdG86emhvdXRpYW5yYW5AaHVhd2VpLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPnpob3V0aWFucmFuQGh1YXdlaS5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwv Yj4gPGEgaHJlZj0ibWFpbHRvOndhbmdhajNAY2hpbmF0ZWxlY29tLmNuIiB0YXJnZXQ9Il9ibGFu ayI+d2FuZ2FqM0BjaGluYXRlbGVjb20uY248L2E+OyBJRVRGIElQUE0gV0cgJmx0OzxhIGhyZWY9 Im1haWx0bzppcHBtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aXBwbUBpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbaXBwbV0gRlc6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtbGktaXBwbS1vdHdhbXAtb24tbGFnLTAyLnR4dDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBoYWQgYSBicmllZiByZXZp ZXcgYnV0IGZhaWxlZCB0byBmaW5kIGRldGFpbHMgb24gaG93IHRoZSBUV0FNUCBzZXNzaW9ucyB3 b3VsZCBiZSAmcXVvdDtndWFyYW50ZWVkJnF1b3Q7IHRvIHRyYXZlbCBvbiBhIGNlcnRhaW4gTEFH IHNlZ21lbnQuIEFzIGZhciBhcyBJIGtub3cgdGhlIExBRyBpbXBsZW1lbnRhdGlvbiBtYXkgYmUN CiBkaWZmZXJlbnQgYmV0d2VlbiB2ZW5kb3JzIGFuZCBhcyBzdWNoIEkga25vdyBvZiBubyAmcXVv dDtvbmUgbWV0aG9kIGZpdHMgYWxsJnF1b3Q7IHRvIGFjdHVhbGx5IGFjY29tcGxpc2ggdGhlIG1l YXN1cmVtZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+U28gdGhpcyBkcmFmdCBkb2VzIG5vdCBhY3R1YWxseSBwcm92aWRlIGFueSBz b2x1dGlvbiB0byB0aGUgcHJvYmxlbSBvZiBiZWluZyBhYmxlIHRvIG1lYXN1cmUgTEFHIHNlZ21l bnRzIHNlcGFyYXRlbHkgYW5kIGRldGVybWluaXN0aWNhbGx5LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gV2VkLCBKYW4gMjYsIDIw MjIgYXQgMTE6MDMgQU0gVGlhbnJhbiBaaG91ICZsdDt6aG91dGlhbnJhbj08YSBocmVmPSJtYWls dG86NDBodWF3ZWkuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBodWF3ZWku Y29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5IaSBBbmp1biw8YnI+DQo8YnI+DQpUaGFua3MgdmVyeSBtdWNoIGZv ciB5b3VyIGludGVyZXN0IGFuZCBjb21tZW50cy48YnI+DQpCb3RoIGFyZSBnb29kIHF1ZXN0aW9u cy48YnI+DQpQbGVhc2Ugc2VlIGluIGxpbmUuPGJyPg0KPGJyPg0KQ2hlZXJzLDxicj4NClRpYW5y YW48YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IDxhIGhy ZWY9Im1haWx0bzp3YW5nYWozQGNoaW5hdGVsZWNvbS5jbiIgdGFyZ2V0PSJfYmxhbmsiPndhbmdh ajNAY2hpbmF0ZWxlY29tLmNuPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp3YW5nYWozQGNo aW5hdGVsZWNvbS5jbiIgdGFyZ2V0PSJfYmxhbmsiPndhbmdhajNAY2hpbmF0ZWxlY29tLmNuPC9h Pl0NCjxicj4NClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyNiwgMjAyMiA1OjIxIFBNPGJyPg0K VG86IFRpYW5yYW4gWmhvdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnpob3V0aWFucmFuQGh1YXdlaS5j b20iIHRhcmdldD0iX2JsYW5rIj56aG91dGlhbnJhbkBodWF3ZWkuY29tPC9hPiZndDs7ICdJRVRG IElQUE0gV0cnICZsdDs8YSBocmVmPSJtYWlsdG86aXBwbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPmlwcG1AaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NClN1YmplY3Q6IFJFOiBbaXBwbV0gRlc6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGktaXBwbS1vdHdhbXAtb24tbGFnLTAy LnR4dDxicj4NCjxicj4NCkhpLCBUaWFucmFuOjxicj4NCjxicj4NCkhhdmUgYSBicmllZiByZXZp ZXcgb2YgdGhpcyBkcmFmdC4gSSB0aGluayBpdHMgYWltIGlzIHN0cmFpZ2h0Zm9yd2FyZCBhbmQg d2lsbCBiZSB1c2VmdWwgdG8gdXRpbGl6ZSB0aGUgbWVtYmVyIGxpbmsgd2l0aGluIHRoZSBMQUcu PGJyPg0KU29tZSBjb21tZW50cyBhcmUgYmVsb3c6PGJyPg0KMSkgSXQgc2VlbXMgdGhlcmUgaXMg bm8gU2VuZGVyL1JlZmxlY3RvciBiZWhhdmlvciBkZXNjcmlwdGlvbiBmb3IgdGhlIE1pcmNvIE9X QU1QIHNlc3Npb24gYW5kIHRoZSBwYWNrZXQgZm9ybWF0Pw0KPGJyPg0KPGJyPg0KPGJyPg0KWlRS Jmd0OyBPV0FNUCBpcyBzaW1wbGUgYW5kIHRoZXJlIGlzIG5vIHJlZmxlY3Rvci4gVGhlIHNlbmRl ciBjYW5ub3QgZ2V0IHRoZSBhY2sgZnJvbSB0aGUgcmVjZWl2ZXIuIFNvIHdlIGFyZSBub3QgZ29p bmcgdG8gZXh0ZW5kIHRoZSBPV0FNUCB0ZXN0IHBhY2tldC48YnI+DQpUaGUgYmVoYXZpb3IgaXMg ZGVzY3JpYmVkIGluIHNlY3Rpb24gMy4yOjxicj4NCiZxdW90OyBUaGUgbWljcm8gT1dBTVAgU2Vu ZGVyIE1VU1Qgc2VuZCB0aGUgbWljcm8gT1dBTVAtVGVzdCBwYWNrZXRzIG92ZXIgdGhlIG1lbWJl ciBsaW5rIHdpdGggd2hpY2ggdGhlIHNlc3Npb24gaXMgYXNzb2NpYXRlZC4gV2hlbiByZWNlaXZl cyBhIFRlc3QgcGFja2V0LCB0aGUgbWljcm8gT1dBTVAgcmVjZWl2ZXIgTVVTVCB1c2UgdGhlIG1l bWJlciBsaW5rIGZyb20gd2hpY2ggdGhlIFRlc3QgcGFja2V0IGlzIHJlY2VpdmVkIHRvIGNvcnJl bGF0ZSB0aGUNCiBtaWNybyBPV0FNUCBzZXNzaW9uLiBJZiB0aGVyZSBpcyBubyBzdWNoIGEgc2Vz c2lvbiwgdGhlIFRlc3QgcGFja2V0IE1VU1QgYmUgZGlzY2FyZGVkLiAmcXVvdDsNCjxicj4NCjxi cj4NCjIpIEZvciB0aGUgbmV3bHkgZGVmaW5lZCBTZXNzaW9uLVNlbmRlciBQYWNrZXQvU2Vzc2lv bi1SZWZsZWN0b3IgUGFja2V0LCBob3cgdG8gYXNzdXJlIHRoZSBiYWNrd2FyZCBjb21wYXRpYmls aXR5PyBXaGF0IEkgaGF2ZSBzZWVuIGlzIHRoYXQgeW91IGFkZCB0d28gYWRkaXRpb25hbCBmaWVs ZHMgd2l0aGluIHRoZSBleGlzdGluZyBQYWNrZXQ/DQo8YnI+DQo8YnI+DQpaVFImZ3Q7IEkgYW0g bm90IGF3YXJlIG9mIHRoZSBjb21wYXRpYmlsaXR5IHByb2JsZW0uIElmIGEgbm9kZSBzdXBwb3J0 cyBtaWNybyBzZXNzaW9uLCBpdCBjYW4gdW5kZXJzdGFuZCB0aGUgbmV3IHBhY2tldCBleHRlbnNp b24uIElmIGEgbm9kZSBkb2VzIG5vdCBzdXBwb3J0IG1pY3JvIHNlc3Npb24sIGl0IGp1c3QgaWdu b3JlcyB0aGUgbmV3IGZpZWxkcy4gQmVjYXVzZSB0aGUgbmV3IGZpZWxkcyBpcyBpbiB0aGUgcmVz ZXJ2ZWQgem9uZS48YnI+DQpNb3Jlb3ZlciwgdGhlIHZhbGlkYXRpb24gbWVjaGFuaXNtIGNhbiBm aWd1cmUgb3V0IGlmIHRoZSByZWZsZWN0b3IgY2FuIHN1cHBvcnQgdGhlIG1pY3JvIHNlc3Npb24u DQo8YnI+DQo8YnI+DQpCZXN0IFJlZ2FyZHM8YnI+DQo8YnI+DQpBaWp1biBXYW5nPGJyPg0KQ2hp bmEgVGVsZWNvbTxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJv bTogaXBwbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPmlwcG0tYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IE9uIEJlaGFsZiBPZiBUaWFu cmFuIFpob3U8YnI+DQpTZW50OiBNb25kYXksIEphbnVhcnkgMjQsIDIwMjIgMjoyMyBQTTxicj4N ClRvOiBJRVRGIElQUE0gV0cgKDxhIGhyZWY9Im1haWx0bzppcHBtQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+aXBwbUBpZXRmLm9yZzwvYT4pICZsdDs8YSBocmVmPSJtYWlsdG86aXBwbUBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlwcG1AaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NClN1YmplY3Q6 IFtpcHBtXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saS1pcHBtLW90 d2FtcC1vbi1sYWctMDIudHh0PGJyPg0KPGJyPg0KSGkgV0csPGJyPg0KPGJyPg0KV2UgdGhpbmsg dGhpcyBpcyBhbiB1c2VmdWwgd29yayBvbiBhZGFwdGluZyBPV0FNUC9UV0FNUCBpbiBMQUcgcGVy Zm9ybWFuY2UgbWVhc3VyZW1lbnQuPGJyPg0KV2UgdXBkYXRlZCB0aGlzIGRyYWZ0IGJhc2VkIG9u IHRoZSBjb21tZW50cyBmcm9tIHRoZSBtZWV0aW5nIGRpc2N1c3Npb24gYW5kIG1haWxpbmcgbGlz dC48YnI+DQpUaGFua3MgZm9yIGFsbCB0aGUgc3VnZ2VzdGlvbnMuPGJyPg0KTW9yZSByZXZpZXdz IGFuZCBjb21tZW50cyBhcmUgd2VsY29tZS48YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0KVGlhbnJh bjxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogPGEgaHJl Zj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn PC9hPl08YnI+DQpTZW50OiBNb25kYXksIEphbnVhcnkgMjQsIDIwMjIgMjoxNyBQTTxicj4NClRv OiBHcmVnIE1pcnNreSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwvYT4mZ3Q7OyBHdW8gSnVuICZs dDs8YSBocmVmPSJtYWlsdG86Z3VvLmp1bjJAenRlLmNvbS5jbiIgdGFyZ2V0PSJfYmxhbmsiPmd1 by5qdW4yQHp0ZS5jb20uY248L2E+Jmd0OzsgSnVuIEd1byAmbHQ7PGEgaHJlZj0ibWFpbHRvOmd1 by5qdW4yQHp0ZS5jb20uY24iIHRhcmdldD0iX2JsYW5rIj5ndW8uanVuMkB6dGUuY29tLmNuPC9h PiZndDs7DQogUmFrZXNoIEdhbmRoaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJnYW5kaGlAY2lzY28u Y29tIiB0YXJnZXQ9Il9ibGFuayI+cmdhbmRoaUBjaXNjby5jb208L2E+Jmd0OzsgVGlhbnJhbiBa aG91ICZsdDs8YSBocmVmPSJtYWlsdG86emhvdXRpYW5yYW5AaHVhd2VpLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPnpob3V0aWFucmFuQGh1YXdlaS5jb208L2E+Jmd0OzsgWmhlbnFpYW5nIExpICZsdDs8 YSBocmVmPSJtYWlsdG86bGlfemhlbnFpYW5nQGhvdG1haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ bGlfemhlbnFpYW5nQGhvdG1haWwuY29tPC9hPiZndDs8YnI+DQpTdWJqZWN0OiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpLWlwcG0tb3R3YW1wLW9uLWxhZy0wMi50eHQ8YnI+ DQo8YnI+DQo8YnI+DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGktaXBwbS1vdHdhbXAt b24tbGFnLTAyLnR4dDxicj4NCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVGlh bnJhbiBaaG91IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpO YW1lOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJhZnQtbGktaXBw bS1vdHdhbXAtb24tbGFnPGJyPg0KUmV2aXNpb246Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 MDI8YnI+DQpUaXRsZTombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE9uZS13YXkv VHdvLXdheSBBY3RpdmUgTWVhc3VyZW1lbnQgUHJvdG9jb2wgRXh0ZW5zaW9ucyBmb3I8YnI+DQpQ ZXJmb3JtYW5jZSBNZWFzdXJlbWVudCBvbiBMQUc8YnI+DQpEb2N1bWVudCBkYXRlOiZuYnNwOyAy MDIyLTAxLTI0PGJyPg0KR3JvdXA6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJ bmRpdmlkdWFsIFN1Ym1pc3Npb248YnI+DQpQYWdlczombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IDEzPGJyPg0KVVJMOjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L2FyY2hpdmUvaWQvZHJhZnQtbGktaXBwbS1vdHdhbXAtb24tbGFnLTAyLnR4dCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtbGktaXBwbS1vdHdh bXAtb24tbGFnLTAyLnR4dDwvYT48YnI+DQpTdGF0dXM6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGktaXBwbS1vdHdhbXAtb24tbGFnLyIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxpLWlw cG0tb3R3YW1wLW9uLWxhZy88L2E+PGJyPg0KSHRtbGl6ZWQ6PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1saS1pcHBtLW90d2FtcC1vbi1s YWciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1s L2RyYWZ0LWxpLWlwcG0tb3R3YW1wLW9uLWxhZzwvYT48YnI+DQpEaWZmOjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1saS1pcHBtLW90d2FtcC1v bi1sYWctMDIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDI9ZHJhZnQtbGktaXBwbS1vdHdhbXAtb24tbGFnLTAyPC9hPjxicj4NCjxicj4NCkFic3RyYWN0 Ojxicj4NCiZuYnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50IGRlZmluZXMgZXh0ZW5zaW9ucyB0byBP bmUtd2F5IEFjdGl2ZSBNZWFzdXJlbWVudDxicj4NCiZuYnNwOyAmbmJzcDtQcm90b2NvbCAoT1dB TVApLCBhbmQgVHdvLXdheSBBY3RpdmUgTWVhc3VyZW1lbnQgUHJvdG9jb2wgKFRXQU1QKSB0bzxi cj4NCiZuYnNwOyAmbmJzcDtpbXBsZW1lbnQgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQgb24gZXZl cnkgbWVtYmVyIGxpbmsgb2YgYSBMaW5rPGJyPg0KJm5ic3A7ICZuYnNwO0FnZ3JlZ2F0aW9uIEdy b3VwIChMQUcpLiZuYnNwOyBLbm93aW5nIHRoZSBtZWFzdXJlZCBtZXRyaWNzIG9mIGVhY2ggbWVt YmVyPGJyPg0KJm5ic3A7ICZuYnNwO2xpbmsgb2YgYSBMQUcgZW5hYmxlcyBvcGVyYXRvcnMgdG8g ZW5mb3JjZSB0aGUgcGVyZm9ybWFuY2UgYmFzZWQ8YnI+DQombmJzcDsgJm5ic3A7dHJhZmZpYyBz dGVlcmluZyBwb2xpY3kgYWNyb3NzIHRoZSBtZW1iZXIgbGlua3MuPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8YnI+DQo8YnI+DQo8YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmlwcG0g bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmlwcG1AaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5pcHBtQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaXBwbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBwbTwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmlwcG0gbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmlwcG1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pcHBt QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaXBwbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaXBwbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0tDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUEwODMyIj5IZW5yaWsgTnlkZWxsPC9zcGFuPjwvc3Ryb25nPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxi cj4NCjwvc3Bhbj48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6I0Y1OUQxNSI+U3IgUHJvZHVj dCBNYW5hZ2VyPC9zcGFuPjwvc3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjxzcGFuIHN0eWxl PSJjb2xvcjojMUEwODMyIj4xLjg2Ni42ODUuODE4MTxicj4NCjxhIGhyZWY9Im1haWx0bzpobnlk ZWxsQGFjY2VkaWFuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmhueWRlbGxAYWNjZWRpYW4uY29tPC9h Pjwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPGEgaHJlZj0iaHR0cDovL2FjY2Vk aWFuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9u ZSI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIxNTciIGhlaWdodD0iNTAiIGlkPSJnbWFpbC1tXzM5 ODQ5ODQ0ODk5MDQxOTc0NTJfeDAwNWZfeDAwMDBfaTEwMjUiIHNyYz0iaHR0cHM6Ly9pLnhpbmsu aW8vSW1hZ2VzL0dldC9ONjM4MzIvYTY1LnBuZyI+PC9zcGFuPjwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5mYWNlYm9vay5jb20vYWNjZWRpYW4vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lIj48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjI1IiBo ZWlnaHQ9IjI1IiBpZD0iZ21haWwtbV8zOTg0OTg0NDg5OTA0MTk3NDUyX3gwMDVmX3gwMDAwX2kx MDI2IiBzcmM9Imh0dHBzOi8vaS54aW5rLmlvL0ltYWdlcy9HZXQvTjYzODMyL2Y5Ny5wbmciPjwv c3Bhbj48L2E+Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90d2l0dGVyLmNvbS9BY2NlZGlhbiIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZSI+PGltZyBib3Jk ZXI9IjAiIHdpZHRoPSIyNSIgaGVpZ2h0PSIyNSIgaWQ9ImdtYWlsLW1fMzk4NDk4NDQ4OTkwNDE5 NzQ1Ml94MDA1Zl94MDAwMF9pMTAyNyIgc3JjPSJodHRwczovL2kueGluay5pby9JbWFnZXMvR2V0 L042MzgzMi90OTkucG5nIj48L3NwYW4+PC9hPiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vY2EubGlu a2VkaW4uY29tL2NvbXBhbnkvYWNjZWRpYW4iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMjUiIGhlaWdodD0i MjUiIGlkPSJnbWFpbC1tXzM5ODQ5ODQ0ODk5MDQxOTc0NTJfeDAwNWZfeDAwMDBfaTEwMjgiIHNy Yz0iaHR0cHM6Ly9pLnhpbmsuaW8vSW1hZ2VzL0dldC9ONjM4MzIvbDU0LnBuZyI+PC9zcGFuPjwv YT48YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmFjY2VkaWFuLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZSI+PGltZyBib3JkZXI9IjAiIHdpZHRo PSIyOTQiIGhlaWdodD0iMSIgaWQ9ImdtYWlsLW1fMzk4NDk4NDQ4OTkwNDE5NzQ1Ml94MDA1Zl94 MDAwMF9pMTAyOSIgc3JjPSJodHRwczovL2kueGluay5pby9JbWFnZXMvR2V0L042MzgzMi9sLmpw ZyI+PC9zcGFuPjwvYT48YnI+DQo8L3NwYW4+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiNG NTlEMTUiPjxhIGhyZWY9Imh0dHA6Ly9hY2NlZGlhbi5jb20iIHRhcmdldD0iX2JsYW5rIj5hY2Nl ZGlhbi5jb208L2E+PC9zcGFuPjwvc3Ryb25nPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0i RlItQ0EiIHN0eWxlPSJmb250LXNpemU6Ny41cHQiPkF2aXMgZGUgY29uZmlkZW50aWFsaXTDqTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkZSLUNBIiBzdHlsZT0iZm9udC1z aXplOjcuNXB0Ij5MZXMgaW5mb3JtYXRpb25zIGNvbnRlbnVlcyBkYW5zIGxlIHByw6lzZW50IG1l c3NhZ2UgZXQgZGFucyB0b3V0ZSBwacOoY2UgcXVpIGx1aSBlc3Qgam9pbnRlIHNvbnQgY29uZmlk ZW50aWVsbGVzIGV0IHBldXZlbnQgw6p0cmUgcHJvdMOpZ8OpZXMgcGFyIGxlIHNlY3JldCBwcm9m ZXNzaW9ubmVsLiBDZXMgaW5mb3JtYXRpb25zIHNvbnQgw6AgbOKAmXVzYWdlIGV4Y2x1c2lmIGRl IHNvbg0KIG91IGRlIHNlcyBkZXN0aW5hdGFpcmVzLiBTaSB2b3VzIHJlY2V2ZXogY2UgbWVzc2Fn ZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBz4oCZaWwgdm91cyBwbGFpdCBjb21tdW5pcXVlciBpbW3D qWRpYXRlbWVudCBhdmVjIGzigJlleHDDqWRpdGV1ciBldCBlbiBkw6l0cnVpcmUgdG91dCBleGVt cGxhaXJlLiBEZSBwbHVzLCBpbCB2b3VzIGVzdCBzdHJpY3RlbWVudCBpbnRlcmRpdCBkZSBsZSBk aXZ1bGd1ZXIsIGRlIGxlIGRpc3RyaWJ1ZXIgb3UgZGUgbGUgcmVwcm9kdWlyZQ0KIHNhbnMgbOKA mWF1dG9yaXNhdGlvbiBkZSBs4oCZZXhww6lkaXRldXIuIE1lcmNpLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwPjxzcGFuIGxhbmc9IkZSLUNBIiBzdHlsZT0iZm9udC1zaXplOjcuNXB0Ij5Db25m aWRlbnRpYWxpdHkgbm90aWNlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo3LjVwdCI+VGhpcyBlLW1haWwgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnQg aGVyZXRvIGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIHdoaWNoIG1heSBiZSBwcml2 aWxlZ2VkIGFuZCB3aGljaCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgaXRz IGFkZHJlc3NlZShzKS4gSWYgeW91IHJlY2VpdmUgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBwbGVh c2UgaW5mb3JtIHNlbmRlcg0KIGltbWVkaWF0ZWx5IGFuZCBkZXN0cm95IGFueSBjb3B5IHRoZXJl b2YuIEZ1cnRoZXJtb3JlLCBhbnkgZGlzY2xvc3VyZSwgZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcg b2YgdGhpcyBtZXNzYWdlIGFuZC9vciBhbnkgYXR0YWNobWVudCBoZXJldG8gd2l0aG91dCB0aGUg Y29uc2VudCBvZiB0aGUgc2VuZGVyIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIFRoYW5rIHlvdS48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxQTA4 MzIiPkhlbnJpayBOeWRlbGw8L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPC9z cGFuPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojRjU5RDE1Ij5TciBQcm9kdWN0IE1hbmFn ZXI8L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9y OiMxQTA4MzIiPjEuODY2LjY4NS44MTgxPGJyPg0KPGEgaHJlZj0ibWFpbHRvOmhueWRlbGxAYWNj ZWRpYW4uY29tIiB0YXJnZXQ9Il9ibGFuayI+aG55ZGVsbEBhY2NlZGlhbi5jb208L2E+PC9zcGFu Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8YSBocmVmPSJodHRwOi8vYWNjZWRpYW4uY29t IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lIj48aW1n IGJvcmRlcj0iMCIgd2lkdGg9IjE1NyIgaGVpZ2h0PSI1MCIgaWQ9Il94MDAwMF9pMTAzMCIgc3Jj PSJodHRwczovL2kueGluay5pby9JbWFnZXMvR2V0L042MzgzMi9hNjUucG5nIj48L3NwYW4+PC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmZhY2Vib29rLmNvbS9hY2NlZGlhbi8iIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVy PSIwIiB3aWR0aD0iMjUiIGhlaWdodD0iMjUiIGlkPSJfeDAwMDBfaTEwMzEiIHNyYz0iaHR0cHM6 Ly9pLnhpbmsuaW8vSW1hZ2VzL0dldC9ONjM4MzIvZjk3LnBuZyI+PC9zcGFuPjwvYT4mbmJzcDs8 YSBocmVmPSJodHRwczovL3R3aXR0ZXIuY29tL0FjY2VkaWFuIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lIj48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjI1 IiBoZWlnaHQ9IjI1IiBpZD0iX3gwMDAwX2kxMDMyIiBzcmM9Imh0dHBzOi8vaS54aW5rLmlvL0lt YWdlcy9HZXQvTjYzODMyL3Q5OS5wbmciPjwvc3Bhbj48L2E+Jm5ic3A7PGEgaHJlZj0iaHR0cHM6 Ly9jYS5saW5rZWRpbi5jb20vY29tcGFueS9hY2NlZGlhbiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZSI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIyNSIg aGVpZ2h0PSIyNSIgaWQ9Il94MDAwMF9pMTAzMyIgc3JjPSJodHRwczovL2kueGluay5pby9JbWFn ZXMvR2V0L042MzgzMi9sNTQucG5nIj48L3NwYW4+PC9hPjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93 d3cuYWNjZWRpYW4uY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9InRleHQtZGVjb3Jh dGlvbjpub25lIj48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjI5NCIgaGVpZ2h0PSIxIiBpZD0iX3gw MDAwX2kxMDM0IiBzcmM9Imh0dHBzOi8vaS54aW5rLmlvL0ltYWdlcy9HZXQvTjYzODMyL2wuanBn Ij48L3NwYW4+PC9hPjxicj4NCjwvc3Bhbj48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6I0Y1 OUQxNSI+PGEgaHJlZj0iaHR0cDovL2FjY2VkaWFuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFjY2Vk aWFuLmNvbTwvYT48L3NwYW4+PC9zdHJvbmc+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRlIt Q0EiIHN0eWxlPSJmb250LXNpemU6Ny41cHQiPkF2aXMgZGUgY29uZmlkZW50aWFsaXTDqTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkZSLUNBIiBzdHlsZT0iZm9udC1zaXpl OjcuNXB0Ij5MZXMgaW5mb3JtYXRpb25zIGNvbnRlbnVlcyBkYW5zIGxlIHByw6lzZW50IG1lc3Nh Z2UgZXQgZGFucyB0b3V0ZSBwacOoY2UgcXVpIGx1aSBlc3Qgam9pbnRlIHNvbnQgY29uZmlkZW50 aWVsbGVzIGV0IHBldXZlbnQgw6p0cmUgcHJvdMOpZ8OpZXMgcGFyIGxlIHNlY3JldCBwcm9mZXNz aW9ubmVsLiBDZXMgaW5mb3JtYXRpb25zIHNvbnQgw6AgbOKAmXVzYWdlIGV4Y2x1c2lmIGRlIHNv bg0KIG91IGRlIHNlcyBkZXN0aW5hdGFpcmVzLiBTaSB2b3VzIHJlY2V2ZXogY2UgbWVzc2FnZSBw YXIgZXJyZXVyLCB2ZXVpbGxleiBz4oCZaWwgdm91cyBwbGFpdCBjb21tdW5pcXVlciBpbW3DqWRp YXRlbWVudCBhdmVjIGzigJlleHDDqWRpdGV1ciBldCBlbiBkw6l0cnVpcmUgdG91dCBleGVtcGxh aXJlLiBEZSBwbHVzLCBpbCB2b3VzIGVzdCBzdHJpY3RlbWVudCBpbnRlcmRpdCBkZSBsZSBkaXZ1 bGd1ZXIsIGRlIGxlIGRpc3RyaWJ1ZXIgb3UgZGUgbGUgcmVwcm9kdWlyZQ0KIHNhbnMgbOKAmWF1 dG9yaXNhdGlvbiBkZSBs4oCZZXhww6lkaXRldXIuIE1lcmNpLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwPjxzcGFuIGxhbmc9IkZSLUNBIiBzdHlsZT0iZm9udC1zaXplOjcuNXB0Ij5Db25maWRl bnRpYWxpdHkgbm90aWNlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjVwdCI+VGhpcyBlLW1haWwgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnQgaGVy ZXRvIGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIHdoaWNoIG1heSBiZSBwcml2aWxl Z2VkIGFuZCB3aGljaCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgaXRzIGFk ZHJlc3NlZShzKS4gSWYgeW91IHJlY2VpdmUgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2Ug aW5mb3JtIHNlbmRlcg0KIGltbWVkaWF0ZWx5IGFuZCBkZXN0cm95IGFueSBjb3B5IHRoZXJlb2Yu IEZ1cnRoZXJtb3JlLCBhbnkgZGlzY2xvc3VyZSwgZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcgb2Yg dGhpcyBtZXNzYWdlIGFuZC9vciBhbnkgYXR0YWNobWVudCBoZXJldG8gd2l0aG91dCB0aGUgY29u c2VudCBvZiB0aGUgc2VuZGVyIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIFRoYW5rIHlvdS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_26d83b5f046a439785f52d9599209c95huaweicom_-- From nobody Thu Jan 27 02:15:36 2022 Return-Path: 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 D951B3A1D6F for ; Thu, 27 Jan 2022 02:15:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=accedian.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OShL2x40UFWG for ; Thu, 27 Jan 2022 02:15:30 -0800 (PST) Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE69B3A1D6D for ; Thu, 27 Jan 2022 02:15:29 -0800 (PST) Received: by mail-yb1-xb30.google.com with SMTP id g14so7063396ybs.8 for ; Thu, 27 Jan 2022 02:15:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=accedian.com; s=corp1; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aynf4ZyldHlVj6IkdkPRUQ9zjnlUyIHQgTvHvZHo6Mw=; b=S1EO5AaEnvik8cfz3zHQNSaxHZafCPOgHUc00MMEs5T5V3svqNG1/02/oQpBUfM5wd bj9PTdI5Ywv12ggzMZOKJjdpNayS4IIxhsNyu9jXyUByz3BZxHAaj+QlQ2W763FoKcpI Dfw0K+WEvs0pdei6EtM5Ruru8Ksy5rlSwHV6QKfr5vwHOBxGWMWb5tq+9QmAFxkvsw5E FKPKOXLEJQGKxtJHTjTs4na+H3bTBjx22Ig4EC5xAx8qukVxT+hC3KA/3JT3Ot3mKO1u jopBCc3nui+OpxYkJ5I+jGqhCB7s5uwfYdejdtKdXYmjodRUh8ahtkpx3r5sNFqJq2h1 wfNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aynf4ZyldHlVj6IkdkPRUQ9zjnlUyIHQgTvHvZHo6Mw=; b=GRkmBMVB+PPIb4jQbybvVT+2H0y35iN0H5M7xkUqGxWs+Mm7gyz0keARusf8Y5hB+3 P42jB5vA2ejKeXrrUhx9vwqFVLJBqgGvu08QTg1/c4GaeMN/WbT0bEQX79QkhRohIxLV Rk0fKYfG/0+TAcMoF7NoxvylX8aW/erR0UZB+wzt/6vYQxP9DJRfhgornOoqBaW4EA2A 4Ands4obVZsIo1d15yS2Dv+gh7i39TM93j+PlfDrZ8Mw8VbGVML7R5CKxb8ig8kakLW6 WGAzhylYhqX05DNKokQsvgcie0jWdmM/Q3JFSP5Z6UuwTHdpraj3EcFPu5H/3VtD58xd VE+A== X-Gm-Message-State: AOAM533aPWGGSMHNcZJOWRNxsrucDK9zarN8NKIou08KH+TJgEXBO7Nh /BoyK9mGZmF/2AB+Y6K5Yahg8im/0XQIVnsF3+RvEmKDhoYr4q1Ww2m1XbgiRSiszjoqmkybPCr EqhZvJmvsGranhwg= X-Google-Smtp-Source: ABdhPJwMjCJswSCTYak/VGtwl78eIbxZrVmJj8sPXdeecQ6l7uqfoB5ckinrCxDwOo5GIqsGHwesoU8LrdWxW324oBY= X-Received: by 2002:a05:6902:1028:: with SMTP id x8mr2263454ybt.716.1643278527976; Thu, 27 Jan 2022 02:15:27 -0800 (PST) MIME-Version: 1.0 References: <164300504281.12619.16642699818590435984@ietfa.amsl.com> <015a01d81295$fdd37370$f97a5a50$@chinatelecom.cn> <70c388c86215411796ef55d48711b216@huawei.com> <3a33416375314462af22d1837e8472dc@huawei.com> <26d83b5f046a439785f52d9599209c95@huawei.com> In-Reply-To: <26d83b5f046a439785f52d9599209c95@huawei.com> From: Henrik Nydell Date: Thu, 27 Jan 2022 11:15:11 +0100 Message-ID: To: Tianran Zhou Cc: "wangaj3@chinatelecom.cn" , IETF IPPM WG Content-Type: multipart/alternative; boundary="000000000000ed71b705d68d98c2" Archived-At: Subject: Re: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2022 10:15:35 -0000 --000000000000ed71b705d68d98c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable OK, but this requires that the sender runs on the device that performs the LAG. This would be quite a serious limitation of the feature I believe On Thu, Jan 27, 2022 at 10:48 AM Tianran Zhou wrote: > Hi Henrik, > > > > Both sender and reflector keep the mapping between member link and the > micro session. Either by configuration or negotiation or auto-learning. > > So, in your switch case, if the sender receives the packet from C, not A, > the sender know it=E2=80=99s wrong. The test packet should be dropped and= not > counted. > > > > Best, > > Tianran > > *From:* Henrik Nydell [mailto:hnydell@accedian.com] > *Sent:* Thursday, January 27, 2022 5:29 PM > *To:* Tianran Zhou > *Cc:* wangaj3@chinatelecom.cn; IETF IPPM WG > *Subject:* Re: [ippm] FW: New Version Notification for > draft-li-ippm-otwamp-on-lag-02.txt > > > > Thanks for the clarification, but this "member link validation mechanism" > depends fully on configuration between the session sender and the session > reflector right? So even if they have agreed that a certain session ID > belongs to lag link A, there is no way to be sure that this is the case, > the intermediate switches may place these packets randomly over links A-C > and the TWAMP/OWAMP sender/reflectors will have no knowledge of this. So = I > dont know if this addition adds much usefulnes over the already existing > capabilities of TWAMP, where you can use the 5-tuple of port-pair, IP-pai= r > and TOS to differentiate session from each other. > > > > > > On Thu, Jan 27, 2022 at 2:37 AM Tianran Zhou > wrote: > > Hi Henrik, > > > > Thanks very much for your review. > > Your perspective is absolutely correct. > > This draft is not able to =E2=80=9Cguarantee=E2=80=9D a specific LAG path= . For example, > there is a switch between the two end points, or in the case the reflecto= r > is not capable. > > I.e., as you said, there is no "one method fits all" to guarantee the pat= h. > > > > However, this draft seek another way round, the member link validation > mechanism. > > There is an assumption in the introduction =E2=80=9CThis document intends= to > address the scenario where a LAG directly connects two nodes (A and B).= =E2=80=9D > > With the member link validation, sender/reflector will drop measurement > data, when the test packet is not from the expected member link. > > In this way, the measurement could always be correct. > > > > This is somewhat similar to Paris Traceroute ( > https://paris-traceroute.net/about/), IMHO. > > > > Cheers, > > Tianran > > > > *From:* Henrik Nydell [mailto:hnydell@accedian.com] > *Sent:* Wednesday, January 26, 2022 6:17 PM > *To:* Tianran Zhou > *Cc:* wangaj3@chinatelecom.cn; IETF IPPM WG > *Subject:* Re: [ippm] FW: New Version Notification for > draft-li-ippm-otwamp-on-lag-02.txt > > > > I had a brief review but failed to find details on how the TWAMP sessions > would be "guaranteed" to travel on a certain LAG segment. As far as I kno= w > the LAG implementation may be different between vendors and as such I kno= w > of no "one method fits all" to actually accomplish the measurement. > > > > So this draft does not actually provide any solution to the problem of > being able to measure LAG segments separately and deterministically. > > > > On Wed, Jan 26, 2022 at 11:03 AM Tianran Zhou 40huawei.com@dmarc.ietf.org> wrote: > > Hi Anjun, > > Thanks very much for your interest and comments. > Both are good questions. > Please see in line. > > Cheers, > Tianran > > -----Original Message----- > From: wangaj3@chinatelecom.cn [mailto:wangaj3@chinatelecom.cn] > Sent: Wednesday, January 26, 2022 5:21 PM > To: Tianran Zhou ; 'IETF IPPM WG' > Subject: RE: [ippm] FW: New Version Notification for > draft-li-ippm-otwamp-on-lag-02.txt > > Hi, Tianran: > > Have a brief review of this draft. I think its aim is straightforward and > will be useful to utilize the member link within the LAG. > Some comments are below: > 1) It seems there is no Sender/Reflector behavior description for the > Mirco OWAMP session and the packet format? > > > ZTR> OWAMP is simple and there is no reflector. The sender cannot get the > ack from the receiver. So we are not going to extend the OWAMP test packe= t. > The behavior is described in section 3.2: > " The micro OWAMP Sender MUST send the micro OWAMP-Test packets over the > member link with which the session is associated. When receives a Test > packet, the micro OWAMP receiver MUST use the member link from which the > Test packet is received to correlate the micro OWAMP session. If there is > no such a session, the Test packet MUST be discarded. " > > 2) For the newly defined Session-Sender Packet/Session-Reflector Packet, > how to assure the backward compatibility? What I have seen is that you ad= d > two additional fields within the existing Packet? > > ZTR> I am not aware of the compatibility problem. If a node supports micr= o > session, it can understand the new packet extension. If a node does not > support micro session, it just ignores the new fields. Because the new > fields is in the reserved zone. > Moreover, the validation mechanism can figure out if the reflector can > support the micro session. > > Best Regards > > Aijun Wang > China Telecom > > -----Original Message----- > From: ippm On Behalf Of Tianran Zhou > Sent: Monday, January 24, 2022 2:23 PM > To: IETF IPPM WG (ippm@ietf.org) > Subject: [ippm] FW: New Version Notification for > draft-li-ippm-otwamp-on-lag-02.txt > > Hi WG, > > We think this is an useful work on adapting OWAMP/TWAMP in LAG performanc= e > measurement. > We updated this draft based on the comments from the meeting discussion > and mailing list. > Thanks for all the suggestions. > More reviews and comments are welcome. > > Cheers, > Tianran > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, January 24, 2022 2:17 PM > To: Greg Mirsky ; Guo Jun ; > Jun Guo ; Rakesh Gandhi ; Tianran > Zhou ; Zhenqiang Li > Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt > > > A new version of I-D, draft-li-ippm-otwamp-on-lag-02.txt > has been successfully submitted by Tianran Zhou and posted to the IETF > repository. > > Name: draft-li-ippm-otwamp-on-lag > Revision: 02 > Title: One-way/Two-way Active Measurement Protocol Extensions fo= r > Performance Measurement on LAG > Document date: 2022-01-24 > Group: Individual Submission > Pages: 13 > URL: > https://www.ietf.org/archive/id/draft-li-ippm-otwamp-on-lag-02.txt > Status: > https://datatracker.ietf.org/doc/draft-li-ippm-otwamp-on-lag/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-li-ippm-otwamp-on-lag > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-li-ippm-otwamp-on-lag-02 > > Abstract: > This document defines extensions to One-way Active Measurement > Protocol (OWAMP), and Two-way Active Measurement Protocol (TWAMP) to > implement performance measurement on every member link of a Link > Aggregation Group (LAG). Knowing the measured metrics of each member > link of a LAG enables operators to enforce the performance based > traffic steering policy across the member links. > > > > > > The IETF Secretariat > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > > > > -- > > > *Henrik Nydell* > *Sr Product Manager* > 1.866.685.8181 > hnydell@accedian.com > > > > > *accedian.com * > > > > Avis de confidentialit=C3=A9 > > Les informations contenues dans le pr=C3=A9sent message et dans toute pi= =C3=A8ce qui > lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3= =A9es par le secret > professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de s= on ou de ses > destinataires. Si vous recevez ce message par erreur, veuillez s=E2=80=99= il vous > plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3=A9diteur et en= d=C3=A9truire tout > exemplaire. De plus, il vous est strictement interdit de le divulguer, de > le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80= =99exp=C3=A9diteur. > Merci. > > Confidentiality notice > > This e-mail message and any attachment hereto contain confidential > information which may be privileged and which is intended for the exclusi= ve > use of its addressee(s). If you receive this message in error, please > inform sender immediately and destroy any copy thereof. Furthermore, any > disclosure, distribution or copying of this message and/or any attachment > hereto without the consent of the sender is strictly prohibited. Thank yo= u. > > > > > -- > > > *Henrik Nydell* > *Sr Product Manager* > 1.866.685.8181 > hnydell@accedian.com > > > > > *accedian.com * > > > > Avis de confidentialit=C3=A9 > > Les informations contenues dans le pr=C3=A9sent message et dans toute pi= =C3=A8ce qui > lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3= =A9es par le secret > professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de s= on ou de ses > destinataires. Si vous recevez ce message par erreur, veuillez s=E2=80=99= il vous > plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3=A9diteur et en= d=C3=A9truire tout > exemplaire. De plus, il vous est strictement interdit de le divulguer, de > le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80= =99exp=C3=A9diteur. > Merci. > > Confidentiality notice > > This e-mail message and any attachment hereto contain confidential > information which may be privileged and which is intended for the exclusi= ve > use of its addressee(s). If you receive this message in error, please > inform sender immediately and destroy any copy thereof. Furthermore, any > disclosure, distribution or copying of this message and/or any attachment > hereto without the consent of the sender is strictly prohibited. Thank yo= u. > --=20 *Henrik Nydell* *Sr Product Manager* 1.866.685.8181 hnydell@accedian.com *accedian.com * --=20 Avis de confidentialit=C3=A9 Les informations contenues dans le pr=C3=A9sent=20 message et dans toute pi=C3=A8ce qui=20 lui est jointe sont confidentielles et=20 peuvent =C3=AAtre prot=C3=A9g=C3=A9es par le=20 secret professionnel. Ces informations sont=20 =C3=A0 l=E2=80=99usage exclusif de son ou de ses destinataires. Si vous recevez ce=20 message par erreur, veuillez=20 s=E2=80=99il vous plait communiquer imm=C3=A9diatement=20 avec l=E2=80=99exp=C3=A9diteur et en=20 d=C3=A9truire tout exemplaire. De plus, il vous est=20 strictement interdit de=20 le divulguer, de le distribuer ou de le reproduire=20 sans l=E2=80=99autorisation=20 de l=E2=80=99exp=C3=A9diteur. Merci. Confidentiality notice This e-mail message and any attachment hereto contain confidential=20 information=20 which may be privileged and which is intended for the=20 exclusive use of its=20 addressee(s). If you receive this message in error, please inform sender=20 immediately and destroy any copy thereof.=20 Furthermore, any disclosure,=20 distribution or copying of this message=20 and/or any attachment hereto=20 without the consent of the sender is=20 strictly prohibited. Thank you. --000000000000ed71b705d68d98c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
        OK,= but this requires that the sender runs on the device that performs the LAG= . This would be quite a serious limitation of the feature I believe

        On= Thu, Jan 27, 2022 at 10:48 AM Tianran Zhou <zhoutianran@huawei.com> wrote:

        Hi Henrik,

        =C2=A0

        Both sender and reflector keep the mapping b= etween member link and the micro session. Either by configuration or negoti= ation or auto-learning.

        So, in your switch case, if the sender recei= ves the packet from C, not A, the sender know it=E2=80=99s wrong. The test = packet should be dropped and not counted.

        =C2=A0

        Best,

        Tianran

        From: Henrik Nydell [mailto:hnydell@accedian.com]
        Sent: Thursday, January 27, 2022 5:29 PM
        To: Tianran Zhou <zhoutianran@huawei.com>
        Cc: wan= gaj3@chinatelecom.cn; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [ippm] FW: New Version Notification for draft-li-ippm-o= twamp-on-lag-02.txt

        =C2=A0

        Thanks for the clarification, but this "member = link validation mechanism" depends fully on configuration between the = session sender and the session reflector right? So even if they have agreed= that a certain session ID belongs=C2=A0to lag link A, there is no way to be sure that this is the case, the intermediate swit= ches may place these packets randomly over links A-C and the TWAMP/OWAMP se= nder/reflectors will have no knowledge of this. So I dont know if this addi= tion adds much usefulnes over the already existing capabilities of TWAMP, where you can use the 5-tuple of p= ort-pair, IP-pair and TOS to differentiate session from each other.<= u>

        =C2=A0

        =C2=A0

        On Thu, Jan 27, 2022 at 2:37 AM Tianran Zhou <zhoutianran@huawei= .com> wrote:

        Hi Henrik,

        =C2=A0

        Thanks very much for your review.<= /u>

        Your perspective is absolutely correct.

        This draft is not able to =E2=80=9Cguarantee= =E2=80=9D a specific LAG path. For example, there is a switch between the two end points, or in the case the reflector is not capable.=

        I.e., as you said, there is no "one met= hod fits all" to guarantee the path.

        =C2=A0

        However, this draft seek another way round, = the member link validation mechanism.

        There is an assumption in the introduction = =E2=80=9CThis document intends to address the scenario where a LAG directly connects two nodes (A and B).=E2=80=9D

        With the member link validation, sender/refl= ector will drop measurement data, when the test packet is not from the expected member link.

        In this way, the measurement could always be= correct.

        =C2=A0

        This is somewhat similar to Paris Traceroute= (https:/= /paris-traceroute.net/about/), IMHO.

        =C2=A0

        Cheers,

        Tianran

        =C2=A0

        From: Henrik Nydell [mailto:hnydell@accedian.com]
        Sent: Wednesday, January 26, 2022 6:17 PM
        To: Tianran Zhou <zhoutianran@huawei.com>
        Cc: wan= gaj3@chinatelecom.cn; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [ippm] FW: New Version Notification for draft-li-ippm-o= twamp-on-lag-02.txt

        =C2=A0

        I had a brief review but failed to find details on h= ow the TWAMP sessions would be "guaranteed" to travel on a certai= n LAG segment. As far as I know the LAG implementation may be different between vendors and as such I know of no "one method fits a= ll" to actually accomplish the measurement.

        =C2=A0

        So this draft does not actually provide any solution= to the problem of being able to measure LAG segments separately and determ= inistically.

        =C2=A0

        On Wed, Jan 26, 2022 at 11:03 AM Tianran Zhou <zh= outianran=3D40huawei.com@dmarc.ietf.org> wrote:

        Hi Anjun,

        Thanks very much for your interest and comments.
        Both are good questions.
        Please see in line.

        Cheers,
        Tianran

        -----Original Message-----
        From: wangaj3@= chinatelecom.cn [mailto:wangaj3@chinatelecom.cn]
        Sent: Wednesday, January 26, 2022 5:21 PM
        To: Tianran Zhou <zhoutianran@huawei.com>; 'IETF IPPM WG' <ippm@ietf.org>
        Subject: RE: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-o= n-lag-02.txt

        Hi, Tianran:

        Have a brief review of this draft. I think its aim is straightforward and w= ill be useful to utilize the member link within the LAG.
        Some comments are below:
        1) It seems there is no Sender/Reflector behavior description for the Mirco= OWAMP session and the packet format?


        ZTR> OWAMP is simple and there is no reflector. The sender cannot get th= e ack from the receiver. So we are not going to extend the OWAMP test packe= t.
        The behavior is described in section 3.2:
        " The micro OWAMP Sender MUST send the micro OWAMP-Test packets over t= he member link with which the session is associated. When receives a Test p= acket, the micro OWAMP receiver MUST use the member link from which the Tes= t packet is received to correlate the micro OWAMP session. If there is no such a session, the Test packet MUST b= e discarded. "

        2) For the newly defined Session-Sender Packet/Session-Reflector Packet, ho= w to assure the backward compatibility? What I have seen is that you add tw= o additional fields within the existing Packet?

        ZTR> I am not aware of the compatibility problem. If a node supports mic= ro session, it can understand the new packet extension. If a node does not = support micro session, it just ignores the new fields. Because the new fiel= ds is in the reserved zone.
        Moreover, the validation mechanism can figure out if the reflector can supp= ort the micro session.

        Best Regards

        Aijun Wang
        China Telecom

        -----Original Message-----
        From: ippm <i= ppm-bounces@ietf.org> On Behalf Of Tianran Zhou
        Sent: Monday, January 24, 2022 2:23 PM
        To: IETF IPPM WG (ippm@i= etf.org) <ippm@ie= tf.org>
        Subject: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-la= g-02.txt

        Hi WG,

        We think this is an useful work on adapting OWAMP/TWAMP in LAG performance = measurement.
        We updated this draft based on the comments from the meeting discussion and= mailing list.
        Thanks for all the suggestions.
        More reviews and comments are welcome.

        Cheers,
        Tianran

        -----Original Message-----
        From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
        Sent: Monday, January 24, 2022 2:17 PM
        To: Greg Mirsky <gregimirsky@gmail.com>; Guo Jun <guo.jun2@zte.com.cn>; Jun Guo <guo.jun2@zte.com.cn= >; Rakesh Gandhi <r= gandhi@cisco.com>; Tianran Zhou <zhoutianran@huawei.com>; Zhenqiang Li &l= t;li_zhenqian= g@hotmail.com>
        Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

        A new version of I-D, draft-li-ippm-otwamp-on-lag-02.txt
        has been successfully submitted by Tianran Zhou and posted to the IETF repo= sitory.

        Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-li-ippm-otwamp-on-lag Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
        Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 One-way/Two-way Active Measurement= Protocol Extensions for
        Performance Measurement on LAG
        Document date:=C2=A0 2022-01-24
        Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
        Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 13
        URL:
        https://www.ietf.org/archive/id/draft-li-ippm-otwamp-= on-lag-02.txt
        Status:
        https://datatracker.ietf.org/doc/draft-li-ippm-otwamp-on-l= ag/
        Htmlized:
        https://datatracker.ietf.org/doc/html/draft-li-ippm-ot= wamp-on-lag
        Diff:
        https://www.ietf.org/rfcdiff?url2=3Ddraft-li-ippm-otw= amp-on-lag-02

        Abstract:
        =C2=A0 =C2=A0This document defines extensions to One-way Active Measurement=
        =C2=A0 =C2=A0Protocol (OWAMP), and Two-way Active Measurement Protocol (TWA= MP) to
        =C2=A0 =C2=A0implement performance measurement on every member link of a Li= nk
        =C2=A0 =C2=A0Aggregation Group (LAG).=C2=A0 Knowing the measured metrics of= each member
        =C2=A0 =C2=A0link of a LAG enables operators to enforce the performance bas= ed
        =C2=A0 =C2=A0traffic steering policy across the member links.





        The IETF Secretariat


        _______________________________________________
        ippm mailing list
        ippm@ietf.org
        ht= tps://www.ietf.org/mailman/listinfo/ippm

        _______________________________________________
        ippm mailing list
        ippm@ietf.org
        ht= tps://www.ietf.org/mailman/listinfo/ippm


        =C2=A0

        --


        Henrik Nydell
        Sr Product Manager
        1.866.685.8181
        hnydell@accedian.= com

        =C2=A0=C2=A0

        acc= edian.com

        =C2=A0

        Avis de confidentialit=C3= =A9

        Les informations contenue= s dans le pr=C3=A9sent message et dans toute pi=C3=A8ce qui lui est jointe = sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9es par le secret= professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de so= n ou de ses destinataires. Si vous recevez ce message par erreur, veuillez s= =E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3= =A9diteur et en d=C3=A9truire tout exemplaire. De plus, il vous est stricte= ment interdit de le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80=99exp=C3=A9diteur. Merci.=

        Confidentiality notice

        This e-mail message and any attachment h= ereto contain confidential information which may be privileged and which is= intended for the exclusive use of its addressee(s). If you receive this me= ssage in error, please inform sender immediately and destroy any copy thereof. Furthermore, any disclosure, dis= tribution or copying of this message and/or any attachment hereto without t= he consent of the sender is strictly prohibited. Thank you.


        =C2=A0

        --


        Henrik Nydell
        Sr Product Manager
        1.866.685.8181
        hnydell@accedian.= com

        =C2=A0=C2=A0

        acc= edian.com

        =C2=A0

        Avis de confidentialit=C3= =A9

        Les informations contenue= s dans le pr=C3=A9sent message et dans toute pi=C3=A8ce qui lui est jointe = sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9es par le secret= professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de so= n ou de ses destinataires. Si vous recevez ce message par erreur, veuillez s= =E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3= =A9diteur et en d=C3=A9truire tout exemplaire. De plus, il vous est stricte= ment interdit de le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80=99exp=C3=A9diteur. Merci.=

        Confidentiality notice

        This e-mail message and any attachment h= ereto contain confidential information which may be privileged and which is= intended for the exclusive use of its addressee(s). If you receive this me= ssage in error, please inform sender immediately and destroy any copy thereof. Furthermore, any disclosure, dis= tribution or copying of this message and/or any attachment hereto without t= he consent of the sender is strictly prohibited. Thank you.



        --

        Henrik Nydell
        Sr Product Manager
        1.866.685.8181
        hnydell@accedian.= com
        3D""
        =3D""=C2=A03D""=C2=A03D""
        3D""
        accedian.com=

        Avis de confidentialit=C3=A9

        Les informations contenues dans le pr=C3=A9sent message et dans toute pi=C3=A8= ce qui=20 lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9e= s par le=20 secret professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif= de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez=20 s=E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp= =C3=A9diteur et en=20 d=C3=A9truire tout exemplaire. De plus, il vous est strictement interdit de= =20 le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisat= ion=20 de l=E2=80=99exp=C3=A9diteur. Merci.

        Confidentiality notice

        This e-mail message and any attachment hereto contain confidential=20 information which may be privileged and which is intended for the=20 exclusive use of its addressee(s). If you receive this message in error, please inform sender immediately and destroy any copy thereof.=20 Furthermore, any disclosure, distribution or copying of this message=20 and/or any attachment hereto without the consent of the sender is=20 strictly prohibited. Thank you.

        --000000000000ed71b705d68d98c2-- From nobody Thu Jan 27 03:48:40 2022 Return-Path: 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 CDB8A3A0D11 for ; Thu, 27 Jan 2022 03:48:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwh6f003HqIZ for ; Thu, 27 Jan 2022 03:48:32 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF0A53A0D0D for ; Thu, 27 Jan 2022 03:48:31 -0800 (PST) Received: from fraeml738-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JkzJQ56Gnz6FH3v for ; Thu, 27 Jan 2022 19:44:06 +0800 (CST) Received: from kwepeml100005.china.huawei.com (7.221.188.221) by fraeml738-chm.china.huawei.com (10.206.15.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Thu, 27 Jan 2022 12:48:28 +0100 Received: from kwepeml500004.china.huawei.com (7.221.188.141) by kwepeml100005.china.huawei.com (7.221.188.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Thu, 27 Jan 2022 19:48:26 +0800 Received: from kwepeml500004.china.huawei.com ([7.221.188.141]) by kwepeml500004.china.huawei.com ([7.221.188.141]) with mapi id 15.01.2308.021; Thu, 27 Jan 2022 19:48:26 +0800 From: Tianran Zhou To: Henrik Nydell CC: wangaj3 , IETF IPPM WG Thread-Topic: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt Thread-Index: AQHYEOoOM8BWGUje9EistfVjjUvI2qxxspuggALRbQCAAI1nUP//gkoAgAF/fcCAAAVcAIAAidVA//+DMYCAAKAqHg== Date: Thu, 27 Jan 2022 11:48:26 +0000 Message-ID: <3836af861e8c43b2843f083e5ec3c51e@huawei.com> References: <164300504281.12619.16642699818590435984@ietfa.amsl.com> <015a01d81295$fdd37370$f97a5a50$@chinatelecom.cn> <70c388c86215411796ef55d48711b216@huawei.com> <3a33416375314462af22d1837e8472dc@huawei.com> <26d83b5f046a439785f52d9599209c95@huawei.com>, In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_3836af861e8c43b2843f083e5ec3c51ehuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2022 11:48:38 -0000 --_000_3836af861e8c43b2843f083e5ec3c51ehuaweicom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgSGVucmlrLA0KDQpNYXkgSSB1bmRlcnN0YW5kIHdoYXShr3MgdGhlIGxpbWl0cz8NClRoZSB0 d2FtcCBvciBsYWc/IE9yIG90aGVyPw0KQWN0dWFsbHkgYm90aCBhcmUgc3VwcG9ydGVkIGluIGV4 aXN0aW5nIGRldmljZXMuIEFzIGZhciBhcyBJIGtub3cgcXVpdGUgbm9ybWFsLg0KDQpCZXN0LA0K VGlhbnJhbg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpTZW50 IGZyb20gV2VMaW5rDQq3orz+yMujuiBIZW5yaWsgTnlkZWxsPGhueWRlbGxAYWNjZWRpYW4uY29t PG1haWx0bzpobnlkZWxsQGFjY2VkaWFuLmNvbT4+DQrK1bz+yMujuiBUaWFucmFuIFpob3U8emhv dXRpYW5yYW5AaHVhd2VpLmNvbTxtYWlsdG86emhvdXRpYW5yYW5AaHVhd2VpLmNvbT4+DQqzrcvN o7ogd2FuZ2FqMzx3YW5nYWozQGNoaW5hdGVsZWNvbS5jbjxtYWlsdG86d2FuZ2FqM0BjaGluYXRl bGVjb20uY24+PjtJRVRGIElQUE0gV0c8aXBwbUBpZXRmLm9yZzxtYWlsdG86aXBwbUBpZXRmLm9y Zz4+DQrW98zio7ogUmU6IFtpcHBtXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1saS1pcHBtLW90d2FtcC1vbi1sYWctMDIudHh0DQrKsbzko7ogMjAyMi0wMS0yNyAxODox NTozOQ0KDQpPSywgYnV0IHRoaXMgcmVxdWlyZXMgdGhhdCB0aGUgc2VuZGVyIHJ1bnMgb24gdGhl IGRldmljZSB0aGF0IHBlcmZvcm1zIHRoZSBMQUcuIFRoaXMgd291bGQgYmUgcXVpdGUgYSBzZXJp b3VzIGxpbWl0YXRpb24gb2YgdGhlIGZlYXR1cmUgSSBiZWxpZXZlDQoNCk9uIFRodSwgSmFuIDI3 LCAyMDIyIGF0IDEwOjQ4IEFNIFRpYW5yYW4gWmhvdSA8emhvdXRpYW5yYW5AaHVhd2VpLmNvbTxt YWlsdG86emhvdXRpYW5yYW5AaHVhd2VpLmNvbT4+IHdyb3RlOg0KSGkgSGVucmlrLA0KDQpCb3Ro IHNlbmRlciBhbmQgcmVmbGVjdG9yIGtlZXAgdGhlIG1hcHBpbmcgYmV0d2VlbiBtZW1iZXIgbGlu ayBhbmQgdGhlIG1pY3JvIHNlc3Npb24uIEVpdGhlciBieSBjb25maWd1cmF0aW9uIG9yIG5lZ290 aWF0aW9uIG9yIGF1dG8tbGVhcm5pbmcuDQpTbywgaW4geW91ciBzd2l0Y2ggY2FzZSwgaWYgdGhl IHNlbmRlciByZWNlaXZlcyB0aGUgcGFja2V0IGZyb20gQywgbm90IEEsIHRoZSBzZW5kZXIga25v dyBpdKGvcyB3cm9uZy4gVGhlIHRlc3QgcGFja2V0IHNob3VsZCBiZSBkcm9wcGVkIGFuZCBub3Qg Y291bnRlZC4NCg0KQmVzdCwNClRpYW5yYW4NCkZyb206IEhlbnJpayBOeWRlbGwgW21haWx0bzpo bnlkZWxsQGFjY2VkaWFuLmNvbTxtYWlsdG86aG55ZGVsbEBhY2NlZGlhbi5jb20+XQ0KU2VudDog VGh1cnNkYXksIEphbnVhcnkgMjcsIDIwMjIgNToyOSBQTQ0KVG86IFRpYW5yYW4gWmhvdSA8emhv dXRpYW5yYW5AaHVhd2VpLmNvbTxtYWlsdG86emhvdXRpYW5yYW5AaHVhd2VpLmNvbT4+DQpDYzog d2FuZ2FqM0BjaGluYXRlbGVjb20uY248bWFpbHRvOndhbmdhajNAY2hpbmF0ZWxlY29tLmNuPjsg SUVURiBJUFBNIFdHIDxpcHBtQGlldGYub3JnPG1haWx0bzppcHBtQGlldGYub3JnPj4NClN1Ympl Y3Q6IFJlOiBbaXBwbV0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGkt aXBwbS1vdHdhbXAtb24tbGFnLTAyLnR4dA0KDQpUaGFua3MgZm9yIHRoZSBjbGFyaWZpY2F0aW9u LCBidXQgdGhpcyAibWVtYmVyIGxpbmsgdmFsaWRhdGlvbiBtZWNoYW5pc20iIGRlcGVuZHMgZnVs bHkgb24gY29uZmlndXJhdGlvbiBiZXR3ZWVuIHRoZSBzZXNzaW9uIHNlbmRlciBhbmQgdGhlIHNl c3Npb24gcmVmbGVjdG9yIHJpZ2h0PyBTbyBldmVuIGlmIHRoZXkgaGF2ZSBhZ3JlZWQgdGhhdCBh IGNlcnRhaW4gc2Vzc2lvbiBJRCBiZWxvbmdzIHRvIGxhZyBsaW5rIEEsIHRoZXJlIGlzIG5vIHdh eSB0byBiZSBzdXJlIHRoYXQgdGhpcyBpcyB0aGUgY2FzZSwgdGhlIGludGVybWVkaWF0ZSBzd2l0 Y2hlcyBtYXkgcGxhY2UgdGhlc2UgcGFja2V0cyByYW5kb21seSBvdmVyIGxpbmtzIEEtQyBhbmQg dGhlIFRXQU1QL09XQU1QIHNlbmRlci9yZWZsZWN0b3JzIHdpbGwgaGF2ZSBubyBrbm93bGVkZ2Ug b2YgdGhpcy4gU28gSSBkb250IGtub3cgaWYgdGhpcyBhZGRpdGlvbiBhZGRzIG11Y2ggdXNlZnVs bmVzIG92ZXIgdGhlIGFscmVhZHkgZXhpc3RpbmcgY2FwYWJpbGl0aWVzIG9mIFRXQU1QLCB3aGVy ZSB5b3UgY2FuIHVzZSB0aGUgNS10dXBsZSBvZiBwb3J0LXBhaXIsIElQLXBhaXIgYW5kIFRPUyB0 byBkaWZmZXJlbnRpYXRlIHNlc3Npb24gZnJvbSBlYWNoIG90aGVyLg0KDQoNCk9uIFRodSwgSmFu IDI3LCAyMDIyIGF0IDI6MzcgQU0gVGlhbnJhbiBaaG91IDx6aG91dGlhbnJhbkBodWF3ZWkuY29t PG1haWx0bzp6aG91dGlhbnJhbkBodWF3ZWkuY29tPj4gd3JvdGU6DQpIaSBIZW5yaWssDQoNClRo YW5rcyB2ZXJ5IG11Y2ggZm9yIHlvdXIgcmV2aWV3Lg0KWW91ciBwZXJzcGVjdGl2ZSBpcyBhYnNv bHV0ZWx5IGNvcnJlY3QuDQpUaGlzIGRyYWZ0IGlzIG5vdCBhYmxlIHRvIKGwZ3VhcmFudGVlobEg YSBzcGVjaWZpYyBMQUcgcGF0aC4gRm9yIGV4YW1wbGUsIHRoZXJlIGlzIGEgc3dpdGNoIGJldHdl ZW4gdGhlIHR3byBlbmQgcG9pbnRzLCBvciBpbiB0aGUgY2FzZSB0aGUgcmVmbGVjdG9yIGlzIG5v dCBjYXBhYmxlLg0KSS5lLiwgYXMgeW91IHNhaWQsIHRoZXJlIGlzIG5vICJvbmUgbWV0aG9kIGZp dHMgYWxsIiB0byBndWFyYW50ZWUgdGhlIHBhdGguDQoNCkhvd2V2ZXIsIHRoaXMgZHJhZnQgc2Vl ayBhbm90aGVyIHdheSByb3VuZCwgdGhlIG1lbWJlciBsaW5rIHZhbGlkYXRpb24gbWVjaGFuaXNt Lg0KVGhlcmUgaXMgYW4gYXNzdW1wdGlvbiBpbiB0aGUgaW50cm9kdWN0aW9uIKGwVGhpcyBkb2N1 bWVudCBpbnRlbmRzIHRvIGFkZHJlc3MgdGhlIHNjZW5hcmlvIHdoZXJlIGEgTEFHIGRpcmVjdGx5 IGNvbm5lY3RzIHR3byBub2RlcyAoQSBhbmQgQikuobENCldpdGggdGhlIG1lbWJlciBsaW5rIHZh bGlkYXRpb24sIHNlbmRlci9yZWZsZWN0b3Igd2lsbCBkcm9wIG1lYXN1cmVtZW50IGRhdGEsIHdo ZW4gdGhlIHRlc3QgcGFja2V0IGlzIG5vdCBmcm9tIHRoZSBleHBlY3RlZCBtZW1iZXIgbGluay4N CkluIHRoaXMgd2F5LCB0aGUgbWVhc3VyZW1lbnQgY291bGQgYWx3YXlzIGJlIGNvcnJlY3QuDQoN ClRoaXMgaXMgc29tZXdoYXQgc2ltaWxhciB0byBQYXJpcyBUcmFjZXJvdXRlIChodHRwczovL3Bh cmlzLXRyYWNlcm91dGUubmV0L2Fib3V0LyksIElNSE8uDQoNCkNoZWVycywNClRpYW5yYW4NCg0K RnJvbTogSGVucmlrIE55ZGVsbCBbbWFpbHRvOmhueWRlbGxAYWNjZWRpYW4uY29tPG1haWx0bzpo bnlkZWxsQGFjY2VkaWFuLmNvbT5dDQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMjYsIDIwMjIg NjoxNyBQTQ0KVG86IFRpYW5yYW4gWmhvdSA8emhvdXRpYW5yYW5AaHVhd2VpLmNvbTxtYWlsdG86 emhvdXRpYW5yYW5AaHVhd2VpLmNvbT4+DQpDYzogd2FuZ2FqM0BjaGluYXRlbGVjb20uY248bWFp bHRvOndhbmdhajNAY2hpbmF0ZWxlY29tLmNuPjsgSUVURiBJUFBNIFdHIDxpcHBtQGlldGYub3Jn PG1haWx0bzppcHBtQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbaXBwbV0gRlc6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGktaXBwbS1vdHdhbXAtb24tbGFnLTAyLnR4dA0K DQpJIGhhZCBhIGJyaWVmIHJldmlldyBidXQgZmFpbGVkIHRvIGZpbmQgZGV0YWlscyBvbiBob3cg dGhlIFRXQU1QIHNlc3Npb25zIHdvdWxkIGJlICJndWFyYW50ZWVkIiB0byB0cmF2ZWwgb24gYSBj ZXJ0YWluIExBRyBzZWdtZW50LiBBcyBmYXIgYXMgSSBrbm93IHRoZSBMQUcgaW1wbGVtZW50YXRp b24gbWF5IGJlIGRpZmZlcmVudCBiZXR3ZWVuIHZlbmRvcnMgYW5kIGFzIHN1Y2ggSSBrbm93IG9m IG5vICJvbmUgbWV0aG9kIGZpdHMgYWxsIiB0byBhY3R1YWxseSBhY2NvbXBsaXNoIHRoZSBtZWFz dXJlbWVudC4NCg0KU28gdGhpcyBkcmFmdCBkb2VzIG5vdCBhY3R1YWxseSBwcm92aWRlIGFueSBz b2x1dGlvbiB0byB0aGUgcHJvYmxlbSBvZiBiZWluZyBhYmxlIHRvIG1lYXN1cmUgTEFHIHNlZ21l bnRzIHNlcGFyYXRlbHkgYW5kIGRldGVybWluaXN0aWNhbGx5Lg0KDQpPbiBXZWQsIEphbiAyNiwg MjAyMiBhdCAxMTowMyBBTSBUaWFucmFuIFpob3UgPHpob3V0aWFucmFuPTQwaHVhd2VpLmNvbUBk bWFyYy5pZXRmLm9yZzxtYWlsdG86NDBodWF3ZWkuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6 DQpIaSBBbmp1biwNCg0KVGhhbmtzIHZlcnkgbXVjaCBmb3IgeW91ciBpbnRlcmVzdCBhbmQgY29t bWVudHMuDQpCb3RoIGFyZSBnb29kIHF1ZXN0aW9ucy4NClBsZWFzZSBzZWUgaW4gbGluZS4NCg0K Q2hlZXJzLA0KVGlhbnJhbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogd2Fu Z2FqM0BjaGluYXRlbGVjb20uY248bWFpbHRvOndhbmdhajNAY2hpbmF0ZWxlY29tLmNuPiBbbWFp bHRvOndhbmdhajNAY2hpbmF0ZWxlY29tLmNuPG1haWx0bzp3YW5nYWozQGNoaW5hdGVsZWNvbS5j bj5dDQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMjYsIDIwMjIgNToyMSBQTQ0KVG86IFRpYW5y YW4gWmhvdSA8emhvdXRpYW5yYW5AaHVhd2VpLmNvbTxtYWlsdG86emhvdXRpYW5yYW5AaHVhd2Vp LmNvbT4+OyAnSUVURiBJUFBNIFdHJyA8aXBwbUBpZXRmLm9yZzxtYWlsdG86aXBwbUBpZXRmLm9y Zz4+DQpTdWJqZWN0OiBSRTogW2lwcG1dIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LWxpLWlwcG0tb3R3YW1wLW9uLWxhZy0wMi50eHQNCg0KSGksIFRpYW5yYW46DQoNCkhh dmUgYSBicmllZiByZXZpZXcgb2YgdGhpcyBkcmFmdC4gSSB0aGluayBpdHMgYWltIGlzIHN0cmFp Z2h0Zm9yd2FyZCBhbmQgd2lsbCBiZSB1c2VmdWwgdG8gdXRpbGl6ZSB0aGUgbWVtYmVyIGxpbmsg d2l0aGluIHRoZSBMQUcuDQpTb21lIGNvbW1lbnRzIGFyZSBiZWxvdzoNCjEpIEl0IHNlZW1zIHRo ZXJlIGlzIG5vIFNlbmRlci9SZWZsZWN0b3IgYmVoYXZpb3IgZGVzY3JpcHRpb24gZm9yIHRoZSBN aXJjbyBPV0FNUCBzZXNzaW9uIGFuZCB0aGUgcGFja2V0IGZvcm1hdD8NCg0KDQpaVFI+IE9XQU1Q IGlzIHNpbXBsZSBhbmQgdGhlcmUgaXMgbm8gcmVmbGVjdG9yLiBUaGUgc2VuZGVyIGNhbm5vdCBn ZXQgdGhlIGFjayBmcm9tIHRoZSByZWNlaXZlci4gU28gd2UgYXJlIG5vdCBnb2luZyB0byBleHRl bmQgdGhlIE9XQU1QIHRlc3QgcGFja2V0Lg0KVGhlIGJlaGF2aW9yIGlzIGRlc2NyaWJlZCBpbiBz ZWN0aW9uIDMuMjoNCiIgVGhlIG1pY3JvIE9XQU1QIFNlbmRlciBNVVNUIHNlbmQgdGhlIG1pY3Jv IE9XQU1QLVRlc3QgcGFja2V0cyBvdmVyIHRoZSBtZW1iZXIgbGluayB3aXRoIHdoaWNoIHRoZSBz ZXNzaW9uIGlzIGFzc29jaWF0ZWQuIFdoZW4gcmVjZWl2ZXMgYSBUZXN0IHBhY2tldCwgdGhlIG1p Y3JvIE9XQU1QIHJlY2VpdmVyIE1VU1QgdXNlIHRoZSBtZW1iZXIgbGluayBmcm9tIHdoaWNoIHRo ZSBUZXN0IHBhY2tldCBpcyByZWNlaXZlZCB0byBjb3JyZWxhdGUgdGhlIG1pY3JvIE9XQU1QIHNl c3Npb24uIElmIHRoZXJlIGlzIG5vIHN1Y2ggYSBzZXNzaW9uLCB0aGUgVGVzdCBwYWNrZXQgTVVT VCBiZSBkaXNjYXJkZWQuICINCg0KMikgRm9yIHRoZSBuZXdseSBkZWZpbmVkIFNlc3Npb24tU2Vu ZGVyIFBhY2tldC9TZXNzaW9uLVJlZmxlY3RvciBQYWNrZXQsIGhvdyB0byBhc3N1cmUgdGhlIGJh Y2t3YXJkIGNvbXBhdGliaWxpdHk/IFdoYXQgSSBoYXZlIHNlZW4gaXMgdGhhdCB5b3UgYWRkIHR3 byBhZGRpdGlvbmFsIGZpZWxkcyB3aXRoaW4gdGhlIGV4aXN0aW5nIFBhY2tldD8NCg0KWlRSPiBJ IGFtIG5vdCBhd2FyZSBvZiB0aGUgY29tcGF0aWJpbGl0eSBwcm9ibGVtLiBJZiBhIG5vZGUgc3Vw cG9ydHMgbWljcm8gc2Vzc2lvbiwgaXQgY2FuIHVuZGVyc3RhbmQgdGhlIG5ldyBwYWNrZXQgZXh0 ZW5zaW9uLiBJZiBhIG5vZGUgZG9lcyBub3Qgc3VwcG9ydCBtaWNybyBzZXNzaW9uLCBpdCBqdXN0 IGlnbm9yZXMgdGhlIG5ldyBmaWVsZHMuIEJlY2F1c2UgdGhlIG5ldyBmaWVsZHMgaXMgaW4gdGhl IHJlc2VydmVkIHpvbmUuDQpNb3Jlb3ZlciwgdGhlIHZhbGlkYXRpb24gbWVjaGFuaXNtIGNhbiBm aWd1cmUgb3V0IGlmIHRoZSByZWZsZWN0b3IgY2FuIHN1cHBvcnQgdGhlIG1pY3JvIHNlc3Npb24u DQoNCkJlc3QgUmVnYXJkcw0KDQpBaWp1biBXYW5nDQpDaGluYSBUZWxlY29tDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpcHBtIDxpcHBtLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBUaWFucmFuIFpob3UNClNl bnQ6IE1vbmRheSwgSmFudWFyeSAyNCwgMjAyMiAyOjIzIFBNDQpUbzogSUVURiBJUFBNIFdHIChp cHBtQGlldGYub3JnPG1haWx0bzppcHBtQGlldGYub3JnPikgPGlwcG1AaWV0Zi5vcmc8bWFpbHRv OmlwcG1AaWV0Zi5vcmc+Pg0KU3ViamVjdDogW2lwcG1dIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LWxpLWlwcG0tb3R3YW1wLW9uLWxhZy0wMi50eHQNCg0KSGkgV0csDQoN CldlIHRoaW5rIHRoaXMgaXMgYW4gdXNlZnVsIHdvcmsgb24gYWRhcHRpbmcgT1dBTVAvVFdBTVAg aW4gTEFHIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50Lg0KV2UgdXBkYXRlZCB0aGlzIGRyYWZ0IGJh c2VkIG9uIHRoZSBjb21tZW50cyBmcm9tIHRoZSBtZWV0aW5nIGRpc2N1c3Npb24gYW5kIG1haWxp bmcgbGlzdC4NClRoYW5rcyBmb3IgYWxsIHRoZSBzdWdnZXN0aW9ucy4NCk1vcmUgcmV2aWV3cyBh bmQgY29tbWVudHMgYXJlIHdlbGNvbWUuDQoNCkNoZWVycywNClRpYW5yYW4NCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPl0NClNlbnQ6IE1vbmRheSwgSmFudWFy eSAyNCwgMjAyMiAyOjE3IFBNDQpUbzogR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNv bTxtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tPj47IEd1byBKdW4gPGd1by5qdW4yQHp0ZS5j b20uY248bWFpbHRvOmd1by5qdW4yQHp0ZS5jb20uY24+PjsgSnVuIEd1byA8Z3VvLmp1bjJAenRl LmNvbS5jbjxtYWlsdG86Z3VvLmp1bjJAenRlLmNvbS5jbj4+OyBSYWtlc2ggR2FuZGhpIDxyZ2Fu ZGhpQGNpc2NvLmNvbTxtYWlsdG86cmdhbmRoaUBjaXNjby5jb20+PjsgVGlhbnJhbiBaaG91IDx6 aG91dGlhbnJhbkBodWF3ZWkuY29tPG1haWx0bzp6aG91dGlhbnJhbkBodWF3ZWkuY29tPj47IFpo ZW5xaWFuZyBMaSA8bGlfemhlbnFpYW5nQGhvdG1haWwuY29tPG1haWx0bzpsaV96aGVucWlhbmdA aG90bWFpbC5jb20+Pg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1saS1pcHBtLW90d2FtcC1vbi1sYWctMDIudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQs IGRyYWZ0LWxpLWlwcG0tb3R3YW1wLW9uLWxhZy0wMi50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxs eSBzdWJtaXR0ZWQgYnkgVGlhbnJhbiBaaG91IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3Np dG9yeS4NCg0KTmFtZTogICAgICAgICAgIGRyYWZ0LWxpLWlwcG0tb3R3YW1wLW9uLWxhZw0KUmV2 aXNpb246ICAgICAgIDAyDQpUaXRsZTogICAgICAgICAgT25lLXdheS9Ud28td2F5IEFjdGl2ZSBN ZWFzdXJlbWVudCBQcm90b2NvbCBFeHRlbnNpb25zIGZvcg0KUGVyZm9ybWFuY2UgTWVhc3VyZW1l bnQgb24gTEFHDQpEb2N1bWVudCBkYXRlOiAgMjAyMi0wMS0yNA0KR3JvdXA6ICAgICAgICAgIElu ZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6ICAgICAgICAgIDEzDQpVUkw6DQpodHRwczovL3d3 dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LWxpLWlwcG0tb3R3YW1wLW9uLWxhZy0wMi50eHQN ClN0YXR1czoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxpLWlwcG0t b3R3YW1wLW9uLWxhZy8NCkh0bWxpemVkOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvaHRtbC9kcmFmdC1saS1pcHBtLW90d2FtcC1vbi1sYWcNCkRpZmY6DQpodHRwczovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbGktaXBwbS1vdHdhbXAtb24tbGFnLTAyDQoNCkFi c3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGV4dGVuc2lvbnMgdG8gT25lLXdheSBB Y3RpdmUgTWVhc3VyZW1lbnQNCiAgIFByb3RvY29sIChPV0FNUCksIGFuZCBUd28td2F5IEFjdGl2 ZSBNZWFzdXJlbWVudCBQcm90b2NvbCAoVFdBTVApIHRvDQogICBpbXBsZW1lbnQgcGVyZm9ybWFu Y2UgbWVhc3VyZW1lbnQgb24gZXZlcnkgbWVtYmVyIGxpbmsgb2YgYSBMaW5rDQogICBBZ2dyZWdh dGlvbiBHcm91cCAoTEFHKS4gIEtub3dpbmcgdGhlIG1lYXN1cmVkIG1ldHJpY3Mgb2YgZWFjaCBt ZW1iZXINCiAgIGxpbmsgb2YgYSBMQUcgZW5hYmxlcyBvcGVyYXRvcnMgdG8gZW5mb3JjZSB0aGUg cGVyZm9ybWFuY2UgYmFzZWQNCiAgIHRyYWZmaWMgc3RlZXJpbmcgcG9saWN5IGFjcm9zcyB0aGUg bWVtYmVyIGxpbmtzLg0KDQoNCg0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmlwcG0gbWFpbGluZyBs aXN0DQppcHBtQGlldGYub3JnPG1haWx0bzppcHBtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQppcHBtIG1haWxpbmcgbGlzdA0KaXBwbUBpZXRmLm9yZzxt YWlsdG86aXBwbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaXBwbQ0KDQoNCi0tDQoNCkhlbnJpayBOeWRlbGwNClNyIFByb2R1Y3QgTWFuYWdlcg0KMS44 NjYuNjg1LjgxODENCmhueWRlbGxAYWNjZWRpYW4uY29tPG1haWx0bzpobnlkZWxsQGFjY2VkaWFu LmNvbT4NCltodHRwczovL2kueGluay5pby9JbWFnZXMvR2V0L042MzgzMi9hNjUucG5nXTxodHRw Oi8vYWNjZWRpYW4uY29tPg0KW2h0dHBzOi8vaS54aW5rLmlvL0ltYWdlcy9HZXQvTjYzODMyL2Y5 Ny5wbmddPGh0dHBzOi8vd3d3LmZhY2Vib29rLmNvbS9hY2NlZGlhbi8+IFtodHRwczovL2kueGlu ay5pby9JbWFnZXMvR2V0L042MzgzMi90OTkucG5nXSA8aHR0cHM6Ly90d2l0dGVyLmNvbS9BY2Nl ZGlhbj4gIFtodHRwczovL2kueGluay5pby9JbWFnZXMvR2V0L042MzgzMi9sNTQucG5nXSA8aHR0 cHM6Ly9jYS5saW5rZWRpbi5jb20vY29tcGFueS9hY2NlZGlhbj4NCjxodHRwOi8vd3d3LmFjY2Vk aWFuLmNvbT4NCmFjY2VkaWFuLmNvbTxodHRwOi8vYWNjZWRpYW4uY29tPg0KDQoNCkF2aXMgZGUg Y29uZmlkZW50aWFsaXSopg0KDQpMZXMgaW5mb3JtYXRpb25zIGNvbnRlbnVlcyBkYW5zIGxlIHBy qKZzZW50IG1lc3NhZ2UgZXQgZGFucyB0b3V0ZSBwaaioY2UgcXVpIGx1aSBlc3Qgam9pbnRlIHNv bnQgY29uZmlkZW50aWVsbGVzIGV0IHBldXZlbnQgqLp0cmUgcHJvdKimZ6imZXMgcGFyIGxlIHNl Y3JldCBwcm9mZXNzaW9ubmVsLiBDZXMgaW5mb3JtYXRpb25zIHNvbnQgqKQgbKGvdXNhZ2UgZXhj bHVzaWYgZGUgc29uIG91IGRlIHNlcyBkZXN0aW5hdGFpcmVzLiBTaSB2b3VzIHJlY2V2ZXogY2Ug bWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBzoa9pbCB2b3VzIHBsYWl0IGNvbW11bmlxdWVy IGltbaimZGlhdGVtZW50IGF2ZWMgbKGvZXhwqKZkaXRldXIgZXQgZW4gZKimdHJ1aXJlIHRvdXQg ZXhlbXBsYWlyZS4gRGUgcGx1cywgaWwgdm91cyBlc3Qgc3RyaWN0ZW1lbnQgaW50ZXJkaXQgZGUg bGUgZGl2dWxndWVyLCBkZSBsZSBkaXN0cmlidWVyIG91IGRlIGxlIHJlcHJvZHVpcmUgc2FucyBs oa9hdXRvcmlzYXRpb24gZGUgbKGvZXhwqKZkaXRldXIuIE1lcmNpLg0KDQpDb25maWRlbnRpYWxp dHkgbm90aWNlDQoNClRoaXMgZS1tYWlsIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50IGhlcmV0 byBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUgcHJpdmlsZWdl ZCBhbmQgd2hpY2ggaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIGl0cyBhZGRy ZXNzZWUocykuIElmIHlvdSByZWNlaXZlIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIGlu Zm9ybSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRlc3Ryb3kgYW55IGNvcHkgdGhlcmVvZi4gRnVy dGhlcm1vcmUsIGFueSBkaXNjbG9zdXJlLCBkaXN0cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlz IG1lc3NhZ2UgYW5kL29yIGFueSBhdHRhY2htZW50IGhlcmV0byB3aXRob3V0IHRoZSBjb25zZW50 IG9mIHRoZSBzZW5kZXIgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gVGhhbmsgeW91Lg0KDQoNCi0t DQoNCkhlbnJpayBOeWRlbGwNClNyIFByb2R1Y3QgTWFuYWdlcg0KMS44NjYuNjg1LjgxODENCmhu eWRlbGxAYWNjZWRpYW4uY29tPG1haWx0bzpobnlkZWxsQGFjY2VkaWFuLmNvbT4NCltodHRwczov L2kueGluay5pby9JbWFnZXMvR2V0L042MzgzMi9hNjUucG5nXTxodHRwOi8vYWNjZWRpYW4uY29t Pg0KW2h0dHBzOi8vaS54aW5rLmlvL0ltYWdlcy9HZXQvTjYzODMyL2Y5Ny5wbmddPGh0dHBzOi8v d3d3LmZhY2Vib29rLmNvbS9hY2NlZGlhbi8+IFtodHRwczovL2kueGluay5pby9JbWFnZXMvR2V0 L042MzgzMi90OTkucG5nXSA8aHR0cHM6Ly90d2l0dGVyLmNvbS9BY2NlZGlhbj4gIFtodHRwczov L2kueGluay5pby9JbWFnZXMvR2V0L042MzgzMi9sNTQucG5nXSA8aHR0cHM6Ly9jYS5saW5rZWRp bi5jb20vY29tcGFueS9hY2NlZGlhbj4NCjxodHRwOi8vd3d3LmFjY2VkaWFuLmNvbT4NCmFjY2Vk aWFuLmNvbTxodHRwOi8vYWNjZWRpYW4uY29tPg0KDQoNCkF2aXMgZGUgY29uZmlkZW50aWFsaXSo pg0KDQpMZXMgaW5mb3JtYXRpb25zIGNvbnRlbnVlcyBkYW5zIGxlIHByqKZzZW50IG1lc3NhZ2Ug ZXQgZGFucyB0b3V0ZSBwaaioY2UgcXVpIGx1aSBlc3Qgam9pbnRlIHNvbnQgY29uZmlkZW50aWVs bGVzIGV0IHBldXZlbnQgqLp0cmUgcHJvdKimZ6imZXMgcGFyIGxlIHNlY3JldCBwcm9mZXNzaW9u bmVsLiBDZXMgaW5mb3JtYXRpb25zIHNvbnQgqKQgbKGvdXNhZ2UgZXhjbHVzaWYgZGUgc29uIG91 IGRlIHNlcyBkZXN0aW5hdGFpcmVzLiBTaSB2b3VzIHJlY2V2ZXogY2UgbWVzc2FnZSBwYXIgZXJy ZXVyLCB2ZXVpbGxleiBzoa9pbCB2b3VzIHBsYWl0IGNvbW11bmlxdWVyIGltbaimZGlhdGVtZW50 IGF2ZWMgbKGvZXhwqKZkaXRldXIgZXQgZW4gZKimdHJ1aXJlIHRvdXQgZXhlbXBsYWlyZS4gRGUg cGx1cywgaWwgdm91cyBlc3Qgc3RyaWN0ZW1lbnQgaW50ZXJkaXQgZGUgbGUgZGl2dWxndWVyLCBk ZSBsZSBkaXN0cmlidWVyIG91IGRlIGxlIHJlcHJvZHVpcmUgc2FucyBsoa9hdXRvcmlzYXRpb24g ZGUgbKGvZXhwqKZkaXRldXIuIE1lcmNpLg0KDQpDb25maWRlbnRpYWxpdHkgbm90aWNlDQoNClRo aXMgZS1tYWlsIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50IGhlcmV0byBjb250YWluIGNvbmZp ZGVudGlhbCBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBhbmQgd2hpY2ggaXMg aW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIGl0cyBhZGRyZXNzZWUocykuIElmIHlv dSByZWNlaXZlIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSBzZW5kZXIgaW1t ZWRpYXRlbHkgYW5kIGRlc3Ryb3kgYW55IGNvcHkgdGhlcmVvZi4gRnVydGhlcm1vcmUsIGFueSBk aXNjbG9zdXJlLCBkaXN0cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlzIG1lc3NhZ2UgYW5kL29y IGFueSBhdHRhY2htZW50IGhlcmV0byB3aXRob3V0IHRoZSBjb25zZW50IG9mIHRoZSBzZW5kZXIg aXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gVGhhbmsgeW91Lg0KDQoNCi0tDQoNCkhlbnJpayBOeWRl bGwNClNyIFByb2R1Y3QgTWFuYWdlcg0KMS44NjYuNjg1LjgxODENCmhueWRlbGxAYWNjZWRpYW4u Y29tPG1haWx0bzpobnlkZWxsQGFjY2VkaWFuLmNvbT4NCltodHRwczovL2kueGluay5pby9JbWFn ZXMvR2V0L042MzgzMi9hNjUucG5nXTxodHRwOi8vYWNjZWRpYW4uY29tPg0KW2h0dHBzOi8vaS54 aW5rLmlvL0ltYWdlcy9HZXQvTjYzODMyL2Y5Ny5wbmddPGh0dHBzOi8vd3d3LmZhY2Vib29rLmNv bS9hY2NlZGlhbi8+IFtodHRwczovL2kueGluay5pby9JbWFnZXMvR2V0L042MzgzMi90OTkucG5n XSA8aHR0cHM6Ly90d2l0dGVyLmNvbS9BY2NlZGlhbj4gIFtodHRwczovL2kueGluay5pby9JbWFn ZXMvR2V0L042MzgzMi9sNTQucG5nXSA8aHR0cHM6Ly9jYS5saW5rZWRpbi5jb20vY29tcGFueS9h Y2NlZGlhbj4NCjxodHRwOi8vd3d3LmFjY2VkaWFuLmNvbT4NCmFjY2VkaWFuLmNvbTxodHRwOi8v YWNjZWRpYW4uY29tPg0KDQoNCkF2aXMgZGUgY29uZmlkZW50aWFsaXSopg0KDQpMZXMgaW5mb3Jt YXRpb25zIGNvbnRlbnVlcyBkYW5zIGxlIHByqKZzZW50IG1lc3NhZ2UgZXQgZGFucyB0b3V0ZSBw aaioY2UgcXVpIGx1aSBlc3Qgam9pbnRlIHNvbnQgY29uZmlkZW50aWVsbGVzIGV0IHBldXZlbnQg qLp0cmUgcHJvdKimZ6imZXMgcGFyIGxlIHNlY3JldCBwcm9mZXNzaW9ubmVsLiBDZXMgaW5mb3Jt YXRpb25zIHNvbnQgqKQgbKGvdXNhZ2UgZXhjbHVzaWYgZGUgc29uIG91IGRlIHNlcyBkZXN0aW5h dGFpcmVzLiBTaSB2b3VzIHJlY2V2ZXogY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBz oa9pbCB2b3VzIHBsYWl0IGNvbW11bmlxdWVyIGltbaimZGlhdGVtZW50IGF2ZWMgbKGvZXhwqKZk aXRldXIgZXQgZW4gZKimdHJ1aXJlIHRvdXQgZXhlbXBsYWlyZS4gRGUgcGx1cywgaWwgdm91cyBl c3Qgc3RyaWN0ZW1lbnQgaW50ZXJkaXQgZGUgbGUgZGl2dWxndWVyLCBkZSBsZSBkaXN0cmlidWVy IG91IGRlIGxlIHJlcHJvZHVpcmUgc2FucyBsoa9hdXRvcmlzYXRpb24gZGUgbKGvZXhwqKZkaXRl dXIuIE1lcmNpLg0KDQpDb25maWRlbnRpYWxpdHkgbm90aWNlDQoNClRoaXMgZS1tYWlsIG1lc3Nh Z2UgYW5kIGFueSBhdHRhY2htZW50IGhlcmV0byBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1h dGlvbiB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBhbmQgd2hpY2ggaXMgaW50ZW5kZWQgZm9yIHRo ZSBleGNsdXNpdmUgdXNlIG9mIGl0cyBhZGRyZXNzZWUocykuIElmIHlvdSByZWNlaXZlIHRoaXMg bWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRl c3Ryb3kgYW55IGNvcHkgdGhlcmVvZi4gRnVydGhlcm1vcmUsIGFueSBkaXNjbG9zdXJlLCBkaXN0 cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlzIG1lc3NhZ2UgYW5kL29yIGFueSBhdHRhY2htZW50 IGhlcmV0byB3aXRob3V0IHRoZSBjb25zZW50IG9mIHRoZSBzZW5kZXIgaXMgc3RyaWN0bHkgcHJv aGliaXRlZC4gVGhhbmsgeW91Lg0K --_000_3836af861e8c43b2843f083e5ec3c51ehuaweicom_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
        Hi Henrik,

        May I understand&= nbsp;what=A1=AFs the limits?
        The twamp or = ;lag? Or other?
        Actually both are=  supported in existing devices. As far a= s I know quite normal.

        Best,
        Tianran 





        Sent from WeLink<= /span>
        =B7=A2=BC=FE=C8=CB=A3=BA Henrik Nydell<hnydell@accedian.com>
        =CA=D5=BC=FE=C8=CB=A3=BA Tianran Zhou<zhoutianran@huawei.com>
        =B3=AD=CB=CD=A3=BA wangaj3<wangaj3@chinatelecom.cn>;IETF IPPM WG<ippm@ietf.org>
        =D6=F7=CC=E2=A3=BA Re: [ippm] FW: New Version Notification for = draft-li-ippm-otwamp-on-lag-02.txt
        =CA=B1=BC=E4=A3=BA 2022-01-27 18:15:39

        OK, but this require= s that the sender runs on the device that performs the LAG. This would be q= uite a serious limitation of the feature I believe

        On Thu, Jan 27, 2022 at 10:48 AM Tian= ran Zhou <zhoutianran@huawei.c= om> wrote:

        Hi Henrik,

         

        Both sender and reflector keep the mapping= between member link and the micro session. Either by configuration or nego= tiation or auto-learning.

        So, in your switch case, if the sender rec= eives the packet from C, not A, the sender know it=A1=AFs wrong. The test p= acket should be dropped and not counted.

         

        Best,

        Tianran

        From: Henrik Nydell [mailto:hnydell@accedian.com]
        Sent: Thursday, January 27, 2022 5:29 PM
        To: Tianran Zhou <zhoutianran@huawei.com>
        Cc: wan= gaj3@chinatelecom.cn; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [ippm] FW: New Version Notification for draft-li-ippm-o= twamp-on-lag-02.txt

         

        Thanks for the clarification, but this "member = link validation mechanism" depends fully on configuration between the = session sender and the session reflector right? So even if they have agreed= that a certain session ID belongs to lag link A, there is no way to be sure that this is the case, the intermediate swit= ches may place these packets randomly over links A-C and the TWAMP/OWAMP se= nder/reflectors will have no knowledge of this. So I dont know if this addi= tion adds much usefulnes over the already existing capabilities of TWAMP, where you can use the 5-tuple of p= ort-pair, IP-pair and TOS to differentiate session from each other.<= u>

         

         

        On Thu, Jan 27, 2022 at 2:37 AM Tianran Zhou <zhoutianran@huawei= .com> wrote:

        Hi Henrik,

         

        Thanks very much for your review.

        Your perspective is absolutely correct.

        This draft is not able to =A1=B0guarantee= =A1=B1 a specific LAG path. For example, there is a switch between the two = end points, or in the case the reflector is not capable.

        I.e., as you said, there is no "one m= ethod fits all" to guarantee the path.

         

        However, this draft seek another way round= , the member link validation mechanism.

        There is an assumption in the introduction= =A1=B0This document intends to address the scenario where a LAG directly c= onnects two nodes (A and B).=A1=B1

        With the member link validation, sender/re= flector will drop measurement data, when the test packet is not from the ex= pected member link.

        In this way, the measurement could always = be correct.

         

        This is somewhat similar to Paris Tracerou= te (https= ://paris-traceroute.net/about/), IMHO.

         

        Cheers,

        Tianran

         

        From: Henrik Nydell [mailto:hnydell@accedian.com]
        Sent: Wednesday, January 26, 2022 6:17 PM
        To: Tianran Zhou <zhoutianran@huawei.com>
        Cc: wan= gaj3@chinatelecom.cn; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [ippm] FW: New Version Notification for draft-li-ippm-o= twamp-on-lag-02.txt

         

        I had a brief review but failed to find details on h= ow the TWAMP sessions would be "guaranteed" to travel on a certai= n LAG segment. As far as I know the LAG implementation may be different bet= ween vendors and as such I know of no "one method fits all" to actually accomplish the measurement.

         

        So this draft does not actually provide any solution= to the problem of being able to measure LAG segments separately and determ= inistically.

         

        On Wed, Jan 26, 2022 at 11:03 AM Tianran Zhou <zh= outianran=3D40huawei.com@dmarc.ietf.org> wrote:

        Hi Anjun,

        Thanks very much for your interest and comments.
        Both are good questions.
        Please see in line.

        Cheers,
        Tianran

        -----Original Message-----
        From: wangaj3@= chinatelecom.cn [mailto:wangaj3@chinatelecom.cn]
        Sent: Wednesday, January 26, 2022 5:21 PM
        To: Tianran Zhou <zhoutianran@huawei.com>; 'IETF IPPM WG' <ippm@ietf.org>
        Subject: RE: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-o= n-lag-02.txt

        Hi, Tianran:

        Have a brief review of this draft. I think its aim is straightforward and w= ill be useful to utilize the member link within the LAG.
        Some comments are below:
        1) It seems there is no Sender/Reflector behavior description for the Mirco= OWAMP session and the packet format?


        ZTR> OWAMP is simple and there is no reflector. The sender cannot get th= e ack from the receiver. So we are not going to extend the OWAMP test packe= t.
        The behavior is described in section 3.2:
        " The micro OWAMP Sender MUST send the micro OWAMP-Test packets over t= he member link with which the session is associated. When receives a Test p= acket, the micro OWAMP receiver MUST use the member link from which the Tes= t packet is received to correlate the micro OWAMP session. If there is no such a session, the Test packet MUST b= e discarded. "

        2) For the newly defined Session-Sender Packet/Session-Reflector Packet, ho= w to assure the backward compatibility? What I have seen is that you add tw= o additional fields within the existing Packet?

        ZTR> I am not aware of the compatibility problem. If a node supports mic= ro session, it can understand the new packet extension. If a node does not = support micro session, it just ignores the new fields. Because the new fiel= ds is in the reserved zone.
        Moreover, the validation mechanism can figure out if the reflector can supp= ort the micro session.

        Best Regards

        Aijun Wang
        China Telecom

        -----Original Message-----
        From: ippm <i= ppm-bounces@ietf.org> On Behalf Of Tianran Zhou
        Sent: Monday, January 24, 2022 2:23 PM
        To: IETF IPPM WG (ippm@i= etf.org) <ippm@ie= tf.org>
        Subject: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-la= g-02.txt

        Hi WG,

        We think this is an useful work on adapting OWAMP/TWAMP in LAG performance = measurement.
        We updated this draft based on the comments from the meeting discussion and= mailing list.
        Thanks for all the suggestions.
        More reviews and comments are welcome.

        Cheers,
        Tianran

        -----Original Message-----
        From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
        Sent: Monday, January 24, 2022 2:17 PM
        To: Greg Mirsky <gregimirsky@gmail.com>; Guo Jun <guo.jun2@zte.com.cn>; Jun Guo <guo.jun2@zte.com.cn= >; Rakesh Gandhi <r= gandhi@cisco.com>; Tianran Zhou <zhoutianran@huawei.com>; Zhenqiang Li &l= t;li_zhenqian= g@hotmail.com>
        Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

        A new version of I-D, draft-li-ippm-otwamp-on-lag-02.txt
        has been successfully submitted by Tianran Zhou and posted to the IETF repo= sitory.

        Name:           draft-li-ippm-otwamp-on-lag Revision:       02
        Title:          One-way/Two-way Active Measurement= Protocol Extensions for
        Performance Measurement on LAG
        Document date:  2022-01-24
        Group:          Individual Submission
        Pages:          13
        URL:
        https://www.ietf.org/archive/id/draft-li-ippm-otwamp-= on-lag-02.txt
        Status:
        https://datatracker.ietf.org/doc/draft-li-ippm-otwamp-on-l= ag/
        Htmlized:
        https://datatracker.ietf.org/doc/html/draft-li-ippm-ot= wamp-on-lag
        Diff:
        https://www.ietf.org/rfcdiff?url2=3Ddraft-li-ippm-otw= amp-on-lag-02

        Abstract:
           This document defines extensions to One-way Active Measurement=
           Protocol (OWAMP), and Two-way Active Measurement Protocol (TWA= MP) to
           implement performance measurement on every member link of a Li= nk
           Aggregation Group (LAG).  Knowing the measured metrics of= each member
           link of a LAG enables operators to enforce the performance bas= ed
           traffic steering policy across the member links.





        The IETF Secretariat


        _______________________________________________
        ippm mailing list
        ippm@ietf.org
        ht= tps://www.ietf.org/mailman/listinfo/ippm

        _______________________________________________
        ippm mailing list
        ippm@ietf.org
        ht= tps://www.ietf.org/mailman/listinfo/ippm


         

        --


        Henrik Nydell
        Sr Product Manager
        1.866.685.8181
        hnydell@accedian.= com

          

        a= ccedian.com

         

        Avis de confidentialit=A8= =A6

        Les informations contenue= s dans le pr=A8=A6sent message et dans toute pi=A8=A8ce qui lui est jointe = sont confidentielles et peuvent =A8=BAtre prot=A8=A6g=A8=A6es par le secret= professionnel. Ces informations sont =A8=A4 l=A1=AFusage exclusif de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez s= =A1=AFil vous plait communiquer imm=A8=A6diatement avec l=A1=AFexp=A8=A6dit= eur et en d=A8=A6truire tout exemplaire. De plus, il vous est strictement i= nterdit de le divulguer, de le distribuer ou de le reproduire sans l=A1=AFautorisation de l=A1=AFexp=A8=A6diteur. Merci.

        Confidentiality notice

        This e-mail message and any attachment h= ereto contain confidential information which may be privileged and which is= intended for the exclusive use of its addressee(s). If you receive this me= ssage in error, please inform sender immediately and destroy any copy thereof. Furthermore, any disclosure, dis= tribution or copying of this message and/or any attachment hereto without t= he consent of the sender is strictly prohibited. Thank you.


         

        --


        Henrik Nydell
        Sr Product Manager
        1.866.685.8181
        hnydell@accedian.= com

          

        a= ccedian.com

         

        Avis de confidentialit=A8= =A6

        Les informations contenue= s dans le pr=A8=A6sent message et dans toute pi=A8=A8ce qui lui est jointe = sont confidentielles et peuvent =A8=BAtre prot=A8=A6g=A8=A6es par le secret= professionnel. Ces informations sont =A8=A4 l=A1=AFusage exclusif de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez s= =A1=AFil vous plait communiquer imm=A8=A6diatement avec l=A1=AFexp=A8=A6dit= eur et en d=A8=A6truire tout exemplaire. De plus, il vous est strictement i= nterdit de le divulguer, de le distribuer ou de le reproduire sans l=A1=AFautorisation de l=A1=AFexp=A8=A6diteur. Merci.

        Confidentiality notice

        This e-mail message and any attachment h= ereto contain confidential information which may be privileged and which is= intended for the exclusive use of its addressee(s). If you receive this me= ssage in error, please inform sender immediately and destroy any copy thereof. Furthermore, any disclosure, dis= tribution or copying of this message and/or any attachment hereto without t= he consent of the sender is strictly prohibited. Thank you.



        --

        Henrik Nydell
        Sr Product Manager
        1.866.685.8181
        hnydell@accedian.= com
        3D""
        =3D"" 3D"" 3D""
        3D""
        accedian.com=

        Avis de confidentialit=A8=A6

        Les informations contenues dans le= pr=A8=A6sent message et dans toute pi=A8=A8ce qui lui est jointe sont conf= identielles et peuvent =A8=BAtre prot=A8=A6g=A8=A6es par le secret professi= onnel. Ces informations sont =A8=A4 l=A1=AFusage exclusif de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez s=A1=AF= il vous plait communiquer imm=A8=A6diatement avec l=A1=AFexp=A8=A6diteur et= en d=A8=A6truire tout exemplaire. De plus, il vous est strictement interdi= t de le divulguer, de le distribuer ou de le reproduire sans l=A1=AFautorisation de l=A1=AFexp=A8=A6diteur. Merci.

        Confidentiality notice

        This e-mail message and any attachment hereto contain c= onfidential information which may be privileged and which is intended for t= he exclusive use of its addressee(s). If you receive this message in error,= please inform sender immediately and destroy any copy thereof. Furthermore, any disclosure, distribution or= copying of this message and/or any attachment hereto without the consent o= f the sender is strictly prohibited. Thank you.

        --_000_3836af861e8c43b2843f083e5ec3c51ehuaweicom_-- From nobody Thu Jan 27 04:20:47 2022 Return-Path: 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 B99A33A085B for ; Thu, 27 Jan 2022 04:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=accedian.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ODwClGc0C_L for ; Thu, 27 Jan 2022 04:20:40 -0800 (PST) Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39EE93A085A for ; Thu, 27 Jan 2022 04:20:40 -0800 (PST) Received: by mail-yb1-xb33.google.com with SMTP id r65so8009697ybc.11 for ; Thu, 27 Jan 2022 04:20:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=accedian.com; s=corp1; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q/lmToyVlDjgeEJ4fRXsvNmJxIXJ2R0fFjBUEdYOQgQ=; b=EuNgvmrnntt9DGPKNU2JF0VBoM626C80b6DpaobTk3QlU13qymi81bPXdbNRJwM1Ft DlIpjeEZTNqUGgeU17J4t+w1cO9Io11Xve+xcx4j5Jfc17WP9CktMK6C4kPOSaMVX1xN kFw5aUaFieGwqaDG9wz2MO/56ih0QC2d7ih0hF3OddQemY1XfTsRDCtRiKOUnm6/5WcG IGXW8EbMIVOaRyEczSP2irf03ka55aOUuVsGd+hVerYV4QcvtE7os1SRLF1v2tMFPrp3 nUieyw4HQwY0pWZgng9NV1mNt04CTgrPpeOi6H3IAZ22CRW1p+9FG4FhVe8xEz6RiCiq 6Vkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Q/lmToyVlDjgeEJ4fRXsvNmJxIXJ2R0fFjBUEdYOQgQ=; b=wW6nJOlcwriTAv6cDxT8nTbbSrdOMrnAhkL7i1t8G+dheGk4FS56gGc85xjrhg9FoA 4Jm99Nm+K5hxoOch4stH/b+3j7VOqIcHkXwSpSI142GFQR6eg7zVh9JU3nFGxelI5FOr Ij+0oBF8Ni4aaaYUGlqmOQq/nORC1xuxZFIC48Ry54TAOyZqYkvBxLRPL834uyn+Gjwb 54uZWrATdpneZkFX6icREhK1VJYiSWgF+jH2CsGn7YFvUOWk54I2RaB2G4ENdm75a5XO GOa6DpsBGUi5oNMxXkTFlFrX97MMluD6PghXa51XIhdejQrwDs+N6eJ2oqo2NEJ6YL4V zUhA== X-Gm-Message-State: AOAM532Fm4T5YKjHfKD4/x/H6EKf9VKy4cONgPUcGGV40IC5u3MPjX1H VaN+LEzNMgUmjt6cloduqGrvP2rW6vDGlIdtxe7v+PL+BapUIgnbo15TFH8tSep91SKifW/vzmu i7gzQmY7aUg== X-Google-Smtp-Source: ABdhPJwoXe+tUuphc4whfDLT+d87miAbTYsw5ai8sw0YjdskoTAm8gMN+zhNxZGacJaThB+c7eHtMsFhQCi1AALDItU= X-Received: by 2002:a25:9f83:: with SMTP id u3mr5324876ybq.474.1643286037976; Thu, 27 Jan 2022 04:20:37 -0800 (PST) MIME-Version: 1.0 References: <164300504281.12619.16642699818590435984@ietfa.amsl.com> <015a01d81295$fdd37370$f97a5a50$@chinatelecom.cn> <70c388c86215411796ef55d48711b216@huawei.com> <3a33416375314462af22d1837e8472dc@huawei.com> <26d83b5f046a439785f52d9599209c95@huawei.com> <3836af861e8c43b2843f083e5ec3c51e@huawei.com> In-Reply-To: <3836af861e8c43b2843f083e5ec3c51e@huawei.com> From: Henrik Nydell Date: Thu, 27 Jan 2022 13:20:20 +0100 Message-ID: To: Tianran Zhou Cc: wangaj3 , IETF IPPM WG Content-Type: multipart/alternative; boundary="0000000000008ef02505d68f5878" Archived-At: Subject: Re: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2022 12:20:46 -0000 --0000000000008ef02505d68f5878 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In my mind TWAMP, being a layer-3 method, is more commonly used on longer e-2-e layer3 connections, for example sender from a central core site out to a reflector on a radio base station. The path between may have several layer3 hops and many layer-2. If there is LAG somewhere there in the middle of the path, how will this draft help? On Thu, Jan 27, 2022 at 12:48 PM Tianran Zhou wrote: > Hi Henrik, > > May I understand what=E2=80=99s the limits? > The twamp or lag? Or other? > > Actually both are supported in existing devices. As far as I know quite n= ormal. > > Best, > Tianran > > > > > ------------------------------ > > Sent from WeLink > *=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A *Henrik Nydell > *=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A *Tianran Zhou > *=E6=8A=84=E9=80=81=EF=BC=9A *wangaj3;IETF IPPM = WG > *=E4=B8=BB=E9=A2=98=EF=BC=9A *Re: [ippm] FW: New Version Notification for > draft-li-ippm-otwamp-on-lag-02.txt > *=E6=97=B6=E9=97=B4=EF=BC=9A *2022-01-27 18:15:39 > > OK, but this requires that the sender runs on the device that performs th= e > LAG. This would be quite a serious limitation of the feature I believe > > On Thu, Jan 27, 2022 at 10:48 AM Tianran Zhou > wrote: > >> Hi Henrik, >> >> >> >> Both sender and reflector keep the mapping between member link and the >> micro session. Either by configuration or negotiation or auto-learning. >> >> So, in your switch case, if the sender receives the packet from C, not A= , >> the sender know it=E2=80=99s wrong. The test packet should be dropped an= d not >> counted. >> >> >> >> Best, >> >> Tianran >> >> *From:* Henrik Nydell [mailto:hnydell@accedian.com] >> *Sent:* Thursday, January 27, 2022 5:29 PM >> *To:* Tianran Zhou >> *Cc:* wangaj3@chinatelecom.cn; IETF IPPM WG >> *Subject:* Re: [ippm] FW: New Version Notification for >> draft-li-ippm-otwamp-on-lag-02.txt >> >> >> >> Thanks for the clarification, but this "member link validation mechanism= " >> depends fully on configuration between the session sender and the sessio= n >> reflector right? So even if they have agreed that a certain session ID >> belongs to lag link A, there is no way to be sure that this is the case, >> the intermediate switches may place these packets randomly over links A-= C >> and the TWAMP/OWAMP sender/reflectors will have no knowledge of this. So= I >> dont know if this addition adds much usefulnes over the already existing >> capabilities of TWAMP, where you can use the 5-tuple of port-pair, IP-pa= ir >> and TOS to differentiate session from each other. >> >> >> >> >> >> On Thu, Jan 27, 2022 at 2:37 AM Tianran Zhou >> wrote: >> >> Hi Henrik, >> >> >> >> Thanks very much for your review. >> >> Your perspective is absolutely correct. >> >> This draft is not able to =E2=80=9Cguarantee=E2=80=9D a specific LAG pat= h. For example, >> there is a switch between the two end points, or in the case the reflect= or >> is not capable. >> >> I.e., as you said, there is no "one method fits all" to guarantee the >> path. >> >> >> >> However, this draft seek another way round, the member link validation >> mechanism. >> >> There is an assumption in the introduction =E2=80=9CThis document intend= s to >> address the scenario where a LAG directly connects two nodes (A and B).= =E2=80=9D >> >> With the member link validation, sender/reflector will drop measurement >> data, when the test packet is not from the expected member link. >> >> In this way, the measurement could always be correct. >> >> >> >> This is somewhat similar to Paris Traceroute ( >> https://paris-traceroute.net/about/), IMHO. >> >> >> >> Cheers, >> >> Tianran >> >> >> >> *From:* Henrik Nydell [mailto:hnydell@accedian.com] >> *Sent:* Wednesday, January 26, 2022 6:17 PM >> *To:* Tianran Zhou >> *Cc:* wangaj3@chinatelecom.cn; IETF IPPM WG >> *Subject:* Re: [ippm] FW: New Version Notification for >> draft-li-ippm-otwamp-on-lag-02.txt >> >> >> >> I had a brief review but failed to find details on how the TWAMP session= s >> would be "guaranteed" to travel on a certain LAG segment. As far as I kn= ow >> the LAG implementation may be different between vendors and as such I kn= ow >> of no "one method fits all" to actually accomplish the measurement. >> >> >> >> So this draft does not actually provide any solution to the problem of >> being able to measure LAG segments separately and deterministically. >> >> >> >> On Wed, Jan 26, 2022 at 11:03 AM Tianran Zhou > 40huawei.com@dmarc.ietf.org> wrote: >> >> Hi Anjun, >> >> Thanks very much for your interest and comments. >> Both are good questions. >> Please see in line. >> >> Cheers, >> Tianran >> >> -----Original Message----- >> From: wangaj3@chinatelecom.cn [mailto:wangaj3@chinatelecom.cn] >> Sent: Wednesday, January 26, 2022 5:21 PM >> To: Tianran Zhou ; 'IETF IPPM WG' >> Subject: RE: [ippm] FW: New Version Notification for >> draft-li-ippm-otwamp-on-lag-02.txt >> >> Hi, Tianran: >> >> Have a brief review of this draft. I think its aim is straightforward an= d >> will be useful to utilize the member link within the LAG. >> Some comments are below: >> 1) It seems there is no Sender/Reflector behavior description for the >> Mirco OWAMP session and the packet format? >> >> >> ZTR> OWAMP is simple and there is no reflector. The sender cannot get th= e >> ack from the receiver. So we are not going to extend the OWAMP test pack= et. >> The behavior is described in section 3.2: >> " The micro OWAMP Sender MUST send the micro OWAMP-Test packets over the >> member link with which the session is associated. When receives a Test >> packet, the micro OWAMP receiver MUST use the member link from which the >> Test packet is received to correlate the micro OWAMP session. If there i= s >> no such a session, the Test packet MUST be discarded. " >> >> 2) For the newly defined Session-Sender Packet/Session-Reflector Packet, >> how to assure the backward compatibility? What I have seen is that you a= dd >> two additional fields within the existing Packet? >> >> ZTR> I am not aware of the compatibility problem. If a node supports >> micro session, it can understand the new packet extension. If a node doe= s >> not support micro session, it just ignores the new fields. Because the n= ew >> fields is in the reserved zone. >> Moreover, the validation mechanism can figure out if the reflector can >> support the micro session. >> >> Best Regards >> >> Aijun Wang >> China Telecom >> >> -----Original Message----- >> From: ippm On Behalf Of Tianran Zhou >> Sent: Monday, January 24, 2022 2:23 PM >> To: IETF IPPM WG (ippm@ietf.org) >> Subject: [ippm] FW: New Version Notification for >> draft-li-ippm-otwamp-on-lag-02.txt >> >> Hi WG, >> >> We think this is an useful work on adapting OWAMP/TWAMP in LAG >> performance measurement. >> We updated this draft based on the comments from the meeting discussion >> and mailing list. >> Thanks for all the suggestions. >> More reviews and comments are welcome. >> >> Cheers, >> Tianran >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Monday, January 24, 2022 2:17 PM >> To: Greg Mirsky ; Guo Jun ; >> Jun Guo ; Rakesh Gandhi ; >> Tianran Zhou ; Zhenqiang Li < >> li_zhenqiang@hotmail.com> >> Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt >> >> >> A new version of I-D, draft-li-ippm-otwamp-on-lag-02.txt >> has been successfully submitted by Tianran Zhou and posted to the IETF >> repository. >> >> Name: draft-li-ippm-otwamp-on-lag >> Revision: 02 >> Title: One-way/Two-way Active Measurement Protocol Extensions f= or >> Performance Measurement on LAG >> Document date: 2022-01-24 >> Group: Individual Submission >> Pages: 13 >> URL: >> https://www.ietf.org/archive/id/draft-li-ippm-otwamp-on-lag-02.txt >> Status: >> https://datatracker.ietf.org/doc/draft-li-ippm-otwamp-on-lag/ >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-li-ippm-otwamp-on-lag >> Diff: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-li-ippm-otwamp-on-lag-02 >> >> Abstract: >> This document defines extensions to One-way Active Measurement >> Protocol (OWAMP), and Two-way Active Measurement Protocol (TWAMP) to >> implement performance measurement on every member link of a Link >> Aggregation Group (LAG). Knowing the measured metrics of each member >> link of a LAG enables operators to enforce the performance based >> traffic steering policy across the member links. >> >> >> >> >> >> The IETF Secretariat >> >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> >> >> >> >> -- >> >> >> *Henrik Nydell* >> *Sr Product Manager* >> 1.866.685.8181 >> hnydell@accedian.com >> >> >> >> >> *accedian.com * >> >> >> >> Avis de confidentialit=C3=A9 >> >> Les informations contenues dans le pr=C3=A9sent message et dans toute pi= =C3=A8ce >> qui lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g= =C3=A9es par le >> secret professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclu= sif de son ou de >> ses destinataires. Si vous recevez ce message par erreur, veuillez s=E2= =80=99il >> vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3=A9diteur= et en d=C3=A9truire tout >> exemplaire. De plus, il vous est strictement interdit de le divulguer, d= e >> le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80= =99exp=C3=A9diteur. >> Merci. >> >> Confidentiality notice >> >> This e-mail message and any attachment hereto contain confidential >> information which may be privileged and which is intended for the exclus= ive >> use of its addressee(s). If you receive this message in error, please >> inform sender immediately and destroy any copy thereof. Furthermore, any >> disclosure, distribution or copying of this message and/or any attachmen= t >> hereto without the consent of the sender is strictly prohibited. Thank y= ou. >> >> >> >> >> -- >> >> >> *Henrik Nydell* >> *Sr Product Manager* >> 1.866.685.8181 >> hnydell@accedian.com >> >> >> >> >> *accedian.com * >> >> >> >> Avis de confidentialit=C3=A9 >> >> Les informations contenues dans le pr=C3=A9sent message et dans toute pi= =C3=A8ce >> qui lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g= =C3=A9es par le >> secret professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclu= sif de son ou de >> ses destinataires. Si vous recevez ce message par erreur, veuillez s=E2= =80=99il >> vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3=A9diteur= et en d=C3=A9truire tout >> exemplaire. De plus, il vous est strictement interdit de le divulguer, d= e >> le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80= =99exp=C3=A9diteur. >> Merci. >> >> Confidentiality notice >> >> This e-mail message and any attachment hereto contain confidential >> information which may be privileged and which is intended for the exclus= ive >> use of its addressee(s). If you receive this message in error, please >> inform sender immediately and destroy any copy thereof. Furthermore, any >> disclosure, distribution or copying of this message and/or any attachmen= t >> hereto without the consent of the sender is strictly prohibited. Thank y= ou. >> > > > -- > > *Henrik Nydell* > *Sr Product Manager* > 1.866.685.8181 > hnydell@accedian.com > > > > > *accedian.com * > > Avis de confidentialit=C3=A9 > > Les informations contenues dans le pr=C3=A9sent message et dans toute pi= =C3=A8ce qui > lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3= =A9es par le secret > professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de s= on ou de ses > destinataires. Si vous recevez ce message par erreur, veuillez s=E2=80=99= il vous > plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3=A9diteur et en= d=C3=A9truire tout > exemplaire. De plus, il vous est strictement interdit de le divulguer, de > le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80= =99exp=C3=A9diteur. > Merci. > > Confidentiality notice > > This e-mail message and any attachment hereto contain confidential > information which may be privileged and which is intended for the exclusi= ve > use of its addressee(s). If you receive this message in error, please > inform sender immediately and destroy any copy thereof. Furthermore, any > disclosure, distribution or copying of this message and/or any attachment > hereto without the consent of the sender is strictly prohibited. Thank yo= u. > --=20 *Henrik Nydell* *Sr Product Manager* 1.866.685.8181 hnydell@accedian.com *accedian.com * --=20 Avis de confidentialit=C3=A9 Les informations contenues dans le pr=C3=A9sent=20 message et dans toute pi=C3=A8ce qui=20 lui est jointe sont confidentielles et=20 peuvent =C3=AAtre prot=C3=A9g=C3=A9es par le=20 secret professionnel. Ces informations sont=20 =C3=A0 l=E2=80=99usage exclusif de son ou de ses destinataires. Si vous recevez ce=20 message par erreur, veuillez=20 s=E2=80=99il vous plait communiquer imm=C3=A9diatement=20 avec l=E2=80=99exp=C3=A9diteur et en=20 d=C3=A9truire tout exemplaire. De plus, il vous est=20 strictement interdit de=20 le divulguer, de le distribuer ou de le reproduire=20 sans l=E2=80=99autorisation=20 de l=E2=80=99exp=C3=A9diteur. Merci. Confidentiality notice This e-mail message and any attachment hereto contain confidential=20 information=20 which may be privileged and which is intended for the=20 exclusive use of its=20 addressee(s). If you receive this message in error, please inform sender=20 immediately and destroy any copy thereof.=20 Furthermore, any disclosure,=20 distribution or copying of this message=20 and/or any attachment hereto=20 without the consent of the sender is=20 strictly prohibited. Thank you. --0000000000008ef02505d68f5878 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
        In = my mind TWAMP, being a layer-3 method, is more commonly used on longer e-2-= e layer3 connections, for example sender from a central core site out to a = reflector on a radio base station. The path between may have several layer3= hops and many layer-2. If there is LAG somewhere there in the middle of th= e path, how will this draft help?


        On Thu, Jan 27, 2022 at 12:48 PM Tianran Zho= u <zhoutianran@huawei.com&= gt; wrote:
        Hi=C2=A0Henrik,
        May=C2=A0I=C2=A0understa= nd=C2=A0what=E2=80=99s=C2=A0the=C2=A0limits?
        The=C2=A0twamp=C2=A0or= =C2=A0lag?=C2=A0Or=C2=A0other?
        Actually=C2=A0both=C2=A0= are=C2=A0supported=C2=A0in=C2=A0existing=C2=A0devices.=C2=A0As=C2=A0far=C2= =A0as=C2=A0I=C2=A0know=C2=A0quite=C2=A0normal.

        Best,
        Tianran=C2=A0





        Sent=C2=A0from=C2=A0WeLi= nk
        OK, but this require= s that the sender runs on the device that performs the LAG. This would be q= uite a serious limitation of the feature I believe

        On Thu, Jan 27, 2022 at 10:48 AM Tian= ran Zhou <zh= outianran@huawei.com> wrote:

        Hi Henrik,

        =C2=A0

        Both sender and reflector keep the mapping b= etween member link and the micro session. Either by configuration or negoti= ation or auto-learning.

        So, in your switch case, if the sender recei= ves the packet from C, not A, the sender know it=E2=80=99s wrong. The test = packet should be dropped and not counted.

        =C2=A0

        Best,

        Tianran

        From: Henrik Nydell [mailto:hnydell@accedian.com]
        Sent: Thursday, January 27, 2022 5:29 PM
        To: Tianran Zhou <zhoutianran@huawei.com>
        Cc: wan= gaj3@chinatelecom.cn; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [ippm] FW: New Version Notification for draft-li-ippm-o= twamp-on-lag-02.txt

        =C2=A0

        Thanks for the clarification, but this "member = link validation mechanism" depends fully on configuration between the = session sender and the session reflector right? So even if they have agreed= that a certain session ID belongs=C2=A0to lag link A, there is no way to be sure that this is the case, the intermediate swit= ches may place these packets randomly over links A-C and the TWAMP/OWAMP se= nder/reflectors will have no knowledge of this. So I dont know if this addi= tion adds much usefulnes over the already existing capabilities of TWAMP, where you can use the 5-tuple of p= ort-pair, IP-pair and TOS to differentiate session from each other.<= u>

        =C2=A0

        =C2=A0

        On Thu, Jan 27, 2022 at 2:37 AM Tianran Zhou <zhoutianran@huawei= .com> wrote:

        Hi Henrik,

        =C2=A0

        Thanks very much for your review.<= /u>

        Your perspective is absolutely correct.

        This draft is not able to =E2=80=9Cguarantee= =E2=80=9D a specific LAG path. For example, there is a switch between the t= wo end points, or in the case the reflector is not capable.

        I.e., as you said, there is no "one met= hod fits all" to guarantee the path.

        =C2=A0

        However, this draft seek another way round, = the member link validation mechanism.

        There is an assumption in the introduction = =E2=80=9CThis document intends to address the scenario where a LAG directly= connects two nodes (A and B).=E2=80=9D

        With the member link validation, sender/refl= ector will drop measurement data, when the test packet is not from the expe= cted member link.

        In this way, the measurement could always be= correct.

        =C2=A0

        This is somewhat similar to Paris Traceroute= (https:/= /paris-traceroute.net/about/), IMHO.

        =C2=A0

        Cheers,

        Tianran

        =C2=A0

        From: Henrik Nydell [mailto:hnydell@accedian.com]
        Sent: Wednesday, January 26, 2022 6:17 PM
        To: Tianran Zhou <zhoutianran@huawei.com>
        Cc: wan= gaj3@chinatelecom.cn; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [ippm] FW: New Version Notification for draft-li-ippm-o= twamp-on-lag-02.txt

        =C2=A0

        I had a brief review but failed to find details on h= ow the TWAMP sessions would be "guaranteed" to travel on a certai= n LAG segment. As far as I know the LAG implementation may be different bet= ween vendors and as such I know of no "one method fits all" to actually accomplish the measurement.

        =C2=A0

        So this draft does not actually provide any solution= to the problem of being able to measure LAG segments separately and determ= inistically.

        =C2=A0

        On Wed, Jan 26, 2022 at 11:03 AM Tianran Zhou <zh= outianran=3D40huawei.com@dmarc.ietf.org> wrote:

        Hi Anjun,

        Thanks very much for your interest and comments.
        Both are good questions.
        Please see in line.

        Cheers,
        Tianran

        -----Original Message-----
        From: wangaj3@= chinatelecom.cn [mailto:wangaj3@chinatelecom.cn]
        Sent: Wednesday, January 26, 2022 5:21 PM
        To: Tianran Zhou <zhoutianran@huawei.com>; 'IETF IPPM WG' <ippm@ietf.org>
        Subject: RE: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-o= n-lag-02.txt

        Hi, Tianran:

        Have a brief review of this draft. I think its aim is straightforward and w= ill be useful to utilize the member link within the LAG.
        Some comments are below:
        1) It seems there is no Sender/Reflector behavior description for the Mirco= OWAMP session and the packet format?


        ZTR> OWAMP is simple and there is no reflector. The sender cannot get th= e ack from the receiver. So we are not going to extend the OWAMP test packe= t.
        The behavior is described in section 3.2:
        " The micro OWAMP Sender MUST send the micro OWAMP-Test packets over t= he member link with which the session is associated. When receives a Test p= acket, the micro OWAMP receiver MUST use the member link from which the Tes= t packet is received to correlate the micro OWAMP session. If there is no such a session, the Test packet MUST b= e discarded. "

        2) For the newly defined Session-Sender Packet/Session-Reflector Packet, ho= w to assure the backward compatibility? What I have seen is that you add tw= o additional fields within the existing Packet?

        ZTR> I am not aware of the compatibility problem. If a node supports mic= ro session, it can understand the new packet extension. If a node does not = support micro session, it just ignores the new fields. Because the new fiel= ds is in the reserved zone.
        Moreover, the validation mechanism can figure out if the reflector can supp= ort the micro session.

        Best Regards

        Aijun Wang
        China Telecom

        -----Original Message-----
        From: ippm <i= ppm-bounces@ietf.org> On Behalf Of Tianran Zhou
        Sent: Monday, January 24, 2022 2:23 PM
        To: IETF IPPM WG (ippm@i= etf.org) <ippm@ie= tf.org>
        Subject: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-la= g-02.txt

        Hi WG,

        We think this is an useful work on adapting OWAMP/TWAMP in LAG performance = measurement.
        We updated this draft based on the comments from the meeting discussion and= mailing list.
        Thanks for all the suggestions.
        More reviews and comments are welcome.

        Cheers,
        Tianran

        -----Original Message-----
        From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
        Sent: Monday, January 24, 2022 2:17 PM
        To: Greg Mirsky <gregimirsky@gmail.com>; Guo Jun <guo.jun2@zte.com.cn>; Jun Guo <guo.jun2@zte.com.cn= >; Rakesh Gandhi <r= gandhi@cisco.com>; Tianran Zhou <zhoutianran@huawei.com>; Zhenqiang Li &l= t;li_zhenqian= g@hotmail.com>
        Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

        A new version of I-D, draft-li-ippm-otwamp-on-lag-02.txt
        has been successfully submitted by Tianran Zhou and posted to the IETF repo= sitory.

        Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-li-ippm-otwamp-on-lag Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
        Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 One-way/Two-way Active Measurement= Protocol Extensions for
        Performance Measurement on LAG
        Document date:=C2=A0 2022-01-24
        Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
        Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 13
        URL:
        https://www.ietf.org/archive/id/draft-li-ippm-otwamp-= on-lag-02.txt
        Status:
        https://datatracker.ietf.org/doc/draft-li-ippm-otwamp-on-l= ag/
        Htmlized:
        https://datatracker.ietf.org/doc/html/draft-li-ippm-ot= wamp-on-lag
        Diff:
        https://www.ietf.org/rfcdiff?url2=3Ddraft-li-ippm-otw= amp-on-lag-02

        Abstract:
        =C2=A0 =C2=A0This document defines extensions to One-way Active Measurement=
        =C2=A0 =C2=A0Protocol (OWAMP), and Two-way Active Measurement Protocol (TWA= MP) to
        =C2=A0 =C2=A0implement performance measurement on every member link of a Li= nk
        =C2=A0 =C2=A0Aggregation Group (LAG).=C2=A0 Knowing the measured metrics of= each member
        =C2=A0 =C2=A0link of a LAG enables operators to enforce the performance bas= ed
        =C2=A0 =C2=A0traffic steering policy across the member links.





        The IETF Secretariat


        _______________________________________________
        ippm mailing list
        ippm@ietf.org
        ht= tps://www.ietf.org/mailman/listinfo/ippm

        _______________________________________________
        ippm mailing list
        ippm@ietf.org
        ht= tps://www.ietf.org/mailman/listinfo/ippm


        =C2=A0

        --


        Henrik Nydell
        Sr Product Manager
        1.866.685.8181
        hnydell@accedian.= com
        =
        =C2=A0=C2=A0

        acc= edian.com

        =C2=A0

        Avis de confidentialit=C3= =A9

        Les informations contenue= s dans le pr=C3=A9sent message et dans toute pi=C3=A8ce qui lui est jointe = sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9es par le secret= professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de so= n ou de ses destinataires. Si vous recevez ce message par erreur, veuillez s= =E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3= =A9diteur et en d=C3=A9truire tout exemplaire. De plus, il vous est stricte= ment interdit de le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80=99exp=C3=A9diteur. Merci.=

        Confidentiality notice

        This e-mail message and any attachment h= ereto contain confidential information which may be privileged and which is= intended for the exclusive use of its addressee(s). If you receive this me= ssage in error, please inform sender immediately and destroy any copy thereof. Furthermore, any disclosure, dis= tribution or copying of this message and/or any attachment hereto without t= he consent of the sender is strictly prohibited. Thank you.


        =C2=A0

        --


        Henrik Nydell
        Sr Product Manager
        1.866.685.8181
        hnydell@accedian.= com

        =C2=A0=C2=A0

        acc= edian.com

        =C2=A0

        Avis de confidentialit=C3= =A9

        Les informations contenue= s dans le pr=C3=A9sent message et dans toute pi=C3=A8ce qui lui est jointe = sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9es par le secret= professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de so= n ou de ses destinataires. Si vous recevez ce message par erreur, veuillez s= =E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3= =A9diteur et en d=C3=A9truire tout exemplaire. De plus, il vous est stricte= ment interdit de le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80=99exp=C3=A9diteur. Merci.=

        Confidentiality notice

        This e-mail message and any attachment h= ereto contain confidential information which may be privileged and which is= intended for the exclusive use of its addressee(s). If you receive this me= ssage in error, please inform sender immediately and destroy any copy thereof. Furthermore, any disclosure, dis= tribution or copying of this message and/or any attachment hereto without t= he consent of the sender is strictly prohibited. Thank you.



        --

        Henrik Nydell
        Sr Product Manager
        1.866.685.8181
        hnydell@accedian.= com
        3D""
        =3D""=C2=A03D""=C2=A03D""
        3D""
        accedian.com=

        Avis de confidentialit=C3=A9

        Les informations contenues dans le= pr=C3=A9sent message et dans toute pi=C3=A8ce qui lui est jointe sont conf= identielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9es par le secret professi= onnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez s=E2=80= =99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3=A9dit= eur et en d=C3=A9truire tout exemplaire. De plus, il vous est strictement i= nterdit de le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80=99exp=C3=A9diteur. Merci.<= /p>

        Confidentiality notice

        This e-mail message and any attachment hereto contain c= onfidential information which may be privileged and which is intended for t= he exclusive use of its addressee(s). If you receive this message in error,= please inform sender immediately and destroy any copy thereof. Furthermore, any disclosure, distribution or= copying of this message and/or any attachment hereto without the consent o= f the sender is strictly prohibited. Thank you.



        --

        Henrik Nydell
        Sr Product Manager
        1.866.685.8181
        hnydell@accedian.= com
        3D""
        =3D""=C2=A03D""=C2=A03D""
        3D""
        accedian.com=

        Avis de confidentialit=C3=A9

        Les informations contenues dans le pr=C3=A9sent message et dans toute pi=C3=A8= ce qui=20 lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9e= s par le=20 secret professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif= de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez=20 s=E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp= =C3=A9diteur et en=20 d=C3=A9truire tout exemplaire. De plus, il vous est strictement interdit de= =20 le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisat= ion=20 de l=E2=80=99exp=C3=A9diteur. Merci.

        Confidentiality notice

        This e-mail message and any attachment hereto contain confidential=20 information which may be privileged and which is intended for the=20 exclusive use of its addressee(s). If you receive this message in error, please inform sender immediately and destroy any copy thereof.=20 Furthermore, any disclosure, distribution or copying of this message=20 and/or any attachment hereto without the consent of the sender is=20 strictly prohibited. Thank you.

        --0000000000008ef02505d68f5878-- From nobody Thu Jan 27 04:37:00 2022 Return-Path: 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 EBBEF3A09DD for ; Thu, 27 Jan 2022 04:36:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNvTX27ali1T for ; Thu, 27 Jan 2022 04:36:52 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C0273A09DA for ; Thu, 27 Jan 2022 04:36:52 -0800 (PST) Received: from fraeml740-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Jl0P93k7Cz689QP for ; Thu, 27 Jan 2022 20:33:17 +0800 (CST) Received: from kwepeml100006.china.huawei.com (7.221.188.192) by fraeml740-chm.china.huawei.com (10.206.15.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Thu, 27 Jan 2022 13:36:47 +0100 Received: from kwepeml500004.china.huawei.com (7.221.188.141) by kwepeml100006.china.huawei.com (7.221.188.192) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Thu, 27 Jan 2022 20:36:46 +0800 Received: from kwepeml500004.china.huawei.com ([7.221.188.141]) by kwepeml500004.china.huawei.com ([7.221.188.141]) with mapi id 15.01.2308.021; Thu, 27 Jan 2022 20:36:46 +0800 From: Tianran Zhou To: Henrik Nydell CC: wangaj3 , IETF IPPM WG Thread-Topic: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt Thread-Index: AQHYEOoOM8BWGUje9EistfVjjUvI2qxxspuggALRbQCAAI1nUP//gkoAgAF/fcCAAAVcAIAAidVA//+DMYCAAKAqHv//gs0AABFWj0I= Date: Thu, 27 Jan 2022 12:36:46 +0000 Message-ID: References: <164300504281.12619.16642699818590435984@ietfa.amsl.com> <015a01d81295$fdd37370$f97a5a50$@chinatelecom.cn> <70c388c86215411796ef55d48711b216@huawei.com> <3a33416375314462af22d1837e8472dc@huawei.com> <26d83b5f046a439785f52d9599209c95@huawei.com> <3836af861e8c43b2843f083e5ec3c51e@huawei.com>, In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_fcac32a905284eed866d8ffba9f1d0f1huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2022 12:36:58 -0000 --_000_fcac32a905284eed866d8ffba9f1d0f1huaweicom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgSGVucmlrLA0KDQpUaGlzIGRyYWZ0IGlzIG5vdCB0YXJnZXRpbmcgZm9yIHlvdXIgY2FzZS4g Q2hpbmEgbW9iaWxlIHJhaXNlZCB0aGUgTEFHIFBNIHJlcXVpcmVtZW50IGluIHRoZWlyIG5ldHdv cmsuDQoNCkJ1dCBhcyBJIG1lbnRpb25lZCBpbiB0aGUgaW50cm9kdWN0aW9uLCBpdCBjb3VsZCBi ZSBwb3RlbnRpYWxseSB1c2VkIGZvciBTUiBwb2xpY3kgd2l0aCBMMyBtdWx0aSBob3BzLiBUaGlz IGlzIG91dCBvZiBzY29wZS4gQnV0IEkgd291bGQgaGFwcHkgdG8gc2hhcmUgbXkgcG9pbnQuIDot KQ0KDQpCZXN0LA0KVGlhbnJhbg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KDQpTZW50IGZyb20gV2VMaW5rDQq3orz+yMujuiBIZW5yaWsgTnlkZWxsPGhueWRlbGxA YWNjZWRpYW4uY29tPG1haWx0bzpobnlkZWxsQGFjY2VkaWFuLmNvbT4+DQrK1bz+yMujuiBUaWFu cmFuIFpob3U8emhvdXRpYW5yYW5AaHVhd2VpLmNvbTxtYWlsdG86emhvdXRpYW5yYW5AaHVhd2Vp LmNvbT4+DQqzrcvNo7ogd2FuZ2FqMzx3YW5nYWozQGNoaW5hdGVsZWNvbS5jbjxtYWlsdG86d2Fu Z2FqM0BjaGluYXRlbGVjb20uY24+PjtJRVRGIElQUE0gV0c8aXBwbUBpZXRmLm9yZzxtYWlsdG86 aXBwbUBpZXRmLm9yZz4+DQrW98zio7ogUmU6IFtpcHBtXSBGVzogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1saS1pcHBtLW90d2FtcC1vbi1sYWctMDIudHh0DQrKsbzko7ogMjAy Mi0wMS0yNyAyMDoyMDo1Mw0KDQpJbiBteSBtaW5kIFRXQU1QLCBiZWluZyBhIGxheWVyLTMgbWV0 aG9kLCBpcyBtb3JlIGNvbW1vbmx5IHVzZWQgb24gbG9uZ2VyIGUtMi1lIGxheWVyMyBjb25uZWN0 aW9ucywgZm9yIGV4YW1wbGUgc2VuZGVyIGZyb20gYSBjZW50cmFsIGNvcmUgc2l0ZSBvdXQgdG8g YSByZWZsZWN0b3Igb24gYSByYWRpbyBiYXNlIHN0YXRpb24uIFRoZSBwYXRoIGJldHdlZW4gbWF5 IGhhdmUgc2V2ZXJhbCBsYXllcjMgaG9wcyBhbmQgbWFueSBsYXllci0yLiBJZiB0aGVyZSBpcyBM QUcgc29tZXdoZXJlIHRoZXJlIGluIHRoZSBtaWRkbGUgb2YgdGhlIHBhdGgsIGhvdyB3aWxsIHRo aXMgZHJhZnQgaGVscD8NCg0KDQpPbiBUaHUsIEphbiAyNywgMjAyMiBhdCAxMjo0OCBQTSBUaWFu cmFuIFpob3UgPHpob3V0aWFucmFuQGh1YXdlaS5jb208bWFpbHRvOnpob3V0aWFucmFuQGh1YXdl aS5jb20+PiB3cm90ZToNCkhpIEhlbnJpaywNCg0KTWF5IEkgdW5kZXJzdGFuZCB3aGF0oa9zIHRo ZSBsaW1pdHM/DQpUaGUgdHdhbXAgb3IgbGFnPyBPciBvdGhlcj8NCkFjdHVhbGx5IGJvdGggYXJl IHN1cHBvcnRlZCBpbiBleGlzdGluZyBkZXZpY2VzLiBBcyBmYXIgYXMgSSBrbm93IHF1aXRlIG5v cm1hbC4NCg0KQmVzdCwNClRpYW5yYW4NCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCg0KU2VudCBmcm9tIFdlTGluaw0Kt6K8/sjLo7ogSGVucmlrIE55ZGVsbDxobnlk ZWxsQGFjY2VkaWFuLmNvbTxtYWlsdG86aG55ZGVsbEBhY2NlZGlhbi5jb20+Pg0KytW8/sjLo7og VGlhbnJhbiBaaG91PHpob3V0aWFucmFuQGh1YXdlaS5jb208bWFpbHRvOnpob3V0aWFucmFuQGh1 YXdlaS5jb20+Pg0Ks63LzaO6IHdhbmdhajM8d2FuZ2FqM0BjaGluYXRlbGVjb20uY248bWFpbHRv OndhbmdhajNAY2hpbmF0ZWxlY29tLmNuPj47SUVURiBJUFBNIFdHPGlwcG1AaWV0Zi5vcmc8bWFp bHRvOmlwcG1AaWV0Zi5vcmc+Pg0K1vfM4qO6IFJlOiBbaXBwbV0gRlc6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtbGktaXBwbS1vdHdhbXAtb24tbGFnLTAyLnR4dA0KyrG85KO6 IDIwMjItMDEtMjcgMTg6MTU6MzkNCg0KT0ssIGJ1dCB0aGlzIHJlcXVpcmVzIHRoYXQgdGhlIHNl bmRlciBydW5zIG9uIHRoZSBkZXZpY2UgdGhhdCBwZXJmb3JtcyB0aGUgTEFHLiBUaGlzIHdvdWxk IGJlIHF1aXRlIGEgc2VyaW91cyBsaW1pdGF0aW9uIG9mIHRoZSBmZWF0dXJlIEkgYmVsaWV2ZQ0K DQpPbiBUaHUsIEphbiAyNywgMjAyMiBhdCAxMDo0OCBBTSBUaWFucmFuIFpob3UgPHpob3V0aWFu cmFuQGh1YXdlaS5jb208bWFpbHRvOnpob3V0aWFucmFuQGh1YXdlaS5jb20+PiB3cm90ZToNCkhp IEhlbnJpaywNCg0KQm90aCBzZW5kZXIgYW5kIHJlZmxlY3RvciBrZWVwIHRoZSBtYXBwaW5nIGJl dHdlZW4gbWVtYmVyIGxpbmsgYW5kIHRoZSBtaWNybyBzZXNzaW9uLiBFaXRoZXIgYnkgY29uZmln dXJhdGlvbiBvciBuZWdvdGlhdGlvbiBvciBhdXRvLWxlYXJuaW5nLg0KU28sIGluIHlvdXIgc3dp dGNoIGNhc2UsIGlmIHRoZSBzZW5kZXIgcmVjZWl2ZXMgdGhlIHBhY2tldCBmcm9tIEMsIG5vdCBB LCB0aGUgc2VuZGVyIGtub3cgaXShr3Mgd3JvbmcuIFRoZSB0ZXN0IHBhY2tldCBzaG91bGQgYmUg ZHJvcHBlZCBhbmQgbm90IGNvdW50ZWQuDQoNCkJlc3QsDQpUaWFucmFuDQpGcm9tOiBIZW5yaWsg TnlkZWxsIFttYWlsdG86aG55ZGVsbEBhY2NlZGlhbi5jb208bWFpbHRvOmhueWRlbGxAYWNjZWRp YW4uY29tPl0NClNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDI3LCAyMDIyIDU6MjkgUE0NClRvOiBU aWFucmFuIFpob3UgPHpob3V0aWFucmFuQGh1YXdlaS5jb208bWFpbHRvOnpob3V0aWFucmFuQGh1 YXdlaS5jb20+Pg0KQ2M6IHdhbmdhajNAY2hpbmF0ZWxlY29tLmNuPG1haWx0bzp3YW5nYWozQGNo aW5hdGVsZWNvbS5jbj47IElFVEYgSVBQTSBXRyA8aXBwbUBpZXRmLm9yZzxtYWlsdG86aXBwbUBp ZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW2lwcG1dIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWxpLWlwcG0tb3R3YW1wLW9uLWxhZy0wMi50eHQNCg0KVGhhbmtzIGZvciB0 aGUgY2xhcmlmaWNhdGlvbiwgYnV0IHRoaXMgIm1lbWJlciBsaW5rIHZhbGlkYXRpb24gbWVjaGFu aXNtIiBkZXBlbmRzIGZ1bGx5IG9uIGNvbmZpZ3VyYXRpb24gYmV0d2VlbiB0aGUgc2Vzc2lvbiBz ZW5kZXIgYW5kIHRoZSBzZXNzaW9uIHJlZmxlY3RvciByaWdodD8gU28gZXZlbiBpZiB0aGV5IGhh dmUgYWdyZWVkIHRoYXQgYSBjZXJ0YWluIHNlc3Npb24gSUQgYmVsb25ncyB0byBsYWcgbGluayBB LCB0aGVyZSBpcyBubyB3YXkgdG8gYmUgc3VyZSB0aGF0IHRoaXMgaXMgdGhlIGNhc2UsIHRoZSBp bnRlcm1lZGlhdGUgc3dpdGNoZXMgbWF5IHBsYWNlIHRoZXNlIHBhY2tldHMgcmFuZG9tbHkgb3Zl ciBsaW5rcyBBLUMgYW5kIHRoZSBUV0FNUC9PV0FNUCBzZW5kZXIvcmVmbGVjdG9ycyB3aWxsIGhh dmUgbm8ga25vd2xlZGdlIG9mIHRoaXMuIFNvIEkgZG9udCBrbm93IGlmIHRoaXMgYWRkaXRpb24g YWRkcyBtdWNoIHVzZWZ1bG5lcyBvdmVyIHRoZSBhbHJlYWR5IGV4aXN0aW5nIGNhcGFiaWxpdGll cyBvZiBUV0FNUCwgd2hlcmUgeW91IGNhbiB1c2UgdGhlIDUtdHVwbGUgb2YgcG9ydC1wYWlyLCBJ UC1wYWlyIGFuZCBUT1MgdG8gZGlmZmVyZW50aWF0ZSBzZXNzaW9uIGZyb20gZWFjaCBvdGhlci4N Cg0KDQpPbiBUaHUsIEphbiAyNywgMjAyMiBhdCAyOjM3IEFNIFRpYW5yYW4gWmhvdSA8emhvdXRp YW5yYW5AaHVhd2VpLmNvbTxtYWlsdG86emhvdXRpYW5yYW5AaHVhd2VpLmNvbT4+IHdyb3RlOg0K SGkgSGVucmlrLA0KDQpUaGFua3MgdmVyeSBtdWNoIGZvciB5b3VyIHJldmlldy4NCllvdXIgcGVy c3BlY3RpdmUgaXMgYWJzb2x1dGVseSBjb3JyZWN0Lg0KVGhpcyBkcmFmdCBpcyBub3QgYWJsZSB0 byChsGd1YXJhbnRlZaGxIGEgc3BlY2lmaWMgTEFHIHBhdGguIEZvciBleGFtcGxlLCB0aGVyZSBp cyBhIHN3aXRjaCBiZXR3ZWVuIHRoZSB0d28gZW5kIHBvaW50cywgb3IgaW4gdGhlIGNhc2UgdGhl IHJlZmxlY3RvciBpcyBub3QgY2FwYWJsZS4NCkkuZS4sIGFzIHlvdSBzYWlkLCB0aGVyZSBpcyBu byAib25lIG1ldGhvZCBmaXRzIGFsbCIgdG8gZ3VhcmFudGVlIHRoZSBwYXRoLg0KDQpIb3dldmVy LCB0aGlzIGRyYWZ0IHNlZWsgYW5vdGhlciB3YXkgcm91bmQsIHRoZSBtZW1iZXIgbGluayB2YWxp ZGF0aW9uIG1lY2hhbmlzbS4NClRoZXJlIGlzIGFuIGFzc3VtcHRpb24gaW4gdGhlIGludHJvZHVj dGlvbiChsFRoaXMgZG9jdW1lbnQgaW50ZW5kcyB0byBhZGRyZXNzIHRoZSBzY2VuYXJpbyB3aGVy ZSBhIExBRyBkaXJlY3RseSBjb25uZWN0cyB0d28gbm9kZXMgKEEgYW5kIEIpLqGxDQpXaXRoIHRo ZSBtZW1iZXIgbGluayB2YWxpZGF0aW9uLCBzZW5kZXIvcmVmbGVjdG9yIHdpbGwgZHJvcCBtZWFz dXJlbWVudCBkYXRhLCB3aGVuIHRoZSB0ZXN0IHBhY2tldCBpcyBub3QgZnJvbSB0aGUgZXhwZWN0 ZWQgbWVtYmVyIGxpbmsuDQpJbiB0aGlzIHdheSwgdGhlIG1lYXN1cmVtZW50IGNvdWxkIGFsd2F5 cyBiZSBjb3JyZWN0Lg0KDQpUaGlzIGlzIHNvbWV3aGF0IHNpbWlsYXIgdG8gUGFyaXMgVHJhY2Vy b3V0ZSAoaHR0cHM6Ly9wYXJpcy10cmFjZXJvdXRlLm5ldC9hYm91dC8pLCBJTUhPLg0KDQpDaGVl cnMsDQpUaWFucmFuDQoNCkZyb206IEhlbnJpayBOeWRlbGwgW21haWx0bzpobnlkZWxsQGFjY2Vk aWFuLmNvbTxtYWlsdG86aG55ZGVsbEBhY2NlZGlhbi5jb20+XQ0KU2VudDogV2VkbmVzZGF5LCBK YW51YXJ5IDI2LCAyMDIyIDY6MTcgUE0NClRvOiBUaWFucmFuIFpob3UgPHpob3V0aWFucmFuQGh1 YXdlaS5jb208bWFpbHRvOnpob3V0aWFucmFuQGh1YXdlaS5jb20+Pg0KQ2M6IHdhbmdhajNAY2hp bmF0ZWxlY29tLmNuPG1haWx0bzp3YW5nYWozQGNoaW5hdGVsZWNvbS5jbj47IElFVEYgSVBQTSBX RyA8aXBwbUBpZXRmLm9yZzxtYWlsdG86aXBwbUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW2lw cG1dIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpLWlwcG0tb3R3YW1w LW9uLWxhZy0wMi50eHQNCg0KSSBoYWQgYSBicmllZiByZXZpZXcgYnV0IGZhaWxlZCB0byBmaW5k IGRldGFpbHMgb24gaG93IHRoZSBUV0FNUCBzZXNzaW9ucyB3b3VsZCBiZSAiZ3VhcmFudGVlZCIg dG8gdHJhdmVsIG9uIGEgY2VydGFpbiBMQUcgc2VnbWVudC4gQXMgZmFyIGFzIEkga25vdyB0aGUg TEFHIGltcGxlbWVudGF0aW9uIG1heSBiZSBkaWZmZXJlbnQgYmV0d2VlbiB2ZW5kb3JzIGFuZCBh cyBzdWNoIEkga25vdyBvZiBubyAib25lIG1ldGhvZCBmaXRzIGFsbCIgdG8gYWN0dWFsbHkgYWNj b21wbGlzaCB0aGUgbWVhc3VyZW1lbnQuDQoNClNvIHRoaXMgZHJhZnQgZG9lcyBub3QgYWN0dWFs bHkgcHJvdmlkZSBhbnkgc29sdXRpb24gdG8gdGhlIHByb2JsZW0gb2YgYmVpbmcgYWJsZSB0byBt ZWFzdXJlIExBRyBzZWdtZW50cyBzZXBhcmF0ZWx5IGFuZCBkZXRlcm1pbmlzdGljYWxseS4NCg0K T24gV2VkLCBKYW4gMjYsIDIwMjIgYXQgMTE6MDMgQU0gVGlhbnJhbiBaaG91IDx6aG91dGlhbnJh bj00MGh1YXdlaS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwaHVhd2VpLmNvbUBkbWFyYy5p ZXRmLm9yZz4+IHdyb3RlOg0KSGkgQW5qdW4sDQoNClRoYW5rcyB2ZXJ5IG11Y2ggZm9yIHlvdXIg aW50ZXJlc3QgYW5kIGNvbW1lbnRzLg0KQm90aCBhcmUgZ29vZCBxdWVzdGlvbnMuDQpQbGVhc2Ug c2VlIGluIGxpbmUuDQoNCkNoZWVycywNClRpYW5yYW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IHdhbmdhajNAY2hpbmF0ZWxlY29tLmNuPG1haWx0bzp3YW5nYWozQGNoaW5h dGVsZWNvbS5jbj4gW21haWx0bzp3YW5nYWozQGNoaW5hdGVsZWNvbS5jbjxtYWlsdG86d2FuZ2Fq M0BjaGluYXRlbGVjb20uY24+XQ0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDI2LCAyMDIyIDU6 MjEgUE0NClRvOiBUaWFucmFuIFpob3UgPHpob3V0aWFucmFuQGh1YXdlaS5jb208bWFpbHRvOnpo b3V0aWFucmFuQGh1YXdlaS5jb20+PjsgJ0lFVEYgSVBQTSBXRycgPGlwcG1AaWV0Zi5vcmc8bWFp bHRvOmlwcG1AaWV0Zi5vcmc+Pg0KU3ViamVjdDogUkU6IFtpcHBtXSBGVzogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC1saS1pcHBtLW90d2FtcC1vbi1sYWctMDIudHh0DQoNCkhp LCBUaWFucmFuOg0KDQpIYXZlIGEgYnJpZWYgcmV2aWV3IG9mIHRoaXMgZHJhZnQuIEkgdGhpbmsg aXRzIGFpbSBpcyBzdHJhaWdodGZvcndhcmQgYW5kIHdpbGwgYmUgdXNlZnVsIHRvIHV0aWxpemUg dGhlIG1lbWJlciBsaW5rIHdpdGhpbiB0aGUgTEFHLg0KU29tZSBjb21tZW50cyBhcmUgYmVsb3c6 DQoxKSBJdCBzZWVtcyB0aGVyZSBpcyBubyBTZW5kZXIvUmVmbGVjdG9yIGJlaGF2aW9yIGRlc2Ny aXB0aW9uIGZvciB0aGUgTWlyY28gT1dBTVAgc2Vzc2lvbiBhbmQgdGhlIHBhY2tldCBmb3JtYXQ/ DQoNCg0KWlRSPiBPV0FNUCBpcyBzaW1wbGUgYW5kIHRoZXJlIGlzIG5vIHJlZmxlY3Rvci4gVGhl IHNlbmRlciBjYW5ub3QgZ2V0IHRoZSBhY2sgZnJvbSB0aGUgcmVjZWl2ZXIuIFNvIHdlIGFyZSBu b3QgZ29pbmcgdG8gZXh0ZW5kIHRoZSBPV0FNUCB0ZXN0IHBhY2tldC4NClRoZSBiZWhhdmlvciBp cyBkZXNjcmliZWQgaW4gc2VjdGlvbiAzLjI6DQoiIFRoZSBtaWNybyBPV0FNUCBTZW5kZXIgTVVT VCBzZW5kIHRoZSBtaWNybyBPV0FNUC1UZXN0IHBhY2tldHMgb3ZlciB0aGUgbWVtYmVyIGxpbmsg d2l0aCB3aGljaCB0aGUgc2Vzc2lvbiBpcyBhc3NvY2lhdGVkLiBXaGVuIHJlY2VpdmVzIGEgVGVz dCBwYWNrZXQsIHRoZSBtaWNybyBPV0FNUCByZWNlaXZlciBNVVNUIHVzZSB0aGUgbWVtYmVyIGxp bmsgZnJvbSB3aGljaCB0aGUgVGVzdCBwYWNrZXQgaXMgcmVjZWl2ZWQgdG8gY29ycmVsYXRlIHRo ZSBtaWNybyBPV0FNUCBzZXNzaW9uLiBJZiB0aGVyZSBpcyBubyBzdWNoIGEgc2Vzc2lvbiwgdGhl IFRlc3QgcGFja2V0IE1VU1QgYmUgZGlzY2FyZGVkLiAiDQoNCjIpIEZvciB0aGUgbmV3bHkgZGVm aW5lZCBTZXNzaW9uLVNlbmRlciBQYWNrZXQvU2Vzc2lvbi1SZWZsZWN0b3IgUGFja2V0LCBob3cg dG8gYXNzdXJlIHRoZSBiYWNrd2FyZCBjb21wYXRpYmlsaXR5PyBXaGF0IEkgaGF2ZSBzZWVuIGlz IHRoYXQgeW91IGFkZCB0d28gYWRkaXRpb25hbCBmaWVsZHMgd2l0aGluIHRoZSBleGlzdGluZyBQ YWNrZXQ/DQoNClpUUj4gSSBhbSBub3QgYXdhcmUgb2YgdGhlIGNvbXBhdGliaWxpdHkgcHJvYmxl bS4gSWYgYSBub2RlIHN1cHBvcnRzIG1pY3JvIHNlc3Npb24sIGl0IGNhbiB1bmRlcnN0YW5kIHRo ZSBuZXcgcGFja2V0IGV4dGVuc2lvbi4gSWYgYSBub2RlIGRvZXMgbm90IHN1cHBvcnQgbWljcm8g c2Vzc2lvbiwgaXQganVzdCBpZ25vcmVzIHRoZSBuZXcgZmllbGRzLiBCZWNhdXNlIHRoZSBuZXcg ZmllbGRzIGlzIGluIHRoZSByZXNlcnZlZCB6b25lLg0KTW9yZW92ZXIsIHRoZSB2YWxpZGF0aW9u IG1lY2hhbmlzbSBjYW4gZmlndXJlIG91dCBpZiB0aGUgcmVmbGVjdG9yIGNhbiBzdXBwb3J0IHRo ZSBtaWNybyBzZXNzaW9uLg0KDQpCZXN0IFJlZ2FyZHMNCg0KQWlqdW4gV2FuZw0KQ2hpbmEgVGVs ZWNvbQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaXBwbSA8aXBwbS1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzppcHBtLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2Yg VGlhbnJhbiBaaG91DQpTZW50OiBNb25kYXksIEphbnVhcnkgMjQsIDIwMjIgMjoyMyBQTQ0KVG86 IElFVEYgSVBQTSBXRyAoaXBwbUBpZXRmLm9yZzxtYWlsdG86aXBwbUBpZXRmLm9yZz4pIDxpcHBt QGlldGYub3JnPG1haWx0bzppcHBtQGlldGYub3JnPj4NClN1YmplY3Q6IFtpcHBtXSBGVzogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saS1pcHBtLW90d2FtcC1vbi1sYWctMDIu dHh0DQoNCkhpIFdHLA0KDQpXZSB0aGluayB0aGlzIGlzIGFuIHVzZWZ1bCB3b3JrIG9uIGFkYXB0 aW5nIE9XQU1QL1RXQU1QIGluIExBRyBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudC4NCldlIHVwZGF0 ZWQgdGhpcyBkcmFmdCBiYXNlZCBvbiB0aGUgY29tbWVudHMgZnJvbSB0aGUgbWVldGluZyBkaXNj dXNzaW9uIGFuZCBtYWlsaW5nIGxpc3QuDQpUaGFua3MgZm9yIGFsbCB0aGUgc3VnZ2VzdGlvbnMu DQpNb3JlIHJldmlld3MgYW5kIGNvbW1lbnRzIGFyZSB3ZWxjb21lLg0KDQpDaGVlcnMsDQpUaWFu cmFuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gW21haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz5dDQpTZW50 OiBNb25kYXksIEphbnVhcnkgMjQsIDIwMjIgMjoxNyBQTQ0KVG86IEdyZWcgTWlyc2t5IDxncmVn aW1pcnNreUBnbWFpbC5jb208bWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbT4+OyBHdW8gSnVu IDxndW8uanVuMkB6dGUuY29tLmNuPG1haWx0bzpndW8uanVuMkB6dGUuY29tLmNuPj47IEp1biBH dW8gPGd1by5qdW4yQHp0ZS5jb20uY248bWFpbHRvOmd1by5qdW4yQHp0ZS5jb20uY24+PjsgUmFr ZXNoIEdhbmRoaSA8cmdhbmRoaUBjaXNjby5jb208bWFpbHRvOnJnYW5kaGlAY2lzY28uY29tPj47 IFRpYW5yYW4gWmhvdSA8emhvdXRpYW5yYW5AaHVhd2VpLmNvbTxtYWlsdG86emhvdXRpYW5yYW5A aHVhd2VpLmNvbT4+OyBaaGVucWlhbmcgTGkgPGxpX3poZW5xaWFuZ0Bob3RtYWlsLmNvbTxtYWls dG86bGlfemhlbnFpYW5nQGhvdG1haWwuY29tPj4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtbGktaXBwbS1vdHdhbXAtb24tbGFnLTAyLnR4dA0KDQoNCkEgbmV3 IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1saS1pcHBtLW90d2FtcC1vbi1sYWctMDIudHh0DQpoYXMg YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFRpYW5yYW4gWmhvdSBhbmQgcG9zdGVkIHRv IHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgICAgICBkcmFmdC1saS1pcHBtLW90 d2FtcC1vbi1sYWcNClJldmlzaW9uOiAgICAgICAwMg0KVGl0bGU6ICAgICAgICAgIE9uZS13YXkv VHdvLXdheSBBY3RpdmUgTWVhc3VyZW1lbnQgUHJvdG9jb2wgRXh0ZW5zaW9ucyBmb3INClBlcmZv cm1hbmNlIE1lYXN1cmVtZW50IG9uIExBRw0KRG9jdW1lbnQgZGF0ZTogIDIwMjItMDEtMjQNCkdy b3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgICAxMw0K VVJMOg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1saS1pcHBtLW90d2Ft cC1vbi1sYWctMDIudHh0DQpTdGF0dXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1saS1pcHBtLW90d2FtcC1vbi1sYWcvDQpIdG1saXplZDoNCmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbGktaXBwbS1vdHdhbXAtb24tbGFnDQpEaWZm Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWxpLWlwcG0tb3R3YW1w LW9uLWxhZy0wMg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBleHRlbnNp b25zIHRvIE9uZS13YXkgQWN0aXZlIE1lYXN1cmVtZW50DQogICBQcm90b2NvbCAoT1dBTVApLCBh bmQgVHdvLXdheSBBY3RpdmUgTWVhc3VyZW1lbnQgUHJvdG9jb2wgKFRXQU1QKSB0bw0KICAgaW1w bGVtZW50IHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50IG9uIGV2ZXJ5IG1lbWJlciBsaW5rIG9mIGEg TGluaw0KICAgQWdncmVnYXRpb24gR3JvdXAgKExBRykuICBLbm93aW5nIHRoZSBtZWFzdXJlZCBt ZXRyaWNzIG9mIGVhY2ggbWVtYmVyDQogICBsaW5rIG9mIGEgTEFHIGVuYWJsZXMgb3BlcmF0b3Jz IHRvIGVuZm9yY2UgdGhlIHBlcmZvcm1hbmNlIGJhc2VkDQogICB0cmFmZmljIHN0ZWVyaW5nIHBv bGljeSBhY3Jvc3MgdGhlIG1lbWJlciBsaW5rcy4NCg0KDQoNCg0KDQpUaGUgSUVURiBTZWNyZXRh cmlhdA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQppcHBtIG1haWxpbmcgbGlzdA0KaXBwbUBpZXRmLm9yZzxtYWlsdG86aXBwbUBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBwbQ0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KaXBwbSBtYWlsaW5nIGxpc3QN CmlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0NCg0KDQotLQ0KDQpIZW5yaWsgTnlkZWxsDQpTciBQcm9k dWN0IE1hbmFnZXINCjEuODY2LjY4NS44MTgxDQpobnlkZWxsQGFjY2VkaWFuLmNvbTxtYWlsdG86 aG55ZGVsbEBhY2NlZGlhbi5jb20+DQpbaHR0cHM6Ly9pLnhpbmsuaW8vSW1hZ2VzL0dldC9ONjM4 MzIvYTY1LnBuZ108aHR0cDovL2FjY2VkaWFuLmNvbT4NCltodHRwczovL2kueGluay5pby9JbWFn ZXMvR2V0L042MzgzMi9mOTcucG5nXTxodHRwczovL3d3dy5mYWNlYm9vay5jb20vYWNjZWRpYW4v PiBbaHR0cHM6Ly9pLnhpbmsuaW8vSW1hZ2VzL0dldC9ONjM4MzIvdDk5LnBuZ10gPGh0dHBzOi8v dHdpdHRlci5jb20vQWNjZWRpYW4+ICBbaHR0cHM6Ly9pLnhpbmsuaW8vSW1hZ2VzL0dldC9ONjM4 MzIvbDU0LnBuZ10gPGh0dHBzOi8vY2EubGlua2VkaW4uY29tL2NvbXBhbnkvYWNjZWRpYW4+DQo8 aHR0cDovL3d3dy5hY2NlZGlhbi5jb20+DQphY2NlZGlhbi5jb208aHR0cDovL2FjY2VkaWFuLmNv bT4NCg0KDQpBdmlzIGRlIGNvbmZpZGVudGlhbGl0qKYNCg0KTGVzIGluZm9ybWF0aW9ucyBjb250 ZW51ZXMgZGFucyBsZSBwcqimc2VudCBtZXNzYWdlIGV0IGRhbnMgdG91dGUgcGmoqGNlIHF1aSBs dWkgZXN0IGpvaW50ZSBzb250IGNvbmZpZGVudGllbGxlcyBldCBwZXV2ZW50IKi6dHJlIHByb3So pmeopmVzIHBhciBsZSBzZWNyZXQgcHJvZmVzc2lvbm5lbC4gQ2VzIGluZm9ybWF0aW9ucyBzb250 IKikIGyhr3VzYWdlIGV4Y2x1c2lmIGRlIHNvbiBvdSBkZSBzZXMgZGVzdGluYXRhaXJlcy4gU2kg dm91cyByZWNldmV6IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogc6GvaWwgdm91cyBw bGFpdCBjb21tdW5pcXVlciBpbW2opmRpYXRlbWVudCBhdmVjIGyhr2V4cKimZGl0ZXVyIGV0IGVu IGSopnRydWlyZSB0b3V0IGV4ZW1wbGFpcmUuIERlIHBsdXMsIGlsIHZvdXMgZXN0IHN0cmljdGVt ZW50IGludGVyZGl0IGRlIGxlIGRpdnVsZ3VlciwgZGUgbGUgZGlzdHJpYnVlciBvdSBkZSBsZSBy ZXByb2R1aXJlIHNhbnMgbKGvYXV0b3Jpc2F0aW9uIGRlIGyhr2V4cKimZGl0ZXVyLiBNZXJjaS4N Cg0KQ29uZmlkZW50aWFsaXR5IG5vdGljZQ0KDQpUaGlzIGUtbWFpbCBtZXNzYWdlIGFuZCBhbnkg YXR0YWNobWVudCBoZXJldG8gY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gd2hpY2gg bWF5IGJlIHByaXZpbGVnZWQgYW5kIHdoaWNoIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZl IHVzZSBvZiBpdHMgYWRkcmVzc2VlKHMpLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIG1lc3NhZ2UgaW4g ZXJyb3IsIHBsZWFzZSBpbmZvcm0gc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkZXN0cm95IGFueSBj b3B5IHRoZXJlb2YuIEZ1cnRoZXJtb3JlLCBhbnkgZGlzY2xvc3VyZSwgZGlzdHJpYnV0aW9uIG9y IGNvcHlpbmcgb2YgdGhpcyBtZXNzYWdlIGFuZC9vciBhbnkgYXR0YWNobWVudCBoZXJldG8gd2l0 aG91dCB0aGUgY29uc2VudCBvZiB0aGUgc2VuZGVyIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIFRo YW5rIHlvdS4NCg0KDQotLQ0KDQpIZW5yaWsgTnlkZWxsDQpTciBQcm9kdWN0IE1hbmFnZXINCjEu ODY2LjY4NS44MTgxDQpobnlkZWxsQGFjY2VkaWFuLmNvbTxtYWlsdG86aG55ZGVsbEBhY2NlZGlh bi5jb20+DQpbaHR0cHM6Ly9pLnhpbmsuaW8vSW1hZ2VzL0dldC9ONjM4MzIvYTY1LnBuZ108aHR0 cDovL2FjY2VkaWFuLmNvbT4NCltodHRwczovL2kueGluay5pby9JbWFnZXMvR2V0L042MzgzMi9m OTcucG5nXTxodHRwczovL3d3dy5mYWNlYm9vay5jb20vYWNjZWRpYW4vPiBbaHR0cHM6Ly9pLnhp bmsuaW8vSW1hZ2VzL0dldC9ONjM4MzIvdDk5LnBuZ10gPGh0dHBzOi8vdHdpdHRlci5jb20vQWNj ZWRpYW4+ICBbaHR0cHM6Ly9pLnhpbmsuaW8vSW1hZ2VzL0dldC9ONjM4MzIvbDU0LnBuZ10gPGh0 dHBzOi8vY2EubGlua2VkaW4uY29tL2NvbXBhbnkvYWNjZWRpYW4+DQo8aHR0cDovL3d3dy5hY2Nl ZGlhbi5jb20+DQphY2NlZGlhbi5jb208aHR0cDovL2FjY2VkaWFuLmNvbT4NCg0KDQpBdmlzIGRl IGNvbmZpZGVudGlhbGl0qKYNCg0KTGVzIGluZm9ybWF0aW9ucyBjb250ZW51ZXMgZGFucyBsZSBw cqimc2VudCBtZXNzYWdlIGV0IGRhbnMgdG91dGUgcGmoqGNlIHF1aSBsdWkgZXN0IGpvaW50ZSBz b250IGNvbmZpZGVudGllbGxlcyBldCBwZXV2ZW50IKi6dHJlIHByb3SopmeopmVzIHBhciBsZSBz ZWNyZXQgcHJvZmVzc2lvbm5lbC4gQ2VzIGluZm9ybWF0aW9ucyBzb250IKikIGyhr3VzYWdlIGV4 Y2x1c2lmIGRlIHNvbiBvdSBkZSBzZXMgZGVzdGluYXRhaXJlcy4gU2kgdm91cyByZWNldmV6IGNl IG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogc6GvaWwgdm91cyBwbGFpdCBjb21tdW5pcXVl ciBpbW2opmRpYXRlbWVudCBhdmVjIGyhr2V4cKimZGl0ZXVyIGV0IGVuIGSopnRydWlyZSB0b3V0 IGV4ZW1wbGFpcmUuIERlIHBsdXMsIGlsIHZvdXMgZXN0IHN0cmljdGVtZW50IGludGVyZGl0IGRl IGxlIGRpdnVsZ3VlciwgZGUgbGUgZGlzdHJpYnVlciBvdSBkZSBsZSByZXByb2R1aXJlIHNhbnMg bKGvYXV0b3Jpc2F0aW9uIGRlIGyhr2V4cKimZGl0ZXVyLiBNZXJjaS4NCg0KQ29uZmlkZW50aWFs aXR5IG5vdGljZQ0KDQpUaGlzIGUtbWFpbCBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudCBoZXJl dG8gY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVn ZWQgYW5kIHdoaWNoIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiBpdHMgYWRk cmVzc2VlKHMpLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBp bmZvcm0gc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkZXN0cm95IGFueSBjb3B5IHRoZXJlb2YuIEZ1 cnRoZXJtb3JlLCBhbnkgZGlzY2xvc3VyZSwgZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcgb2YgdGhp cyBtZXNzYWdlIGFuZC9vciBhbnkgYXR0YWNobWVudCBoZXJldG8gd2l0aG91dCB0aGUgY29uc2Vu dCBvZiB0aGUgc2VuZGVyIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIFRoYW5rIHlvdS4NCg0KDQot LQ0KDQpIZW5yaWsgTnlkZWxsDQpTciBQcm9kdWN0IE1hbmFnZXINCjEuODY2LjY4NS44MTgxDQpo bnlkZWxsQGFjY2VkaWFuLmNvbTxtYWlsdG86aG55ZGVsbEBhY2NlZGlhbi5jb20+DQpbaHR0cHM6 Ly9pLnhpbmsuaW8vSW1hZ2VzL0dldC9ONjM4MzIvYTY1LnBuZ108aHR0cDovL2FjY2VkaWFuLmNv bT4NCltodHRwczovL2kueGluay5pby9JbWFnZXMvR2V0L042MzgzMi9mOTcucG5nXTxodHRwczov L3d3dy5mYWNlYm9vay5jb20vYWNjZWRpYW4vPiBbaHR0cHM6Ly9pLnhpbmsuaW8vSW1hZ2VzL0dl dC9ONjM4MzIvdDk5LnBuZ10gPGh0dHBzOi8vdHdpdHRlci5jb20vQWNjZWRpYW4+ICBbaHR0cHM6 Ly9pLnhpbmsuaW8vSW1hZ2VzL0dldC9ONjM4MzIvbDU0LnBuZ10gPGh0dHBzOi8vY2EubGlua2Vk aW4uY29tL2NvbXBhbnkvYWNjZWRpYW4+DQo8aHR0cDovL3d3dy5hY2NlZGlhbi5jb20+DQphY2Nl ZGlhbi5jb208aHR0cDovL2FjY2VkaWFuLmNvbT4NCg0KDQpBdmlzIGRlIGNvbmZpZGVudGlhbGl0 qKYNCg0KTGVzIGluZm9ybWF0aW9ucyBjb250ZW51ZXMgZGFucyBsZSBwcqimc2VudCBtZXNzYWdl IGV0IGRhbnMgdG91dGUgcGmoqGNlIHF1aSBsdWkgZXN0IGpvaW50ZSBzb250IGNvbmZpZGVudGll bGxlcyBldCBwZXV2ZW50IKi6dHJlIHByb3SopmeopmVzIHBhciBsZSBzZWNyZXQgcHJvZmVzc2lv bm5lbC4gQ2VzIGluZm9ybWF0aW9ucyBzb250IKikIGyhr3VzYWdlIGV4Y2x1c2lmIGRlIHNvbiBv dSBkZSBzZXMgZGVzdGluYXRhaXJlcy4gU2kgdm91cyByZWNldmV6IGNlIG1lc3NhZ2UgcGFyIGVy cmV1ciwgdmV1aWxsZXogc6GvaWwgdm91cyBwbGFpdCBjb21tdW5pcXVlciBpbW2opmRpYXRlbWVu dCBhdmVjIGyhr2V4cKimZGl0ZXVyIGV0IGVuIGSopnRydWlyZSB0b3V0IGV4ZW1wbGFpcmUuIERl IHBsdXMsIGlsIHZvdXMgZXN0IHN0cmljdGVtZW50IGludGVyZGl0IGRlIGxlIGRpdnVsZ3Vlciwg ZGUgbGUgZGlzdHJpYnVlciBvdSBkZSBsZSByZXByb2R1aXJlIHNhbnMgbKGvYXV0b3Jpc2F0aW9u IGRlIGyhr2V4cKimZGl0ZXVyLiBNZXJjaS4NCg0KQ29uZmlkZW50aWFsaXR5IG5vdGljZQ0KDQpU aGlzIGUtbWFpbCBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudCBoZXJldG8gY29udGFpbiBjb25m aWRlbnRpYWwgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgYW5kIHdoaWNoIGlz IGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiBpdHMgYWRkcmVzc2VlKHMpLiBJZiB5 b3UgcmVjZWl2ZSB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBpbmZvcm0gc2VuZGVyIGlt bWVkaWF0ZWx5IGFuZCBkZXN0cm95IGFueSBjb3B5IHRoZXJlb2YuIEZ1cnRoZXJtb3JlLCBhbnkg ZGlzY2xvc3VyZSwgZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBtZXNzYWdlIGFuZC9v ciBhbnkgYXR0YWNobWVudCBoZXJldG8gd2l0aG91dCB0aGUgY29uc2VudCBvZiB0aGUgc2VuZGVy IGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIFRoYW5rIHlvdS4NCg0KDQotLQ0KDQpIZW5yaWsgTnlk ZWxsDQpTciBQcm9kdWN0IE1hbmFnZXINCjEuODY2LjY4NS44MTgxDQpobnlkZWxsQGFjY2VkaWFu LmNvbTxtYWlsdG86aG55ZGVsbEBhY2NlZGlhbi5jb20+DQpbaHR0cHM6Ly9pLnhpbmsuaW8vSW1h Z2VzL0dldC9ONjM4MzIvYTY1LnBuZ108aHR0cDovL2FjY2VkaWFuLmNvbT4NCltodHRwczovL2ku eGluay5pby9JbWFnZXMvR2V0L042MzgzMi9mOTcucG5nXTxodHRwczovL3d3dy5mYWNlYm9vay5j b20vYWNjZWRpYW4vPiBbaHR0cHM6Ly9pLnhpbmsuaW8vSW1hZ2VzL0dldC9ONjM4MzIvdDk5LnBu Z10gPGh0dHBzOi8vdHdpdHRlci5jb20vQWNjZWRpYW4+ICBbaHR0cHM6Ly9pLnhpbmsuaW8vSW1h Z2VzL0dldC9ONjM4MzIvbDU0LnBuZ10gPGh0dHBzOi8vY2EubGlua2VkaW4uY29tL2NvbXBhbnkv YWNjZWRpYW4+DQo8aHR0cDovL3d3dy5hY2NlZGlhbi5jb20+DQphY2NlZGlhbi5jb208aHR0cDov L2FjY2VkaWFuLmNvbT4NCg0KDQpBdmlzIGRlIGNvbmZpZGVudGlhbGl0qKYNCg0KTGVzIGluZm9y bWF0aW9ucyBjb250ZW51ZXMgZGFucyBsZSBwcqimc2VudCBtZXNzYWdlIGV0IGRhbnMgdG91dGUg cGmoqGNlIHF1aSBsdWkgZXN0IGpvaW50ZSBzb250IGNvbmZpZGVudGllbGxlcyBldCBwZXV2ZW50 IKi6dHJlIHByb3SopmeopmVzIHBhciBsZSBzZWNyZXQgcHJvZmVzc2lvbm5lbC4gQ2VzIGluZm9y bWF0aW9ucyBzb250IKikIGyhr3VzYWdlIGV4Y2x1c2lmIGRlIHNvbiBvdSBkZSBzZXMgZGVzdGlu YXRhaXJlcy4gU2kgdm91cyByZWNldmV6IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXog c6GvaWwgdm91cyBwbGFpdCBjb21tdW5pcXVlciBpbW2opmRpYXRlbWVudCBhdmVjIGyhr2V4cKim ZGl0ZXVyIGV0IGVuIGSopnRydWlyZSB0b3V0IGV4ZW1wbGFpcmUuIERlIHBsdXMsIGlsIHZvdXMg ZXN0IHN0cmljdGVtZW50IGludGVyZGl0IGRlIGxlIGRpdnVsZ3VlciwgZGUgbGUgZGlzdHJpYnVl ciBvdSBkZSBsZSByZXByb2R1aXJlIHNhbnMgbKGvYXV0b3Jpc2F0aW9uIGRlIGyhr2V4cKimZGl0 ZXVyLiBNZXJjaS4NCg0KQ29uZmlkZW50aWFsaXR5IG5vdGljZQ0KDQpUaGlzIGUtbWFpbCBtZXNz YWdlIGFuZCBhbnkgYXR0YWNobWVudCBoZXJldG8gY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3Jt YXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgYW5kIHdoaWNoIGlzIGludGVuZGVkIGZvciB0 aGUgZXhjbHVzaXZlIHVzZSBvZiBpdHMgYWRkcmVzc2VlKHMpLiBJZiB5b3UgcmVjZWl2ZSB0aGlz IG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBpbmZvcm0gc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBk ZXN0cm95IGFueSBjb3B5IHRoZXJlb2YuIEZ1cnRoZXJtb3JlLCBhbnkgZGlzY2xvc3VyZSwgZGlz dHJpYnV0aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBtZXNzYWdlIGFuZC9vciBhbnkgYXR0YWNobWVu dCBoZXJldG8gd2l0aG91dCB0aGUgY29uc2VudCBvZiB0aGUgc2VuZGVyIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQuIFRoYW5rIHlvdS4NCg== --_000_fcac32a905284eed866d8ffba9f1d0f1huaweicom_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
        Hi Henrik,

        This draft is&nbs= p;not targeting for your case. China mobile&n= bsp;raised the LAG PM requirement in their&nb= sp;network.

        But as I men= tioned in the introduction, it could be = potentially used for SR policy with L3 m= ulti hops. This is out of scope. But&nbs= p;I would happy to share my point. :-)

        Best,
        Tianran 





        Sent from WeLink<= /span>
        =B7=A2=BC=FE=C8=CB=A3=BA Henrik Nydell<hnydell@accedian.com>
        =CA=D5=BC=FE=C8=CB=A3=BA Tianran Zhou<zhoutianran@huawei.com>
        =B3=AD=CB=CD=A3=BA wangaj3<wangaj3@chinatelecom.cn>;IETF IPPM WG<ippm@ietf.org>
        =D6=F7=CC=E2=A3=BA Re: [ippm] FW: New Version Notification for = draft-li-ippm-otwamp-on-lag-02.txt
        =CA=B1=BC=E4=A3=BA 2022-01-27 20:20:53

        In my mind TWAMP, be= ing a layer-3 method, is more commonly used on longer e-2-e layer3 connecti= ons, for example sender from a central core site out to a reflector on a ra= dio base station. The path between may have several layer3 hops and many layer-2. If there is LAG somewhere there= in the middle of the path, how will this draft help?


        On Thu, Jan 27, 2022 at 12:48 PM Tian= ran Zhou <zhoutianran@huawei.c= om> wrote:
        Hi Henrik,<= /span>

        May I underst= and what=A1=AFs the limits?
        The twamp or&= nbsp;lag? Or other?
        Actually both = ;are supported in existing devices. As far&nb= sp;as I know quite normal.

        Best,
        Tianran 




        Sent from WeL= ink
        =B7=A2=BC=FE=C8=CB=A3=BA Henrik Nydell<hnydell@accedian.com>
        =CA=D5=BC=FE=C8=CB=A3=BA Tianran Zhou<zhoutianran@huawei.com>
        =B3=AD=CB=CD=A3=BA wangaj3<wangaj3@chinatelecom.cn>;IETF IPPM WG<= ;ippm@ietf.org>
        =D6=F7=CC=E2=A3=BA Re: [ippm] FW: New Version Notification for = draft-li-ippm-otwamp-on-lag-02.txt
        =CA=B1=BC=E4=A3=BA 2022-01-27 18:15:39

        OK, but this require= s that the sender runs on the device that performs the LAG. This would be q= uite a serious limitation of the feature I believe

        On Thu, Jan 27, 2022 at 10:48 AM Tian= ran Zhou <zh= outianran@huawei.com> wrote:

        Hi Henrik,

         

        Both sender and reflector keep the mapping= between member link and the micro session. Either by configuration or nego= tiation or auto-learning.

        So, in your switch case, if the sender rec= eives the packet from C, not A, the sender know it=A1=AFs wrong. The test p= acket should be dropped and not counted.

         

        Best,

        Tianran

        From: Henrik Nydell [mailto:hnydell@accedian.com]
        Sent: Thursday, January 27, 2022 5:29 PM
        To: Tianran Zhou <zhoutianran@huawei.com>
        Cc: wan= gaj3@chinatelecom.cn; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [ippm] FW: New Version Notification for draft-li-ippm-o= twamp-on-lag-02.txt

         

        Thanks for the clarification, but this "member = link validation mechanism" depends fully on configuration between the = session sender and the session reflector right? So even if they have agreed= that a certain session ID belongs to lag link A, there is no way to be sure that this is the case, the intermediate swit= ches may place these packets randomly over links A-C and the TWAMP/OWAMP se= nder/reflectors will have no knowledge of this. So I dont know if this addi= tion adds much usefulnes over the already existing capabilities of TWAMP, where you can use the 5-tuple of p= ort-pair, IP-pair and TOS to differentiate session from each other.<= u>

         

         

        On Thu, Jan 27, 2022 at 2:37 AM Tianran Zhou <zhoutianran@huawei= .com> wrote:

        Hi Henrik,

         

        Thanks very much for your review.

        Your perspective is absolutely correct.

        This draft is not able to =A1=B0guarantee= =A1=B1 a specific LAG path. For example, there is a switch between the two = end points, or in the case the reflector is not capable.

        I.e., as you said, there is no "one m= ethod fits all" to guarantee the path.

         

        However, this draft seek another way round= , the member link validation mechanism.

        There is an assumption in the introduction= =A1=B0This document intends to address the scenario where a LAG directly c= onnects two nodes (A and B).=A1=B1

        With the member link validation, sender/re= flector will drop measurement data, when the test packet is not from the ex= pected member link.

        In this way, the measurement could always = be correct.

         

        This is somewhat similar to Paris Tracerou= te (https= ://paris-traceroute.net/about/), IMHO.

         

        Cheers,

        Tianran

         

        From: Henrik Nydell [mailto:hnydell@accedian.com]
        Sent: Wednesday, January 26, 2022 6:17 PM
        To: Tianran Zhou <zhoutianran@huawei.com>
        Cc: wan= gaj3@chinatelecom.cn; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [ippm] FW: New Version Notification for draft-li-ippm-o= twamp-on-lag-02.txt

         

        I had a brief review but failed to find details on h= ow the TWAMP sessions would be "guaranteed" to travel on a certai= n LAG segment. As far as I know the LAG implementation may be different bet= ween vendors and as such I know of no "one method fits all" to actually accomplish the measurement.

         

        So this draft does not actually provide any solution= to the problem of being able to measure LAG segments separately and determ= inistically.

         

        On Wed, Jan 26, 2022 at 11:03 AM Tianran Zhou <zh= outianran=3D40huawei.com@dmarc.ietf.org> wrote:

        Hi Anjun,

        Thanks very much for your interest and comments.
        Both are good questions.
        Please see in line.

        Cheers,
        Tianran

        -----Original Message-----
        From: wangaj3@= chinatelecom.cn [mailto:wangaj3@chinatelecom.cn]
        Sent: Wednesday, January 26, 2022 5:21 PM
        To: Tianran Zhou <zhoutianran@huawei.com>; 'IETF IPPM WG' <ippm@ietf.org>
        Subject: RE: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-o= n-lag-02.txt

        Hi, Tianran:

        Have a brief review of this draft. I think its aim is straightforward and w= ill be useful to utilize the member link within the LAG.
        Some comments are below:
        1) It seems there is no Sender/Reflector behavior description for the Mirco= OWAMP session and the packet format?


        ZTR> OWAMP is simple and there is no reflector. The sender cannot get th= e ack from the receiver. So we are not going to extend the OWAMP test packe= t.
        The behavior is described in section 3.2:
        " The micro OWAMP Sender MUST send the micro OWAMP-Test packets over t= he member link with which the session is associated. When receives a Test p= acket, the micro OWAMP receiver MUST use the member link from which the Tes= t packet is received to correlate the micro OWAMP session. If there is no such a session, the Test packet MUST b= e discarded. "

        2) For the newly defined Session-Sender Packet/Session-Reflector Packet, ho= w to assure the backward compatibility? What I have seen is that you add tw= o additional fields within the existing Packet?

        ZTR> I am not aware of the compatibility problem. If a node supports mic= ro session, it can understand the new packet extension. If a node does not = support micro session, it just ignores the new fields. Because the new fiel= ds is in the reserved zone.
        Moreover, the validation mechanism can figure out if the reflector can supp= ort the micro session.

        Best Regards

        Aijun Wang
        China Telecom

        -----Original Message-----
        From: ippm <i= ppm-bounces@ietf.org> On Behalf Of Tianran Zhou
        Sent: Monday, January 24, 2022 2:23 PM
        To: IETF IPPM WG (ippm@i= etf.org) <ippm@ie= tf.org>
        Subject: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-la= g-02.txt

        Hi WG,

        We think this is an useful work on adapting OWAMP/TWAMP in LAG performance = measurement.
        We updated this draft based on the comments from the meeting discussion and= mailing list.
        Thanks for all the suggestions.
        More reviews and comments are welcome.

        Cheers,
        Tianran

        -----Original Message-----
        From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
        Sent: Monday, January 24, 2022 2:17 PM
        To: Greg Mirsky <gregimirsky@gmail.com>; Guo Jun <guo.jun2@zte.com.cn>; Jun Guo <guo.jun2@zte.com.cn= >; Rakesh Gandhi <r= gandhi@cisco.com>; Tianran Zhou <zhoutianran@huawei.com>; Zhenqiang Li &l= t;li_zhenqian= g@hotmail.com>
        Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

        A new version of I-D, draft-li-ippm-otwamp-on-lag-02.txt
        has been successfully submitted by Tianran Zhou and posted to the IETF repo= sitory.

        Name:           draft-li-ippm-otwamp-on-lag Revision:       02
        Title:          One-way/Two-way Active Measurement= Protocol Extensions for
        Performance Measurement on LAG
        Document date:  2022-01-24
        Group:          Individual Submission
        Pages:          13
        URL:
        https://www.ietf.org/archive/id/draft-li-ippm-otwamp-= on-lag-02.txt
        Status:
        https://datatracker.ietf.org/doc/draft-li-ippm-otwamp-on-l= ag/
        Htmlized:
        https://datatracker.ietf.org/doc/html/draft-li-ippm-ot= wamp-on-lag
        Diff:
        https://www.ietf.org/rfcdiff?url2=3Ddraft-li-ippm-otw= amp-on-lag-02

        Abstract:
           This document defines extensions to One-way Active Measurement=
           Protocol (OWAMP), and Two-way Active Measurement Protocol (TWA= MP) to
           implement performance measurement on every member link of a Li= nk
           Aggregation Group (LAG).  Knowing the measured metrics of= each member
           link of a LAG enables operators to enforce the performance bas= ed
           traffic steering policy across the member links.





        The IETF Secretariat


        _______________________________________________
        ippm mailing list
        ippm@ietf.org
        ht= tps://www.ietf.org/mailman/listinfo/ippm

        _______________________________________________
        ippm mailing list
        ippm@ietf.org
        ht= tps://www.ietf.org/mailman/listinfo/ippm


         

        --


        Henrik Nydell
        Sr Product Manager
        1.866.685.8181
        hnydell@accedian.= com
        =
          

        a= ccedian.com

         

        Avis de confidentialit=A8= =A6

        Les informations contenue= s dans le pr=A8=A6sent message et dans toute pi=A8=A8ce qui lui est jointe = sont confidentielles et peuvent =A8=BAtre prot=A8=A6g=A8=A6es par le secret= professionnel. Ces informations sont =A8=A4 l=A1=AFusage exclusif de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez s= =A1=AFil vous plait communiquer imm=A8=A6diatement avec l=A1=AFexp=A8=A6dit= eur et en d=A8=A6truire tout exemplaire. De plus, il vous est strictement i= nterdit de le divulguer, de le distribuer ou de le reproduire sans l=A1=AFautorisation de l=A1=AFexp=A8=A6diteur. Merci.

        Confidentiality notice

        This e-mail message and any attachment h= ereto contain confidential information which may be privileged and which is= intended for the exclusive use of its addressee(s). If you receive this me= ssage in error, please inform sender immediately and destroy any copy thereof. Furthermore, any disclosure, dis= tribution or copying of this message and/or any attachment hereto without t= he consent of the sender is strictly prohibited. Thank you.


         

        --


        Henrik Nydell
        Sr Product Manager
        1.866.685.8181
        hnydell@accedian.= com

          

        a= ccedian.com

         

        Avis de confidentialit=A8= =A6

        Les informations contenue= s dans le pr=A8=A6sent message et dans toute pi=A8=A8ce qui lui est jointe = sont confidentielles et peuvent =A8=BAtre prot=A8=A6g=A8=A6es par le secret= professionnel. Ces informations sont =A8=A4 l=A1=AFusage exclusif de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez s= =A1=AFil vous plait communiquer imm=A8=A6diatement avec l=A1=AFexp=A8=A6dit= eur et en d=A8=A6truire tout exemplaire. De plus, il vous est strictement i= nterdit de le divulguer, de le distribuer ou de le reproduire sans l=A1=AFautorisation de l=A1=AFexp=A8=A6diteur. Merci.

        Confidentiality notice

        This e-mail message and any attachment h= ereto contain confidential information which may be privileged and which is= intended for the exclusive use of its addressee(s). If you receive this me= ssage in error, please inform sender immediately and destroy any copy thereof. Furthermore, any disclosure, dis= tribution or copying of this message and/or any attachment hereto without t= he consent of the sender is strictly prohibited. Thank you.



        --

        Henrik Nydell
        Sr Product Manager
        1.866.685.8181
        hnydell@accedian.= com
        3D""
        =3D"" 3D"" 3D""
        3D""
        accedian.com=

        Avis de confidentialit=A8=A6

        Les informations contenues dans le= pr=A8=A6sent message et dans toute pi=A8=A8ce qui lui est jointe sont conf= identielles et peuvent =A8=BAtre prot=A8=A6g=A8=A6es par le secret professi= onnel. Ces informations sont =A8=A4 l=A1=AFusage exclusif de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez s=A1=AF= il vous plait communiquer imm=A8=A6diatement avec l=A1=AFexp=A8=A6diteur et= en d=A8=A6truire tout exemplaire. De plus, il vous est strictement interdi= t de le divulguer, de le distribuer ou de le reproduire sans l=A1=AFautorisation de l=A1=AFexp=A8=A6diteur. Merci.

        Confidentiality notice

        This e-mail message and any attachment hereto contain c= onfidential information which may be privileged and which is intended for t= he exclusive use of its addressee(s). If you receive this message in error,= please inform sender immediately and destroy any copy thereof. Furthermore, any disclosure, distribution or= copying of this message and/or any attachment hereto without the consent o= f the sender is strictly prohibited. Thank you.



        --

        Henrik Nydell
        Sr Product Manager
        1.866.685.8181
        hnydell@accedian.= com
        3D""
        =3D"" 3D"" 3D""
        3D""
        accedian.com=

        Avis de confidentialit=A8=A6

        Les informations contenues dans le= pr=A8=A6sent message et dans toute pi=A8=A8ce qui lui est jointe sont conf= identielles et peuvent =A8=BAtre prot=A8=A6g=A8=A6es par le secret professi= onnel. Ces informations sont =A8=A4 l=A1=AFusage exclusif de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez s=A1=AF= il vous plait communiquer imm=A8=A6diatement avec l=A1=AFexp=A8=A6diteur et= en d=A8=A6truire tout exemplaire. De plus, il vous est strictement interdi= t de le divulguer, de le distribuer ou de le reproduire sans l=A1=AFautorisation de l=A1=AFexp=A8=A6diteur. Merci.

        Confidentiality notice

        This e-mail message and any attachment hereto contain c= onfidential information which may be privileged and which is intended for t= he exclusive use of its addressee(s). If you receive this message in error,= please inform sender immediately and destroy any copy thereof. Furthermore, any disclosure, distribution or= copying of this message and/or any attachment hereto without the consent o= f the sender is strictly prohibited. Thank you.

        --_000_fcac32a905284eed866d8ffba9f1d0f1huaweicom_-- From nobody Thu Jan 27 04:56:58 2022 Return-Path: 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 4714B3A0B8F for ; Thu, 27 Jan 2022 04:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=accedian.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hoRIxfSj8VI for ; Thu, 27 Jan 2022 04:56:50 -0800 (PST) Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF5B93A0B7B for ; Thu, 27 Jan 2022 04:56:49 -0800 (PST) Received: by mail-yb1-xb31.google.com with SMTP id k31so8435670ybj.4 for ; Thu, 27 Jan 2022 04:56:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=accedian.com; s=corp1; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vhq/I9c7q7dBW6sn6aYqKnDAcn6DUws0ejE2U+SSanM=; b=Zbv+g+U6cDV7aPcthqtYB+26ykntpXBF2C6wl9MNXd0wBCSjdSzYT7ONVHVQvrmrc/ E2JSXlKPa55a6rAex6pkhI3s3zSp/8bB8lLeufFRqpXboTMxbkaUZcWytjYgWew8Vvt8 XbtX3a8KWyV5C/R47yfKLgsR+J9dP3cveGhgw+lH5tQrWq/eW7AfyT+yF6EtNeGOFGD+ j5oB0qDeWhoxmRVCs4pNhtWSAwy+/gZv/Be4LpklkXeagniZ6xZKyAy0pq/I9PoKatY0 Zzi6O0XVbB9R4bWnv//3vNBfyp0I5crSi7vQ/6YgUHHBH2XDbKPseRTbDFki3+Apk0Ry 4log== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vhq/I9c7q7dBW6sn6aYqKnDAcn6DUws0ejE2U+SSanM=; b=8RCKKeTqmwaUStyGnh7AGR2i1QhZl6kDIoAzAxj+pyB4fXJANSo6hxEHRv8VYLgZr3 l/YK+0TgQAo05zBsdXLtcx7B2O3s8dn7OS67lb7Aq+ptW1cJlq6wzqJ0bYKpQvn4SFxF NOIh1SQ3b9amnCyUNmRs9Ni4dMj1mcSHujjzVzWVxzBDd0PlHggvwcMOTx6HLChuiGod lMVnhLoKsjhWrl/UyR6Q2KHqPW4asoYAcQ4sHgvJXkTszZCeLnaIk5QfAdd0fqY+ZrLy XznVtwxXvHctj6QQISJGz/oVL196H1LZFNv6/OPpee96t+yRYYIKP3kao5Gejc4iLWO5 TdIA== X-Gm-Message-State: AOAM5337xkdBKBlBXupzpqOM+8f3N1LdO5w+nz394ZoBqQKQRFwkrDyj R2hLwLTC6C4xPocXMuIPfDIYZElNdUulhDXSChA8l1eW3NMvtxRCa/tUedmLF/cvR4EdIDLj7Yb A5qg8YrXovQ== X-Google-Smtp-Source: ABdhPJz6hRy/MquEqWbVWggbdn+e0742iMGEJN8ts1Q+DPIHk8lwZH3PINX6Bk9DBBKYxI+1fOexLKhumZgok2d42xw= X-Received: by 2002:a25:9f83:: with SMTP id u3mr5522011ybq.474.1643288207764; Thu, 27 Jan 2022 04:56:47 -0800 (PST) MIME-Version: 1.0 References: <164300504281.12619.16642699818590435984@ietfa.amsl.com> <015a01d81295$fdd37370$f97a5a50$@chinatelecom.cn> <70c388c86215411796ef55d48711b216@huawei.com> <3a33416375314462af22d1837e8472dc@huawei.com> <26d83b5f046a439785f52d9599209c95@huawei.com> <3836af861e8c43b2843f083e5ec3c51e@huawei.com> In-Reply-To: From: Henrik Nydell Date: Thu, 27 Jan 2022 13:56:30 +0100 Message-ID: To: Tianran Zhou Cc: wangaj3 , IETF IPPM WG Content-Type: multipart/alternative; boundary="000000000000e3461005d68fd996" Archived-At: Subject: Re: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2022 12:56:56 -0000 --000000000000e3461005d68fd996 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable OK, then I fail to understand why this extension is required, at least when it comes to LAG. There are already standards for monitoring L2 links, and in you LAG case it would then be more appropriate to use 3x Y.1731 or similar to accomplish this. In general I would support the concept of "micro sessions", or "session IDs" but this should then be promoted as a common method to allow several TWAMP flows between the same two endpoints, and not mention LAG specifically, since it actually does not help monitoring LAG paths in a general sense as I have described. On Thu, Jan 27, 2022 at 1:37 PM Tianran Zhou wrote= : > Hi Henrik, > > > This draft is not targeting for your case. China mobile raised the LAG PM= requirement in their network. > > > But as I mentioned in the introduction, it could be potentially used for = SR policy with L3 multi hops. This is out of scope. But I would happy to sh= are my point. :-) > > Best, > Tianran > > > > > ------------------------------ > > Sent from WeLink > *=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A *Henrik Nydell > *=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A *Tianran Zhou > *=E6=8A=84=E9=80=81=EF=BC=9A *wangaj3;IETF IPPM = WG > *=E4=B8=BB=E9=A2=98=EF=BC=9A *Re: [ippm] FW: New Version Notification for > draft-li-ippm-otwamp-on-lag-02.txt > *=E6=97=B6=E9=97=B4=EF=BC=9A *2022-01-27 20:20:53 > > In my mind TWAMP, being a layer-3 method, is more commonly used on longer > e-2-e layer3 connections, for example sender from a central core site out > to a reflector on a radio base station. The path between may have several > layer3 hops and many layer-2. If there is LAG somewhere there in the midd= le > of the path, how will this draft help? > > > On Thu, Jan 27, 2022 at 12:48 PM Tianran Zhou > wrote: > >> Hi Henrik, >> >> May I understand what=E2=80=99s the limits? >> The twamp or lag? Or other? >> >> Actually both are supported in existing devices. As far as I know quite = normal. >> >> Best, >> Tianran >> >> >> >> >> ------------------------------ >> >> Sent from WeLink >> *=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A *Henrik Nydell >> *=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A *Tianran Zhou >> *=E6=8A=84=E9=80=81=EF=BC=9A *wangaj3;IETF IPPM= WG >> *=E4=B8=BB=E9=A2=98=EF=BC=9A *Re: [ippm] FW: New Version Notification fo= r >> draft-li-ippm-otwamp-on-lag-02.txt >> *=E6=97=B6=E9=97=B4=EF=BC=9A *2022-01-27 18:15:39 >> >> OK, but this requires that the sender runs on the device that performs >> the LAG. This would be quite a serious limitation of the feature I belie= ve >> >> On Thu, Jan 27, 2022 at 10:48 AM Tianran Zhou >> wrote: >> >>> Hi Henrik, >>> >>> >>> >>> Both sender and reflector keep the mapping between member link and the >>> micro session. Either by configuration or negotiation or auto-learning. >>> >>> So, in your switch case, if the sender receives the packet from C, not >>> A, the sender know it=E2=80=99s wrong. The test packet should be droppe= d and not >>> counted. >>> >>> >>> >>> Best, >>> >>> Tianran >>> >>> *From:* Henrik Nydell [mailto:hnydell@accedian.com] >>> *Sent:* Thursday, January 27, 2022 5:29 PM >>> *To:* Tianran Zhou >>> *Cc:* wangaj3@chinatelecom.cn; IETF IPPM WG >>> *Subject:* Re: [ippm] FW: New Version Notification for >>> draft-li-ippm-otwamp-on-lag-02.txt >>> >>> >>> >>> Thanks for the clarification, but this "member link validation >>> mechanism" depends fully on configuration between the session sender an= d >>> the session reflector right? So even if they have agreed that a certain >>> session ID belongs to lag link A, there is no way to be sure that this = is >>> the case, the intermediate switches may place these packets randomly ov= er >>> links A-C and the TWAMP/OWAMP sender/reflectors will have no knowledge = of >>> this. So I dont know if this addition adds much usefulnes over the alre= ady >>> existing capabilities of TWAMP, where you can use the 5-tuple of port-p= air, >>> IP-pair and TOS to differentiate session from each other. >>> >>> >>> >>> >>> >>> On Thu, Jan 27, 2022 at 2:37 AM Tianran Zhou >>> wrote: >>> >>> Hi Henrik, >>> >>> >>> >>> Thanks very much for your review. >>> >>> Your perspective is absolutely correct. >>> >>> This draft is not able to =E2=80=9Cguarantee=E2=80=9D a specific LAG pa= th. For example, >>> there is a switch between the two end points, or in the case the reflec= tor >>> is not capable. >>> >>> I.e., as you said, there is no "one method fits all" to guarantee the >>> path. >>> >>> >>> >>> However, this draft seek another way round, the member link validation >>> mechanism. >>> >>> There is an assumption in the introduction =E2=80=9CThis document inten= ds to >>> address the scenario where a LAG directly connects two nodes (A and B).= =E2=80=9D >>> >>> With the member link validation, sender/reflector will drop measurement >>> data, when the test packet is not from the expected member link. >>> >>> In this way, the measurement could always be correct. >>> >>> >>> >>> This is somewhat similar to Paris Traceroute ( >>> https://paris-traceroute.net/about/), IMHO. >>> >>> >>> >>> Cheers, >>> >>> Tianran >>> >>> >>> >>> *From:* Henrik Nydell [mailto:hnydell@accedian.com] >>> *Sent:* Wednesday, January 26, 2022 6:17 PM >>> *To:* Tianran Zhou >>> *Cc:* wangaj3@chinatelecom.cn; IETF IPPM WG >>> *Subject:* Re: [ippm] FW: New Version Notification for >>> draft-li-ippm-otwamp-on-lag-02.txt >>> >>> >>> >>> I had a brief review but failed to find details on how the TWAMP >>> sessions would be "guaranteed" to travel on a certain LAG segment. As f= ar >>> as I know the LAG implementation may be different between vendors and a= s >>> such I know of no "one method fits all" to actually accomplish the >>> measurement. >>> >>> >>> >>> So this draft does not actually provide any solution to the problem of >>> being able to measure LAG segments separately and deterministically. >>> >>> >>> >>> On Wed, Jan 26, 2022 at 11:03 AM Tianran Zhou >> 40huawei.com@dmarc.ietf.org> wrote: >>> >>> Hi Anjun, >>> >>> Thanks very much for your interest and comments. >>> Both are good questions. >>> Please see in line. >>> >>> Cheers, >>> Tianran >>> >>> -----Original Message----- >>> From: wangaj3@chinatelecom.cn [mailto:wangaj3@chinatelecom.cn] >>> Sent: Wednesday, January 26, 2022 5:21 PM >>> To: Tianran Zhou ; 'IETF IPPM WG' >> > >>> Subject: RE: [ippm] FW: New Version Notification for >>> draft-li-ippm-otwamp-on-lag-02.txt >>> >>> Hi, Tianran: >>> >>> Have a brief review of this draft. I think its aim is straightforward >>> and will be useful to utilize the member link within the LAG. >>> Some comments are below: >>> 1) It seems there is no Sender/Reflector behavior description for the >>> Mirco OWAMP session and the packet format? >>> >>> >>> ZTR> OWAMP is simple and there is no reflector. The sender cannot get >>> the ack from the receiver. So we are not going to extend the OWAMP test >>> packet. >>> The behavior is described in section 3.2: >>> " The micro OWAMP Sender MUST send the micro OWAMP-Test packets over th= e >>> member link with which the session is associated. When receives a Test >>> packet, the micro OWAMP receiver MUST use the member link from which th= e >>> Test packet is received to correlate the micro OWAMP session. If there = is >>> no such a session, the Test packet MUST be discarded. " >>> >>> 2) For the newly defined Session-Sender Packet/Session-Reflector Packet= , >>> how to assure the backward compatibility? What I have seen is that you = add >>> two additional fields within the existing Packet? >>> >>> ZTR> I am not aware of the compatibility problem. If a node supports >>> micro session, it can understand the new packet extension. If a node do= es >>> not support micro session, it just ignores the new fields. Because the = new >>> fields is in the reserved zone. >>> Moreover, the validation mechanism can figure out if the reflector can >>> support the micro session. >>> >>> Best Regards >>> >>> Aijun Wang >>> China Telecom >>> >>> -----Original Message----- >>> From: ippm On Behalf Of Tianran Zhou >>> Sent: Monday, January 24, 2022 2:23 PM >>> To: IETF IPPM WG (ippm@ietf.org) >>> Subject: [ippm] FW: New Version Notification for >>> draft-li-ippm-otwamp-on-lag-02.txt >>> >>> Hi WG, >>> >>> We think this is an useful work on adapting OWAMP/TWAMP in LAG >>> performance measurement. >>> We updated this draft based on the comments from the meeting discussion >>> and mailing list. >>> Thanks for all the suggestions. >>> More reviews and comments are welcome. >>> >>> Cheers, >>> Tianran >>> >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Monday, January 24, 2022 2:17 PM >>> To: Greg Mirsky ; Guo Jun ; >>> Jun Guo ; Rakesh Gandhi ; >>> Tianran Zhou ; Zhenqiang Li < >>> li_zhenqiang@hotmail.com> >>> Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.tx= t >>> >>> >>> A new version of I-D, draft-li-ippm-otwamp-on-lag-02.txt >>> has been successfully submitted by Tianran Zhou and posted to the IETF >>> repository. >>> >>> Name: draft-li-ippm-otwamp-on-lag >>> Revision: 02 >>> Title: One-way/Two-way Active Measurement Protocol Extensions >>> for >>> Performance Measurement on LAG >>> Document date: 2022-01-24 >>> Group: Individual Submission >>> Pages: 13 >>> URL: >>> https://www.ietf.org/archive/id/draft-li-ippm-otwamp-on-lag-02.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-li-ippm-otwamp-on-lag/ >>> Htmlized: >>> https://datatracker.ietf.org/doc/html/draft-li-ippm-otwamp-on-lag >>> Diff: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-li-ippm-otwamp-on-lag-02 >>> >>> Abstract: >>> This document defines extensions to One-way Active Measurement >>> Protocol (OWAMP), and Two-way Active Measurement Protocol (TWAMP) to >>> implement performance measurement on every member link of a Link >>> Aggregation Group (LAG). Knowing the measured metrics of each membe= r >>> link of a LAG enables operators to enforce the performance based >>> traffic steering policy across the member links. >>> >>> >>> >>> >>> >>> The IETF Secretariat >>> >>> >>> _______________________________________________ >>> ippm mailing list >>> ippm@ietf.org >>> https://www.ietf.org/mailman/listinfo/ippm >>> >>> _______________________________________________ >>> ippm mailing list >>> ippm@ietf.org >>> https://www.ietf.org/mailman/listinfo/ippm >>> >>> >>> >>> >>> -- >>> >>> >>> *Henrik Nydell* >>> *Sr Product Manager* >>> 1.866.685.8181 >>> hnydell@accedian.com >>> >>> >>> >>> >>> *accedian.com * >>> >>> >>> >>> Avis de confidentialit=C3=A9 >>> >>> Les informations contenues dans le pr=C3=A9sent message et dans toute p= i=C3=A8ce >>> qui lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9= g=C3=A9es par le >>> secret professionnel. Ces informations sont =C3=A0 l=E2=80=99usage excl= usif de son ou de >>> ses destinataires. Si vous recevez ce message par erreur, veuillez s=E2= =80=99il >>> vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3=A9diteu= r et en d=C3=A9truire tout >>> exemplaire. De plus, il vous est strictement interdit de le divulguer, = de >>> le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2= =80=99exp=C3=A9diteur. >>> Merci. >>> >>> Confidentiality notice >>> >>> This e-mail message and any attachment hereto contain confidential >>> information which may be privileged and which is intended for the exclu= sive >>> use of its addressee(s). If you receive this message in error, please >>> inform sender immediately and destroy any copy thereof. Furthermore, an= y >>> disclosure, distribution or copying of this message and/or any attachme= nt >>> hereto without the consent of the sender is strictly prohibited. Thank = you. >>> >>> >>> >>> >>> -- >>> >>> >>> *Henrik Nydell* >>> *Sr Product Manager* >>> 1.866.685.8181 >>> hnydell@accedian.com >>> >>> >>> >>> >>> *accedian.com * >>> >>> >>> >>> Avis de confidentialit=C3=A9 >>> >>> Les informations contenues dans le pr=C3=A9sent message et dans toute p= i=C3=A8ce >>> qui lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9= g=C3=A9es par le >>> secret professionnel. Ces informations sont =C3=A0 l=E2=80=99usage excl= usif de son ou de >>> ses destinataires. Si vous recevez ce message par erreur, veuillez s=E2= =80=99il >>> vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3=A9diteu= r et en d=C3=A9truire tout >>> exemplaire. De plus, il vous est strictement interdit de le divulguer, = de >>> le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2= =80=99exp=C3=A9diteur. >>> Merci. >>> >>> Confidentiality notice >>> >>> This e-mail message and any attachment hereto contain confidential >>> information which may be privileged and which is intended for the exclu= sive >>> use of its addressee(s). If you receive this message in error, please >>> inform sender immediately and destroy any copy thereof. Furthermore, an= y >>> disclosure, distribution or copying of this message and/or any attachme= nt >>> hereto without the consent of the sender is strictly prohibited. Thank = you. >>> >> >> >> -- >> >> *Henrik Nydell* >> *Sr Product Manager* >> 1.866.685.8181 >> hnydell@accedian.com >> >> >> >> >> *accedian.com * >> >> Avis de confidentialit=C3=A9 >> >> Les informations contenues dans le pr=C3=A9sent message et dans toute pi= =C3=A8ce >> qui lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g= =C3=A9es par le >> secret professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclu= sif de son ou de >> ses destinataires. Si vous recevez ce message par erreur, veuillez s=E2= =80=99il >> vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3=A9diteur= et en d=C3=A9truire tout >> exemplaire. De plus, il vous est strictement interdit de le divulguer, d= e >> le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80= =99exp=C3=A9diteur. >> Merci. >> >> Confidentiality notice >> >> This e-mail message and any attachment hereto contain confidential >> information which may be privileged and which is intended for the exclus= ive >> use of its addressee(s). If you receive this message in error, please >> inform sender immediately and destroy any copy thereof. Furthermore, any >> disclosure, distribution or copying of this message and/or any attachmen= t >> hereto without the consent of the sender is strictly prohibited. Thank y= ou. >> > > > -- > > *Henrik Nydell* > *Sr Product Manager* > 1.866.685.8181 > hnydell@accedian.com > > > > > *accedian.com * > > Avis de confidentialit=C3=A9 > > Les informations contenues dans le pr=C3=A9sent message et dans toute pi= =C3=A8ce qui > lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3= =A9es par le secret > professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de s= on ou de ses > destinataires. Si vous recevez ce message par erreur, veuillez s=E2=80=99= il vous > plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3=A9diteur et en= d=C3=A9truire tout > exemplaire. De plus, il vous est strictement interdit de le divulguer, de > le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80= =99exp=C3=A9diteur. > Merci. > > Confidentiality notice > > This e-mail message and any attachment hereto contain confidential > information which may be privileged and which is intended for the exclusi= ve > use of its addressee(s). If you receive this message in error, please > inform sender immediately and destroy any copy thereof. Furthermore, any > disclosure, distribution or copying of this message and/or any attachment > hereto without the consent of the sender is strictly prohibited. Thank yo= u. > --=20 *Henrik Nydell* *Sr Product Manager* 1.866.685.8181 hnydell@accedian.com *accedian.com * --=20 Avis de confidentialit=C3=A9 Les informations contenues dans le pr=C3=A9sent=20 message et dans toute pi=C3=A8ce qui=20 lui est jointe sont confidentielles et=20 peuvent =C3=AAtre prot=C3=A9g=C3=A9es par le=20 secret professionnel. Ces informations sont=20 =C3=A0 l=E2=80=99usage exclusif de son ou de ses destinataires. Si vous recevez ce=20 message par erreur, veuillez=20 s=E2=80=99il vous plait communiquer imm=C3=A9diatement=20 avec l=E2=80=99exp=C3=A9diteur et en=20 d=C3=A9truire tout exemplaire. De plus, il vous est=20 strictement interdit de=20 le divulguer, de le distribuer ou de le reproduire=20 sans l=E2=80=99autorisation=20 de l=E2=80=99exp=C3=A9diteur. Merci. Confidentiality notice This e-mail message and any attachment hereto contain confidential=20 information=20 which may be privileged and which is intended for the=20 exclusive use of its=20 addressee(s). If you receive this message in error, please inform sender=20 immediately and destroy any copy thereof.=20 Furthermore, any disclosure,=20 distribution or copying of this message=20 and/or any attachment hereto=20 without the consent of the sender is=20 strictly prohibited. Thank you. --000000000000e3461005d68fd996 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
        OK,= then I fail to understand why this extension is required, at least when it= comes to LAG. There are already standards for monitoring L2 links, and in = you LAG case it would then be more appropriate to use 3x Y.1731 or similar = to accomplish this.

        In ge= neral I would support the concept of "micro sessions", or "s= ession IDs" but this should then be promoted as a common method to all= ow several TWAMP flows between the same two endpoints, and not mention LAG = specifically, since it actually does not help monitoring LAG paths in a gen= eral sense as I have described.


        On Thu, Jan 27, 2022 at 1:37 PM Tianran Zhou <= ;zhoutianran@huawei.com> w= rote:
        Hi=C2=A0Henrik,
        This=C2=A0draft=C2=A0is= =C2=A0not=C2=A0targeting=C2=A0for=C2=A0your=C2=A0case.=C2=A0China=C2=A0mobi= le=C2=A0raised=C2=A0the=C2=A0LAG=C2=A0PM=C2=A0requirement=C2=A0in=C2=A0thei= r=C2=A0network.

        But=C2=A0as=C2=A0I=C2=A0= mentioned=C2=A0in=C2=A0the=C2=A0introduction,=C2=A0it=C2=A0could=C2=A0be=C2= =A0potentially=C2=A0used=C2=A0for=C2=A0SR=C2=A0policy=C2=A0with=C2=A0L3=C2= =A0multi=C2=A0hops.=C2=A0This=C2=A0is=C2=A0out=C2=A0of=C2=A0scope.=C2=A0But= =C2=A0I=C2=A0would=C2=A0happy=C2=A0to=C2=A0share=C2=A0my=C2=A0point.=C2=A0:= -)

        Best,
        Tianran=C2=A0





        Sent=C2=A0from=C2=A0WeLi= nk
        In my mind TWAMP, be= ing a layer-3 method, is more commonly used on longer e-2-e layer3 connecti= ons, for example sender from a central core site out to a reflector on a ra= dio base station. The path between may have several layer3 hops and many layer-2. If there is LAG somewhere there= in the middle of the path, how will this draft help?


        On Thu, Jan 27, 2022 at 12:48 PM Tian= ran Zhou <zh= outianran@huawei.com> wrote:
        Hi=C2=A0Henrik,

        May=C2=A0I=C2=A0understa= nd=C2=A0what=E2=80=99s=C2=A0the=C2=A0limits?
        The=C2=A0twamp=C2=A0or= =C2=A0lag?=C2=A0Or=C2=A0other?
        Actually=C2=A0both=C2=A0= are=C2=A0supported=C2=A0in=C2=A0existing=C2=A0devices.=C2=A0As=C2=A0far=C2= =A0as=C2=A0I=C2=A0know=C2=A0quite=C2=A0normal.

        Best,
        Tianran=C2=A0





        Sent=C2=A0from=C2=A0WeLi= nk
        OK, but this require= s that the sender runs on the device that performs the LAG. This would be q= uite a serious limitation of the feature I believe

        On Thu, Jan 27, 2022 at 10:48 AM Tian= ran Zhou <zh= outianran@huawei.com> wrote:

        Hi Henrik,

        =C2=A0

        Both sender and reflector keep the mapping b= etween member link and the micro session. Either by configuration or negoti= ation or auto-learning.

        So, in your switch case, if the sender recei= ves the packet from C, not A, the sender know it=E2=80=99s wrong. The test = packet should be dropped and not counted.

        =C2=A0

        Best,

        Tianran

        From: Henrik Nydell [mailto:hnydell@accedian.com]
        Sent: Thursday, January 27, 2022 5:29 PM
        To: Tianran Zhou <zhoutianran@huawei.com>
        Cc: wan= gaj3@chinatelecom.cn; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [ippm] FW: New Version Notification for draft-li-ippm-o= twamp-on-lag-02.txt

        =C2=A0

        Thanks for the clarification, but this "member = link validation mechanism" depends fully on configuration between the = session sender and the session reflector right? So even if they have agreed= that a certain session ID belongs=C2=A0to lag link A, there is no way to be sure that this is the case, the intermediate swit= ches may place these packets randomly over links A-C and the TWAMP/OWAMP se= nder/reflectors will have no knowledge of this. So I dont know if this addi= tion adds much usefulnes over the already existing capabilities of TWAMP, where you can use the 5-tuple of p= ort-pair, IP-pair and TOS to differentiate session from each other.<= u>

        =C2=A0

        =C2=A0

        On Thu, Jan 27, 2022 at 2:37 AM Tianran Zhou <zhoutianran@huawei= .com> wrote:

        Hi Henrik,

        =C2=A0

        Thanks very much for your review.<= /u>

        Your perspective is absolutely correct.

        This draft is not able to =E2=80=9Cguarantee= =E2=80=9D a specific LAG path. For example, there is a switch between the t= wo end points, or in the case the reflector is not capable.

        I.e., as you said, there is no "one met= hod fits all" to guarantee the path.

        =C2=A0

        However, this draft seek another way round, = the member link validation mechanism.

        There is an assumption in the introduction = =E2=80=9CThis document intends to address the scenario where a LAG directly= connects two nodes (A and B).=E2=80=9D

        With the member link validation, sender/refl= ector will drop measurement data, when the test packet is not from the expe= cted member link.

        In this way, the measurement could always be= correct.

        =C2=A0

        This is somewhat similar to Paris Traceroute= (https:/= /paris-traceroute.net/about/), IMHO.

        =C2=A0

        Cheers,

        Tianran

        =C2=A0

        From: Henrik Nydell [mailto:hnydell@accedian.com]
        Sent: Wednesday, January 26, 2022 6:17 PM
        To: Tianran Zhou <zhoutianran@huawei.com>
        Cc: wan= gaj3@chinatelecom.cn; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [ippm] FW: New Version Notification for draft-li-ippm-o= twamp-on-lag-02.txt

        =C2=A0

        I had a brief review but failed to find details on h= ow the TWAMP sessions would be "guaranteed" to travel on a certai= n LAG segment. As far as I know the LAG implementation may be different bet= ween vendors and as such I know of no "one method fits all" to actually accomplish the measurement.

        =C2=A0

        So this draft does not actually provide any solution= to the problem of being able to measure LAG segments separately and determ= inistically.

        =C2=A0

        On Wed, Jan 26, 2022 at 11:03 AM Tianran Zhou <zh= outianran=3D40huawei.com@dmarc.ietf.org> wrote:

        Hi Anjun,

        Thanks very much for your interest and comments.
        Both are good questions.
        Please see in line.

        Cheers,
        Tianran

        -----Original Message-----
        From: wangaj3@= chinatelecom.cn [mailto:wangaj3@chinatelecom.cn]
        Sent: Wednesday, January 26, 2022 5:21 PM
        To: Tianran Zhou <zhoutianran@huawei.com>; 'IETF IPPM WG' <ippm@ietf.org>
        Subject: RE: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-o= n-lag-02.txt

        Hi, Tianran:

        Have a brief review of this draft. I think its aim is straightforward and w= ill be useful to utilize the member link within the LAG.
        Some comments are below:
        1) It seems there is no Sender/Reflector behavior description for the Mirco= OWAMP session and the packet format?


        ZTR> OWAMP is simple and there is no reflector. The sender cannot get th= e ack from the receiver. So we are not going to extend the OWAMP test packe= t.
        The behavior is described in section 3.2:
        " The micro OWAMP Sender MUST send the micro OWAMP-Test packets over t= he member link with which the session is associated. When receives a Test p= acket, the micro OWAMP receiver MUST use the member link from which the Tes= t packet is received to correlate the micro OWAMP session. If there is no such a session, the Test packet MUST b= e discarded. "

        2) For the newly defined Session-Sender Packet/Session-Reflector Packet, ho= w to assure the backward compatibility? What I have seen is that you add tw= o additional fields within the existing Packet?

        ZTR> I am not aware of the compatibility problem. If a node supports mic= ro session, it can understand the new packet extension. If a node does not = support micro session, it just ignores the new fields. Because the new fiel= ds is in the reserved zone.
        Moreover, the validation mechanism can figure out if the reflector can supp= ort the micro session.

        Best Regards

        Aijun Wang
        China Telecom

        -----Original Message-----
        From: ippm <i= ppm-bounces@ietf.org> On Behalf Of Tianran Zhou
        Sent: Monday, January 24, 2022 2:23 PM
        To: IETF IPPM WG (ippm@i= etf.org) <ippm@ie= tf.org>
        Subject: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-la= g-02.txt

        Hi WG,

        We think this is an useful work on adapting OWAMP/TWAMP in LAG performance = measurement.
        We updated this draft based on the comments from the meeting discussion and= mailing list.
        Thanks for all the suggestions.
        More reviews and comments are welcome.

        Cheers,
        Tianran

        -----Original Message-----
        From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
        Sent: Monday, January 24, 2022 2:17 PM
        To: Greg Mirsky <gregimirsky@gmail.com>; Guo Jun <guo.jun2@zte.com.cn>; Jun Guo <guo.jun2@zte.com.cn= >; Rakesh Gandhi <r= gandhi@cisco.com>; Tianran Zhou <zhoutianran@huawei.com>; Zhenqiang Li &l= t;li_zhenqian= g@hotmail.com>
        Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

        A new version of I-D, draft-li-ippm-otwamp-on-lag-02.txt
        has been successfully submitted by Tianran Zhou and posted to the IETF repo= sitory.

        Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-li-ippm-otwamp-on-lag Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
        Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 One-way/Two-way Active Measurement= Protocol Extensions for
        Performance Measurement on LAG
        Document date:=C2=A0 2022-01-24
        Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
        Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 13
        URL:
        https://www.ietf.org/archive/id/draft-li-ippm-otwamp-= on-lag-02.txt
        Status:
        https://datatracker.ietf.org/doc/draft-li-ippm-otwamp-on-l= ag/
        Htmlized:
        https://datatracker.ietf.org/doc/html/draft-li-ippm-ot= wamp-on-lag
        Diff:
        https://www.ietf.org/rfcdiff?url2=3Ddraft-li-ippm-otw= amp-on-lag-02

        Abstract:
        =C2=A0 =C2=A0This document defines extensions to One-way Active Measurement=
        =C2=A0 =C2=A0Protocol (OWAMP), and Two-way Active Measurement Protocol (TWA= MP) to
        =C2=A0 =C2=A0implement performance measurement on every member link of a Li= nk
        =C2=A0 =C2=A0Aggregation Group (LAG).=C2=A0 Knowing the measured metrics of= each member
        =C2=A0 =C2=A0link of a LAG enables operators to enforce the performance bas= ed
        =C2=A0 =C2=A0traffic steering policy across the member links.





        The IETF Secretariat


        _______________________________________________
        ippm mailing list
        ippm@ietf.org
        ht= tps://www.ietf.org/mailman/listinfo/ippm

        _______________________________________________
        ippm mailing list
        ippm@ietf.org
        ht= tps://www.ietf.org/mailman/listinfo/ippm


        =C2=A0

        --

        =C2=A0

        Avis de confidentialit=C3= =A9

        Les informations contenue= s dans le pr=C3=A9sent message et dans toute pi=C3=A8ce qui lui est jointe = sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9es par le secret= professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de so= n ou de ses destinataires. Si vous recevez ce message par erreur, veuillez s= =E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3= =A9diteur et en d=C3=A9truire tout exemplaire. De plus, il vous est stricte= ment interdit de le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80=99exp=C3=A9diteur. Merci.=

        Confidentiality notice

        This e-mail message and any attachment h= ereto contain confidential information which may be privileged and which is= intended for the exclusive use of its addressee(s). If you receive this me= ssage in error, please inform sender immediately and destroy any copy thereof. Furthermore, any disclosure, dis= tribution or copying of this message and/or any attachment hereto without t= he consent of the sender is strictly prohibited. Thank you.


        =C2=A0

        --


        Henrik Nydell
        Sr Product Manager
        1.866.685.8181
        hnydell@accedian.= com
        <= br> =C2=A0=C2=A0
        =
        acc= edian.com

        =C2=A0

        Avis de confidentialit=C3= =A9

        Les informations contenue= s dans le pr=C3=A9sent message et dans toute pi=C3=A8ce qui lui est jointe = sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9es par le secret= professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de so= n ou de ses destinataires. Si vous recevez ce message par erreur, veuillez s= =E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3= =A9diteur et en d=C3=A9truire tout exemplaire. De plus, il vous est stricte= ment interdit de le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80=99exp=C3=A9diteur. Merci.=

        Confidentiality notice

        This e-mail message and any attachment h= ereto contain confidential information which may be privileged and which is= intended for the exclusive use of its addressee(s). If you receive this me= ssage in error, please inform sender immediately and destroy any copy thereof. Furthermore, any disclosure, dis= tribution or copying of this message and/or any attachment hereto without t= he consent of the sender is strictly prohibited. Thank you.



        --

        Henrik Nydell
        Sr Product Manager
        1.866.685.8181
        hnydell@accedian.= com
        3D""
        =3D""=C2=A03D""=C2=A03D""
        3D""
        accedian.com=

        Avis de confidentialit=C3=A9

        Les informations contenues dans le= pr=C3=A9sent message et dans toute pi=C3=A8ce qui lui est jointe sont conf= identielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9es par le secret professi= onnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez s=E2=80= =99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3=A9dit= eur et en d=C3=A9truire tout exemplaire. De plus, il vous est strictement i= nterdit de le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80=99exp=C3=A9diteur. Merci.<= /p>

        Confidentiality notice

        This e-mail message and any attachment hereto contain c= onfidential information which may be privileged and which is intended for t= he exclusive use of its addressee(s). If you receive this message in error,= please inform sender immediately and destroy any copy thereof. Furthermore, any disclosure, distribution or= copying of this message and/or any attachment hereto without the consent o= f the sender is strictly prohibited. Thank you.



        --

        Henrik Nydell
        Sr Product Manager
        1.866.685.8181
        hnydell@accedian.= com
        3D""
        =3D""=C2=A03D""=C2=A03D""
        3D""
        accedian.com=

        Avis de confidentialit=C3=A9

        Les informations contenues dans le= pr=C3=A9sent message et dans toute pi=C3=A8ce qui lui est jointe sont conf= identielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9es par le secret professi= onnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez s=E2=80= =99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3=A9dit= eur et en d=C3=A9truire tout exemplaire. De plus, il vous est strictement i= nterdit de le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80=99exp=C3=A9diteur. Merci.<= /p>

        Confidentiality notice

        This e-mail message and any attachment hereto contain c= onfidential information which may be privileged and which is intended for t= he exclusive use of its addressee(s). If you receive this message in error,= please inform sender immediately and destroy any copy thereof. Furthermore, any disclosure, distribution or= copying of this message and/or any attachment hereto without the consent o= f the sender is strictly prohibited. Thank you.



        --

        Henrik Nydell
        Sr Product Manager
        1.866.685.8181
        hnydell@accedian.= com
        3D""
        =3D""=C2=A03D""=C2=A03D""
        3D""
        accedian.com=

        Avis de confidentialit=C3=A9

        Les informations contenues dans le pr=C3=A9sent message et dans toute pi=C3=A8= ce qui=20 lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9e= s par le=20 secret professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif= de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez=20 s=E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp= =C3=A9diteur et en=20 d=C3=A9truire tout exemplaire. De plus, il vous est strictement interdit de= =20 le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisat= ion=20 de l=E2=80=99exp=C3=A9diteur. Merci.

        Confidentiality notice

        This e-mail message and any attachment hereto contain confidential=20 information which may be privileged and which is intended for the=20 exclusive use of its addressee(s). If you receive this message in error, please inform sender immediately and destroy any copy thereof.=20 Furthermore, any disclosure, distribution or copying of this message=20 and/or any attachment hereto without the consent of the sender is=20 strictly prohibited. Thank you.

        --000000000000e3461005d68fd996-- From nobody Thu Jan 27 10:42:29 2022 Return-Path: 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 A1AFF3A0C31; Thu, 27 Jan 2022 10:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_REMOTE_IMAGE=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBnzYmpSx9a5; Thu, 27 Jan 2022 10:42:22 -0800 (PST) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2090.outbound.protection.outlook.com [40.107.223.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CA813A0C2D; Thu, 27 Jan 2022 10:42:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Qd/8/VYQgrwFQ8dUn0gmtw7qIO181+rN9PfsSs2z7ZpJhdetFVJamV4+UfLrp6892/AKPlZJ2SHrdmpvz7/448WLZ4t1ST0/i0UKUJHUnDiYRCSJgzfKdnm3JHjC7PAj115vwCOMUy37LNCHtGClTU5CpO+M1WqDaLU3GfSGi2rlUw3hCSKw/16XheD3cau71tUSHxeVnepHYJ1BagewJXviK8xUIPMRAMbTC8oVcvHpVN77/qTQ9pv51OUCcv8eUzF4fyMXlQjObrG2RITerQBczx3pS9q87ElWuuGUm0dwBp7q4nib5XqR9BeHF1/tAxq9yUruLkaOdoyjm4HysA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=E6Za+QreDTMyT0GR9GxHnVZF1LFXc8AzHhdaMgd3Atk=; b=epMceCTbXyRk7QX7pbSc4W4DZ/Q8zbMwL5CMGY24MC4te5SSIJEI45I2pEvv4GwHsqbK7hum7YTWl6RbVe7rtXy7acWIa6pSmKX9zJdPMnDZjqwpmmGbbT6FspZ/0bmHSMRhw19eazv+tOgFGn5KGug5WUvYMADc75IV0NVQggDtFO/a7r1ITcUvKKDEjKdxqexvAlXV4ZV3t/mV5Rv2Xspzrv7NUWWdXXVePiBbRHPn421Ev6PRuwN/L71CmSpmSHB8RhwFM7YSoDBlAaQyJPEfTooVG6+S8qoXBl6FPDP/1zQq+7N4ZFD4k/PcjJJbJ0ugl1cXf6PJQ8CAwbW29Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E6Za+QreDTMyT0GR9GxHnVZF1LFXc8AzHhdaMgd3Atk=; b=n5OijiksNi55XYaepJQ9MlcTbi/mv2EhyrpMY7frOsnsxFoLKuV5N0kxt47MIsNIjUoXkc7AaFQYXpdKXkt6lUxNfGfsruqB1Fg0NkdNLzL5x6dBbvR+eb7ne+NSkRmTfHS3Ilu6xC6APwgoiADpSYzPSe7m0fOG9Ok1nh+FTsQ= Received: from PH0PR13MB4795.namprd13.prod.outlook.com (2603:10b6:510:92::15) by BN6PR13MB2948.namprd13.prod.outlook.com (2603:10b6:405:81::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.5; Thu, 27 Jan 2022 18:42:14 +0000 Received: from PH0PR13MB4795.namprd13.prod.outlook.com ([fe80::e59d:61b0:e122:be76]) by PH0PR13MB4795.namprd13.prod.outlook.com ([fe80::e59d:61b0:e122:be76%4]) with mapi id 15.20.4951.005; Thu, 27 Jan 2022 18:42:13 +0000 From: Haoyu Song To: Gyan Mishra , Tianran Zhou CC: Greg Mirsky , IETF IPPM WG , "spring@ietf.org" Thread-Topic: [ippm] [spring] Active OAM in SRv6 Thread-Index: AdgTBAVv6vallEwgQVCAy2m6n5m7fAABJueAAAkAnYAAA6MGgAAb+IDA Date: Thu, 27 Jan 2022 18:42:13 +0000 Message-ID: References: <97ee51feb17c4bcc84bc575768c06c3e@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ebc1740e-e5be-4caf-a15e-08d9e1c4bc4f x-ms-traffictypediagnostic: BN6PR13MB2948:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9VlPVsJWOo+bUFXYlhKhWrmI5gUBlOV+lSrcqPXzR4eI/pfHEWLiRVVVzFs/AQLU4vfBHO4tdgXeoRWVqJdIc8dNuWCpwntObLQs77xXqya/PW30CvhwTJEwWsCaeXLQKCvznqWS091+xLY1lRoyPFPkAz7KLJpLAPEEr2qjxXTyF0RIjJ2hicZZDrGxgjez5LfJpG/VlqfrealbaEL6iq9xvAWxvLR5RuISh9psCsHrTmDbG0jwu1Oy1DRenbeECoGplXGTPb8szyE5AWxhsNuT6BDEbhpb8K8wqCQdzNcAiop8TYRwTDU99lqqM/pupTYrdkgRwhYyZBkjX1MOmSHaNQkWzsZYj5qzJroEJzVRimqA8iY0xZKT+0m8fZifhonr58POZ+xnAbDckCM8MlDk2NoGNFst769af/W77lQesd5e2q6NGPGpm6x2mAO7Nl9OwhGdeyrlbRRaQDZh8Sq/29Y+vZKk+7eydSyV91+jzuVkgHoCQOXmc6xa4+lCbps75tt0KQtaMgCjncZ8PSRF1zuLzX5zJvr2jL3tqSd7MQx0pBrijJdO2Lp4CLYSICx4k5EoBl/ANGuCtCHodLTaDyl7U6izW3YRtN6mkDnZ2cKrVzSO4M5g4mnNs9E+mX1tBxDIv/tjIeMliYZbLhA6JaHLtUy46qR4OVCleV02x7JGrv5220meuQxvNrq7Gc4gFGN+3rPpQU3ODS3tKO6QQOlou3PptKY74UP8ArfZXPp11vaDW573n99dYw/2kS6xBCMPH1RsWvU7WxA1c3h1bm5AlZ6z10iv/KdH588cbyz7mTtV7g0RQXaAdbDDutbOyzItjtYl+iMZl7l8S/1AKpuA0hf3lTVomtZBuS19N+mNIbPX8C38IZY6hu4U x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR13MB4795.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(76116006)(64756008)(8676002)(8936002)(4326008)(71200400001)(66446008)(66946007)(316002)(86362001)(66476007)(66556008)(5660300002)(52536014)(40140700001)(6506007)(7696005)(166002)(9326002)(38070700005)(54906003)(966005)(53546011)(110136005)(508600001)(2906002)(33656002)(38100700002)(9686003)(83380400001)(122000001)(44832011)(26005)(186003)(55016003)(20210929001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?QjwOE4+0+tPneX3P7Xu+0fkl2wyZeD6IOKNr7korno9CBI91OJ9PdEV+cO4S?= =?us-ascii?Q?VtleE0BBg9LBKYcG4/N/q+YrR1wBlo9H8dY4PcJhbodwoHU+8FNEwa2Ukp22?= =?us-ascii?Q?dpfM9XW4QE60/N+nxL8MNQBo3Gdk3od+w6pAbDwQiE8LGDY21B0QvU3Aw+5R?= =?us-ascii?Q?6ZS1olqzNMfvhibzdUIuAzzZKc3pOfJhQdUb4zZGeCBM5o09Ft9AIkWh9SEk?= =?us-ascii?Q?FTw1CIZxfdYvqIZYDgRJwCZIS4YIys0sEGpuTkvY1rsPvgNLx+C16Hq7KM0b?= =?us-ascii?Q?KZ3WvNCqr0CxoUx7a+B8h3lq5Btq1T2TGs5jpeB/qCzV29EbFFDeDSVKA55r?= =?us-ascii?Q?E8KcWDZFd65eDgd9I+tsefFpd60xjjqy/v3uGKsoMOh4TJd/iCN5tDkd+XXS?= =?us-ascii?Q?aVr1g2c99y1e/GG49gh6kCazKW2RqZaJbiUFivYhMYCgDHpgUOPRcbrjR9mv?= =?us-ascii?Q?EHhpjtfmggtBWuyJgHAQ8obEpOGe6rnMDCY0vayLgKPBUUlCAfjBtg0nMWe8?= =?us-ascii?Q?EIEYOuR/c14nltr3gvOH9rdETuUu/eoQto6WpzYT++bc2sz1HwWoLcmJsrck?= =?us-ascii?Q?bcrDo5OtP0GvgBZL3PLF/mCB9tK5FVd/g2I0mEas/NzycGPz0b+ioCSvS/ZG?= =?us-ascii?Q?O4Wtc5Bs7F0zoNE5RuKJHoO8khrcwy4reuijsDe9qlc0pWgVGkF5OfM0mRA5?= =?us-ascii?Q?hWrTxhyLjY2OvD4iahNerhHJq8LwDCpsYLiAQZzykAn0mXv2uFCoPYo3r0+r?= =?us-ascii?Q?Kw0H57AiHgPhEu5SRWDDj3IxWoXNt6z11/DHEnLveimt+dfKptPYNiPDXy8+?= =?us-ascii?Q?dl9p5/GlSZLCapk4jGHaz0wek9Qm63ZCiEAgNRWKgjmirEF+sw6aGcqN6NSb?= =?us-ascii?Q?NJ7IAkokVpMfvruKCCBYqxBrPNV2Nl/W+AdgtS23FgEBpnue5l2sdgPbCg6u?= =?us-ascii?Q?gb+gUKNyG2M78iCrNcrDPVn177onzAYZ8R7yO3I6bOY+1rhKsTYKhdLVCwfv?= =?us-ascii?Q?v/AZzhwNbld2bGJ/RzZKMex2tiwujZ+liowVrQsQAUXE0YVSRruseS2Du/I/?= =?us-ascii?Q?7pk81JMt3ehydZnqKe9UYVeOlDuzqyyqbzprb3n3yLnXdmJwRTiVFtkaC39E?= =?us-ascii?Q?nD65KLdNVXgUvNv3RY5T1mOIJbEP4MnxrIoqf6x5050rvTER6JxbLZWx5qh5?= =?us-ascii?Q?4WC7tdNNEkdI3pfnvO84ah/68Qb92os4sfzE++d99p3q1fEFqrnuY6hMpCtU?= =?us-ascii?Q?89Ekixry0mxjwH8z+GaTbqpnmy+Hvo6cXJzDPeRkl1BGw5WqUJTJYQAJLifq?= =?us-ascii?Q?cZHKpeWSTEoTwNRThl9p/NHSC4CkXJQva8R0i7Vk/TRNr9lGtP4gsUzIJU9T?= =?us-ascii?Q?7E2cJ+kbReth++pT6Z+MrbrrWeTivFdRFD1GKze2zjiqqhNa5701ATpzRzpv?= =?us-ascii?Q?jRMPyowsQxHi6wC2Tzlcag8fhu29Z/g2ZgsxU0I7HPVmVMnZrVl+63TNwqTi?= =?us-ascii?Q?CgQyS/KKyYQtZD6FSjWbr7dXjLma5HfggSjARSyrtnhWzeqlBoLdgfM6UAmD?= =?us-ascii?Q?8WoN7WxaaRaq9G/eTumicXNMYJiT0Yk30IVvf70JjoWmdOEsU8utomItah55?= =?us-ascii?Q?jQ=3D=3D?= Content-Type: multipart/alternative; boundary="_000_PH0PR13MB479582418405803B955A66359A219PH0PR13MB4795namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR13MB4795.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ebc1740e-e5be-4caf-a15e-08d9e1c4bc4f X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2022 18:42:13.5829 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9vAao49T/uior0K/koVw52i+BZTseKPoOODhokqRBsdQsCDMJeo+Op2XxRnijIWVXpMoAJ3F1wCt1CtoeMxwEQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR13MB2948 Archived-At: Subject: Re: [ippm] [spring] Active OAM in SRv6 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2022 18:42:28 -0000 --_000_PH0PR13MB479582418405803B955A66359A219PH0PR13MB4795namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Gyan, Thank you for your comments! Please see inline for response marked with [HS= ] Best, Haoyu From: Gyan Mishra Sent: Wednesday, January 26, 2022 9:03 PM To: Tianran Zhou Cc: Greg Mirsky ; Haoyu Song ; IETF IPPM WG ; spring@ietf.org Subject: Re: [ippm] [spring] Active OAM in SRv6 Hi Haoyu I think it would be good to identify the problem statement and gap with exi= sting IPPM WG STAMP, TWAMP PM technologies and why they cannot be utilized = or fall short in what you are trying to achieve with Active OAM in SRv6. [HS] My understanding is that STAMP/TWAMP are for end-to-end measurements, = here we want to collect data from every node and every link on any path, wi= thout needing to set up any sessions. So the scope and coverage are differe= nt. In-situ IOAM data packets is already possible with SRv6 as mentioned as thi= s draft mentions below as normative reference. https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-data-16 [HS] There's no accepted solution on how to support IOAM in SRv6 yet. Our p= roposal aims to provide such a solution, and (1) the solution avoids the is= sues on encapsulating the IOAM trace in EHs and (2) it's extensible to incl= ude OAM methods beyond IOAM. This draft as well mentioned as normative reference draft below provides OA= M ping and traceroute with SRH O flag to SRv6 PGM endpoints and SID list tr= acing capabilities very handy for troubleshooting. https://datatracker.ietf.org/doc/html/draft-ietf-6man-spring-srv6-oam-13 [HS] This is for in-band OAM for SRv6 user traffic and it only works for tr= iggering postcard exports (i.e., don't allow the packet to carry data). Our= proposal support all the IOAM options and more important, it's an active m= ethod which means one can generate and inject probing packets to cover arbi= trary paths by crafting an SRH. This draft as well also mentioned as normative reference draft below provid= es in-situ IOAM for OAM and PM information can be piggybacked in data packe= ts in SRH TLV SRv6 PGM SIF function SRv6.TLV recording the operational and = telemetry info in the data packets. https://datatracker.ietf.org/doc/html/draft-ali-spring-ioam-srv6-05 [HS] This draft proposes to encapsulate IOAM in SRH TLV. Due to the overhea= d concern (IOAM trace could be large) and other issues related to EH, I don= 't support such a solution. [HS] The three drafts you mentioned are all be reference in our draft and d= iscussed. We think our use cases are different and our approach is more gen= eral and extensible to our use cases. Thanks Gyan On Wed, Jan 26, 2022 at 10:19 PM Tianran Zhou > wrote: Hi Haoyu, The application is really interesting and useful. I am not sure if it is necessary to create a new OAM protocol at transport = layer. IMHO, a per hop/per segment extension based on STAMP could be more practica= l. https://www.ietf.org/archive/id/draft-wang-ippm-stamp-hbh-extensions-03.txt= Best, Tianran From: ippm [mailto:ippm-bounces@ietf.org] On = Behalf Of Greg Mirsky Sent: Thursday, January 27, 2022 7:01 AM To: Haoyu Song > Cc: spring@ietf.org; IETF IPPM WG > Subject: Re: [ippm] [spring] Active OAM in SRv6 Hi Haoyu, thank you for bringing the topic of Active OAM to the discussion. As the co= ncept of Active IOAM is introduced in the IPPM WG draft it seems to me like addi= ng the IPPM WG community to the discussion is the right thing to do. Please find my notes in-lined below under the GIM>> tag. Regards, Greg On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song > wrote: Hi SPRING WG, Real time monitor on every node and every link on a network is necessary to= detect gray failures, which are the key culprit for poor QoS but hard to = catch. SR provides an ideal mechanism, when working with some efficient pla= nning algorithm, to achieve that with low cost. Our proposal SRv6 In-situ= Active Measurement (SIAM) suggests a simple active measurement approach w= hich can support different GIM>> I wonder what gaps you find in the existing active measurement protoc= ols, e.g., STAMP and RFC 6734 (would be more convenient to use an acronym).= It appears to me that, for example, STAMP and its extensions, including th= e SRPM draft, comprehensively address the PM OAM requirements for SRv6. options of IOAM and other OAM methods in SRv6, without needing to worry abo= ut the extension header issue. GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows: In terms of the classification given in [RFC7799] IOAM could be portrayed as Hybrid Type 1. Does your proposal change that? Your comments, questions, and suggestions are very welcome. I'd like to kno= w your opinion if you think this work is in scope and should be adopted by = the working group. If you are interested in contributing to this work, ple= ase also let me know. https://datatracker.ietf.org/doc/draft-song-spring-si= am/ Thank you very much! Best regards, Haoyu _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email] Gyan Mishra Network Solutions Architect Email gyan.s.mishra@verizon.com M 301 502-1347 --_000_PH0PR13MB479582418405803B955A66359A219PH0PR13MB4795namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

        Hi Gyan,

         

        Thank you for your comments! Please see inline for r= esponse marked with [HS]

         

        Best,

        Haoyu

         

        From: Gyan Mishra <hayabusagsm@gmail.com&g= t;
        Sent: Wednesday, January 26, 2022 9:03 PM
        To: Tianran Zhou <zhoutianran=3D40huawei.com@dmarc.ietf.org> Cc: Greg Mirsky <gregimirsky@gmail.com>; Haoyu Song <haoyu.= song@futurewei.com>; IETF IPPM WG <ippm@ietf.org>; spring@ietf.org=
        Subject: Re: [ippm] [spring] Active OAM in SRv6

         

        Hi Haoyu 

         

        I think it would be good to identify the problem sta= tement and gap with existing IPPM WG STAMP, TWAMP PM technologies and why t= hey cannot be utilized or fall short in what you are trying to achieve= with Active OAM in SRv6. 

         

        [HS] My understanding is that STAMP/TWAMP are for en= d-to-end measurements, here we want to collect data from every node and eve= ry link on any path, without needing to set up any sessions. So the scope a= nd coverage are different.  

         

        In-situ IOAM data packets is already possible with S= Rv6 as mentioned as this draft mentions below as normative reference.<= /o:p>

         

        https://datatr= acker.ietf.org/doc/html/draft-ietf-ippm-ioam-data-16

         

        [HS] There’s no accepted solution on how to su= pport IOAM in SRv6 yet. Our proposal aims to provide such a solution, and (= 1) the solution avoids the issues on encapsulating the IOAM trace in EHs an= d (2) it’s extensible to include OAM methods beyond IOAM.

         

        This draft as well mentioned as normative reference = draft below provides OAM ping and traceroute with SRH O flag to SRv6 PGM en= dpoints and SID list tracing capabilities very handy for troubleshooting.

         

         

        [HS] This is for in-band OAM for SRv6 user traffic a= nd it only works for triggering postcard exports (i.e., don’t allow t= he packet to carry data). Our proposal support all the IOAM options and mor= e important, it’s an active method which means one can generate and inject probing packets to cover arbitrary paths= by crafting an SRH.

         

        This draft as well also mentioned as normative refer= ence draft below provides in-situ IOAM for OAM and PM information can be pi= ggybacked in data packets in SRH TLV SRv6 PGM SIF function SRv6.TLV recordi= ng the operational and telemetry info in the data packets.

        [HS] This draft proposes to encapsulate IOAM in SRH = TLV. Due to the overhead concern (IOAM trace could be large) and other issu= es related to EH, I don’t support such a solution.

         

        [HS] The three drafts you mentioned are all be refer= ence in our draft and discussed. We think our use cases are different and o= ur approach is more general and extensible to our use cases.

         

        Thanks 

         

        Gyan 

         

        On Wed, Jan 26, 2022 at 10:19 PM Tianran Zhou <zh= outianran=3D40huawei.com@dmarc.ietf.org> wrote:

        Hi Haoyu,

         

        The application is really interestin= g and useful.

        I am not sure if it is necessary to = create a new OAM protocol at transport layer.

        IMHO, a per hop/per segment extensio= n based on STAMP could be more practical.

        https://www.ietf.org/archive/id/draft-wang-ippm-stamp-hbh-extensions= -03.txt

         

        Best,

        Tianran  

         

        From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Greg Mirsky
        Sent: Thursday, January 27, 2022 7:01 AM
        To: Haoyu Song <haoyu.song@futurewei.com>
        Cc: spring@ietf= .org; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [ippm] [spring] Active OAM in SRv6

         

        Hi Haoyu,

        thank you for bringing the topic of Active OAM to the discussion. = As the concept of Active IOAM is introduced in the IPPM WG draft it seems to me like adding the IPPM WG community to = the discussion is the right thing to do. 

        Please find my notes in-lined below under the GIM>> tag.

         

        Regards,

        Greg

         

        On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song <haoyu.song@futurewei.com>= wrote:

        Hi SPRING WG,

         

        Real time monitor on every node and every link on a network is nec= essary to detect  gray failures, which are the key culprit for poor Qo= S but hard to catch. SR provides an ideal mechanism, when working with some efficient planning algorithm, to achieve= that with low cost.   Our proposal SRv6 In-situ Active Measureme= nt (SIAM) suggests a simple  active measurement approach which can sup= port different

        GIM>> I wonder what gaps you find in the existing active mea= surement protocols, e.g., STAMP and RFC 6734 (would be more convenient to u= se an acronym). It appears to me that, for example, STAMP and its extensions, including the SRPM draft, comprehensively address the PM OAM requirements for SRv6.&n= bsp;

        options of IOAM and other OAM methods in SRv6, without needing to = worry about the extension header issue.  

        GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows:<= o:p>

           In terms of the classification given

           in [RFC7799] IOAM could be portrayed as Hybrid Type 1= .

        Does your proposal change that?

         

        Your comments, questions, and suggestions are very welcome. I̵= 7;d like to know your opinion if you think this work is in scope and should= be adopted by the working group.  If you are interested in contributing to this work, please also let me know. https://datatracker.ietf.org/doc/draft-song-spring-siam/

         

        Thank you very much!

         

        Best regards,

        Haoyu

        _______________________________________________
        spring mailing list
        spring@ietf.org https://www.ietf.org/mailman/listinfo/spring=

        _______________________________________________
        ippm mailing list
        ippm@ietf.org
        https://www.ietf.org/mailman/listinfo/ippm

        --

        <= span style=3D"color:#222222">

        Gyan Mishra=

        Network Solutions Architect&nb= sp;

        Email gyan.s.mishr= a@verizon.com

        M 301 = 502-1347

         

        --_000_PH0PR13MB479582418405803B955A66359A219PH0PR13MB4795namp_-- From nobody Thu Jan 27 10:50:33 2022 Return-Path: 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 B9E743A0CC1; Thu, 27 Jan 2022 10:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93-qNN7R8Nqs; Thu, 27 Jan 2022 10:50:20 -0800 (PST) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2091.outbound.protection.outlook.com [40.107.92.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 872FD3A0CBC; Thu, 27 Jan 2022 10:50:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GKepWI+i/i9bYNqRH3mHbl4HRQwI6y0rSMP0E1GVeZFeDDOEfmDAMErEx66UFSSUWaMnHu9WoDHL+0ozEnJQ0tKcVeRd8bHEzmjfJOGZL8rKsDl9o10gNM8x4sUPVRtTwiDGpT4bkw6v8gXr9oo0pb7pPtMs0Mb/SWyVft71sE5suHqegzTuYqyYiS25QMrj6axy6aGWIzna7mnVBFYISI0Pl3Sd48EnA6mBTimD24IwTdZZvSKxPa1AxlKws1Zox6Gt3Jexuzjzdzn09E1niO0Cpg8CCDeHBct5pBwDAhn3fLLW/gWU535jJ3Ywnknx/JHJw7teUbSAVSpuwLcAyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=DpdQKduVRMEpISJGAZ/uDt9LsYiH/TssOc+DR8d3Jws=; b=gCgpJLF52e4Ve/qiYGr3lls79LZJ4XooioOh/MmTAuZ/V/Ig3/81PpnscJl65TzD9uf7YLxo1WNxsQUomEgVcMY1M88DWqcinQrMKDrDEABLAVO8PVVshNB4X9NPw9z08/POWJxCEfPTOvt/ReUcuWKyHI1Y8UFKqsSzbV+Rl2SX6jHjDRYm0jyRWYbPVW5SksXMut50bgIXcdBr6VL/MvaOVMwSTOKtjFYDMmNo1cmEVSBQQiBy/s+0G0sl7MAFQxsHxHjiE3uj5bRK9ZmjS9e6vvqqOgyzsONN0Q91cm3aVehfWk7IFWgnEolA4qdHLuWpcC4UBnNaZi2q2QqXqw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DpdQKduVRMEpISJGAZ/uDt9LsYiH/TssOc+DR8d3Jws=; b=LN6TlPUjLmmd3MSFlHq7m8qQ4g7UhgTI9CqKNAKdBqMMslOGa/ofnTsiQ+Rn8i7mrURwu6Tel1aMntHGxZCbtdt2n3De28C+zClZa+JXyUrKnkFI+SsGRcVf+oFiZpL14RvFLr53DGhhIoiZS/txdf6Bt/lOhb2+l7QfAX63MnQ= Received: from PH0PR13MB4795.namprd13.prod.outlook.com (2603:10b6:510:92::15) by DM6PR13MB3483.namprd13.prod.outlook.com (2603:10b6:5:14a::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.5; Thu, 27 Jan 2022 18:50:11 +0000 Received: from PH0PR13MB4795.namprd13.prod.outlook.com ([fe80::e59d:61b0:e122:be76]) by PH0PR13MB4795.namprd13.prod.outlook.com ([fe80::e59d:61b0:e122:be76%4]) with mapi id 15.20.4951.005; Thu, 27 Jan 2022 18:50:11 +0000 From: Haoyu Song To: Tianran Zhou , Greg Mirsky CC: "spring@ietf.org" , IETF IPPM WG Thread-Topic: [ippm] [spring] Active OAM in SRv6 Thread-Index: AdgTBAVv6vallEwgQVCAy2m6n5m7fAABJueAAAkAnYAAIFPokA== Date: Thu, 27 Jan 2022 18:50:11 +0000 Message-ID: References: <97ee51feb17c4bcc84bc575768c06c3e@huawei.com> In-Reply-To: <97ee51feb17c4bcc84bc575768c06c3e@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bce4a446-8497-40da-cfd7-08d9e1c5d8fb x-ms-traffictypediagnostic: DM6PR13MB3483:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: d9HXmKWb6So/whC3heOmuX/ikfX+niESno/OHOs9a1a++e1rdFfS0VtBX+vxxym1UOzJOF7/pxlkZE1QpUaDb109GSgrRp6EgF6yf4zgkKwmvek5jlJ31MzrHxvjykKHGpYPYhxIkXZfiICwuXs7s11V6XBoQ8WXaz9PKCdSE6cbKPzAxoIYCiWrUo8AIZiMJ8MIYt48RRrcOANNjVEayH/VSO71WcMm1Arb/A/1AmA3Sjm9eK9YIaazrkQssyZxgokggSdoquvVEfWVlQjM2NYAgvE7JkA54PSVSXYhIVQOmO5wyPzHDbLjPVRhg/H8I58TLtk7EeioMYSHxpLrQUGjDIEowae/546GxFWqm0ll7jg+q+8sqV/Jduq05BBILrCWp4/FiEqLo3WCjJybvI8ZaWDl2wCKXEqYHogfsJHD5nB93TbqJ7FQEq60hr5PLoEgbFc7TkI0T+UX+gk86vYc2HhLGpLxL3QUK8altaU5Q2omANwzmce9sGnDFOtlJ1Ts/jpoce3537dT7BofNwUKp8+TEd4+9HlOYuCRNWyGqkDc1OhMab2mg7NWtwKz8iS0yaryJtZ9Tfc0okcdp59YMjmQLUkKHRCOII4+2kD7jDm/EIEHzsTqEDx+qJDNA/ZL4B5uYfL/Ts7oIdn4OFNHyVjN16adz0u5AQ0CS2e7fWJrP3vr26+H/t3LtBLZa3MBykb7ytZa1qVNUtICu3xqrJjng4pv9+Pn/HKpZkfi9Rq2u2g+W8yfsYVOUbxgp/r/bS3N4bJip603/8awGfwauAHJTf2biGJzBYkpzFEnA0qEbAcri9EGG1vV8hP6GbQJ3a4diUDBZOUH3BfqJg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR13MB4795.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(9686003)(2906002)(5660300002)(966005)(44832011)(52536014)(508600001)(53546011)(7696005)(6506007)(55016003)(71200400001)(86362001)(9326002)(66476007)(4326008)(166002)(66556008)(64756008)(33656002)(8936002)(38100700002)(54906003)(186003)(26005)(316002)(83380400001)(110136005)(76116006)(122000001)(38070700005)(66946007)(66446008)(8676002)(20210929001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?NKSSFETjavHMR4ZVFefg23ROHHBZkRE4N4nRZO0tVbUvVfhR1W0Fc3prDVOk?= =?us-ascii?Q?sWu9BryZbv/LP/oo8t8Bt+nknehBfCVgOFGWnJQnuhStaelgE+oZ1RFzPV8y?= =?us-ascii?Q?BGngsf46uA1+cMrPpYtIuzX8BrJ4MWfxYi+OgJRni4p2nt7WWhafCEckfZYs?= =?us-ascii?Q?o9gPqk1bxc7qockWDQ58+fx8D5zVSMmvjN10+Aj7h0OALkQck0IqKunGhEI5?= =?us-ascii?Q?Qj5IsyCk8ouxp8uRbevQzlAVZmuh21MIdKwsdj5wcmoJ+g3AJ+3/vuKfe2cw?= =?us-ascii?Q?yS/jYodlxrHjvymF6uwVMALTQ6Y32HbkOykIuUI7WLIYr3clQhDf/opC0Uux?= =?us-ascii?Q?D/9YTFodwcGKaXPjcaz1U+hBpm1bOOKCvyoNVV5ab04AJySpC6zCDN8ENbbT?= =?us-ascii?Q?t8czL8LAWy088iSmCx+GFY7oaS+3/1WlTcO1+rsYVd0xf2Lxyi2e8vmazZyP?= =?us-ascii?Q?kwbCyJX/zuxVwzQnpFhEdwnEAZ6+jjHX7APUj/n3ZWnf62z/9zaqcKCrkIBY?= =?us-ascii?Q?YPUc8Ftos8GV1eIzfScuJRPM5k+juk5asEFpbRMuQovFE2o5jfIxcTnyrld9?= =?us-ascii?Q?p1OviH2nVQdd/2Y0Hf52TIqPlF8udmxtg6USotby2OILMo+VF6HNz2Hl87WP?= =?us-ascii?Q?YOPZgVd37q9WqxTysGBlFRu6AsPutDkrDW9gv27TihmlGJ0Jl8EQRXv1mspw?= =?us-ascii?Q?vaTkPVozdROeRFLrwRexbYnJcFjrZQxgDsrhc8AqeQVnNEWanfLIV5l2CToW?= =?us-ascii?Q?Vk1O3YYfk1XQ9I5d7+U95dlLdJJt/IcYQWuwmmnrvtWFxdlb3m8h453gmi5B?= =?us-ascii?Q?nTiXXFGkrH4DmbmUwFR4l0cenFLZFQKG2f/Qdz7XnSW+yKxLT0T/01i0902h?= =?us-ascii?Q?Tx/wYbn+/MUiD5QnXO+dTUgnN1GQaGpbtGXmq5hC5DDcU2Sreesoo3k+AAyu?= =?us-ascii?Q?PWqdYJJI3YBMWJf5gUk++klXVmPaoTM2uOhO6IU6OSDhNik9O0caJbp8/O7x?= =?us-ascii?Q?TessmGROUuaZ8JInhMpiSRuP/KKFcapYhpwWprinB8YwfE0zUT3Jmoh154TR?= =?us-ascii?Q?hIILt2X7cJbb+wgOtrgqpPRCb4zrNroRQsI1eSfs7VWh6vuMV+pSDJW12/yu?= =?us-ascii?Q?+BCuM3HUJrSILMeN8M8h/X07FIYtdMVHBwSoz4xe7r9szx56ksbDc4I5hgLY?= =?us-ascii?Q?BnKIi9b5dsvF8AABurCiXxpHIPIPZFJCpI/JNA1+dsrLEUBMhfgFSMVqruHr?= =?us-ascii?Q?d+EsX3yISErMeJaCNyYKECDVF2LBhAdb5jHsUdmVpJ24w98A09Aq3Bt3TUtQ?= =?us-ascii?Q?RbKQbSDXvCBpj9YtCBDTtGcfm2RdW4B0SiNstmTd6iVfRghlArf6rtf9MPx1?= =?us-ascii?Q?o3Em/m531F35SLQThA7vw4cDAw+9b0tEFbc5P2nDIPrhJYea8VVu6iFc1/4K?= =?us-ascii?Q?UjZtU+/gikS36WelnaJKwNDWnVXZI6VjXrvl597aqO7kXRs4NJlzQya+62Q6?= =?us-ascii?Q?76BVh17fvIvywUZU7g9BXD3i5Y2J+1HhO6/WE7BhX0Y8oM/4DDkU02rv+3Fg?= =?us-ascii?Q?HSKwu1cYr+1Fx1oWKl9ECIlSOiQeFAUkr3nycUhi0LDTcold0Y8Tm0DTv7rH?= =?us-ascii?Q?Rg=3D=3D?= Content-Type: multipart/alternative; boundary="_000_PH0PR13MB4795FC71FE9560BCB10F3CAD9A219PH0PR13MB4795namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR13MB4795.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: bce4a446-8497-40da-cfd7-08d9e1c5d8fb X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2022 18:50:11.3262 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: oJFjgkCnAco08zkyH/jDQ0s+Mt6i7R3R9fTjfDO9BW8F5bbshDJEAj/0uQg/m3rhNy7yot0Jm29Lqjy1WsuCqw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR13MB3483 Archived-At: Subject: Re: [ippm] [spring] Active OAM in SRv6 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2022 18:50:26 -0000 --_000_PH0PR13MB4795FC71FE9560BCB10F3CAD9A219PH0PR13MB4795namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tianran, We didn't invent any new protocol but to simply use UDP for the probing pac= kets in SRv6. What we want to avoid is SRH TLV in EH which can significantly increase the= EH overhead because the data needed to be carried may be too large. Also, since IOAM options have been well defined, it's unnecessary to augmen= t the other existing protocols to provide similar functionality. We just ne= ed a way to encapsulate them. Best, Haoyu From: Tianran Zhou Sent: Wednesday, January 26, 2022 7:19 PM To: Greg Mirsky ; Haoyu Song Cc: spring@ietf.org; IETF IPPM WG Subject: RE: [ippm] [spring] Active OAM in SRv6 Hi Haoyu, The application is really interesting and useful. I am not sure if it is necessary to create a new OAM protocol at transport = layer. IMHO, a per hop/per segment extension based on STAMP could be more practica= l. https://www.ietf.org/archive/id/draft-wang-ippm-stamp-hbh-extensions-03.txt= Best, Tianran From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Greg Mirsky Sent: Thursday, January 27, 2022 7:01 AM To: Haoyu Song > Cc: spring@ietf.org; IETF IPPM WG > Subject: Re: [ippm] [spring] Active OAM in SRv6 Hi Haoyu, thank you for bringing the topic of Active OAM to the discussion. As the co= ncept of Active IOAM is introduced in the IPPM WG draft it seems to me like adding= the IPPM WG community to the discussion is the right thing to do. Please find my notes in-lined below under the GIM>> tag. Regards, Greg On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song > wrote: Hi SPRING WG, Real time monitor on every node and every link on a network is necessary to= detect gray failures, which are the key culprit for poor QoS but hard to = catch. SR provides an ideal mechanism, when working with some efficient pla= nning algorithm, to achieve that with low cost. Our proposal SRv6 In-situ= Active Measurement (SIAM) suggests a simple active measurement approach w= hich can support different GIM>> I wonder what gaps you find in the existing active measurement protoc= ols, e.g., STAMP and RFC 6734 (would be more convenient to use an acronym).= It appears to me that, for example, STAMP and its extensions, including th= e SRPM draft, comprehensively address the PM OAM requirements for SRv6. options of IOAM and other OAM methods in SRv6, without needing to worry abo= ut the extension header issue. GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows: In terms of the classification given in [RFC7799] IOAM could be portrayed as Hybrid Type 1. Does your proposal change that? Your comments, questions, and suggestions are very welcome. I'd like to kno= w your opinion if you think this work is in scope and should be adopted by = the working group. If you are interested in contributing to this work, ple= ase also let me know. https://datatracker.ietf.org/doc/draft-song-spring-si= am/ Thank you very much! Best regards, Haoyu _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_PH0PR13MB4795FC71FE9560BCB10F3CAD9A219PH0PR13MB4795namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

        Hi Tianran,

         

        We didn’t invent any new protocol but to simp= ly use UDP for the probing packets in SRv6.

        What we want to avoid is SRH TLV in EH which can si= gnificantly increase the EH overhead because the data needed to be carried = may be too large.

        Also, since IOAM options have been well defined, it= ’s unnecessary to augment the other existing protocols to provide sim= ilar functionality. We just need a way to encapsulate them.

         

        Best,

        Haoyu

         

        From: Tianran Zhou <zhoutianran@h= uawei.com>
        Sent: Wednesday, January 26, 2022 7:19 PM
        To: Greg Mirsky <gregimirsky@gmail.com>; Haoyu Song <haoyu.= song@futurewei.com>
        Cc: spring@ietf.org; IETF IPPM WG <ippm@ietf.org>
        Subject: RE: [ippm] [spring] Active OAM in SRv6

         

        Hi Haoyu,

         

        The application is really interesting= and useful.

        I am not sure if it is necessary to c= reate a new OAM protocol at transport layer.

        IMHO, a per hop/per segment extension= based on STAMP could be more practical.

        https://= www.ietf.org/archive/id/draft-wang-ippm-stamp-hbh-extensions-03.txt

         

        Best,

        Tianran  

         

        From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Greg Mirsky
        Sent: Thursday, January 27, 2022 7:01 AM
        To: Haoyu Song <haoyu= .song@futurewei.com>
        Cc: spring@ietf.org; IETF IPP= M WG <ippm@ietf.org>
        Subject: Re: [ippm] [spring] Active OAM in SRv6

         

        Hi Haoyu,

        thank you for bringing the topic of Active OAM to th= e discussion. As the concept of Active IOAM is introduced in the IPPM WG draft it seems to me like adding the IPPM WG community to = the discussion is the right thing to do. 

        Please find my notes in-lined below under the GIM>= ;> tag.

         

        Regards,

        Greg

         

        On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song <haoyu.song@futurewei.com> wro= te:

        Hi SPRING WG,

         

        Real time monitor on every node and every link on a network is nec= essary to detect  gray failures, which are the key culprit for poor Qo= S but hard to catch. SR provides an ideal mechanism, when working with some efficient planning algorithm, to achieve= that with low cost.   Our proposal SRv6 In-situ Active Measureme= nt (SIAM) suggests a simple  active measurement approach which can sup= port different

        GIM>> I wonder what gaps you find in the exist= ing active measurement protocols, e.g., STAMP and RFC 6734 (would be more c= onvenient to use an acronym). It appears to me that, for example, STAMP and= its extensions, including the SRPM draft, comprehensively address the PM OAM requirements for SRv6.&n= bsp;

        options of IOAM and other OAM methods in SRv6, without needing to = worry about the extension header issue.  

        GIM>> draft-ietf-ippm-ioam-data classifies IOA= M as follows:

           In terms of the classification given

           in [RFC7799] IOAM could be portrayed as= Hybrid Type 1.

        Does your proposal change that?

         

        Your comments, questions, and suggestions are very welcome. I̵= 7;d like to know your opinion if you think this work is in scope and should= be adopted by the working group.  If you are interested in contributing to this work, please also let me know. https://datatracker.ietf.org/doc/draft-song-spring-siam/

         

        Thank you very much!

         

        Best regards,

        Haoyu

        _______________________________________________
        spring mailing list
        spring@ietf.org https://www.ietf.org/mailman/listinfo/spring

        --_000_PH0PR13MB4795FC71FE9560BCB10F3CAD9A219PH0PR13MB4795namp_-- From nobody Thu Jan 27 11:00:37 2022 Return-Path: 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 BD23C3A0D2D; Thu, 27 Jan 2022 11:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRmDxrmlnont; Thu, 27 Jan 2022 11:00:26 -0800 (PST) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2104.outbound.protection.outlook.com [40.107.243.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2557D3A0D27; Thu, 27 Jan 2022 11:00:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YdmdDqAaEuGjPh6yZZgk2fB/gIGu4qHbCjaVmGUHcJnM53QxK/btewJ/Qkj3OnEfEoWuSotYVcCsMbRdu9ImeufKyWM0BKgGzeqFn+DRzuiZ3xK438JMjbEnPNCSLuTTQF0/yQ52rPTbDXS4XAu0yiAIYW/2JgIORIPVfPMNy12D0d4TikdHpb/wjRduOgN0WmwcXNXCmrGXOgPPHckXtqA1B6OKyyeJupEqzwpMnAin6I1JaoFGBb4p8Sg3F5rOtdyAaYoB2wpnBq7oT4fPYc8k9UPN37CjAhxPcX3SNyxi3tL6Ip7xG8QBnnDcWGsPUtoIIniHAfBZIO0A7Xw6Ng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XflCxJXXIDbhZxNQoT6ldwjQjSHrF0XmXDQpurzvUI0=; b=U1fgLcc0CABudqMAVHd6pJUt5+UaJLLN761crTKbi2otnHzoo66zo398kHJV8LURLjFQgEzC9xoZQzJ7wG1KWGBvmXgYG8coaUsx5F/KkYITpD8hAf2Bjcl+Ei2H+7j4QsTPRURB7/qNNh7RV7pmkuCLpCAGZZvrIxGaUfcnrCNOYjZxKtShsfIiqL25rXT01Jg+MR2EArcnDw0q62Zr80mZw4FyOXZ3Cf3wxeOmok78o/+8wvvV7DQKfSzaOtLvZvdM/1hZehsA1bk3C7HJ/LspbtIO7oP/P12SFo8DX9vLkZVzFg9RkND6XfGWCPP0fQCqc9etHXaJKp3uHT7Ewg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XflCxJXXIDbhZxNQoT6ldwjQjSHrF0XmXDQpurzvUI0=; b=QWKXRAN34EwdeA846+n3jVJ2KbPoKCeQFbu7PedrIKCuvtsu/1dEoHvFkTRygPebdYhqXFbZmhUnGniSNcyI/9LobNSE/nbulmF1mpo+9QGOpzxo1qL3r1zaKCvQuuDAkwMT1vDcYcdJJJO6CZlxACJdc9StHUz0ICSFNT3UsP4= Received: from PH0PR13MB4795.namprd13.prod.outlook.com (2603:10b6:510:92::15) by SA1PR13MB5054.namprd13.prod.outlook.com (2603:10b6:806:184::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4930.8; Thu, 27 Jan 2022 19:00:21 +0000 Received: from PH0PR13MB4795.namprd13.prod.outlook.com ([fe80::e59d:61b0:e122:be76]) by PH0PR13MB4795.namprd13.prod.outlook.com ([fe80::e59d:61b0:e122:be76%4]) with mapi id 15.20.4951.005; Thu, 27 Jan 2022 19:00:21 +0000 From: Haoyu Song To: Greg Mirsky CC: "spring@ietf.org" , IETF IPPM WG Thread-Topic: [spring] Active OAM in SRv6 Thread-Index: AdgTBAVv6vallEwgQVCAy2m6n5m7fAABJueAACmK42A= Date: Thu, 27 Jan 2022 19:00:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 52e4d5a7-32c3-4f0e-363b-08d9e1c744a7 x-ms-traffictypediagnostic: SA1PR13MB5054:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QeUiwygRxTQakYZffli72r9EAMeaq2cWpEuhtT3qKQRdMF78Kv89pT9HWaJvEDoUG98AK2fHiiuXWrBGFAtmHEqNwNrT77GbdAmgY0jT+zggD71yDu4VP8+VfotU6sjTqZ8Y2RMopl0jn0lfCib62bOI+m4QRRjjvaKLqVGg3WBWyrdqrCv2uF7pWr07GmscNx7btr847yKCxcuCyu6Ihm7icV/3t4SMKRj8XX8KQrEjTDJ7Scyy4611uBwNbsp+LQFziBDbYhDoPjgg5LN5dnobOT2KZgM4XcmUk77atE8+qW00W+7wh9g9cDSAixxZ1DYnw1fqJjh1XZTVBQe8gOQG05bPwAMgX73V+tlTdV/SXxAdwVrixn+AVk/TBhzPObZk2SX9Hj0Y+KHjFBrRLmY6C38+mDLM/KgIsPdSahB6W+fCfJnawq//unSdJCcz/v4TDBXsNhUuJxIWh43hxgZBUG3kKTGmsHt2gdKkj9zQMGW/FxUNE8XkSoCntWs96XEpVkbv+ZJFvr3kVt0DmHNbmeA2F4SxzX6GwQqAHRQIBiKNVyfM28jNu7U2Q/ZftO5lDA/rx1SZUTYWqLJYvfpR611LNfZqZoz5tuY6AE25xyQRqn/3oFs76LfESKgt4UUTbquvLSK2aZBZIDLaJoYAFwxhg31hkKmwYB+wV/wClLEDzDN/a5gggMqzJirxo8ea7Yf45i2COgHW2T3LuTUVJggAlWqsYcAI+Jr3q8lK/5Gf+Twr1LqNcQe+UEcyoJG5Iey+jf5tZIU0DrnPmbHtb9v6KURAuL+UHLB4aKCy3IyIzV0pgeHjZz6HajWPUzoUNDaua58C316z6X0KsbdmIDb83fQQbJySCtMV9TkVFJcrGcQ5jBXz/8GjDK5O x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR13MB4795.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(38100700002)(83380400001)(2906002)(6506007)(7696005)(52536014)(33656002)(5660300002)(9326002)(86362001)(508600001)(38070700005)(122000001)(166002)(66556008)(53546011)(66946007)(76116006)(9686003)(54906003)(6916009)(4326008)(44832011)(186003)(966005)(26005)(8936002)(71200400001)(8676002)(55016003)(64756008)(66476007)(66446008)(316002)(20210929001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?2UtilSUpmKwWXmBynvnB4bzK0wq0jm5ptRQwIVZpnC+Nod4EbepK6Tm335q8?= =?us-ascii?Q?4HEYPCGKKUtsbIk5XDS8MoEFkqExYU8MYkmU1OucfFNO1kfxtXV2raIjln7c?= =?us-ascii?Q?83mNFk2dm3GjMmuxZuvoMsIOiClLfA71qTWeaSTGjsL+d8FcA+lojvoIBYHV?= =?us-ascii?Q?sHoLSqR3EXwigiTE060dEPUmAF6gTLcR1nN5OanGHesorJQ0otW+XzjWbOax?= =?us-ascii?Q?ODRXJzvuJ8eFX/pZJfYgY9hhlCPNP7qUhdLP3iuOCpCfINXnBzCAlmzdFzkO?= =?us-ascii?Q?wS3Cj/oKcwkKHW/GA1ID34xNuiIsO6AOYZt5LKk52R8k4abzuCdDtNC+elE9?= =?us-ascii?Q?iRbtkngGRjM5TAXKNP8viQUa7hmHp7+nVLs5QNiA759AqgI1RqLwNYA7unGs?= =?us-ascii?Q?diLsc3XzD72UP9sK2/EekYNXPOOArpZhp7XaggJzrIBbjb7+E9dpdH/2jakp?= =?us-ascii?Q?bCTsF2tK8q1OA5orRTWSeKKPmO5wG52nWDTarAOyYCKWloNcCTlWP7h/5V7Q?= =?us-ascii?Q?J60dvVJHlPZrbEDeCgfZFcnuD6xOxn9jlcj6wjT+yD4faKDcodF0lol5EwIl?= =?us-ascii?Q?n6xs+vDr0QjpHM2ypLXLJfHpuyDCS35moDR0B3ln940d2SHHY8iaNkzFM0kN?= =?us-ascii?Q?o/brLB6KVlB2Q03joQldCW/YnnGMSnfGEwbYRvCvppvLHZ5yQF2DHOG+qR+W?= =?us-ascii?Q?E+oQm4Run7PRoLjCTMC5kiD9qie+FMVAF7AXu8+T6ljYHFUR3hrIFbj2rFbv?= =?us-ascii?Q?7uADaj9eFZjEPITrv1h2qabzoGnoyjJOUG/NtPx2Z1biHIN+0tUiVIWSesoI?= =?us-ascii?Q?0lC371nA8zmJJcjXRNWIkd3Hw3UZxKd2mzg7EbFHRcnPs5S6xesa2gtJlcAl?= =?us-ascii?Q?cbRT9i2BSsso3qWuI4tvvwzki43dV9XWMUuQozfgNJ2LW4F8/f2vy4mZHk7r?= =?us-ascii?Q?BqK/PUZh7etSNHawoygaLtER/SNNUrAmSY7+kNIgs3nPqkw5AhQqNAXE8O2N?= =?us-ascii?Q?gTQ9YlH3lSEC+LyOU1vepN46+0gh9No7ioDIMnxGNXxeYKtyM07r1s2DVLQp?= =?us-ascii?Q?c1agRfXPlsJacWSpfQvIjkUFNo/Cxd91mPKeoxm6SaKsOvu3HL2Uz3JMtFTh?= =?us-ascii?Q?H5kOGJnGR5mbKPgAYzLtKLnf/0syBWJUEhaKtMHjz9Xd/pl19Jv9jR6oa+mQ?= =?us-ascii?Q?DMQeRZ/1yTZ/ayVv+4EQLH+9tSNJCBe0lV8oQSc5sJyo4c613anooMN4BrCF?= =?us-ascii?Q?dvcrE3Ir1f61nhFh8lTI9lmsb8KFkur4XEKbZYgJWi2y+A4uXOOn/k5TeDEY?= =?us-ascii?Q?gSRA/zR8sOcECekhoGx4ZJ3xG4fDA/NUTKjOJHtJHkW9myWTjYuX3xu86fDw?= =?us-ascii?Q?w0QZKTU5dZ6NWsBprHqiVS319tqqmUOElsQoXUiTAH5mywZ3mi0we+6k8rca?= =?us-ascii?Q?bssH/WygdlB5wI3KCqynrmjRainzGgqxPzA8v1i/RFovQ94L4cNivQiBUHuO?= =?us-ascii?Q?O9s27I5rms5fAi0d+jKBQOQlI8DJ9OCpWOQlC+ipk6BhuxxGz22r9QcdOV3C?= =?us-ascii?Q?HcacE1Xzy7ftptYqfXWUGGnlLerIBLUq5D0CIa0iE1qI9WTWWBc/L94YzpAl?= =?us-ascii?Q?zw=3D=3D?= Content-Type: multipart/alternative; boundary="_000_PH0PR13MB479524F559A9E68B541F3C499A219PH0PR13MB4795namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR13MB4795.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 52e4d5a7-32c3-4f0e-363b-08d9e1c744a7 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2022 19:00:21.4624 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qasPS05xU6j64U70gyfY99lY7L7pt2CaXvLx79/pBPqHuAYqnmQSTk7L5AvDIQluHe6CEcQVU5NX10RB/5UPnw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR13MB5054 Archived-At: Subject: Re: [ippm] [spring] Active OAM in SRv6 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2022 19:00:31 -0000 --_000_PH0PR13MB479524F559A9E68B541F3C499A219PH0PR13MB4795namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, Thank you for your questions. Please see inline response. Best, Haoyu From: Greg Mirsky Sent: Wednesday, January 26, 2022 3:01 PM To: Haoyu Song Cc: spring@ietf.org; IETF IPPM WG Subject: Re: [spring] Active OAM in SRv6 Hi Haoyu, thank you for bringing the topic of Active OAM to the discussion. As the co= ncept of Active IOAM is introduced in the IPPM WG draft it seems to me like adding t= he IPPM WG community to the discussion is the right thing to do. Please find my notes in-lined below under the GIM>> tag. Regards, Greg On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song > wrote: Hi SPRING WG, Real time monitor on every node and every link on a network is necessary to= detect gray failures, which are the key culprit for poor QoS but hard to = catch. SR provides an ideal mechanism, when working with some efficient pla= nning algorithm, to achieve that with low cost. Our proposal SRv6 In-situ= Active Measurement (SIAM) suggests a simple active measurement approach w= hich can support different GIM>> I wonder what gaps you find in the existing active measurement protoc= ols, e.g., STAMP and RFC 6734 (would be more convenient to use an acronym).= It appears to me that, for example, STAMP and its extensions, including th= e SRPM draft, comprehensively address the PM OAM requirements for SRv6. HS>> Let's give a few features of our proposal: (1) it's session-less and w= e don't need assign any roles (e.g., reflector); (2) no needs for a return= path. The measurement can start and end at any node (solely determined by = the SRH); (3) udp-based which can support any existing IOAM modes and poten= tially other OAM methods. options of IOAM and other OAM methods in SRv6, without needing to worry abo= ut the extension header issue. GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows: In terms of the classification given in [RFC7799] IOAM could be portrayed as Hybrid Type 1. Does your proposal change that? HS>> In this particular case, IOAM is used for active measurement because i= t's not included in a user packet. Your comments, questions, and suggestions are very welcome. I'd like to kno= w your opinion if you think this work is in scope and should be adopted by = the working group. If you are interested in contributing to this work, ple= ase also let me know. https://datatracker.ietf.org/doc/draft-song-spring-si= am/ Thank you very much! Best regards, Haoyu _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_PH0PR13MB479524F559A9E68B541F3C499A219PH0PR13MB4795namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

        Hi Greg,

         

        Thank you for your questions. Please see inline resp= onse.

         

        Best,

        Haoyu

         

        From: Greg Mirsky <gregimirsky@gmail.com&g= t;
        Sent: Wednesday, January 26, 2022 3:01 PM
        To: Haoyu Song <haoyu.song@futurewei.com>
        Cc: spring@ietf.org; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [spring] Active OAM in SRv6

         

        Hi Haoyu,

        thank you for bringing the topic of Active OAM to th= e discussion. As the concept of Active IOAM is introduced in the IPPM WG draft it seems to me like adding the IPPM WG community to = the discussion is the right thing to do. 

        Please find my notes in-lined below under the GIM>= ;> tag.

         

        Regards,

        Greg

         

        On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song <haoyu.song@futurewei.com> wro= te:

        Hi SPRING WG,

         

        Real time monitor on every node and every link on a network is nec= essary to detect  gray failures, which are the key culprit for poor Qo= S but hard to catch. SR provides an ideal mechanism, when working with some efficient planning algorithm, to achieve= that with low cost.   Our proposal SRv6 In-situ Active Measureme= nt (SIAM) suggests a simple  active measurement approach which can sup= port different

        GIM>> I wonder what gaps you find in the exist= ing active measurement protocols, e.g., STAMP and RFC 6734 (would be more c= onvenient to use an acronym). It appears to me that, for example, STAMP and= its extensions, including the SRPM draft, comprehensively address the PM OAM requirements for SRv6.&n= bsp;

         

        HS>> Let’s give a few features of our pr= oposal: (1) it’s session-less and we don’t need assign any role= s (e.g.,  reflector); (2) no needs for a return path. The measurement = can start and end at any node (solely determined by the SRH); (3) udp-based which can support any existing IOAM modes and potentially other = OAM methods.

        options of IOAM and other OAM methods in SRv6, without needing to = worry about the extension header issue.  

        GIM>> draft-ietf-ippm-ioam-data classifies IOA= M as follows:

           In terms of the classification given

           in [RFC7799] IOAM could be portrayed as= Hybrid Type 1.

        Does your proposal change that?

         

        HS>> In this particular case, IOAM is used for= active measurement because it’s not included in a user packet.

         

        Your comments, questions, and suggestions are very welcome. I̵= 7;d like to know your opinion if you think this work is in scope and should= be adopted by the working group.  If you are interested in contributing to this work, please also let me know. https://datatracker.ietf.org/doc/draft-song-spring-siam/

         

        Thank you very much!

         

        Best regards,

        Haoyu

        _______________________________________________
        spring mailing list
        spring@ietf.org https://www.ietf.org/mailman/listinfo/spring

        --_000_PH0PR13MB479524F559A9E68B541F3C499A219PH0PR13MB4795namp_-- From nobody Thu Jan 27 14:01:18 2022 Return-Path: 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 0618E3A137C; Thu, 27 Jan 2022 14:01:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.997 X-Spam-Level: X-Spam-Status: No, score=-6.997 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KN2cYNu-wPBG; Thu, 27 Jan 2022 14:01:04 -0800 (PST) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23A233A1333; Thu, 27 Jan 2022 14:01:04 -0800 (PST) Received: by mail-ej1-x630.google.com with SMTP id h7so9286714ejf.1; Thu, 27 Jan 2022 14:01:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PjGeXzWOXDCPZeECCJgCIz7jHS/O2+iW8ncNdvofxjs=; b=DAuIJYVB+qQw0RCIUNU5F+KAHU4HlE830ZQwWmW5Stmpd7L0yMgSnpeClXzmBVk2Eo 1jKL+RzFMGbiSIZYN8tAmyl2M5TkO4x//e80X674F7ZLfgAmaOmzgpLo5KJJzbImH1Ef Q1wMQ2E8PTzK/s95H0+VrXrxNax7KT5Qsh1/Wy+MnegnjjfTqmgxpkxlPfX3Cxs93Xvi A3Ya3snugw2NkK+8JmoDnGUGmYtCCW0ZUXYMtWiZ4VUU46K/VIzZstS1hyheJiguxbTB JN4VZQzY459pntsDsIEvMizGZTjpXTSKpM0GJEOQuwGTTdawzTy+m9Ath96RwxjLSQF9 5TNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PjGeXzWOXDCPZeECCJgCIz7jHS/O2+iW8ncNdvofxjs=; b=hbtYjRPtEIEjgJERdYKSkOsJD0BMj/30RbOvHpOumuTpIV2lzHkYy73R3cAURMHWuH Rl1w0FsShxvJgueNr7PxcJN+8uIoSAsfo4jy0s3EVXeG7iFBOpwFALJhjfeyKzufsIkO URrcTuvu6xDXLEfN0GQQ7+diy6nNdxmh52R6+0ol5svg5Adz57ARwPbXFPhmUe45OKX0 PRtKv29TtfnUvgvToAuUbXKrs/QiEGzz4mQnANAW5RcpH/SlV3TZSPRF/ITugcOr1ZJi Ed4sCt8P6dm4TSyxgVLydF1meBvtzfkUsPWkq1Ynm7Y8C36LD2h0HbI335f+XVUKTzkx N5og== X-Gm-Message-State: AOAM532pcEpPLvU90hfCoIjfOlV7wXM02T9bThObZ5vTlLAyJWwp74qG fHI57KJRaS1N43dycStNBEnuYyj+U6OZL9sYppwpy4gxU1RLuA== X-Google-Smtp-Source: ABdhPJyYeok+xbKDvc32tyzQomsvyWIruM2NS2rQd+YtXu4O8eFa+1xqYIA/qMZuO0O3f4FE9leYWWNb/0YrqIR1wEI= X-Received: by 2002:a17:907:a428:: with SMTP id sg40mr4537753ejc.235.1643320861242; Thu, 27 Jan 2022 14:01:01 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Thu, 27 Jan 2022 14:00:49 -0800 Message-ID: To: Haoyu Song Cc: "spring@ietf.org" , IETF IPPM WG Content-Type: multipart/alternative; boundary="0000000000002fbb8a05d697748a" Archived-At: Subject: Re: [ippm] [spring] Active OAM in SRv6 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2022 22:01:15 -0000 --0000000000002fbb8a05d697748a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Haoyu, thank you for your detailed reply. Please find my follow-up notes in-lined below under the GIM2>> tag. Regards, Greg On Thu, Jan 27, 2022 at 11:00 AM Haoyu Song wrote: > Hi Greg, > > > > Thank you for your questions. Please see inline response. > > > > Best, > > Haoyu > > > > *From:* Greg Mirsky > *Sent:* Wednesday, January 26, 2022 3:01 PM > *To:* Haoyu Song > *Cc:* spring@ietf.org; IETF IPPM WG > *Subject:* Re: [spring] Active OAM in SRv6 > > > > Hi Haoyu, > > thank you for bringing the topic of Active OAM to the discussion. As the > concept of Active IOAM is introduced in the IPPM WG draft > it > seems to me like adding the IPPM WG community to the discussion is the > right thing to do. > > Please find my notes in-lined below under the GIM>> tag. > > > > Regards, > > Greg > > > > On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song > wrote: > > Hi SPRING WG, > > > > Real time monitor on every node and every link on a network is necessary > to detect gray failures, which are the key culprit for poor QoS but hard > to catch. SR provides an ideal mechanism, when working with some efficien= t > planning algorithm, to achieve that with low cost. Our proposal SRv6 > In-situ Active Measurement (SIAM) suggests a simple active measurement > approach which can support different > > GIM>> I wonder what gaps you find in the existing active measurement > protocols, e.g., STAMP and RFC 6734 (would be more convenient to use an > acronym). It appears to me that, for example, STAMP and its extensions, > including the SRPM draft > , > comprehensively address the PM OAM requirements for SRv6. > > > > HS>> Let=E2=80=99s give a few features of our proposal: (1) it=E2=80=99s = session-less and > we don=E2=80=99t need assign any roles (e.g., reflector); (2) no needs f= or a > return path. The measurement can start and end at any node (solely > determined by the SRH); (3) udp-based which can support any existing IOAM > modes and potentially other OAM methods. > GIM2>> I don't think adding a protocol that can generate a test probe from an arbitrary node to arbitrary targets (SRv6 supports multicast) is as simple as you present. If an operator needs to monitor the performance of the SR policy used by data packets, IOAM can be applied to data packets. If the operator wants to explore a policy that is not used for data traffic, I imagine IOAM can be added to a test packet of the existing OAM protocol, e.g., ICMP. Am I missing some of the requirements? > options of IOAM and other OAM methods in SRv6, without needing to worry > about the extension header issue. > > GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows: > > In terms of the classification given > > in [RFC7799] IOAM could be portrayed as Hybrid Type 1. > > Does your proposal change that? > > > > HS>> In this particular case, IOAM is used for active measurement because > it=E2=80=99s not included in a user packet. > > > > Your comments, questions, and suggestions are very welcome. I=E2=80=99d l= ike to > know your opinion if you think this work is in scope and should be adopte= d > by the working group. If you are interested in contributing to this work= , > please also let me know. > https://datatracker.ietf.org/doc/draft-song-spring-siam/ > > > > > Thank you very much! > > > > Best regards, > > Haoyu > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > --0000000000002fbb8a05d697748a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
        Hi Haoyu,
        thank you = for your detailed reply. Please find my follow-up notes in-lined below unde= r the GIM2>> tag.

        Regards,
        Greg

        On Thu, Jan 27, 2022 at 11:00 AM Haoyu Song <haoyu.song@futurewei.com> wrote:

        Hi Greg,

        =C2=A0

        Thank you for your questions. Please see inline resp= onse.

        =C2=A0

        Best,

        Haoyu

        =C2=A0

        From: Greg Mirsky <gregimirsky@gmail.com>
        Sent: Wednesday, January 26, 2022 3:01 PM
        To: Haoyu Song <haoyu.song@futurewei.com>
        Cc: spring@ietf= .org; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [spring] Active OAM in SRv6

        =C2=A0

        Hi Haoyu,

        thank you for bringing the topic of Active OAM to th= e discussion. As the concept of Active IOAM is introduced in the IPPM WG draft=C2=A0it seems to me like adding the IPPM WG community to = the discussion is the right thing to do.=C2=A0

        Please find my notes in-lined below under the GIM>= ;> tag.

        =C2=A0

        Regards,

        Greg

        =C2=A0

        On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song <haoyu.song@futurew= ei.com> wrote:

        Hi SPRING WG,

        =C2=A0

        Real time monitor on every node and every link on a = network is necessary to detect =C2=A0gray failures, which are the key culpr= it for poor QoS but hard to catch. SR provides an ideal mechanism, when working with some efficient planning algorithm, to achieve= that with low cost. =C2=A0=C2=A0Our proposal SRv6 In-situ Active Measureme= nt (SIAM) suggests a simple =C2=A0active measurement approach which can sup= port different

        GIM>> I wonder what gaps you find in the exist= ing active measurement protocols, e.g., STAMP and RFC 6734 (would be more c= onvenient to use an acronym). It appears to me that, for example, STAMP and= its extensions, including the SRPM draft, comprehensively address the PM OAM requirements for SRv6.= =C2=A0

        =C2=A0

        HS>> Let=E2=80=99s give a few features of our = proposal: (1) it=E2=80=99s session-less and we don=E2=80=99t need assign an= y roles (e.g., =C2=A0reflector); (2) no needs for a return path. The measur= ement can start and end at any node (solely determined by the SRH); (3) udp-based which can support any existing IOAM modes and potentially other = OAM methods.

        GIM2&= gt;> I don't think adding a protocol that can generate a test probe = from an arbitrary node to arbitrary targets (SRv6 supports multicast) is as= simple as you present. If an operator needs to monitor the performance of = the SR policy used by data packets, IOAM can be applied to data packets. If= the operator wants to explore a policy that is not used for data traffic, = I imagine IOAM can be added to a test packet of the existing OAM protocol, = e.g., ICMP. Am I missing some of the requirements?

        options of IOAM and other OAM methods in SRv6, witho= ut needing to worry about the extension header issue. =C2=A0<= /p>

        GIM>> draft-ietf-ippm-ioam-data classifies IOA= M as follows:

        =C2=A0 =C2=A0In terms of the classification given=

        =C2=A0 =C2=A0in [RFC7799] IOAM could be portrayed as= Hybrid Type 1.

        Does your proposal change=C2=A0that?

        =C2=A0

        HS>> In this particular case, IOAM is used for= active measurement because it=E2=80=99s not included in a user packet.

        =C2=A0

        Your comments, questions, and suggestions are very w= elcome. I=E2=80=99d like to know your opinion if you think this work is in = scope and should be adopted by the working group.=C2=A0 If you are interested in contributing to this work, please also let me know. https://datatracker.ietf.org/doc/draft-song-spring-siam/<= /p>

        =C2=A0

        Thank you very much!

        =C2=A0

        Best regards,

        Haoyu

        _______________________________________________
        spring mailing list
        spring@ietf.org https://www.ietf.org/mailman/listinfo/spring

        --0000000000002fbb8a05d697748a-- From nobody Thu Jan 27 15:53:46 2022 Return-Path: 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 52E1D3A0D76; Thu, 27 Jan 2022 15:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3g2M94sUgLsR; Thu, 27 Jan 2022 15:53:34 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE8AF3A0D73; Thu, 27 Jan 2022 15:53:33 -0800 (PST) Received: from fraeml743-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JlHTX6x9nz67qQW; Fri, 28 Jan 2022 07:53:04 +0800 (CST) Received: from kwepeml100006.china.huawei.com (7.221.188.192) by fraeml743-chm.china.huawei.com (10.206.15.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Fri, 28 Jan 2022 00:53:29 +0100 Received: from kwepeml500004.china.huawei.com (7.221.188.141) by kwepeml100006.china.huawei.com (7.221.188.192) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Fri, 28 Jan 2022 07:53:27 +0800 Received: from kwepeml500004.china.huawei.com ([7.221.188.141]) by kwepeml500004.china.huawei.com ([7.221.188.141]) with mapi id 15.01.2308.021; Fri, 28 Jan 2022 07:53:27 +0800 From: Tianran Zhou To: Greg Mirsky , Haoyu Song CC: "spring@ietf.org" , IETF IPPM WG Thread-Topic: [ippm] [spring] Active OAM in SRv6 Thread-Index: AQHYE7A06f/gyTGOgUm2wvpgg3yLEax25TKAgACg4RA= Date: Thu, 27 Jan 2022 23:53:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.112.40.195] Content-Type: multipart/alternative; boundary="_000_e4fabc5658e344479d3da296f1bf9ab4huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] [spring] Active OAM in SRv6 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2022 23:53:39 -0000 --_000_e4fabc5658e344479d3da296f1bf9ab4huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSGFveXUsDQoNCkkgYWdyZWUgd2l0aCBHcmVnLiBJIHRoaW5rIElPQU0gd2l0aCBleGlzdGlu ZyBPQU0gcHJvdG9jb2wgY2FuIGFkZHJlc3MgeW91ciBjYXNlLg0KQWdhaW4sIEkgY2FuIHNob3cg eW91IHNvbWUgbW9yZSBkZXRhaWxzIG9uIHlvdXIgbW90aXZhdGlvbi4NCigxKSBpdOKAmXMgc2Vz c2lvbi1sZXNzIGFuZCB3ZSBkb27igJl0IG5lZWQgYXNzaWduIGFueSByb2xlcyAoZS5nLiwgIHJl ZmxlY3Rvcik7DQpaVFI+IEkgYW0gbm90IHN1cmUgaWYgSSB1bmRlcnN0YW5kIHdoYXQgdGhlIOKA nHNlc3Npb24tbGVzc+KAnSBtZWFuLg0KQnV0IEkgdGhpbmsgaW4geW91ciBhcHBsaWNhdGlvbiwg dGhlIHNlbmRlciBzaG91bGQga2VlcCB0aGUgc2Vzc2lvbiBzdGF0ZSwgcmlnaHQ/DQpSZWZsZWN0 b3IgaXMgbm90IGFsd2F5cyByZXF1aXJlZC4gT1dBTVAgaXMgb25lIHdheSwgc28gbm8gcmVmbGVj dG9yLiBTVEFNUCwgSU1ITywgY291bGQgYWxzbyBiZSBvbmUgd2F5Lg0KSW4gUkZDODc2MiwgU1RB TVAg4oCcZW5hYmxlcyB0aGUgbWVhc3VyZW1lbnQgb2YgYm90aCBvbmUtd2F5IGFuZCByb3VuZC10 cmlwIHBlcmZvcm1hbmNlIG1ldHJpY3PigJ0uDQoNCigyKSBubyBuZWVkcyBmb3IgYSByZXR1cm4g cGF0aC4gVGhlIG1lYXN1cmVtZW50IGNhbiBzdGFydCBhbmQgZW5kIGF0IGFueSBub2RlIChzb2xl bHkgZGV0ZXJtaW5lZCBieSB0aGUgU1JIKTsNClpUUj4gVGhpcyBpcyBhY2hpZXZlZCBieSBTUkgs IHlvdSBkaWQgbm90IGNyZWF0ZSBhbnl0aGluZyBvbiBPQU0gYWZ0ZXIgVURQLiBTbyB0aGlzIGFw cGxpZXMgZm9yIGFueSBvbmUgd2F5IE9BTSBwcm90b2NvbC4NCk9uIHRoZSBvdGhlciBoYW5kLCBt YW55IG1lYXN1cmVtZW50IG5lZWQgdHdvIHdheXMgKGUuZy4sIGRlbGF5KS4gRXZlbiBkYXRhIGNv bGxlY3Rpb25zIG5lZWQgdHdvIHdheXMsIGJlY2F1c2UgdGhlIGZvcndhcmQgYW5kIGJhY2t3YXJk IGFyZSB0b3RhbGx5IGRpZmZlcmVudCB0d28gcGF0aHMuDQpPZiBjYXVzZSwgeW91IGNhbiB1c2Ug b25lIHdheSBwcm90b2NvbCB0byB0cmF2ZWwgYm90aCB3YXkuDQpUd28gd2F5IG5lZWQgYSByZWZs ZWN0b3IsIGJ1dCB3aWxsIGFsc28gcmVkdWNlIGEgbG90IG9mIHJlc291cmNlcy4gRm9yIGV4YW1w bGUgdGhlIGxlbmd0aCBvZiB0aGUgU0lEIGxpc3QuDQoNCigzKSB1ZHAtYmFzZWQgd2hpY2ggY2Fu IHN1cHBvcnQgYW55IGV4aXN0aW5nIElPQU0gbW9kZXMgYW5kIHBvdGVudGlhbGx5IG90aGVyIE9B TSBtZXRob2RzLg0KWlRSPiBTVEFNUCBpcyBVRFAgYmFzZWQuDQoNCkZyb206IGlwcG0gW21haWx0 bzppcHBtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBHcmVnIE1pcnNreQ0KU2VudDog RnJpZGF5LCBKYW51YXJ5IDI4LCAyMDIyIDY6MDEgQU0NClRvOiBIYW95dSBTb25nIDxoYW95dS5z b25nQGZ1dHVyZXdlaS5jb20+DQpDYzogc3ByaW5nQGlldGYub3JnOyBJRVRGIElQUE0gV0cgPGlw cG1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2lwcG1dIFtzcHJpbmddIEFjdGl2ZSBPQU0gaW4g U1J2Ng0KDQpIaSBIYW95dSwNCnRoYW5rIHlvdSBmb3IgeW91ciBkZXRhaWxlZCByZXBseS4gUGxl YXNlIGZpbmQgbXkgZm9sbG93LXVwIG5vdGVzIGluLWxpbmVkIGJlbG93IHVuZGVyIHRoZSBHSU0y Pj4gdGFnLg0KDQpSZWdhcmRzLA0KR3JlZw0KDQpPbiBUaHUsIEphbiAyNywgMjAyMiBhdCAxMTow MCBBTSBIYW95dSBTb25nIDxoYW95dS5zb25nQGZ1dHVyZXdlaS5jb208bWFpbHRvOmhhb3l1LnNv bmdAZnV0dXJld2VpLmNvbT4+IHdyb3RlOg0KSGkgR3JlZywNCg0KVGhhbmsgeW91IGZvciB5b3Vy IHF1ZXN0aW9ucy4gUGxlYXNlIHNlZSBpbmxpbmUgcmVzcG9uc2UuDQoNCkJlc3QsDQpIYW95dQ0K DQpGcm9tOiBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPG1haWx0bzpncmVnaW1p cnNreUBnbWFpbC5jb20+Pg0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDI2LCAyMDIyIDM6MDEg UE0NClRvOiBIYW95dSBTb25nIDxoYW95dS5zb25nQGZ1dHVyZXdlaS5jb208bWFpbHRvOmhhb3l1 LnNvbmdAZnV0dXJld2VpLmNvbT4+DQpDYzogc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdA aWV0Zi5vcmc+OyBJRVRGIElQUE0gV0cgPGlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5v cmc+Pg0KU3ViamVjdDogUmU6IFtzcHJpbmddIEFjdGl2ZSBPQU0gaW4gU1J2Ng0KDQpIaSBIYW95 dSwNCnRoYW5rIHlvdSBmb3IgYnJpbmdpbmcgdGhlIHRvcGljIG9mIEFjdGl2ZSBPQU0gdG8gdGhl IGRpc2N1c3Npb24uIEFzIHRoZSBjb25jZXB0IG9mIEFjdGl2ZSBJT0FNIGlzIGludHJvZHVjZWQg aW4gdGhlIElQUE0gV0cgZHJhZnQ8aHR0cHM6Ly9uYW0xMS5zYWZlbGlua3MucHJvdGVjdGlvbi5v dXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2Ml MkZodG1sJTJGZHJhZnQtaWV0Zi1pcHBtLWlvYW0tZmxhZ3MmZGF0YT0wNCU3QzAxJTdDaGFveXUu c29uZyU0MGZ1dHVyZXdlaS5jb20lN0NjMzQ3YTI5NjU3NmE0YmNjMDJkYzA4ZDllMTFmY2JhMyU3 QzBmZWU4ZmYyYTNiMjQwMTg5Yzc1M2ExZDU1OTFmZWRjJTdDMSU3QzElN0M2Mzc3ODgzNDg5NjA2 NjM0MzMlN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpv aVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCZzZGF0YT1JQ0R4 NHBkbWdYSkJzNjhTQVRjdmtUcFpTT1RaNkxEN0p5Q0NLWU02SUpnJTNEJnJlc2VydmVkPTA+IGl0 IHNlZW1zIHRvIG1lIGxpa2UgYWRkaW5nIHRoZSBJUFBNIFdHIGNvbW11bml0eSB0byB0aGUgZGlz Y3Vzc2lvbiBpcyB0aGUgcmlnaHQgdGhpbmcgdG8gZG8uDQpQbGVhc2UgZmluZCBteSBub3RlcyBp bi1saW5lZCBiZWxvdyB1bmRlciB0aGUgR0lNPj4gdGFnLg0KDQpSZWdhcmRzLA0KR3JlZw0KDQpP biBXZWQsIEphbiAyNiwgMjAyMiBhdCAyOjM3IFBNIEhhb3l1IFNvbmcgPGhhb3l1LnNvbmdAZnV0 dXJld2VpLmNvbTxtYWlsdG86aGFveXUuc29uZ0BmdXR1cmV3ZWkuY29tPj4gd3JvdGU6DQpIaSBT UFJJTkcgV0csDQoNClJlYWwgdGltZSBtb25pdG9yIG9uIGV2ZXJ5IG5vZGUgYW5kIGV2ZXJ5IGxp bmsgb24gYSBuZXR3b3JrIGlzIG5lY2Vzc2FyeSB0byBkZXRlY3QgIGdyYXkgZmFpbHVyZXMsIHdo aWNoIGFyZSB0aGUga2V5IGN1bHByaXQgZm9yIHBvb3IgUW9TIGJ1dCBoYXJkIHRvIGNhdGNoLiBT UiBwcm92aWRlcyBhbiBpZGVhbCBtZWNoYW5pc20sIHdoZW4gd29ya2luZyB3aXRoIHNvbWUgZWZm aWNpZW50IHBsYW5uaW5nIGFsZ29yaXRobSwgdG8gYWNoaWV2ZSB0aGF0IHdpdGggbG93IGNvc3Qu ICAgT3VyIHByb3Bvc2FsIFNSdjYgSW4tc2l0dSBBY3RpdmUgTWVhc3VyZW1lbnQgKFNJQU0pIHN1 Z2dlc3RzIGEgc2ltcGxlICBhY3RpdmUgbWVhc3VyZW1lbnQgYXBwcm9hY2ggd2hpY2ggY2FuIHN1 cHBvcnQgZGlmZmVyZW50DQpHSU0+PiBJIHdvbmRlciB3aGF0IGdhcHMgeW91IGZpbmQgaW4gdGhl IGV4aXN0aW5nIGFjdGl2ZSBtZWFzdXJlbWVudCBwcm90b2NvbHMsIGUuZy4sIFNUQU1QIGFuZCBS RkMgNjczNCAod291bGQgYmUgbW9yZSBjb252ZW5pZW50IHRvIHVzZSBhbiBhY3JvbnltKS4gSXQg YXBwZWFycyB0byBtZSB0aGF0LCBmb3IgZXhhbXBsZSwgU1RBTVAgYW5kIGl0cyBleHRlbnNpb25z LCBpbmNsdWRpbmcgdGhlIFNSUE0gZHJhZnQ8aHR0cHM6Ly9uYW0xMS5zYWZlbGlua3MucHJvdGVj dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmcl MkZkb2MlMkZodG1sJTJGZHJhZnQtaWV0Zi1pcHBtLXN0YW1wLXNycG0mZGF0YT0wNCU3QzAxJTdD aGFveXUuc29uZyU0MGZ1dHVyZXdlaS5jb20lN0NjMzQ3YTI5NjU3NmE0YmNjMDJkYzA4ZDllMTFm Y2JhMyU3QzBmZWU4ZmYyYTNiMjQwMTg5Yzc1M2ExZDU1OTFmZWRjJTdDMSU3QzElN0M2Mzc3ODgz NDg5NjA2NjM0MzMlN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlM Q0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCZzZGF0 YT1DenhnOGRZR2ZEWFZpeVJ0WTJaMnZ1SUtpdCUyQjlQdzBhdHpMb25PVlRkZkUlM0QmcmVzZXJ2 ZWQ9MD4sIGNvbXByZWhlbnNpdmVseSBhZGRyZXNzIHRoZSBQTSBPQU0gcmVxdWlyZW1lbnRzIGZv ciBTUnY2Lg0KDQpIUz4+IExldOKAmXMgZ2l2ZSBhIGZldyBmZWF0dXJlcyBvZiBvdXIgcHJvcG9z YWw6ICgxKSBpdOKAmXMgc2Vzc2lvbi1sZXNzIGFuZCB3ZSBkb27igJl0IG5lZWQgYXNzaWduIGFu eSByb2xlcyAoZS5nLiwgIHJlZmxlY3Rvcik7ICgyKSBubyBuZWVkcyBmb3IgYSByZXR1cm4gcGF0 aC4gVGhlIG1lYXN1cmVtZW50IGNhbiBzdGFydCBhbmQgZW5kIGF0IGFueSBub2RlIChzb2xlbHkg ZGV0ZXJtaW5lZCBieSB0aGUgU1JIKTsgKDMpIHVkcC1iYXNlZCB3aGljaCBjYW4gc3VwcG9ydCBh bnkgZXhpc3RpbmcgSU9BTSBtb2RlcyBhbmQgcG90ZW50aWFsbHkgb3RoZXIgT0FNIG1ldGhvZHMu DQpHSU0yPj4gSSBkb24ndCB0aGluayBhZGRpbmcgYSBwcm90b2NvbCB0aGF0IGNhbiBnZW5lcmF0 ZSBhIHRlc3QgcHJvYmUgZnJvbSBhbiBhcmJpdHJhcnkgbm9kZSB0byBhcmJpdHJhcnkgdGFyZ2V0 cyAoU1J2NiBzdXBwb3J0cyBtdWx0aWNhc3QpIGlzIGFzIHNpbXBsZSBhcyB5b3UgcHJlc2VudC4g SWYgYW4gb3BlcmF0b3IgbmVlZHMgdG8gbW9uaXRvciB0aGUgcGVyZm9ybWFuY2Ugb2YgdGhlIFNS IHBvbGljeSB1c2VkIGJ5IGRhdGEgcGFja2V0cywgSU9BTSBjYW4gYmUgYXBwbGllZCB0byBkYXRh IHBhY2tldHMuIElmIHRoZSBvcGVyYXRvciB3YW50cyB0byBleHBsb3JlIGEgcG9saWN5IHRoYXQg aXMgbm90IHVzZWQgZm9yIGRhdGEgdHJhZmZpYywgSSBpbWFnaW5lIElPQU0gY2FuIGJlIGFkZGVk IHRvIGEgdGVzdCBwYWNrZXQgb2YgdGhlIGV4aXN0aW5nIE9BTSBwcm90b2NvbCwgZS5nLiwgSUNN UC4gQW0gSSBtaXNzaW5nIHNvbWUgb2YgdGhlIHJlcXVpcmVtZW50cz8NCm9wdGlvbnMgb2YgSU9B TSBhbmQgb3RoZXIgT0FNIG1ldGhvZHMgaW4gU1J2Niwgd2l0aG91dCBuZWVkaW5nIHRvIHdvcnJ5 IGFib3V0IHRoZSBleHRlbnNpb24gaGVhZGVyIGlzc3VlLg0KR0lNPj4gZHJhZnQtaWV0Zi1pcHBt LWlvYW0tZGF0YSBjbGFzc2lmaWVzIElPQU0gYXMgZm9sbG93czoNCiAgIEluIHRlcm1zIG9mIHRo ZSBjbGFzc2lmaWNhdGlvbiBnaXZlbg0KICAgaW4gW1JGQzc3OTldIElPQU0gY291bGQgYmUgcG9y dHJheWVkIGFzIEh5YnJpZCBUeXBlIDEuDQpEb2VzIHlvdXIgcHJvcG9zYWwgY2hhbmdlIHRoYXQ/ DQoNCkhTPj4gSW4gdGhpcyBwYXJ0aWN1bGFyIGNhc2UsIElPQU0gaXMgdXNlZCBmb3IgYWN0aXZl IG1lYXN1cmVtZW50IGJlY2F1c2UgaXTigJlzIG5vdCBpbmNsdWRlZCBpbiBhIHVzZXIgcGFja2V0 Lg0KDQpZb3VyIGNvbW1lbnRzLCBxdWVzdGlvbnMsIGFuZCBzdWdnZXN0aW9ucyBhcmUgdmVyeSB3 ZWxjb21lLiBJ4oCZZCBsaWtlIHRvIGtub3cgeW91ciBvcGluaW9uIGlmIHlvdSB0aGluayB0aGlz IHdvcmsgaXMgaW4gc2NvcGUgYW5kIHNob3VsZCBiZSBhZG9wdGVkIGJ5IHRoZSB3b3JraW5nIGdy b3VwLiAgSWYgeW91IGFyZSBpbnRlcmVzdGVkIGluIGNvbnRyaWJ1dGluZyB0byB0aGlzIHdvcmss IHBsZWFzZSBhbHNvIGxldCBtZSBrbm93LiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1zb25nLXNwcmluZy1zaWFtLzxodHRwczovL25hbTExLnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUy RmRvYyUyRmRyYWZ0LXNvbmctc3ByaW5nLXNpYW0lMkYmZGF0YT0wNCU3QzAxJTdDaGFveXUuc29u ZyU0MGZ1dHVyZXdlaS5jb20lN0NjMzQ3YTI5NjU3NmE0YmNjMDJkYzA4ZDllMTFmY2JhMyU3QzBm ZWU4ZmYyYTNiMjQwMTg5Yzc1M2ExZDU1OTFmZWRjJTdDMSU3QzElN0M2Mzc3ODgzNDg5NjA2NjM0 MzMlN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYy bHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCZzZGF0YT1FZ292WW8z dEpnbUNVUjhldTBJJTJCa0YlMkZmOWZjZktGR2k2Z2FPeWN5Rk02ZyUzRCZyZXNlcnZlZD0wPg0K DQpUaGFuayB5b3UgdmVyeSBtdWNoIQ0KDQpCZXN0IHJlZ2FyZHMsDQpIYW95dQ0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNwcmluZyBtYWlsaW5nIGxp c3QNCnNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc8aHR0cHM6Ly9uYW0xMS5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJG bWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nJmRhdGE9MDQlN0MwMSU3Q2hhb3l1LnNvbmclNDBm dXR1cmV3ZWkuY29tJTdDYzM0N2EyOTY1NzZhNGJjYzAyZGMwOGQ5ZTExZmNiYTMlN0MwZmVlOGZm MmEzYjI0MDE4OWM3NTNhMWQ1NTkxZmVkYyU3QzElN0MxJTdDNjM3Nzg4MzQ4OTYwNjYzNDMzJTdD VW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJ aUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAmc2RhdGE9eDBST25XdU1BVyUy QkpoaUVST0glMkZnNCUyQnJ1YWhhYk9hSGN0d042ZVZlWDlqdyUzRCZyZXNlcnZlZD0wPg0K --_000_e4fabc5658e344479d3da296f1bf9ab4huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0 IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEhhb3l1LDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB3aXRoIEdyZWcuIEkgdGhpbmsgSU9BTSB3 aXRoIGV4aXN0aW5nIE9BTSBwcm90b2NvbCBjYW4gYWRkcmVzcyB5b3VyIGNhc2UuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkFnYWluLCBJIGNhbiBzaG93IHlvdSBzb21lIG1vcmUgZGV0YWlscyBvbiB5b3Vy IG1vdGl2YXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ KDEpIGl04oCZcyBzZXNzaW9uLWxlc3MgYW5kIHdlIGRvbuKAmXQgbmVlZCBhc3NpZ24gYW55IHJv bGVzIChlLmcuLCAmbmJzcDtyZWZsZWN0b3IpOw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+WlRSJmd0OyBJIGFtIG5v dCBzdXJlIGlmIEkgdW5kZXJzdGFuZCB3aGF0IHRoZSDigJxzZXNzaW9uLWxlc3PigJ0gbWVhbi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+QnV0IEkgdGhpbmsgaW4geW91ciBhcHBsaWNhdGlvbiwgdGhlIHNl bmRlciBzaG91bGQga2VlcCB0aGUgc2Vzc2lvbiBzdGF0ZSwgcmlnaHQ/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPlJlZmxlY3RvciBpcyBub3QgYWx3YXlzIHJlcXVpcmVkLiBPV0FNUCBpcyBvbmUgd2F5LCBz byBubyByZWZsZWN0b3IuIFNUQU1QLCBJTUhPLCBjb3VsZCBhbHNvIGJlIG9uZSB3YXkuDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+SW4gUkZDODc2MiwgU1RBTVAg4oCcZW5hYmxlcyB0aGUgbWVhc3VyZW1l bnQgb2YgYm90aCBvbmUtd2F5IGFuZCByb3VuZC10cmlwIHBlcmZvcm1hbmNlIG1ldHJpY3PigJ0u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPigyKSBubyBuZWVkcyBmb3IgYSByZXR1cm4gcGF0aC4gVGhlIG1lYXN1cmVt ZW50IGNhbiBzdGFydCBhbmQgZW5kIGF0IGFueSBub2RlIChzb2xlbHkgZGV0ZXJtaW5lZCBieSB0 aGUgU1JIKTsNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlpUUiZndDsgVGhpcyBpcyBhY2hpZXZlZCBieSBTUkgsIHlv dSBkaWQgbm90IGNyZWF0ZSBhbnl0aGluZyBvbiBPQU0gYWZ0ZXIgVURQLiBTbyB0aGlzIGFwcGxp ZXMgZm9yIGFueSBvbmUgd2F5IE9BTSBwcm90b2NvbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+T24gdGhl IG90aGVyIGhhbmQsIG1hbnkgbWVhc3VyZW1lbnQgbmVlZCB0d28gd2F5cyAoZS5nLiwgZGVsYXkp LiBFdmVuIGRhdGEgY29sbGVjdGlvbnMgbmVlZCB0d28gd2F5cywgYmVjYXVzZSB0aGUgZm9yd2Fy ZCBhbmQgYmFja3dhcmQgYXJlIHRvdGFsbHkgZGlmZmVyZW50IHR3bw0KIHBhdGhzLiA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+T2YgY2F1c2UsIHlvdSBjYW4gdXNlIG9uZSB3YXkgcHJvdG9jb2wgdG8gdHJh dmVsIGJvdGggd2F5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Ud28gd2F5IG5lZWQgYSByZWZsZWN0b3Is IGJ1dCB3aWxsIGFsc28gcmVkdWNlIGEgbG90IG9mIHJlc291cmNlcy4gRm9yIGV4YW1wbGUgdGhl IGxlbmd0aCBvZiB0aGUgU0lEIGxpc3QuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4o MykgdWRwLWJhc2VkIHdoaWNoIGNhbiBzdXBwb3J0IGFueSBleGlzdGluZyBJT0FNIG1vZGVzIGFu ZCBwb3RlbnRpYWxseSBvdGhlciBPQU0gbWV0aG9kcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5aVFImZ3Q7IFNUQU1Q IGlzIFVEUCBiYXNlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gaXBwbSBbbWFpbHRvOmlwcG0tYm91bmNlc0BpZXRmLm9y Z10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+R3JlZyBNaXJza3k8YnI+DQo8Yj5TZW50OjwvYj4gRnJp ZGF5LCBKYW51YXJ5IDI4LCAyMDIyIDY6MDEgQU08YnI+DQo8Yj5Ubzo8L2I+IEhhb3l1IFNvbmcg Jmx0O2hhb3l1LnNvbmdAZnV0dXJld2VpLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IHNwcmluZ0Bp ZXRmLm9yZzsgSUVURiBJUFBNIFdHICZsdDtpcHBtQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW2lwcG1dIFtzcHJpbmddIEFjdGl2ZSBPQU0gaW4gU1J2NjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgSGFveXUsPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhhbmsgeW91IGZvciB5b3Vy IGRldGFpbGVkIHJlcGx5LiBQbGVhc2UgZmluZCBteSBmb2xsb3ctdXAgbm90ZXMgaW4tbGluZWQg YmVsb3cgdW5kZXIgdGhlIEdJTTImZ3Q7Jmd0OyB0YWcuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HcmVnPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgSmFuIDI3LCAyMDIy IGF0IDExOjAwIEFNIEhhb3l1IFNvbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpoYW95dS5zb25nQGZ1 dHVyZXdlaS5jb20iPmhhb3l1LnNvbmdAZnV0dXJld2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkhpIEdyZWcsDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYW5r IHlvdSBmb3IgeW91ciBxdWVzdGlvbnMuIFBsZWFzZSBzZWUgaW5saW5lIHJlc3BvbnNlLg0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5CZXN0LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5IYW95dTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IEdyZWcgTWlyc2t5ICZsdDs8YSBocmVmPSJt YWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+Z3JlZ2ltaXJza3lA Z21haWwuY29tPC9hPiZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEphbnVhcnkg MjYsIDIwMjIgMzowMSBQTTxicj4NCjxiPlRvOjwvYj4gSGFveXUgU29uZyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmhhb3l1LnNvbmdAZnV0dXJld2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmhhb3l1LnNv bmdAZnV0dXJld2VpLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86 c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPjsgSUVU RiBJUFBNIFdHICZsdDs8YSBocmVmPSJtYWlsdG86aXBwbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPmlwcG1AaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Nwcmlu Z10gQWN0aXZlIE9BTSBpbiBTUnY2PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIEhhb3l1LDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+dGhhbmsgeW91IGZvciBicmluZ2luZyB0aGUgdG9waWMgb2Yg QWN0aXZlIE9BTSB0byB0aGUgZGlzY3Vzc2lvbi4gQXMgdGhlIGNvbmNlcHQgb2YgQWN0aXZlIElP QU0gaXMgaW50cm9kdWNlZCBpbiB0aGUNCjxhIGhyZWY9Imh0dHBzOi8vbmFtMTEuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmll dGYub3JnJTJGZG9jJTJGaHRtbCUyRmRyYWZ0LWlldGYtaXBwbS1pb2FtLWZsYWdzJmFtcDtkYXRh PTA0JTdDMDElN0NoYW95dS5zb25nJTQwZnV0dXJld2VpLmNvbSU3Q2MzNDdhMjk2NTc2YTRiY2Mw MmRjMDhkOWUxMWZjYmEzJTdDMGZlZThmZjJhM2IyNDAxODljNzUzYTFkNTU5MWZlZGMlN0MxJTdD MSU3QzYzNzc4ODM0ODk2MDY2MzQzMyU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1D NHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0Ql N0MzMDAwJmFtcDtzZGF0YT1JQ0R4NHBkbWdYSkJzNjhTQVRjdmtUcFpTT1RaNkxEN0p5Q0NLWU02 SUpnJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+DQpJUFBNIFdHIGRyYWZ0PC9h PiZuYnNwO2l0IHNlZW1zIHRvIG1lIGxpa2UgYWRkaW5nIHRoZSBJUFBNIFdHIGNvbW11bml0eSB0 byB0aGUgZGlzY3Vzc2lvbiBpcyB0aGUgcmlnaHQgdGhpbmcgdG8gZG8uJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlBsZWFzZSBmaW5k IG15IG5vdGVzIGluLWxpbmVkIGJlbG93IHVuZGVyIHRoZSBHSU0mZ3Q7Jmd0OyB0YWcuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZWdh cmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5HcmVnPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5PbiBXZWQsIEphbiAyNiwgMjAyMiBhdCAyOjM3IFBNIEhhb3l1IFNvbmcgJmx0Ozxh IGhyZWY9Im1haWx0bzpoYW95dS5zb25nQGZ1dHVyZXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5o YW95dS5zb25nQGZ1dHVyZXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgU1BSSU5HIFdHLDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+UmVhbCB0aW1lIG1vbml0b3Igb24gZXZlcnkgbm9kZSBhbmQg ZXZlcnkgbGluayBvbiBhIG5ldHdvcmsgaXMgbmVjZXNzYXJ5IHRvIGRldGVjdCAmbmJzcDtncmF5 IGZhaWx1cmVzLCB3aGljaCBhcmUgdGhlIGtleSBjdWxwcml0IGZvciBwb29yIFFvUyBidXQgaGFy ZCB0byBjYXRjaC4gU1IgcHJvdmlkZXMgYW4gaWRlYWwNCiBtZWNoYW5pc20sIHdoZW4gd29ya2lu ZyB3aXRoIHNvbWUgZWZmaWNpZW50IHBsYW5uaW5nIGFsZ29yaXRobSwgdG8gYWNoaWV2ZSB0aGF0 IHdpdGggbG93IGNvc3QuICZuYnNwOyZuYnNwO091ciBwcm9wb3NhbCBTUnY2IEluLXNpdHUgQWN0 aXZlIE1lYXN1cmVtZW50IChTSUFNKSBzdWdnZXN0cyBhIHNpbXBsZSAmbmJzcDthY3RpdmUgbWVh c3VyZW1lbnQgYXBwcm9hY2ggd2hpY2ggY2FuIHN1cHBvcnQgZGlmZmVyZW50PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+R0lNJmd0OyZndDsgSSB3b25kZXIgd2hhdCBnYXBzIHlvdSBmaW5kIGluIHRoZSBl eGlzdGluZyBhY3RpdmUgbWVhc3VyZW1lbnQgcHJvdG9jb2xzLCBlLmcuLCBTVEFNUCBhbmQgUkZD IDY3MzQgKHdvdWxkIGJlIG1vcmUgY29udmVuaWVudCB0byB1c2UgYW4gYWNyb255bSkuIEl0IGFw cGVhcnMgdG8gbWUgdGhhdCwgZm9yDQogZXhhbXBsZSwgU1RBTVAgYW5kIGl0cyBleHRlbnNpb25z LCBpbmNsdWRpbmcgdGhlIDxhIGhyZWY9Imh0dHBzOi8vbmFtMTEuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJG ZG9jJTJGaHRtbCUyRmRyYWZ0LWlldGYtaXBwbS1zdGFtcC1zcnBtJmFtcDtkYXRhPTA0JTdDMDEl N0NoYW95dS5zb25nJTQwZnV0dXJld2VpLmNvbSU3Q2MzNDdhMjk2NTc2YTRiY2MwMmRjMDhkOWUx MWZjYmEzJTdDMGZlZThmZjJhM2IyNDAxODljNzUzYTFkNTU5MWZlZGMlN0MxJTdDMSU3QzYzNzc4 ODM0ODk2MDY2MzQzMyU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURB aUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJmFt cDtzZGF0YT1DenhnOGRZR2ZEWFZpeVJ0WTJaMnZ1SUtpdCUyQjlQdzBhdHpMb25PVlRkZkUlM0Qm YW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj4NClNSUE0gZHJhZnQ8L2E+LCBjb21wcmVo ZW5zaXZlbHkgYWRkcmVzcyB0aGUgUE0gT0FNIHJlcXVpcmVtZW50cyBmb3IgU1J2Ni4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhTJmd0OyZndDsgTGV04oCZcyBnaXZlIGEgZmV3 IGZlYXR1cmVzIG9mIG91ciBwcm9wb3NhbDogKDEpIGl04oCZcyBzZXNzaW9uLWxlc3MgYW5kIHdl IGRvbuKAmXQgbmVlZCBhc3NpZ24gYW55IHJvbGVzIChlLmcuLCAmbmJzcDtyZWZsZWN0b3IpOyAo Mikgbm8gbmVlZHMgZm9yIGEgcmV0dXJuIHBhdGguIFRoZSBtZWFzdXJlbWVudCBjYW4NCiBzdGFy dCBhbmQgZW5kIGF0IGFueSBub2RlIChzb2xlbHkgZGV0ZXJtaW5lZCBieSB0aGUgU1JIKTsgKDMp IHVkcC1iYXNlZCB3aGljaCBjYW4gc3VwcG9ydCBhbnkgZXhpc3RpbmcgSU9BTSBtb2RlcyBhbmQg cG90ZW50aWFsbHkgb3RoZXIgT0FNIG1ldGhvZHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R0lNMiZndDsmZ3Q7IEkgZG9uJ3QgdGhpbmsgYWRkaW5n IGEgcHJvdG9jb2wgdGhhdCBjYW4gZ2VuZXJhdGUgYSB0ZXN0IHByb2JlIGZyb20gYW4gYXJiaXRy YXJ5IG5vZGUgdG8gYXJiaXRyYXJ5IHRhcmdldHMgKFNSdjYgc3VwcG9ydHMgbXVsdGljYXN0KSBp cyBhcyBzaW1wbGUgYXMgeW91IHByZXNlbnQuIElmIGFuIG9wZXJhdG9yIG5lZWRzIHRvIG1vbml0 b3IgdGhlIHBlcmZvcm1hbmNlIG9mIHRoZSBTUiBwb2xpY3kgdXNlZA0KIGJ5IGRhdGEgcGFja2V0 cywgSU9BTSBjYW4gYmUgYXBwbGllZCB0byBkYXRhIHBhY2tldHMuIElmIHRoZSBvcGVyYXRvciB3 YW50cyB0byBleHBsb3JlIGEgcG9saWN5IHRoYXQgaXMgbm90IHVzZWQgZm9yIGRhdGEgdHJhZmZp YywgSSBpbWFnaW5lIElPQU0gY2FuIGJlIGFkZGVkIHRvIGEgdGVzdCBwYWNrZXQgb2YgdGhlIGV4 aXN0aW5nIE9BTSBwcm90b2NvbCwgZS5nLiwgSUNNUC4gQW0gSSBtaXNzaW5nIHNvbWUgb2YgdGhl IHJlcXVpcmVtZW50cz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g MGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+b3B0aW9ucyBvZiBJT0FNIGFuZCBvdGhlciBPQU0gbWV0aG9kcyBpbiBTUnY2LCB3aXRob3V0 IG5lZWRpbmcgdG8gd29ycnkgYWJvdXQgdGhlIGV4dGVuc2lvbiBoZWFkZXIgaXNzdWUuICZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkdJTSZndDsmZ3Q7IGRyYWZ0LWlldGYtaXBwbS1pb2FtLWRh dGEgY2xhc3NpZmllcyBJT0FNIGFzIGZvbGxvd3M6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7SW4gdGVybXMg b2YgdGhlIGNsYXNzaWZpY2F0aW9uIGdpdmVuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDtpbiBbUkZDNzc5OV0gSU9BTSBj b3VsZCBiZSBwb3J0cmF5ZWQgYXMgSHlicmlkIFR5cGUgMS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Eb2VzIHlvdXIgcHJvcG9z YWwgY2hhbmdlJm5ic3A7dGhhdD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhTJmd0OyZn dDsgSW4gdGhpcyBwYXJ0aWN1bGFyIGNhc2UsIElPQU0gaXMgdXNlZCBmb3IgYWN0aXZlIG1lYXN1 cmVtZW50IGJlY2F1c2UgaXTigJlzIG5vdCBpbmNsdWRlZCBpbiBhIHVzZXIgcGFja2V0Lg0KPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Zb3VyIGNvbW1lbnRzLCBx dWVzdGlvbnMsIGFuZCBzdWdnZXN0aW9ucyBhcmUgdmVyeSB3ZWxjb21lLiBJ4oCZZCBsaWtlIHRv IGtub3cgeW91ciBvcGluaW9uIGlmIHlvdSB0aGluayB0aGlzIHdvcmsgaXMgaW4gc2NvcGUgYW5k IHNob3VsZCBiZSBhZG9wdGVkIGJ5IHRoZSB3b3JraW5nIGdyb3VwLiZuYnNwOyBJZiB5b3UNCiBh cmUgaW50ZXJlc3RlZCBpbiBjb250cmlidXRpbmcgdG8gdGhpcyB3b3JrLCBwbGVhc2UgYWxzbyBs ZXQgbWUga25vdy4gPGEgaHJlZj0iaHR0cHM6Ly9uYW0xMS5zYWZlbGlua3MucHJvdGVjdGlvbi5v dXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2Ml MkZkcmFmdC1zb25nLXNwcmluZy1zaWFtJTJGJmFtcDtkYXRhPTA0JTdDMDElN0NoYW95dS5zb25n JTQwZnV0dXJld2VpLmNvbSU3Q2MzNDdhMjk2NTc2YTRiY2MwMmRjMDhkOWUxMWZjYmEzJTdDMGZl ZThmZjJhM2IyNDAxODljNzUzYTFkNTU5MWZlZGMlN0MxJTdDMSU3QzYzNzc4ODM0ODk2MDY2MzQz MyU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJs dU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJmFtcDtzZGF0YT1FZ292 WW8zdEpnbUNVUjhldTBJJTJCa0YlMkZmOWZjZktGR2k2Z2FPeWN5Rk02ZyUzRCZhbXA7cmVzZXJ2 ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtc29uZy1zcHJpbmctc2lhbS88L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5U aGFuayB5b3UgdmVyeSBtdWNoITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QmVzdCByZWdh cmRzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IYW95dTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzcHJpbmcgbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL25hbTExLnNhZmVs aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5v cmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmcmYW1wO2RhdGE9MDQlN0MwMSU3Q2hhb3l1 LnNvbmclNDBmdXR1cmV3ZWkuY29tJTdDYzM0N2EyOTY1NzZhNGJjYzAyZGMwOGQ5ZTExZmNiYTMl N0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNhMWQ1NTkxZmVkYyU3QzElN0MxJTdDNjM3Nzg4MzQ4OTYw NjYzNDMzJTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlq b2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAmYW1wO3NkYXRh PXgwUk9uV3VNQVclMkJKaGlFUk9IJTJGZzQlMkJydWFoYWJPYUhjdHdONmVWZVg5anclM0QmYW1w O3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NwcmluZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_e4fabc5658e344479d3da296f1bf9ab4huaweicom_-- From nobody Thu Jan 27 15:54:20 2022 Return-Path: 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 675013A0E30; Thu, 27 Jan 2022 15:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iSysByTkwPZ; Thu, 27 Jan 2022 15:54:00 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC7CA3A0DF4; Thu, 27 Jan 2022 15:53:59 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 499) id C1465119C6; Thu, 27 Jan 2022 15:53:59 -0800 (PST) To: nmalykh@ieee.org, ruthcivil@gmail.com, acmorton@att.com, reshad@yahoo.com, mjethanandani@gmail.com, kostas.pentikousis@detecon.com From: RFC Errata System Cc: rfc-ed@rfc-editor.org, iesg@ietf.org, ippm@ietf.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20220127235359.C1465119C6@rfc-editor.org> Date: Thu, 27 Jan 2022 15:53:59 -0800 (PST) Archived-At: Subject: [ippm] [Errata Verified] RFC8913 (6751) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2022 23:54:13 -0000 The following errata report has been verified for RFC8913, "Two-Way Active Measurement Protocol (TWAMP) YANG Data Model". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6751 -------------------------------------- Status: Verified Type: Editorial Reported by: Nikolai Malykh Date Reported: 2021-11-23 Verified by: RFC Editor Section: 5.1 Original Text ------------- Please note that the backslash ('\') character near the end of the diagram is used for formatting purposes only (i.e., "reflector-udp-port]" should be treated as part of the same line as "[sender-ip sender-udp-port reflector-ip"). Corrected Text -------------- Please note that the backslash ('\') character near the end of the diagram is used for formatting purposes only (i.e., "reflector-udp-port]" should be treated as part of the same line as "[sender-ip sender-udp-port reflector-ip]"). Notes ----- Omitted character ']' at the end of a sentence. -------------------------------------- RFC8913 (draft-ietf-ippm-twamp-yang-13) -------------------------------------- Title : Two-Way Active Measurement Protocol (TWAMP) YANG Data Model Publication Date : November 2021 Author(s) : R. Civil, A. Morton, R. Rahman, M. Jethanandani, K. Pentikousis, Ed. Category : PROPOSED STANDARD Source : IP Performance Measurement Area : Transport Stream : IETF From nobody Thu Jan 27 16:22:39 2022 Return-Path: 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 BB6A03A0EC2; Thu, 27 Jan 2022 16:22:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.796 X-Spam-Level: X-Spam-Status: No, score=-6.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtDE4v_fVUkB; Thu, 27 Jan 2022 16:22:27 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7F873A0EBF; Thu, 27 Jan 2022 16:22:26 -0800 (PST) Received: from fraeml710-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JlJ6t1SR0z67Yxp; Fri, 28 Jan 2022 08:21:58 +0800 (CST) Received: from kwepeml500003.china.huawei.com (7.221.188.182) by fraeml710-chm.china.huawei.com (10.206.15.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Fri, 28 Jan 2022 01:22:23 +0100 Received: from kwepeml500004.china.huawei.com (7.221.188.141) by kwepeml500003.china.huawei.com (7.221.188.182) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Fri, 28 Jan 2022 08:22:21 +0800 Received: from kwepeml500004.china.huawei.com ([7.221.188.141]) by kwepeml500004.china.huawei.com ([7.221.188.141]) with mapi id 15.01.2308.021; Fri, 28 Jan 2022 08:22:21 +0800 From: Tianran Zhou To: Haoyu Song , Greg Mirsky CC: "spring@ietf.org" , IETF IPPM WG Thread-Topic: [ippm] [spring] Active OAM in SRv6 Thread-Index: AdgTBAVv6vallEwgQVCAy2m6n5m7fP//gxqA//8zIPCAAhkLgP//HqpQ Date: Fri, 28 Jan 2022 00:22:21 +0000 Message-ID: <0d5bbca4caeb4c3e83d7117919aebadc@huawei.com> References: <97ee51feb17c4bcc84bc575768c06c3e@huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.112.40.195] Content-Type: multipart/alternative; boundary="_000_0d5bbca4caeb4c3e83d7117919aebadchuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] [spring] Active OAM in SRv6 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2022 00:22:32 -0000 --_000_0d5bbca4caeb4c3e83d7117919aebadchuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Haoyu, I do not understand why the UDP encapsulation is better than SRH TLV. IMO, IOAM is already too complex, some more work on TLV parsing is not crit= ical. If you care about the data length "because the data needed to be carried ma= y be too large", what's the limit on SRH TLV? What's your use case, and your requirement? Let's evaluate it with numbers. Best, Tianran From: Haoyu Song [mailto:haoyu.song@futurewei.com] Sent: Friday, January 28, 2022 2:50 AM To: Tianran Zhou ; Greg Mirsky Cc: spring@ietf.org; IETF IPPM WG Subject: RE: [ippm] [spring] Active OAM in SRv6 Hi Tianran, We didn't invent any new protocol but to simply use UDP for the probing pac= kets in SRv6. What we want to avoid is SRH TLV in EH which can significantly increase the= EH overhead because the data needed to be carried may be too large. Also, since IOAM options have been well defined, it's unnecessary to augmen= t the other existing protocols to provide similar functionality. We just ne= ed a way to encapsulate them. Best, Haoyu From: Tianran Zhou > Sent: Wednesday, January 26, 2022 7:19 PM To: Greg Mirsky >; Haoy= u Song > Cc: spring@ietf.org; IETF IPPM WG > Subject: RE: [ippm] [spring] Active OAM in SRv6 Hi Haoyu, The application is really interesting and useful. I am not sure if it is necessary to create a new OAM protocol at transport = layer. IMHO, a per hop/per segment extension based on STAMP could be more practica= l. https://www.ietf.org/archive/id/draft-wang-ippm-stamp-hbh-extensions-03.txt= Best, Tianran From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Greg Mirsky Sent: Thursday, January 27, 2022 7:01 AM To: Haoyu Song > Cc: spring@ietf.org; IETF IPPM WG > Subject: Re: [ippm] [spring] Active OAM in SRv6 Hi Haoyu, thank you for bringing the topic of Active OAM to the discussion. As the co= ncept of Active IOAM is introduced in the IPPM WG draft it seems to me like adding= the IPPM WG community to the discussion is the right thing to do. Please find my notes in-lined below under the GIM>> tag. Regards, Greg On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song > wrote: Hi SPRING WG, Real time monitor on every node and every link on a network is necessary to= detect gray failures, which are the key culprit for poor QoS but hard to = catch. SR provides an ideal mechanism, when working with some efficient pla= nning algorithm, to achieve that with low cost. Our proposal SRv6 In-situ= Active Measurement (SIAM) suggests a simple active measurement approach w= hich can support different GIM>> I wonder what gaps you find in the existing active measurement protoc= ols, e.g., STAMP and RFC 6734 (would be more convenient to use an acronym).= It appears to me that, for example, STAMP and its extensions, including th= e SRPM draft, comprehensively address the PM OAM requirements for SRv6. options of IOAM and other OAM methods in SRv6, without needing to worry abo= ut the extension header issue. GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows: In terms of the classification given in [RFC7799] IOAM could be portrayed as Hybrid Type 1. Does your proposal change that? Your comments, questions, and suggestions are very welcome. I'd like to kno= w your opinion if you think this work is in scope and should be adopted by = the working group. If you are interested in contributing to this work, ple= ase also let me know. https://datatracker.ietf.org/doc/draft-song-spring-si= am/ Thank you very much! Best regards, Haoyu _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_0d5bbca4caeb4c3e83d7117919aebadchuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

        Hi Haoyu,

         

        I do not understand why the UDP encap= sulation is better than SRH TLV.

        IMO, IOAM is already too complex, som= e more work on TLV parsing is not critical.

        If you care about the data length = 220;because the data needed to be carried may be too large”, whatR= 17;s the limit on SRH TLV?

        What’s your use case, and your = requirement? Let’s evaluate it with numbers.

         

        Best,

        Tianran

         

        From: Haoyu Song [mailto:haoyu.song@= futurewei.com]
        Sent: Friday, January 28, 2022 2:50 AM
        To: Tianran Zhou <zhoutianran@huawei.com>; Greg Mirsky <gre= gimirsky@gmail.com>
        Cc: spring@ietf.org; IETF IPPM WG <ippm@ietf.org>
        Subject: RE: [ippm] [spring] Active OAM in SRv6

         

        Hi Tianran,

         

        We didn’t invent any new protocol but to simp= ly use UDP for the probing packets in SRv6.

        What we want to avoid is SRH TLV in EH which can si= gnificantly increase the EH overhead because the data needed to be carried = may be too large.

        Also, since IOAM options have been well defined, it= ’s unnecessary to augment the other existing protocols to provide sim= ilar functionality. We just need a way to encapsulate them.

         

        Best,

        Haoyu

         

        From: Tianran Zhou <zhoutianran@huawei.com>
        Sent: Wednesday, January 26, 2022 7:19 PM
        To: Greg Mirsky <gregimi= rsky@gmail.com>; Haoyu Song <haoyu.song@futurewei.com>
        Cc: spring@ietf.org; IETF IPP= M WG <ippm@ietf.org>
        Subject: RE: [ippm] [spring] Active OAM in SRv6

         

        Hi Haoyu,

         

        The application is really interesting= and useful.

        I am not sure if it is necessary to c= reate a new OAM protocol at transport layer.

        IMHO, a per hop/per segment extension= based on STAMP could be more practical.

        https://= www.ietf.org/archive/id/draft-wang-ippm-stamp-hbh-extensions-03.txt

         

        Best,

        Tianran  

         

        From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Greg Mirsky
        Sent: Thursday, January 27, 2022 7:01 AM
        To: Haoyu Song <haoyu= .song@futurewei.com>
        Cc: spring@ietf.org; IETF IPP= M WG <ippm@ietf.org>
        Subject: Re: [ippm] [spring] Active OAM in SRv6

         

        Hi Haoyu,

        thank you for bringing the topic of Active OAM to th= e discussion. As the concept of Active IOAM is introduced in the IPPM WG draft it seems to me like adding the IPPM WG community to = the discussion is the right thing to do. 

        Please find my notes in-lined below under the GIM>= ;> tag.

         

        Regards,

        Greg

         

        On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song <haoyu.song@futurewei.com> wro= te:

        Hi SPRING WG,

         

        Real time monitor on every node and every link on a network is nec= essary to detect  gray failures, which are the key culprit for poor Qo= S but hard to catch. SR provides an ideal mechanism, when working with some efficient planning algorithm, to achieve= that with low cost.   Our proposal SRv6 In-situ Active Measureme= nt (SIAM) suggests a simple  active measurement approach which can sup= port different

        GIM>> I wonder what gaps you find in the exist= ing active measurement protocols, e.g., STAMP and RFC 6734 (would be more c= onvenient to use an acronym). It appears to me that, for example, STAMP and= its extensions, including the SRPM draft, comprehensively address the PM OAM requirements for SRv6.&n= bsp;

        options of IOAM and other OAM methods in SRv6, without needing to = worry about the extension header issue.  

        GIM>> draft-ietf-ippm-ioam-data classifies IOA= M as follows:

           In terms of the classification given

           in [RFC7799] IOAM could be portrayed as= Hybrid Type 1.

        Does your proposal change that?

         

        Your comments, questions, and suggestions are very welcome. I̵= 7;d like to know your opinion if you think this work is in scope and should= be adopted by the working group.  If you are interested in contributing to this work, please also let me know. https://datatracker.ietf.org/doc/draft-song-spring-siam/

         

        Thank you very much!

         

        Best regards,

        Haoyu

        _______________________________________________
        spring mailing list
        spring@ietf.org https://www.ietf.org/mailman/listinfo/spring

        --_000_0d5bbca4caeb4c3e83d7117919aebadchuaweicom_-- From nobody Thu Jan 27 17:14:28 2022 Return-Path: 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 EFD143A121F; Thu, 27 Jan 2022 17:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flRe-IE0ukLZ; Thu, 27 Jan 2022 17:14:21 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC10B3A1216; Thu, 27 Jan 2022 17:14:21 -0800 (PST) Received: from pps.filterd (m0288873.ppops.net [127.0.0.1]) by m0288873.ppops.net-00191d01. (8.16.1.2/8.16.1.2) with SMTP id 20RMpE6Q002776; Thu, 27 Jan 2022 20:14:21 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0288873.ppops.net-00191d01. with ESMTP id 3duwy50umq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Jan 2022 20:14:20 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 20S1EJlk032337; Thu, 27 Jan 2022 20:14:19 -0500 Received: from zlp27127.vci.att.com (zlp27127.vci.att.com [135.66.87.31]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 20S1EEo5032262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 27 Jan 2022 20:14:14 -0500 Received: from zlp27127.vci.att.com (zlp27127.vci.att.com [127.0.0.1]) by zlp27127.vci.att.com (Service) with ESMTP id F037B4009E86; Fri, 28 Jan 2022 01:14:13 +0000 (GMT) Received: from MISOUT7MSGEX2AA.ITServices.sbc.com (unknown [135.66.184.199]) by zlp27127.vci.att.com (Service) with ESMTP id C87BC4009E7D; Fri, 28 Jan 2022 01:14:13 +0000 (GMT) Received: from MISOUT7MSGEX2CD.ITServices.sbc.com (135.66.184.224) by MISOUT7MSGEX2AA.ITServices.sbc.com (135.66.184.199) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.17; Thu, 27 Jan 2022 20:14:13 -0500 Received: from MISOUT7MSGETA02.tmg.ad.att.com (144.160.12.220) by MISOUT7MSGEX2CD.ITServices.sbc.com (135.66.184.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.17 via Frontend Transport; Thu, 27 Jan 2022 20:14:13 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.168) by edgeso2.exch.att.com (144.160.12.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.17; Thu, 27 Jan 2022 20:14:12 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RLV35gzTPatMbq6CEV1ifThDZ5V0to7Jtm++bfKJTal7S8xc5vAQxDFQ3wLWqXaiMGad8cuTKsWHrJcay9jnphHK7p3RJK2dTTIYQJonorybck1OemLKvx865jH1AfEWVmXFYqsQvyqHuy3R+KsKnsEVvy+II4JaxRDm8TopMePa++EfL9u9fYF1FHZQIZewi0rNyBjgBLTETLd2rT3EwZzUIi2TblhDWP29V152DY5aIQY7PnMTScSRJ+fiJ01WPE4Jy75AsWgK7Jp1jpOKg2cc56ABg8nzRv1Eab4Y18vH45LwYvycj6Ua3+5Wfqs+8fATAR03jJDsi3lr/zuP9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=fToltLd9jwNAjKXS9vMoDous1KzBVfD5O9l3YX3XXuU=; b=FFRl+oFsd00Fq/lIMEGG8WK4xDvPFDo0I4c/fnGmZkG+UPfQFW/8nqWCox68YaStbABosrObvBLYfJZyoIyfOMSocCZbMbiawjOu7QqiN9p52FXHlCNOAr8ZB+9Hb3ggO9+ms2q0xzKcLrjRTR6Mrhr1Am5WF4mtPYa6llbtTQeEBc8cU1c9JTS9Dv0ur8zBojX1KP/JwlZCclVuByOnQqVgoY0t7qEvRfY5jPEYDvWL5wtIJ5a3Cmm5Vr1Pb/5KFd8IURpN96nHxEhCXeKH6+NSmjLgxVCo4VW+YXKJ/PGuHHKZ0b5+PXC4frosi3MiDZxaR01c1SwfqVJHx4SUjQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fToltLd9jwNAjKXS9vMoDous1KzBVfD5O9l3YX3XXuU=; b=z+EpMK6QZjffHit9oyaZw9+uMnA1A5zKrtKCIKTQ02v+cj8JYbxrwFHZb+FJHSVJ727ubZSnSXDHwX+LhCVnL3Qj5JO9arW8YC54vKrf6U04QerI7PUlOcByNIlTwSj1khOiwa6Yh8PSrGYHmZGy/zoerY8p45AyUkI4u/NXoLY= Received: from CH0PR02MB7980.namprd02.prod.outlook.com (2603:10b6:610:105::17) by SA1PR02MB8400.namprd02.prod.outlook.com (2603:10b6:806:1f4::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4930.15; Fri, 28 Jan 2022 01:14:11 +0000 Received: from CH0PR02MB7980.namprd02.prod.outlook.com ([fe80::cd34:2582:613:215b]) by CH0PR02MB7980.namprd02.prod.outlook.com ([fe80::cd34:2582:613:215b%4]) with mapi id 15.20.4930.018; Fri, 28 Jan 2022 01:14:10 +0000 From: "MORTON JR., AL" To: "Ruediger.Geib@telekom.de" , "marcus.ihlar=40ericsson.com@dmarc.ietf.org" CC: "ippm@ietf.org" Thread-Topic: draft-morton-ippm-capacity-metric-protocol Thread-Index: AdfquL0WtV/2rjPHSECEUqMgTJWSZwAewXAACivjRQA= Date: Fri, 28 Jan 2022 01:14:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ef15221f-3c69-4d95-bc5d-08d9e1fb7d92 x-ms-traffictypediagnostic: SA1PR02MB8400:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WwR5pHNHL61ecN+q4zJx03of2xVQTnmp6f2Go0jlhbVU1ksZTSm3FCC/sh4PeI5eJMyl0PJsEZRSYCQ0q9/ybij+ac4oPxsJNnAOLDJzJj7spg13OFUwwwoliqNdOjm2NSGf5SSich2cw4+MJJL2YARJ/VjwBgVYBIe69j4QfkzL/P8+8qejbCeoPPH1ozxOhQnxrS5uYKLdYGQSRSqIJjTvxljCPZ+eiw9FNCM0FKcRA+aFsx52rAG5JfOG4FLewPsBiEjamLm3DcC9bL9BSXhHXK07+76X1rFg/LbLcQ+SqWeCkMUQZhlZV/iwEpI7zaCtHc+TD1SZjiGddYMI6dr5roi2k+ZGlqpaxKj9flxVxyHEXRAV6Z87u+oIIxTtfBZ+2hFKAkd+l37xLEe7+tPh9gTrUDsqBAuoPP/mRwMsR1vd5l4f0thC1xyZWOQ8fnOiU+mVeDWs71MQlyPw2OkIb4g/xe+R0GJWzmYSWVPRoWaxcint2u6jy7C9+koXuSDKppwy/lSL9yvANyN0G/Pd4JKhOyimh58nTgFDHg7zOGxtVZj+psRvrQFViBqJPGv0pXAQe7IlG549rnnXblGoSN5r14pn2cVp8WBQ1ZnnUikfOa6AzOi82IkLl2ppybJRbG5XurFRrjGUqEcZNb++3mB+WeICtGwgseJXP4yXgBTIG44k0/zWFNjRM+kQt3ULB5BU5WisdTC00MPZo4johw6RqLLJ2VJr42gkZonEgAdWMeOoXFKi9w3NVncPO2t10Yt6Y+GKRzyUhPCQl6eF5HYqwyMFXvOCNii6ch4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH0PR02MB7980.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(316002)(110136005)(71200400001)(186003)(9686003)(76116006)(66946007)(7696005)(53546011)(6506007)(82202003)(26005)(4326008)(166002)(83380400001)(82960400001)(5660300002)(33656002)(52536014)(38070700005)(30864003)(8936002)(2906002)(966005)(66574015)(508600001)(38100700002)(8676002)(55016003)(66476007)(64756008)(122000001)(66446008)(66556008)(86362001)(579004)(559001)(20210929001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?b4oudmg8zeq4VtZRr3P3bI4F6I7KUKt1yW3TUvagG9d2C8d5hnswswsaXS?= =?iso-8859-1?Q?17XqVJfwKaQSOxGn+UzrERGHtXWMNmnkG1xdCY84muWzbGHKB26d9aFrIC?= =?iso-8859-1?Q?g1S6HXF39guHwgsZ4qNkxjUuEw+b/s0bpw++V6xEl8Y7WycfY62me9TdbB?= =?iso-8859-1?Q?7l2VTeUo3C75CLwO1d1jLUXwS4VSdSdYwm+YzWMlqVcSdavTmlOAbvppx9?= =?iso-8859-1?Q?ViPp75q4NmdudMFWmTfmLwq0IfarwNkmhyVYMBcu3v6nULA4oNHTRi0aJ5?= =?iso-8859-1?Q?gj5nMkLR2y0DWUKbBjeBQ8179PYtvK8IvWPWD4nMWQC6Q5u0fpAvSxz2I9?= =?iso-8859-1?Q?LObG7TQHI7UVdY0Gqsv/eI/tUzhzPDg/HpnYdiYHmuMmpyYFor1HdyHOfW?= =?iso-8859-1?Q?tudVOiJn9H5YbeGGzILY/ef4IKkojmFx2meYPxIZIy2ukklvmXZUuMFC98?= =?iso-8859-1?Q?aVFb3EeDhS4ux6pAMIfV4WOY7ScG7LlAQmt85QAACb7dB7ED8RwZPs5BxI?= =?iso-8859-1?Q?e452QlXL4SlSYN5RuV8bCh0LGQwmFz7fctDc8ynq9EABqENBQ8nB27hTKu?= =?iso-8859-1?Q?qjinEpy6kV4LlGJaLyiL2l553m1elqKcFSqsndtllkLQLtoPoU8hA4izvV?= =?iso-8859-1?Q?326FdWs7dEt8Hvf2uVhgJXmhNJmLEsh1+d9+6hGshiqV1YuG1fTzpqjdGl?= =?iso-8859-1?Q?08briltFyH7B2E5vqqnG6pnPFaLdp6Oje6QIwrUmaFZEGg5HUqZwtt/d0q?= =?iso-8859-1?Q?kdhTw01XW3DuoT3lnJguB9z2/j1/bX3wITtAA3iO20lWmQaKZIWwG+fZk/?= =?iso-8859-1?Q?Gu3m7YlSfF1Wedfp/ymrrOeLPAK6GmwRiOemyE4U/WJ9g+TT7OIXydeIfG?= =?iso-8859-1?Q?P5K2Zh3J+FONnq2yM/NevuyEQ90kUhUdygjWeYhVEfMgglsHkqov0OLdf/?= =?iso-8859-1?Q?CnaY6utCvmx2vbyOMNenaKdDmkNnlWD6fr3pYvloHML9VTsE/X7XMlawnB?= =?iso-8859-1?Q?ORqV6WQqli0rWFH+s6jSi0tlUAOtyEUV1AmnN6Z3mCwvZymbn/N6Ql8VfB?= =?iso-8859-1?Q?3EgNR5TQx0eGjyYky8awxrTG4+82cbD3nkgRT4lLCKcDoV26QxsxoivxR+?= =?iso-8859-1?Q?DhZipjXU1AZIcBhec9CmdNVAg2kO8DTujYWoJNF6XjuYndfQwSvFuUohCf?= =?iso-8859-1?Q?49BFfmYs2D4f+1mWFyir0zsJ4vrDLTUbLIhTnPdKK/XWcwh/wOpPyz/SDl?= =?iso-8859-1?Q?fE802erFf83zlFFat0uGMJFT99g6xj+YFHXh5gMadwYtodfeshCz62+jAd?= =?iso-8859-1?Q?TCAT5ajNYq6xtCQ84+CPxYFei49hmBJATvymWKO3dAJ3U28qmNLvorzw19?= =?iso-8859-1?Q?ZjjTay/6Qr7jzrLTckpM7u7B6YbDQeNE6j2cixFca+PPu53Lu66e0sHNTm?= =?iso-8859-1?Q?siCBVmLoHUJ+Jmg0vic9RAkbZY6Fil8CGXIFtDoVs4RQlSOzwvVbQMXBie?= =?iso-8859-1?Q?68gnPsRORx4HHp6Mkm5FlUHzn+/VBOreauq0Hd79eO5O2XJvoZYu1F8e8I?= =?iso-8859-1?Q?EmkIF5thg2Ixq5+h66jROWujpcj9nBgSI9CQIs2DHLcS4m3G1g=3D=3D?= Content-Type: multipart/alternative; boundary="_000_CH0PR02MB7980214B8DCD7DAB8762D6E4D3229CH0PR02MB7980namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH0PR02MB7980.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ef15221f-3c69-4d95-bc5d-08d9e1fb7d92 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2022 01:14:10.8507 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: l9EcT+raAHRnxM7tW3rn3lGfaKsxsidM3FWLiuH0goKpBwfAHglhSFa7JXUYor8R X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR02MB8400 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: BF9E4E144025A2040211D713664BEA5B613092F6D9136B7BC5FF1A42CBD434E02 X-Proofpoint-GUID: WVdzon2zO6k65nVWraOFkJ04o7RAX0-n X-Proofpoint-ORIG-GUID: WVdzon2zO6k65nVWraOFkJ04o7RAX0-n X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-01-27_06,2022-01-27_01,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 malwarescore=0 adultscore=0 lowpriorityscore=0 priorityscore=1501 mlxlogscore=999 bulkscore=0 impostorscore=0 mlxscore=0 suspectscore=0 clxscore=1011 spamscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2201280003 Archived-At: Subject: Re: [ippm] draft-morton-ippm-capacity-metric-protocol X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2022 01:14:26 -0000 --_000_CH0PR02MB7980214B8DCD7DAB8762D6E4D3229CH0PR02MB7980namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi R=FCdiger, Thanks again for your comments! We discussed some of them at our coding project meeting today. Please see [acm] for replies. All proposals below are implemented in the working text. Al ############ Some comments: Section 3. Protocol Overview The client requires configuration of a test direction parameter (upstream or downstream test) as well as the hostname or IP address of the server in order to begin the setup and configuration exchanges with the server. RG: The draft also mentions a sender and a receiver. Both, client and serve= r may act as sender and receiver. This depends on the test direction, upstream or downstream. Words to that appear in "9. Method of Measurement", at the end of the doc. [acm] OK. Let's try this for the paragraph above: The client requires configuration of a test direction parameter (upstream or downstream test, where the client performs the role of ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ sender or receiver, respectively) as well as the hostname or IP address ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ of the server in order to begin the setup and configuration exchanges with the server. 4. Stopping the Test: The server initiates the phase to stop the test by setting the STOP1 indication in load PDUs or sstatus feedback messages. ( ^^^^) RG: Would it be worth a thought to enable the client to terminate a test? [acm] This sentence in section 3 might benefit from some clarification. I added: 4. Stopping the Test: When the specified test duration has been reached, th= e server ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ initiates the phase to stop the test by setting the STOP1 indication in = load PDUs or status feedback messages. The client acknowledges by setting the= STOP2 in load PDUs or status feedback messages. ... IOW, neither the server nor the client can stop a test prematurely in norma= l operation. Note that the protocol overlays the STOP indication on existing measurement and feedback traffic. It's very simple to implement. Alternatively, a client (or server) can stop sending traffic (load PDUs or status feedback messages, depending on its role). An activity timer will expire at the opposite end, and both client and server will close the connection. The timer value can be set to expire as quickly as needed (some may be sensitive to the amount of load PDUs sent after a test appears to fail). ########## 5. Setup Request and Response Exchange The message format isn't "TLV". Is the protocol extensible (e.g. could secu= rity be adapted to future needs)? [acm] All the message formats/PDUs are extensible. A specific set of formats matc= h a protocol version number (currently 8 in the draft you reviewed). Our goal is to make version 9 and higher backward-compatible. We should be able to add fields to the PDUs and leave earlier parts untouched... ########## 6.2. Test Activation Request - server response .....The remaining 28 octets of the Test Activation Request (normally read RG: A bit worrying, seems to be set by the sender in the reply to a request= only. See editorials... [acm] Here's the full context: If the client has requested an upstream test, the server SHALL include the transmission parameters from the first row of the sending rate table= . The remaining 28 octets of the Test Activation Request (normally read from the first row of the sending rate table) are called the Sending Rate Structure, and SHALL be organized as follows: ... So, the Test Activation Response (the new name for section 6.2) uses the Sending Rate Structure to communicate a starting send rate for the test, IF the client is the sender, as in an upstream test. Perhaps we can clarify: If the client has requested an upstream test, the server SHALL include the transmission parameters from the first row of the sending rate table in the Sending Rate Structure (defined below). ########## 7.1. Test Packet PDU and Roles .... On the other hand, the test configuration MAY use a fixed sending rate requested by the client, RG: contains descriptive text about the method (e.g. decision on the sending rate). The text there certainly is correct. I wonder, whether a reference replacing the text would be sufficient? [acm] Actually, I don't see anything except protocol details near the OTOH sentence above. We can add a second clarifying sentence in the paragraph below: The client MAY communicate the desired fixed rate in its activation request. The reasons to conduct a fixed-rate test include stable measure= ment at the maximum determined by the load adjustment (search) algorithm, or the desire to test at a known subscribed rate without searching. RG: Does the MAY here introduce a new method? If it does, would that requi= re to update the RFC specifying the method? [acm] I don't think an update is necessary. We mentioned this possibility immediately, in RFC 9097 Section 2: * If a network operator is certain of the IP-Layer Capacity to be validated, then testing MAY start with a fixed-rate test at the IP-Layer Capacity and avoid activating the load adjustment algorithm. ########### 10. Security Considerations RG: would a receiver (client and host) require an "Emergency Stop" message? [acm] When would the client or server send this message? As mentioned above, either end can initiate a premature stop, and timer expiration takes care of the test termination at the opposite end. RG: If yes, should it require authentication in order to avoid an attacker from unwanted test termination? [acm] No "Emergency Stop" message, no attack. ######### RG: Would a three-way-handshake make sense to activate testing? (noting that the sender in that case also must be protected against opening of unbounded numbers of tests). A three way handshake protects against forged test set up messages. [acm] The combination of Test Setup and Test Activation define a 4-way handshake. RG: What else could be forged? [acm] everything in the current version, except the Authentication string. RG: Do these require authentication or at least a discussion? Response message feedback (indicating ramp-up/no drop where there's con= gestion or the other way around, congestion where there is none). Stop messages (unwanted termination) Could a host or a client be tricked into persistently acting as a sende= r? [acm] Yes, of course! We want to supply sufficient AUTH and integrity options whe= n needed. That's partly why we petitioned for WG Adoption, to get an early S= EC-DIR review or two. However: I have begin to think that we only need 4 security modes of operation: 1. Unauthenticated (in the protocol now) 2. Password-protected test setup (in the protocol now) 3. Encrypted Test Setup exchanges 4. Run the protocol inside an encrypted tunnel #4 will have performance implications for high capacity measurements on small hosts (in residences, GWs, WLAN devices, etc.) FYI - a client cannot be tricked into persistently acting as a sender. The command that starts the client process determines this role. ######## Editorials [acm] Thanks for these! I'll get to them in a second pass... From: ippm On Behalf Of Ruediger.Geib@telekom.de Sent: Tuesday, December 7, 2021 3:01 AM To: marcus.ihlar=3D40ericsson.com@dmarc.ietf.org Cc: ippm@ietf.org Subject: Re: [ippm] draft-morton-ippm-capacity-metric-protocol Hi Marcus, I support adoption. Regards, Ruediger Some comments: Section 3. Protocol Overview The client requires configuration of a test direction parameter (upstream or downstream test) as well as the hostname or IP address of the server in order to begin the setup and configuration exchanges with the server. RG: The draft also mentions a sender and a receiver. Both, client and serve= r may act as sender and receiver. This depends on the test direction, upstream or downstream. Words to that appear in "9. Method of Measurement", at the end of the doc. 4. Stopping the Test: The server initiates the phase to stop the test by setting the STOP1 indication in load PDUs or sstatus feedback messages. = ( ^^^^) RG: Would it be worth a thought to enable the client to terminate a test? ########## 5. Setup Request and Response Exchange The message format isn't "TLV". Is the protocol extensible (e.g. could secu= rity be adapted to future needs)? ########## 6.2. Test Activation Request - server response .....The remaining 28 octets of the Test Activation Request (normally read RG: A bit worrying, seems to be set by the sender in the reply to a request= only. See editorials... ########## 7.1. Test Packet PDU and Roles .... On the other hand, the test configuration MAY use a fixed sending rate requested by the client, RG: contains descriptive text about the method (e.g. decision on the sendin= g rate). The text there certainly is correct. I wonder, whether a reference replacing the tex= t would be sufficient? RG: Does the MAY here introduce a new method? If it does, would that requi= re to update the RFC specifying the method? ########### 10. Security Considerations RG: would a receiver (client and host) require an "Emergency Stop" message?= If yes, should it require authentication in order to avoid an attacker fro= m unwanted test termination? Would a three-way-handshake make sense to activate testing? (noting that th= e sender in that case also must be protected against opening of unbounded n= umbers of tests). A three way handshake protects against forged test set up= messages. What else could be forged? Do these require authentication or at least a di= scussion? * Response message feedback (indicating ramp-up/no drop where there's c= ongestion or the other way around, congestion where there is none). * Stop messages (unwanted termination) * Could a host or a client be tricked into persistently acting as a sen= der? ######## Editorials 6.2. Test Activation Request - server response ... When the server sends the Test Activation response back, it SHALL set the cmd Response field to: RG: Server Test Activation Reply (or Response - please apply stringently th= rough the text) When the server responds by a Test Activation Reply, it... ---- The server SHALL include all the test parameters again to make the client aware of any changes. RG: The server SHALL repeat all test parameters to indicate changes to the = client. ---- 8. Stopping the Test When the test duration timer on the server expires, it SHALL set the connection test action to STOP and also starts marking all outgoing load or status PDUs with a test action of STOP1. RG: ...and mark all outgoing load... ---- 10. Security Considerations A. Unathenticated mode (for all phases) Unauthenticated ^^^^ Von: ippm > Im Auftrag = von Marcus Ihlar Gesendet: Montag, 6. Dezember 2021 16:53 An: ippm@ietf.org Betreff: [ippm] draft-morton-ippm-capacity-metric-protocol Hi IPPM, This email starts an adoption call for draft-morton-ippm-capacity-metric-pr= otocol, " Test Protocol for One-way IP Capacity Measurement". This documen= t is intended for Standards Track and defines a protocol for measuring Netw= ork Capacity metrics defined in RFC 9097 (https://datatracker.ietf.org/doc/= rfc9097/)= . https://datatracker.ietf.org/doc/draft-morton-ippm-capacity-metric-protocol= / https://datatracker.ietf.org/doc/html/draft-morton-ippm-capacity-metric-pro= tocol-02 This adoption call will last until Monday, December 20. Please review the d= ocument, and reply to this email thread to indicate if you think IPPM shoul= d adopt this document. BR, Marcus --_000_CH0PR02MB7980214B8DCD7DAB8762D6E4D3229CH0PR02MB7980namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

        Hi R=FCdiger, Thanks again= for your comments!

         

        We discussed some of them = at our coding project meeting today.

        Please see [acm] for replies.

         

        All proposals below are im= plemented in the working text.

         

        Al

         

        ############

         

        Some comments:<= /span>

         

        Section  3.  Protocol Overview

         

           The client requires configuration of a test direction parameter=

           (upstream or downstream test) as well as the hostname or IP address<= o:p>

           of the server in order to begin the setup and configuration exchange= s

           with the server.

         

        RG: The draft also mention= s a sender and a receiver. Both, client and server

        may act as sender and rece= iver. This depends on the test direction,

        upstream or downstream.

         

        Words to that appear in &#= 8220;9.  Method of Measurement”, at the end of the doc.

         

        [ac= m]

        OK. Let's try this for the= paragraph above:

         

        The client requires config= uration of a test direction parameter

        (upstream or downstream te= st, where the client performs the role of

                   &n= bsp;            = ;      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^^

        sender or receiver, respec= tively) as well as the hostname or IP address

        ^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^^^

        of the server in order to = begin the setup and configuration exchanges

        with the server.

         

         

        4.  Stopping the Test: The server initiates the phase to stop the

               test by setting the STOP1 indication in load PDUs or sstatus

               feedback messages.   = ;            &n= bsp;            = ;      ( ^^^^)

         

        RG: Would it be worth a th= ought to enable the client to terminate a test?

         

        [ac= m]

        This sentence in section 3= might benefit from some clarification. I added:

         

        4. Stopping the Test: When= the specified test duration has been reached, the server=

                   &n= bsp;          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=

           initiates the phase to stop the test by setting the STOP1 indication= in load

           PDUs or status feedback messages. The clien= t acknowledges by setting the STOP2

           in load PDUs or status feedback messages. .= ..

          

        IOW, neither the server no= r the client can stop a test prematurely in normal

        operation. Note that the p= rotocol overlays the STOP indication on existing

        measurement and feedback t= raffic. It's very simple to implement.&nbs= p;

         

        Alternatively, a client (o= r server) can stop sending traffic

        (load PDUs or status feedb= ack messages, depending on its role).

        An activity timer will exp= ire at the opposite end, and both

        client and server will clo= se the connection. The timer value

        can be set to expire as qu= ickly as needed (some may be sensitive

        to the amount of load PDUs= sent after a test appears to fail).

         

         

        ##########

         

         

        5.  Setup Request and Response Exchange

         

         

        The message format isnR= 17;t “TLV”. Is the protocol extensible (e.g. could security be = adapted to future needs)?

         

        [ac= m]

        All the message formats/PD= Us are extensible. A specific set of formats match a

        protocol version number (c= urrently 8 in the draft you reviewed).

        Our goal is to make versio= n 9 and higher backward-compatible.

        We should be able to add f= ields to the PDUs and leave earlier parts

        untouched...

         

         

        ##########

         

        6.2.  Test Activation Request - server response

         

        …..The remaining 28 = octets of the Test Activation Request (normally read

         

        RG: A bit worrying, seems = to be set by the sender in the reply to a request only. See editorials̷= 0;

         

        [ac= m]

        Here's the full context:

           If the client has requested an upstream test, the server SHALL inclu= de

           the transmission parameters from the first = row of the sending rate table.

         

           The remaining 28 octets of the Test Activation Request (normally rea= d

           from the first row of the sending rate tabl= e) are called the

           Sending Rate Structure, and SHALL be organi= zed as follows:

        ...

         

        So, the Test Activation Re= sponse (the new name for section 6.2)

        uses the Sending Rate Stru= cture to communicate a starting send rate

        for the test, IF the clien= t is the sender, as in an upstream test.

         

        Perhaps we can clarify:

           If the client has requested an upstream test, the server SHALL inclu= de

           the transmission parameters from the first = row of the sending rate table

           in the Sending Rate St= ructure (defined below).

         

         

        ##########

         

         

        7.1.  Test Packet PDU and Roles

         

        …. On the other hand= , the test configuration MAY use a fixed sending

           rate requested by the client,

         

        RG: contains descriptive t= ext about the method (e.g. decision on the

        sending rate). The text th= ere certainly is correct. I wonder, whether

        a reference replacing the = text would be sufficient?

         

        [ac= m]

        Actually, I don't see anyt= hing except protocol details near the OTOH

        sentence above.=

         

        We can add a second clarif= ying sentence in the paragraph below:

           The client MAY communicate the desired fixed rate in its activation =

           request. The reasons to conduct a fixed-rat= e test include stable measurement

           at the maximum determined by the load adjus= tment (search) algorithm,

           or the desire to test at a known subscribed= rate without searching.

         

         

        RG:  Does the MAY here introduce a new method? If it does, would that req= uire

        to update the RFC specifyi= ng the method?

         

        [ac= m]

        I don't think an update is= necessary. We mentioned this possibility

        immediately, in RFC 9097 S= ection 2:

         

           *  If a network operato= r is certain of the IP-Layer Capacity to be

              validated, then testing MAY start with a fixed-rate test at the=

              IP-Layer Capacity and avoid activating the load adjustment

              algorithm.

         

        ###########

         

        10.  Security Considerations

         

         

        RG: would a receiver (clie= nt and host) require an “Emergency Stop” message?

         

        [ac= m]

        When would the client or s= erver send this message?

         

        As mentioned above, either= end can initiate a premature stop, and timer

        expiration takes care of t= he test termination at the opposite end.

         

        RG: If yes, should it requ= ire authentication in order to avoid an attacker

        from unwanted test termina= tion?

         

        [ac= m]

        No “Emergency Stop&#= 8221; message, no attack.

         

        #########

         

         

        RG: Would a three-way-hand= shake make sense to activate testing?

        (noting that the sender in= that case also must be protected against

        opening of unbounded numbe= rs of tests). A three way handshake protects

        against forged test set up= messages.

         

        [ac= m]

        The combination of Test Se= tup and Test Activation define a 4-way handshake.

         

         

        RG: What else could be for= ged?

        [ac= m] everything in the current version, except the Authentication stri= ng.

         

         

        RG: Do these require authe= ntication or at least a discussion?

         

            Response message feedback (indicating ramp-up/no drop where there= 217;s congestion or the other way around, congestion where there is none).<= o:p>

            Stop messages (unwanted termination)

            Could a host or a client be tricked into persistently acting as a se= nder?

            

        [ac= m]

        Yes, of course! We want to= supply sufficient AUTH and integrity options when

        needed.  That's partly why we petitioned for WG Adoption, to get an early SEC= -DIR

        review or two.<= /span>

         

        However:=

         

        I have begin to think that= we only need 4 security modes of operation:

        1. Unauthenticated (in the= protocol now)

        2. Password-protected test= setup (in the protocol now)

        3. Encrypted Test Setup ex= changes

        4. Run the protocol inside= an encrypted tunnel

         

        #4 will have performance i= mplications for high capacity measurements

        on small hosts (in residen= ces, GWs, WLAN devices, etc.)

         

        FYI -  a client cannot be tricked into persistently acting as a sender.

        The command that starts th= e client process determines this role.

         

         

        ########=

         

         

        Editorials

         

        [ac= m]

        Thanks for these!  I'll get to them in a second pass...

         

        From: ippm <ippm-bounces@ietf.org> On Behalf Of Ruediger.Geib@telekom.de
        Sent: Tuesday, December 7, 2021 3:01 AM
        To: marcus.ihlar=3D40ericsson.com@dmarc.ietf.org
        Cc: ippm@ietf.org
        Subject: Re: [ippm] draft-morton-ippm-capacity-metric-protocol<= /o:p>

         

        Hi Marcus,

         

        I support adoption.

         

        Regards, Ruediger

         

         

        Some comments:

         

        Section  3.  Protocol Overview<= /p>

         

           The client requires configuration of a = test direction parameter

           (upstream or downstream test) as well a= s the hostname or IP address

           of the server in order to begin the set= up and configuration exchanges

           with the server.

         

        RG: The draft also mentions a sender and a receiver.= Both, client and server

        may act as sender and receiver. This depends on the = test direction,

        upstream or downstream.

        Words to that appear in “9.  Method of Me= asurement”, at the end of the doc.

         

         

        4.  Stopping the Test: The server initiates the= phase to stop the

               test by setting= the STOP1 indication in load PDUs or sstatus

               feedback messag= es.            =             &nb= sp;            =             &nb= sp;    ( ^^^^)

         

        RG: Would it be worth a thought to enable the client= to terminate a test?

         

        ##########

         

        5.  Setup Request and Response Exchange

         

        The message format isn’t “TLV”. Is= the protocol extensible (e.g. could security be adapted to future needs)?<= o:p>

         

        ##########

         

        6.2.  Test Activation Request - server response=

         

        …..The remaining 28 octets of the Test Activat= ion Request (normally read

         

        RG: A bit worrying, seems to be set by the sender in= the reply to a request only. See editorials…

         

        ##########

         

        7.1.  Test Packet PDU and Roles

         

        …. On the other hand, the test configuration M= AY use a fixed sending

           rate requested by the client,

         

        RG: contains descriptive text about the method (e.g.= decision on the sending rate). The text

        there certainly is correct. I wonder, whether a refe= rence replacing the text would be sufficient?

         

        RG:  Does the MAY here introduce a new method? = If it does, would that require to update the

        RFC specifying the method?

         

        ###########

         

        10.  Security Considerations

         

        RG: would a receiver (client and host) require an &#= 8220;Emergency Stop” message? If yes, should it require authenticatio= n in order to avoid an attacker from unwanted test termination?<= /p>

         

        Would a three-way-handshake make sense to activate t= esting? (noting that the sender in that case also must be protected against= opening of unbounded numbers of tests). A three way handshake protects aga= inst forged test set up messages.

         

        What else could be forged? Do these require authenti= cation or at least a discussion?

        • R= esponse message feedback (indicating ramp-up/no drop where there’s co= ngestion or the other way around, congestion where there is none).
        • Stop messages (unwanted termination)
        • Could a host or a client be tricked into persistently acting= as a sender?

        ########

         

         

        Editorials

         

        6.2.  Test Activation Request - server response=

         

        …   When the server sends the Test A= ctivation response back, it SHALL set

           the cmd Response field to:

         

        RG: Server Test Activation Reply (or Response –= ; please apply stringently through the text)

        When the server responds by a Test Activation Reply,= it…

         

        ----

         

           The server SHALL include all the test p= arameters again to make the

           client aware of any changes.=

         

        RG: The server SHALL repeat all test parameters to i= ndicate changes to the client.

         

        ----

         

        8.  Stopping the Test

         

           When the test duration timer on the ser= ver expires, it SHALL set the

           connection test action to STOP and also= starts marking all outgoing

           load or status PDUs with a test action = of STOP1.

         

        RG: …and mark all outgoing load…

         

        ----

         

        10.  Security Considerations

         

        A. Unathenticated mode (for all phases)

         

        Unauthenticated

            ^^^^

         

        Von: ippm <ippm-= bounces@ietf.org> Im Auftrag von Marcus Ihlar
        Gesendet: Montag, 6. Dezember 2021 16:53
        An: ippm@ietf.org
        Betreff: [ippm] draft-morton-ippm-capacity-metric-protocol

         

        Hi IPPM= ,

        &n= bsp;

        This em= ail starts an adoption call for draft-morton-ippm-capacity-metric-protocol,= " Test Protocol for One-way IP C= apacity Measurement”.  This document is intended for Standards T= rack and defines a protocol for measuring Network Capacity metrics defined = in RFC 9097 (https://datatracker.ietf.org/doc/rfc9097/).

        &n= bsp;

        https://datatracker.ietf.org/doc/draft-morton-ippm-capaci= ty-metric-protocol/

        https://datatracker.ietf.org/doc/html/draft-morton= -ippm-capacity-metric-protocol-02

        &n= bsp;

        This ad= option call will last until Monday, December 20. Please review the document, and reply to this e= mail thread to indicate if you think IPPM should adopt this document.<= /o:p>

        &n= bsp;

        BR,

        Marcus =

         

        --_000_CH0PR02MB7980214B8DCD7DAB8762D6E4D3229CH0PR02MB7980namp_-- From nobody Thu Jan 27 17:45:07 2022 Return-Path: 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 A14133A14A0; Thu, 27 Jan 2022 17:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drDx5VI7Ifhz; Thu, 27 Jan 2022 17:44:58 -0800 (PST) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2131.outbound.protection.outlook.com [40.107.92.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 620153A149B; Thu, 27 Jan 2022 17:44:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=E7OY2qkBfmSl74R7NcoMHxeaSRkZhfVFwze22XdqITlAQQWHNBPRGUAks/mR1rccJJ7oi4FpaesIj8vdEExU4wpWZWl6eCpDYr2gelYD2ItbqaCeBqJ4at9iSTSdd680M0hotLM+Juu4BbYPXPRCumZlvtTd9UhMLPs8UYLJRWWDMjxgOXazWgkmjj4NZzFx0RHIRGcsBkuyck9FkX4Ra6qdOa3R7MQsug02XQGp9YEOTsjkT+idcTfw7L+iFKof2/w8XAgbBXGp/0u97++B1ihA+pz3l4l33q7DrAjJze7F7Az4uID8lFuKlo7wI116MzNt7Y2LsdIa6CdNxWm4ag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=w7FmUkMIcRCjteu/xVuV3iZjx76EsCdxhGBtKIOiNvA=; b=FQRMV1UPD64t/bIkTVDDA8IuU9xEDnrHQ5OugB/Q9/A9mSGrA8iVyPrdjOGBvCO07nBX84ZYmtfvh+PbAsklLS/vrT3FUZvat4l20emgfbw+NVjWm8kmczO7dY2jeJiqx1ZbMArNdgedzU8sfKBwJOga6IPOtbACJaTsae7QrozddEX0TBgcGmn8Lt06wiyA3jrjolzrYCcBlEj2ezmjuXmPgD9qHtUNHCqtPXPLo1r0firyolFnnbTQgn8tYiEIaYz+3wKeh0oWDxGppM9IuImKg9WdkqBzv1/dCXq0Lsszb4zQbzg8BrzMx19pKeaiD4m94c0zb+/3O/SQh7+l+w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w7FmUkMIcRCjteu/xVuV3iZjx76EsCdxhGBtKIOiNvA=; b=ll9wTwN7xeBRvKvIgLrI8yGqxzjXApJ/M0swGdmbrC/z9+ur8hCy763vNrwHeOdOAczScS9zB8q71SpLE5wsu/yfztB5tV7DYCHHTiCq9BeGo0Hv+yG1WyIXgjxwYX0LUlizdpEVEAuUMmYgavZXAqWZ080Ckaz/6j2khcJ9X4g= Received: from BY3PR13MB4787.namprd13.prod.outlook.com (2603:10b6:a03:357::13) by DM6PR13MB3210.namprd13.prod.outlook.com (2603:10b6:5:5::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.5; Fri, 28 Jan 2022 01:44:55 +0000 Received: from BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::e07d:da86:9082:d264]) by BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::e07d:da86:9082:d264%6]) with mapi id 15.20.4951.006; Fri, 28 Jan 2022 01:44:54 +0000 From: Haoyu Song To: Greg Mirsky CC: "spring@ietf.org" , IETF IPPM WG Thread-Topic: [spring] Active OAM in SRv6 Thread-Index: AdgTBAVv6vallEwgQVCAy2m6n5m7fAABJueAACmK42AABqLOgAAHd+Ig Date: Fri, 28 Jan 2022 01:44:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 40955e08-d1f3-4af5-2c74-08d9e1ffc8ab x-ms-traffictypediagnostic: DM6PR13MB3210:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: q5wSzb7sm476Z2axeWhBt2vRB6CfRjGmkMr545G6MvgrD1zBg/h61kjTDsWB+fIGMILlXWCuc/e+cQ+VlDklw1rM/UJHp2wzvmFL8I05RDqExyY8Fjl2CiSVHqQiuu0hx/ezS3Qd948UyOgdSIxmCG3k62vJCenalOoXwdMBVj6bOmLNVArNRH4sMYcDMxjHGr1ZNBYvwg7JfQ99wBlxoyqujROs5voAfLQKrq5wd2opX76dydKcwwoSyOLj/Sd4klE5f5YYqSdztHrhCD0ru9iPpn8D+4o1jY2/t33k1AwSdQL7EzmeD4H2thyfpd/5gtv9SUBHzgO1HFfMtQW/jFi/s7NBwKQKlxQVpGG+Lc+EymUn3nw5KUrbjw/KXoYHRKFutElZzlmeUp+gKc7xWnSPXS9bZddZgQRNnuTm/qm5aInCadwJKUutFtmjZciwQGlf3te3wfTtdCBvpuw7t9T2NLqmm68w/B9ekTzq1Tq6BxI6B/gQL1knvZ5MIYfsXy01ZIlqjMoausihLj++/UXAEmcf0KbdQcgAkDvZjJFYp8T+TY5jeAFmxQ/I4SDkiswPdO6ji9Ebtoe9KoOob+4rM9VjVQhfod9WRCssCGWk4J4tOqaNEzTQ7LIlp+Se7PbnsVHofmBW7ed2z4fV8YvhcjEZRGu2uGGTvhUzoAxfUdPt9slhpt5HS7ZJfI+K40JMyykSDCth1yIWcTYD6eV9ZNBQoBc2v/ksc97ydJqt3y+TKTd37uo47Z62tClMWzaRVBx/25VZ1+wRg7CitpdP5GT2Yur+E29q6ay6RAwMWcs9yRL2wtai4gRpAd6weJz8v8JXchsmvf+8GTgnVw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR13MB4787.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(44832011)(122000001)(166002)(38070700005)(38100700002)(52536014)(2906002)(66946007)(8936002)(76116006)(7696005)(33656002)(53546011)(64756008)(6506007)(508600001)(8676002)(4326008)(66476007)(66556008)(66446008)(71200400001)(316002)(6916009)(186003)(83380400001)(9686003)(5660300002)(966005)(54906003)(86362001)(55016003)(20210929001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?dPQWBARgr8n9NgZlzLAytqLvCL/ReVdsckCKOPSYa5qvJfEMKY0cG4UCF9hN?= =?us-ascii?Q?TzZafLpxwAJpaLQVujO4bZwSqxSZyAe4SLpYyiJvRk0MlrMVSkJBc2lR8XRS?= =?us-ascii?Q?pDMZB54hpO7cc+7+d6cgaRbJhB8kLFcq/coNlFioKAaSeUt92IbGiFYI9STJ?= =?us-ascii?Q?Ltflg1heFa5o1gfA3Gzuumu321a6apQX397q6IeV32VnSmCpkngTWDjCrwTn?= =?us-ascii?Q?pJlzqp1F5I8kGjpObDobp/7s31GoYiVcmAKYKV6FpVdPpMsfy/Sq1mYXhNeP?= =?us-ascii?Q?VtEV3zGPSCivhyrAxETN2e6F3LHZaT6W8aRvpRVpHDbrauhQP2ZXY5Xf95hg?= =?us-ascii?Q?ItQvvfZFkmq37HehjHdrWSjp4Bi0l+DO+RmwD0193OgmIH+VpUbZRosKBIkc?= =?us-ascii?Q?vf7wipv58CIGq/nHI0SZExOBqBcAjQs3aHL16MyCYg0CNUFCSCZAAUplIozP?= =?us-ascii?Q?p5tOaxRSwaGIW+gLAFq3qJ4yil639gFbzOqNy+vGCPwG98xowsaQvjwdcQwc?= =?us-ascii?Q?ZL6PEAxBQFXhiF39vcCagNU2vMEk0cmwT2mf2uxlsNOo1zY7SIL/sWH6qb2N?= =?us-ascii?Q?s5Ffa9bkyBhjmBHl0rc3mNHhCNBqYzaft8bgo/61jm8Id3TSzxguqIIcu294?= =?us-ascii?Q?kA5LG+GDmEM8tSuajHgScncdLH3eLb56AT6aiDA6QYHu6r1OR33Kr2cRiKGB?= =?us-ascii?Q?fV7kVlAiHNUjRny+HQcexFaigWeoK6U8GtMItl4/hGBPfkxabSxBDXu26hxb?= =?us-ascii?Q?F3GOiQ0WvV09S9snNu6pBt0FBq9ALyBbCZP/AUYhC+lTnbh+V5jKaUNDe0N5?= =?us-ascii?Q?IVqAgbOr9btiiuAU8SMbncIhS05cpoxhh4aVVB652yAyCdmF2Kn4MwLVQqMN?= =?us-ascii?Q?Uio/BHRhuEZPCqOrB4udXmaYmR8H5u8gdvjpSitgmNcl+eCyLwOPzhOLImCR?= =?us-ascii?Q?oB1YNByDRewSMX4ukeSBFyBn68J7Kb3MW3lyOKinR3D6q9KZ39zmA/Sy3fvq?= =?us-ascii?Q?9c8GpzRBz3l4ydIZtFCHRl0wGz0g1Yja6Ywp40W/J5lqx9MyGgZ1nrp0X8HT?= =?us-ascii?Q?Iy7K6tIyfzhHSuaeUdWiumraGyYk9G9lCv592hQJcYCj+7AmJf6dHW7dNPwj?= =?us-ascii?Q?rJsIiV+qHnk/qEqMOND8ycjtBF5+/5CM82Ib1Be/SSIdinzJsuLXVravdAU1?= =?us-ascii?Q?ZslmgLhfuXK0KxI34BWcLXTAKQOeLhNECtRJAv6krlrVQVA+zpfXpPrv/1D+?= =?us-ascii?Q?SOzNpMaEfOsgB4Jkq3/Svi3wv5o7RI8ZzWCuiGGcQdeOouvyxCtvPsFxsdJk?= =?us-ascii?Q?/kYZ1m5MmqKNe3gLtPnpGayOH9CnAJRJ0gRzt12+G6A5tinxpGhyJIC07zj7?= =?us-ascii?Q?Gs2dz/rXg0IJCI4CNWZP5dIc7CQVcNxdgfL6sWnkv2fCnqvlXbOSasfanBnm?= =?us-ascii?Q?QlGMLhQa/ertLPBKW8Iy/zwljFqn62eQFF0gZb0gZiO/2BGfGX32eGD1svUn?= =?us-ascii?Q?NiZiyb3FWwwj8CXwYyQyzF+I7N+Hb/yOO8CPYW+EJUuyn9r442nAtBVoWVJa?= =?us-ascii?Q?/tNOVhT7F8b4xvXwJUJPf5mZkMwrOTr+CA9Qr76rAbPFRcNCpF0fgJ94m37w?= =?us-ascii?Q?6EOCBkoR9sgcOhak8L6NcqqbeKCDL5/WaXS1+LvgipGRQ3eHfNGxmQdiMHer?= =?us-ascii?Q?x4asNdlvJfeTxVfT3sVvCzOGVjM=3D?= Content-Type: multipart/alternative; boundary="_000_BY3PR13MB4787B8709B423786E6787C789A229BY3PR13MB4787namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB4787.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 40955e08-d1f3-4af5-2c74-08d9e1ffc8ab X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2022 01:44:54.7944 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: A7I9aG0Ul/shpRqRgbvqJIRB/1LZ23vra3oWxS0h9kr95rGI3tyu1S9zxYLOcjTWjtqym9TZ4558K5wYBXeR7w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR13MB3210 Archived-At: Subject: Re: [ippm] [spring] Active OAM in SRv6 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2022 01:45:04 -0000 --_000_BY3PR13MB4787B8709B423786E6787C789A229BY3PR13MB4787namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, please see Inline From: Greg Mirsky Sent: Thursday, January 27, 2022 2:01 PM To: Haoyu Song Cc: spring@ietf.org; IETF IPPM WG Subject: Re: [spring] Active OAM in SRv6 Hi Haoyu, thank you for your detailed reply. Please find my follow-up notes in-lined = below under the GIM2>> tag. Regards, Greg On Thu, Jan 27, 2022 at 11:00 AM Haoyu Song > wrote: Hi Greg, Thank you for your questions. Please see inline response. Best, Haoyu From: Greg Mirsky > Sent: Wednesday, January 26, 2022 3:01 PM To: Haoyu Song > Cc: spring@ietf.org; IETF IPPM WG > Subject: Re: [spring] Active OAM in SRv6 Hi Haoyu, thank you for bringing the topic of Active OAM to the discussion. As the co= ncept of Active IOAM is introduced in the IPPM WG draft it seems to me like adding t= he IPPM WG community to the discussion is the right thing to do. Please find my notes in-lined below under the GIM>> tag. Regards, Greg On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song > wrote: Hi SPRING WG, Real time monitor on every node and every link on a network is necessary to= detect gray failures, which are the key culprit for poor QoS but hard to = catch. SR provides an ideal mechanism, when working with some efficient pla= nning algorithm, to achieve that with low cost. Our proposal SRv6 In-situ= Active Measurement (SIAM) suggests a simple active measurement approach w= hich can support different GIM>> I wonder what gaps you find in the existing active measurement protoc= ols, e.g., STAMP and RFC 6734 (would be more convenient to use an acronym).= It appears to me that, for example, STAMP and its extensions, including th= e SRPM draft, comprehensively address the PM OAM requirements for SRv6. HS>> Let's give a few features of our proposal: (1) it's session-less and w= e don't need assign any roles (e.g., reflector); (2) no needs for a return= path. The measurement can start and end at any node (solely determined by = the SRH); (3) udp-based which can support any existing IOAM modes and poten= tially other OAM methods. GIM2>> I don't think adding a protocol that can generate a test probe from = an arbitrary node to arbitrary targets (SRv6 supports multicast) is as simp= le as you present. If an operator needs to monitor the performance of the S= R policy used by data packets, IOAM can be applied to data packets. If the = operator wants to explore a policy that is not used for data traffic, I ima= gine IOAM can be added to a test packet of the existing OAM protocol, e.g.,= ICMP. Am I missing some of the requirements? HS2>> For the first point: I don't think a protocol is needed here. If one = wants to test the path a->b->c->d->e, he doesn't need to find a user packet= on that path to carry IOAM (there could be no such packet at all). Instead= , he can generate a probe packet with an SRH for the path and use the probe= packet to carry IOAM. At the path end, it simply extracts and exports the = IOAM data using the mechanism defined for IOAM and drops the probe packet. For the second point: I don't think ICMP can achieve what IOAM can do. IOAM= is much more powerful in terms of the data it can collect. Moreover, the p= roposal can be easily extended to support other kinds of OAM methods. One j= ust carry it in UDP payload using different port. No need to worry about th= e size if such info has to be carried in EH TLV. options of IOAM and other OAM methods in SRv6, without needing to worry abo= ut the extension header issue. GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows: In terms of the classification given in [RFC7799] IOAM could be portrayed as Hybrid Type 1. Does your proposal change that? HS>> In this particular case, IOAM is used for active measurement because i= t's not included in a user packet. Your comments, questions, and suggestions are very welcome. I'd like to kno= w your opinion if you think this work is in scope and should be adopted by = the working group. If you are interested in contributing to this work, ple= ase also let me know. https://datatracker.ietf.org/doc/draft-song-spring-si= am/ Thank you very much! Best regards, Haoyu _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_BY3PR13MB4787B8709B423786E6787C789A229BY3PR13MB4787namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

        Hi Greg, please see Inline

         

        From: Greg Mirsky <gregimirsky@gmail.com&g= t;
        Sent: Thursday, January 27, 2022 2:01 PM
        To: Haoyu Song <haoyu.song@futurewei.com>
        Cc: spring@ietf.org; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [spring] Active OAM in SRv6

         

        Hi Haoyu,

        thank you for your detailed reply. Please find my fo= llow-up notes in-lined below under the GIM2>> tag.

         

        Regards,

        Greg

         

        On Thu, Jan 27, 2022 at 11:00 AM Haoyu Song <haoyu.song@futurewei.com> wr= ote:

        Hi Greg,

         

        Thank you for your questions. Please see inline response.

         

        Best,

        Haoyu

         

        From: Greg Mirsky <gregimirsky@gmail.com>
        Sent: Wednesday, January 26, 2022 3:01 PM
        To: Haoyu Song <haoyu.song@futurewei.com>
        Cc: spring@ietf= .org; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [spring] Active OAM in SRv6

         

        Hi Haoyu,

        thank you for bringing the topic of Active OAM to the discussion. = As the concept of Active IOAM is introduced in the IPPM WG draft it seems to me like adding the IPPM WG community to = the discussion is the right thing to do. 

        Please find my notes in-lined below under the GIM>> tag.

         

        Regards,

        Greg

         

        On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song <haoyu.song@futurewei.com>= wrote:

        Hi SPRING WG,

         

        Real time monitor on every node and every link on a network is nec= essary to detect  gray failures, which are the key culprit for poor Qo= S but hard to catch. SR provides an ideal mechanism, when working with some efficient planning algorithm, to achieve= that with low cost.   Our proposal SRv6 In-situ Active Measureme= nt (SIAM) suggests a simple  active measurement approach which can sup= port different

        GIM>> I wonder what gaps you find in the existing active mea= surement protocols, e.g., STAMP and RFC 6734 (would be more convenient to u= se an acronym). It appears to me that, for example, STAMP and its extensions, including the SRPM draft, comprehensively address the PM OAM requirements for SRv6.&n= bsp;

         

        HS>> Let’s give a few features of our proposal: (1) it= ’s session-less and we don’t need assign any roles (e.g.,  = ;reflector); (2) no needs for a return path. The measurement can start and end at any node (solely determined by the SRH); (3) udp-based wh= ich can support any existing IOAM modes and potentially other OAM methods.<= o:p>

        GIM2>> I don't think adding a protocol that ca= n generate a test probe from an arbitrary node to arbitrary targets (SRv6 s= upports multicast) is as simple as you present. If an operator needs to mon= itor the performance of the SR policy used by data packets, IOAM can be applied to data packets. If the operator want= s to explore a policy that is not used for data traffic, I imagine IOAM can= be added to a test packet of the existing OAM protocol, e.g., ICMP. Am I m= issing some of the requirements?

         

        HS2>> For the first point: I don’t think= a protocol is needed here. If one wants to test the path a->b->c->= ;d->e, he doesn’t need to find a user packet on that path to carry= IOAM (there could be no such packet at all). Instead, he can generate a probe packet with an SRH for the path and use the probe packet to carry = IOAM. At the path end, it simply extracts and exports the IOAM data using t= he mechanism defined for IOAM and drops the probe packet.  =

        For the second point: I don’t think ICMP can a= chieve what IOAM can do. IOAM is much more powerful in terms of the data it= can collect. Moreover, the proposal can be easily extended to support othe= r kinds of OAM methods. One just carry it in UDP payload using different port. No need to worry about the size if su= ch info has to be carried in EH TLV.

        options of IOAM and other OAM methods in SRv6, without needing to = worry about the extension header issue.  

        GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows:<= o:p>

           In terms of the classification given

           in [RFC7799] IOAM could be portrayed as Hybrid Type 1= .

        Does your proposal change that?

         

        HS>> In this particular case, IOAM is used for active measur= ement because it’s not included in a user packet.

         

        Your comments, questions, and suggestions are very welcome. I̵= 7;d like to know your opinion if you think this work is in scope and should= be adopted by the working group.  If you are interested in contributing to this work, please also let me know. https://datatracker.ietf.org/doc/draft-song-spring-siam/

         

        Thank you very much!

         

        Best regards,

        Haoyu

        _______________________________________________
        spring mailing list
        spring@ietf.org https://www.ietf.org/mailman/listinfo/spring=

        --_000_BY3PR13MB4787B8709B423786E6787C789A229BY3PR13MB4787namp_-- From nobody Thu Jan 27 17:57:45 2022 Return-Path: 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 C07733A1531; Thu, 27 Jan 2022 17:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeeAzzcqmX_l; Thu, 27 Jan 2022 17:57:34 -0800 (PST) Received: from NAM02-BN1-obe.outbound.protection.outlook.com (mail-bn1nam07on2126.outbound.protection.outlook.com [40.107.212.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A64193A152E; Thu, 27 Jan 2022 17:57:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IUL13M+nscP4mGzHiw4Og2jTDB4LWXEA5YSZyzMj2sd1jWu1/BxwQ9hlTCOh5KXCqPO85tuiFOg910+KPJOHEKdTtyUZPQZ8ppLIpPxcGoaOVJwvGughL1TSLCMH/ONKiNPYu/kcWzEyFlh9FUSVYdKaN8wEnt9M0vnMksyZ6/iMZzUg2pCEDPrjTwAtaKtGcJjAJXyNcQxvK604xnsYFAaH8stzpuRTjROQs74Yk5TIKjgeDFYbxNQNznFisbeRw1LeLvifjizcKsNL5MNgOBqiocyEypWL2e+brJMSMG3pTtd6TUlkCKlizWn0TchFC+xla98vVSnQcuRjyMbUJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IPsmLvpV+TdEo38sICToEcneNrAPUcbWDHnVQLnVS9o=; b=H1/JNt1tj+Uft/xU1r8fCGnWBvHZwGABA4+O+v2E9FDDBB1+Pfd87D5Wl0+VWg0/Zfvs3E/ugDSUQ6wXVvxAZHS5jOuFsFpLdIeFl6oI6a2zucVNGvutpFbUpThq8Dx50IherJWN59f4zqIHpueGaOz1BeVQdcacu5wyyEdDPBRDyYtuJBwi5oYtH41PFCk9PL4XKkEturI7f4kOSCncY+02PV51YdwgpLtjLh7fOSPt6DIVprp+2gmxckkXELkYKzZ4SDhFAWQmF3MzbllbidMPbxim6cmmrzhLiYFm5VhYfiIZDGQskd1uG4W6ahlTR8QCGQ6K0PjdHEzNwzr0pg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IPsmLvpV+TdEo38sICToEcneNrAPUcbWDHnVQLnVS9o=; b=hLPuiwMz4bZ/QQLxEmiy8aalmAu8QkOplKfm2d1Nk3pxfdi/N9v+jomhYycuh+ONRfGylPZNfrWRXUMn8GMilF80+dvusPZRbJ8fRy1A3R2hCDxO8BQJPZmuQ1/SOty+R4RphrgjtKVfCTiE9xrj4yceE3fYyuzFCvEOoaE9EQQ= Received: from BY3PR13MB4787.namprd13.prod.outlook.com (2603:10b6:a03:357::13) by DM5PR13MB0972.namprd13.prod.outlook.com (2603:10b6:3:79::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.5; Fri, 28 Jan 2022 01:57:29 +0000 Received: from BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::e07d:da86:9082:d264]) by BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::e07d:da86:9082:d264%6]) with mapi id 15.20.4951.006; Fri, 28 Jan 2022 01:57:28 +0000 From: Haoyu Song To: Tianran Zhou , Greg Mirsky CC: "spring@ietf.org" , IETF IPPM WG Thread-Topic: [ippm] [spring] Active OAM in SRv6 Thread-Index: AdgTBAVv6vallEwgQVCAy2m6n5m7fAABJueAAAkAnYAAIFPokAALypSAAAL1VRA= Date: Fri, 28 Jan 2022 01:57:28 +0000 Message-ID: References: <97ee51feb17c4bcc84bc575768c06c3e@huawei.com> <0d5bbca4caeb4c3e83d7117919aebadc@huawei.com> In-Reply-To: <0d5bbca4caeb4c3e83d7117919aebadc@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f8f735b9-5e50-4ccf-167f-08d9e2018a1d x-ms-traffictypediagnostic: DM5PR13MB0972:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Y27Ta4VoZdQymPVHyEfwdYjp9z9zx4deb5FJvCkwNCIjDfPWGlMPfRzqIuF24s3bgZlKvaxViDxdV1+PNYGHYY0mCsQ7QSpT316Xry1XIH4klAEKYDhurDd+oiy1uF8i90Ts44HeT+IEs7lYFAj4z52p2OcgwSVLPiC1TRZe3cy1KBfnktUPJwXYoODob5iJKzvFZlOTeHE1ItKmTlOFvivp6Flgb+ENmr/bPMBVdOCtiTVoQ3Up6d7OtZlAsNI92QHFdjYG6ZGnrvgIpvSTPzUvQco2b+llczJgwggIi4lVQ4ntc/eCeo45te8tMng7/oAIavIHTXKNFtg3pFOdo8A2merqfnWSmEXvv+IJ75uh0KYM1sxNGa09ULYT39Te3o5LoxGx/e8OlzxxKxl3FzwLJiAyjRiNZi4X84DEtnjy8G6uqKLlxcsPPDjbq07IrdLQRQAX/KpGAabS+Ilg2rurzekckQCoVTA/RfzhAspSmEdIHNP0TRT2XHy2zJKrztBr7Iy3BLe7ShJ2XSpgb8+dUIpRlxOYO7lbrFx2i8rVNgqdSkBDqgaHgRJBhRNS1Wv3dxQZtSn3q2yEU3cUGXaZP3dhGhprQz2WMgDsgXIhFo+PUqaSy7QhMpEcQSy40FVEXwSaXiBjW/6p/Qu4HoYfZBz2G81GpBvaTtUSH/+dmKU5OW/nawb56EyPGPcFhLV6LdHCSb+GG1D/LEQHgwX4UFXRZf0Gkzico4YUaY7Bt7eYUc5kKh/yWGI+AbBfQxlKDph+UjsdPmpAziL4xuowMmkjKoE8BVQOIXXoXieA4yOOCUBWTe/qbxMNVwcYo02CE+yY6UBIU2ox6VoTiQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR13MB4787.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(76116006)(8676002)(4326008)(8936002)(66446008)(66556008)(66476007)(86362001)(64756008)(83380400001)(38070700005)(66946007)(55016003)(38100700002)(44832011)(5660300002)(122000001)(166002)(508600001)(110136005)(186003)(2906002)(52536014)(9326002)(71200400001)(316002)(33656002)(54906003)(9686003)(7696005)(53546011)(966005)(6506007)(20210929001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?gawPw0DNJJ9Yv0QA9Ha3hA4T3TTKtPPYJ11kljZxYph2vIXznU+/Xo10iqfd?= =?us-ascii?Q?uu39mpI6+M+Eu8PQ37YydfE6ww+J1D3N0oqGfLfZOHLhIQz5MKxANxvu0JKO?= =?us-ascii?Q?kosf0RQjMsbOEZvM7q5QauwlNeA8zGxG8k0cgAlG1rkqZQuTsfUxtjg/7k4i?= =?us-ascii?Q?9g+ykPWb5BB3Zwff1sii35ed5/teHW+kgyF7LqgOYXcfWI3HnFF3LKls4xLk?= =?us-ascii?Q?xEz39qc3eG58Sa2yMAHg19i9He6WomxhhfHV2JJiu0J11M95oOG/Lzw7Dntm?= =?us-ascii?Q?2zwW43FRzNC63HDX4e4yPDDDuseadv/WIilnNxr9PKaulNwgHLxbCzHxcrve?= =?us-ascii?Q?DPL9gE8M9Bw79C1r76rbi5PhVLaA/j7Zz6kCV9aJzKg5nRhWilVr251Aza3c?= =?us-ascii?Q?MTLKruZmT+94DWXC3SiQVGgwTrXr9G6lSO2mz++T1fb9jzue+f5g3YzL00Td?= =?us-ascii?Q?noNrufUPWbpr4tcMPG7M7eaEvfl4Y4tIkMegbDo/cJywDCHzmIboeH4zagN9?= =?us-ascii?Q?WaGYDL/VrHQUrdrk7MoGuD57bzLUJYLEcEblo085Zp33ddpKpBJ9324WgY2V?= =?us-ascii?Q?DCRFF2YtvHBqo3GX/0j1xhAhRgtdbveWh1b26RZuX9Ufxm6Fk+fSE4VPWBWI?= =?us-ascii?Q?Jf63hpu3Z/lYrovVn37g8eGGAHRFWppLRX1gRmvYf65sodDsXJkeKJSdz9o4?= =?us-ascii?Q?qFvHDSimXDaq8I47XXO6uT8xMWtl7XvR00suXGJDtefGZwv0+9qeJptqKLY3?= =?us-ascii?Q?4JyvSD2LyOzf12JutOTiHaNFGz05xkNLj2m3qMtlvw5qMSB46PC0NCzoLmHH?= =?us-ascii?Q?bDMDmmCFrRSoiRiYbMu2LX+V28vpNW7YW1oIWTfbcWPXrRBx6wIWY2M74sCB?= =?us-ascii?Q?k0fsVEtOrF0iwDLhBZQjkmY1b3sUmLeCq1fR0DH/afFCc20OnjCrEj2A2zNO?= =?us-ascii?Q?V1/vGPUmQItVIVW9rjuW48EUTgqqEzVKY0CHT2zuxVi42rbTMYgLli2cda5D?= =?us-ascii?Q?BRbcDpkejD6Ce0TOIRthjfIqSXRswC3QUan7DsT5+4+ZZ20ToM+aYek2TfEQ?= =?us-ascii?Q?941FMClhcRvK2r01CEbiwkb+qjmy+DYP7ihwbUBJ8Fwd/oXY+R1i7L3dyhqY?= =?us-ascii?Q?LJrD7MH5MnZdPgkKvBqnABmKLTVSYdvc6G1tkuhd80L6rsXvtZHwJ8WRxTQG?= =?us-ascii?Q?WyMo/XIPAszsjFsGoqwg3RKm6IKdlscYkJzp+Gp6vylzw1VNqrfzmX7xb54c?= =?us-ascii?Q?6r8Hny+79GarU3nssP4A9d6BI8viqvPgKeod0xzl5mdWVgB+iJxsSBMG81qG?= =?us-ascii?Q?pTS6wAg+TE6w8mihP7AgaFcELz962hfwNzxs+GQWoDyGR1+PkKMDC9wlMXMP?= =?us-ascii?Q?tuGoAf7/SWihafk2UmcH8I31Qw9ohnfTSfcohRfF8TQe5PMNP4kcDfJjwYGy?= =?us-ascii?Q?nYG0kFLBfVvwnGNKoqt2zxWKtt5up1aPpeSINBBE/BKpL6JV1hRoCIMVskgk?= =?us-ascii?Q?6g1JsQGeqlryW7ppviTE0cxRmejkyljeRZ9xC475thN3HM7tytpxIaFUTur1?= =?us-ascii?Q?ig19wgvS5JU37jOKFZTf28G9yl2qK76N/m4RiDTlOrigm/Q0W2xLsXjVzwg+?= =?us-ascii?Q?/Ei5fL+H9ZCbak0BxRPxhlF6mc4uVe15EcwFoSCyggvq2jIHiD30+jReP81z?= =?us-ascii?Q?7wP0uKS9lixGRUWpcOL9lz/VH8Q=3D?= Content-Type: multipart/alternative; boundary="_000_BY3PR13MB47877877974620DE44EA08509A229BY3PR13MB4787namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB4787.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f8f735b9-5e50-4ccf-167f-08d9e2018a1d X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2022 01:57:28.8705 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 14P7s+HYUFwF7yQlz03wwTbpkizm1cVoN2zxoRgR3STVye1mr0X+F2b/Hf8XP0lC+sOr3U1flPiRAsoh2QQzPw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR13MB0972 Archived-At: Subject: Re: [ippm] [spring] Active OAM in SRv6 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2022 01:57:39 -0000 --_000_BY3PR13MB47877877974620DE44EA08509A229BY3PR13MB4787namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tianran, The use case I target is to generate probing packets to collect node/link = data on arbitrary path. We have algorithms to generate such packets on a fe= w path to cover the entire network (reference is given in the draft). If we= periodically do such measurements, we can gain the visibility of the whole= network and detect the gray failures, which can have countless useful app= lications. Why using UDP rather than EH TLV? here's some of my thoughts. First, I don'= t need to do it in user packets, so essentially the payload is free to use. Second, there are a lot of discussions and debates on the size/location of = the IPv6 EHs, and there are so many proposals want to use the EHs. I don't = want to add more complexity to it. Third, the proposal can be extended to support other OAM schemes using the = same method. Of course, you can also keep introducing new TLV options to EH= . But again, that's the path I don't want to go. Best, Haoyu From: Tianran Zhou Sent: Thursday, January 27, 2022 4:22 PM To: Haoyu Song ; Greg Mirsky Cc: spring@ietf.org; IETF IPPM WG Subject: RE: [ippm] [spring] Active OAM in SRv6 Hi Haoyu, I do not understand why the UDP encapsulation is better than SRH TLV. IMO, IOAM is already too complex, some more work on TLV parsing is not crit= ical. If you care about the data length "because the data needed to be carried ma= y be too large", what's the limit on SRH TLV? What's your use case, and your requirement? Let's evaluate it with numbers. Best, Tianran From: Haoyu Song [mailto:haoyu.song@futurewei.com] Sent: Friday, January 28, 2022 2:50 AM To: Tianran Zhou >; G= reg Mirsky > Cc: spring@ietf.org; IETF IPPM WG > Subject: RE: [ippm] [spring] Active OAM in SRv6 Hi Tianran, We didn't invent any new protocol but to simply use UDP for the probing pac= kets in SRv6. What we want to avoid is SRH TLV in EH which can significantly increase the= EH overhead because the data needed to be carried may be too large. Also, since IOAM options have been well defined, it's unnecessary to augmen= t the other existing protocols to provide similar functionality. We just ne= ed a way to encapsulate them. Best, Haoyu From: Tianran Zhou > Sent: Wednesday, January 26, 2022 7:19 PM To: Greg Mirsky >; Haoy= u Song > Cc: spring@ietf.org; IETF IPPM WG > Subject: RE: [ippm] [spring] Active OAM in SRv6 Hi Haoyu, The application is really interesting and useful. I am not sure if it is necessary to create a new OAM protocol at transport = layer. IMHO, a per hop/per segment extension based on STAMP could be more practica= l. https://www.ietf.org/archive/id/draft-wang-ippm-stamp-hbh-extensions-03.txt= Best, Tianran From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Greg Mirsky Sent: Thursday, January 27, 2022 7:01 AM To: Haoyu Song > Cc: spring@ietf.org; IETF IPPM WG > Subject: Re: [ippm] [spring] Active OAM in SRv6 Hi Haoyu, thank you for bringing the topic of Active OAM to the discussion. As the co= ncept of Active IOAM is introduced in the IPPM WG draft it seems to me like ad= ding the IPPM WG community to the discussion is the right thing to do. Please find my notes in-lined below under the GIM>> tag. Regards, Greg On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song > wrote: Hi SPRING WG, Real time monitor on every node and every link on a network is necessary to= detect gray failures, which are the key culprit for poor QoS but hard to = catch. SR provides an ideal mechanism, when working with some efficient pla= nning algorithm, to achieve that with low cost. Our proposal SRv6 In-situ= Active Measurement (SIAM) suggests a simple active measurement approach w= hich can support different GIM>> I wonder what gaps you find in the existing active measurement protoc= ols, e.g., STAMP and RFC 6734 (would be more convenient to use an acronym).= It appears to me that, for example, STAMP and its extensions, including th= e SRPM draft, comprehensively address the PM OAM requirements for SRv6. options of IOAM and other OAM methods in SRv6, without needing to worry abo= ut the extension header issue. GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows: In terms of the classification given in [RFC7799] IOAM could be portrayed as Hybrid Type 1. Does your proposal change that? Your comments, questions, and suggestions are very welcome. I'd like to kno= w your opinion if you think this work is in scope and should be adopted by = the working group. If you are interested in contributing to this work, ple= ase also let me know. https://datatracker.ietf.org/doc/draft-song-spring-si= am/ Thank you very much! Best regards, Haoyu _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_BY3PR13MB47877877974620DE44EA08509A229BY3PR13MB4787namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

        Hi Tianran,

         

        The use case I target  is to generate probing = packets to collect node/link data on arbitrary path. We have algorithms to = generate such packets on a few path to cover the entire network (reference is given in the draft). If we periodically do such meas= urements, we can gain the visibility of the whole network and detect the gr= ay failures, which can have countless  useful applications.

         

        Why using UDP rather than EH TLV? here’s some= of my thoughts. First, I don’t need to do it in user packets, so ess= entially the payload is free to use.

        Second, there are a lot of discussions and debates = on the size/location of the IPv6 EHs, and there are so many proposals want = to use the EHs. I don’t want to add more complexity to it.

        Third, the proposal can be extended to support othe= r OAM schemes using the same method. Of course, you can also keep introduci= ng new TLV options to EH. But again, that’s the path I don’t want to go.

         

        Best,

        Haoyu

         

        From: Tianran Zhou <zhoutianran@h= uawei.com>
        Sent: Thursday, January 27, 2022 4:22 PM
        To: Haoyu Song <haoyu.song@futurewei.com>; Greg Mirsky <gre= gimirsky@gmail.com>
        Cc: spring@ietf.org; IETF IPPM WG <ippm@ietf.org>
        Subject: RE: [ippm] [spring] Active OAM in SRv6

         

        Hi Haoyu,

         

        I do not understand why the UDP encap= sulation is better than SRH TLV.

        IMO, IOAM is already too complex, som= e more work on TLV parsing is not critical.

        If you care about the data length = 220;because the data needed to be carried may be too large”, whatR= 17;s the limit on SRH TLV?

        What’s your use case, and your = requirement? Let’s evaluate it with numbers.

         

        Best,

        Tianran

         

        From: Haoyu Song [mailto:haoyu.song@futurewei.com]
        Sent: Friday, January 28, 2022 2:50 AM
        To: Tianran Zhou <zhout= ianran@huawei.com>; Greg Mirsky <gregimirsky@gmail.com>
        Cc: spring@ietf.org; IETF IPP= M WG <ippm@ietf.org>
        Subject: RE: [ippm] [spring] Active OAM in SRv6

         

        Hi Tianran,

         

        We didn’t invent any new protocol but to simp= ly use UDP for the probing packets in SRv6.

        What we want to avoid is SRH TLV in EH which can si= gnificantly increase the EH overhead because the data needed to be carried = may be too large.

        Also, since IOAM options have been well defined, it= ’s unnecessary to augment the other existing protocols to provide sim= ilar functionality. We just need a way to encapsulate them.

         

        Best,

        Haoyu

         

        From: Tianran Zhou <zhoutianran@huawei.com>
        Sent: Wednesday, January 26, 2022 7:19 PM
        To: Greg Mirsky <gregimi= rsky@gmail.com>; Haoyu Song <haoyu.song@futurewei.com>
        Cc: spring@ietf.org; IETF IPP= M WG <ippm@ietf.org>
        Subject: RE: [ippm] [spring] Active OAM in SRv6

         

        Hi Haoyu,

         

        The application is really interesting= and useful.

        I am not sure if it is necessary to c= reate a new OAM protocol at transport layer.

        IMHO, a per hop/per segment extension= based on STAMP could be more practical.

        https://= www.ietf.org/archive/id/draft-wang-ippm-stamp-hbh-extensions-03.txt

         

        Best,

        Tianran  

         

        From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Greg Mirsky
        Sent: Thursday, January 27, 2022 7:01 AM
        To: Haoyu Song <haoyu= .song@futurewei.com>
        Cc: spring@ietf.org; IETF IPP= M WG <ippm@ietf.org>
        Subject: Re: [ippm] [spring] Active OAM in SRv6

         

        Hi Haoyu,

        thank you for bringing the topic of Active OAM to th= e discussion. As the concept of Active IOAM is introduced in the IPPM WG draft it seems to me like adding the IPPM WG community to = the discussion is the right thing to do. 

        Please find my notes in-lined below under the GIM>= ;> tag.

         

        Regards,

        Greg

         

        On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song <haoyu.song@futurewei.com> wro= te:

        Hi SPRING WG,

         

        Real time monitor on every node and every link on a network is nec= essary to detect  gray failures, which are the key culprit for poor Qo= S but hard to catch. SR provides an ideal mechanism, when working with some efficient planning algorithm, to achieve= that with low cost.   Our proposal SRv6 In-situ Active Measureme= nt (SIAM) suggests a simple  active measurement approach which can sup= port different

        GIM>> I wonder what gaps you find in the exist= ing active measurement protocols, e.g., STAMP and RFC 6734 (would be more c= onvenient to use an acronym). It appears to me that, for example, STAMP and= its extensions, including the SRPM draft, comprehensively address the PM OAM requirements for SRv6.&n= bsp;

        options of IOAM and other OAM methods in SRv6, without needing to = worry about the extension header issue.  

        GIM>> draft-ietf-ippm-ioam-data classifies IOA= M as follows:

           In terms of the classification given

           in [RFC7799] IOAM could be portrayed as= Hybrid Type 1.

        Does your proposal change that?

         

        Your comments, questions, and suggestions are very welcome. I̵= 7;d like to know your opinion if you think this work is in scope and should= be adopted by the working group.  If you are interested in contributing to this work, please also let me know. https://datatracker.ietf.org/doc/draft-song-spring-siam/

         

        Thank you very much!

         

        Best regards,

        Haoyu

        _______________________________________________
        spring mailing list
        spring@ietf.org https://www.ietf.org/mailman/listinfo/spring

        --_000_BY3PR13MB47877877974620DE44EA08509A229BY3PR13MB4787namp_-- From nobody Thu Jan 27 18:17:40 2022 Return-Path: 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 4630A3A15EF; Thu, 27 Jan 2022 18:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.997 X-Spam-Level: X-Spam-Status: No, score=-6.997 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7Tc2b2JMcZP; Thu, 27 Jan 2022 18:17:33 -0800 (PST) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D6F03A1131; Thu, 27 Jan 2022 18:17:33 -0800 (PST) Received: by mail-ej1-x636.google.com with SMTP id jx6so11106868ejb.0; Thu, 27 Jan 2022 18:17:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0wADkS3zeJSCzW8wUSN7gUugbJtznxML1lznJaKjUyU=; b=MgV7Rhl7xyBYXEIV9ECQMgE6y9s2hDBRQUIOvFYJOdkSu6/ACBnla+y0Sm9Fomz5ZN xYtyCvSY7/KjwSR4ewpM+3jJEF8B2IBGFbdBffK8EHHwh7PrAhtL+gbqLuc9MZnABgO6 SNCzsRHArOH91NySgR6YmUrMR1WLy9CxV5aG4FTG0JLipADkar6rN+uaH58zl2ih2++i 7ExcBeDtj8aptNtXDJQFSEXi525gSSQ/uSL62xxW8Jd/TqFq9G1289VTCzLk17DydxhA RxDx3IqlkhbbucZ0uK+LgprW0PavivdBJMZ6Sgt0IyHcnjcSOt3jYQD7sZeDMjDcJMr5 Hz6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0wADkS3zeJSCzW8wUSN7gUugbJtznxML1lznJaKjUyU=; b=6MIcBf7MwGGAiDFBk67T04ltL6aPbYAWPLXAQ0YtO2OGK2Scr0QVDhf5NmxzZL9nGv zKJy0W8HJ8dAPSv0jg9nY8AFfNEyDJ29dW5zuVNe03A0ZP1z/HwSxRumAZ8nFfqZZ4ff /38zyOyVID+8aiHswypODGxnFmtQ4sfpwpeLd9ss9ge/uV5Tx1EkGLG3k1gCLxW1Dpel cjPeicL/S1crZLZo8HM9sB1pAs41e4NLAIIZ64kcN1hrxXhEs3wcK7dXQVMK+nTM7FaT jZdQ3kJxveBX+o7jIeWN5R03TRarMlUXLnZYUSkdl8EwGj7fdkFVRvMTmoiLU1ZgyeqH qI+Q== X-Gm-Message-State: AOAM5338VxsVR/5xb7AO5Kv9nfNlc6SJpP/bHzsbAZQeRnSSI+GC7OoB QiIDuLKn2zjnKR1Ke7I+YBYupxPutmpSQJwp0C85iGROhawQIA== X-Google-Smtp-Source: ABdhPJyPIWBypqC8LizGjyiXasondCFAXy9Ml2hP7tjJPD+fgj+uDF/E685iCF3swMsRjYtOKzvViG/quq3MPXo498w= X-Received: by 2002:a17:907:a428:: with SMTP id sg40mr5189221ejc.235.1643336250505; Thu, 27 Jan 2022 18:17:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Thu, 27 Jan 2022 18:17:19 -0800 Message-ID: To: Haoyu Song Cc: "spring@ietf.org" , IETF IPPM WG Content-Type: multipart/alternative; boundary="000000000000753b9105d69b0984" Archived-At: Subject: Re: [ippm] [spring] Active OAM in SRv6 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2022 02:17:38 -0000 --000000000000753b9105d69b0984 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Haoyu, now, without in-lining my notes. It appears that you propose not to use draft-ietf-ippm-ioam-ipv6-options . Thus, your proposal cannot be referred to as IOAM in SRv6. At best, it is IOAM-inspired, IOAMish. As a result, a node supporting standardized IOAM would not understand your probe packet without an SW upgrade. In my book, that's a new protocol. In closing, I'll reference two works by Ruediger Geib , where combining the defined techniques of steering test probes with standard IOAM might reveal a lot of useful information about a network: - RFC 8403 - draft-ietf-ippm-connectivity-monitoring Regards, Greg On Thu, Jan 27, 2022 at 5:44 PM Haoyu Song wrote= : > Hi Greg, please see Inline > > > > *From:* Greg Mirsky > *Sent:* Thursday, January 27, 2022 2:01 PM > *To:* Haoyu Song > *Cc:* spring@ietf.org; IETF IPPM WG > *Subject:* Re: [spring] Active OAM in SRv6 > > > > Hi Haoyu, > > thank you for your detailed reply. Please find my follow-up notes in-line= d > below under the GIM2>> tag. > > > > Regards, > > Greg > > > > On Thu, Jan 27, 2022 at 11:00 AM Haoyu Song > wrote: > > Hi Greg, > > > > Thank you for your questions. Please see inline response. > > > > Best, > > Haoyu > > > > *From:* Greg Mirsky > *Sent:* Wednesday, January 26, 2022 3:01 PM > *To:* Haoyu Song > *Cc:* spring@ietf.org; IETF IPPM WG > *Subject:* Re: [spring] Active OAM in SRv6 > > > > Hi Haoyu, > > thank you for bringing the topic of Active OAM to the discussion. As the > concept of Active IOAM is introduced in the IPPM WG draft > it > seems to me like adding the IPPM WG community to the discussion is the > right thing to do. > > Please find my notes in-lined below under the GIM>> tag. > > > > Regards, > > Greg > > > > On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song > wrote: > > Hi SPRING WG, > > > > Real time monitor on every node and every link on a network is necessary > to detect gray failures, which are the key culprit for poor QoS but hard > to catch. SR provides an ideal mechanism, when working with some efficien= t > planning algorithm, to achieve that with low cost. Our proposal SRv6 > In-situ Active Measurement (SIAM) suggests a simple active measurement > approach which can support different > > GIM>> I wonder what gaps you find in the existing active measurement > protocols, e.g., STAMP and RFC 6734 (would be more convenient to use an > acronym). It appears to me that, for example, STAMP and its extensions, > including the SRPM draft > , > comprehensively address the PM OAM requirements for SRv6. > > > > HS>> Let=E2=80=99s give a few features of our proposal: (1) it=E2=80=99s = session-less and > we don=E2=80=99t need assign any roles (e.g., reflector); (2) no needs f= or a > return path. The measurement can start and end at any node (solely > determined by the SRH); (3) udp-based which can support any existing IOAM > modes and potentially other OAM methods. > > GIM2>> I don't think adding a protocol that can generate a test probe fro= m > an arbitrary node to arbitrary targets (SRv6 supports multicast) is as > simple as you present. If an operator needs to monitor the performance of > the SR policy used by data packets, IOAM can be applied to data packets. = If > the operator wants to explore a policy that is not used for data traffic,= I > imagine IOAM can be added to a test packet of the existing OAM protocol, > e.g., ICMP. Am I missing some of the requirements? > > > > HS2>> For the first point: I don=E2=80=99t think a protocol is needed her= e. If one > wants to test the path a->b->c->d->e, he doesn=E2=80=99t need to find a u= ser packet > on that path to carry IOAM (there could be no such packet at all). Instea= d, > he can generate a probe packet with an SRH for the path and use the probe > packet to carry IOAM. At the path end, it simply extracts and exports the > IOAM data using the mechanism defined for IOAM and drops the probe packet= . > > For the second point: I don=E2=80=99t think ICMP can achieve what IOAM ca= n do. > IOAM is much more powerful in terms of the data it can collect. Moreover, > the proposal can be easily extended to support other kinds of OAM methods= . > One just carry it in UDP payload using different port. No need to worry > about the size if such info has to be carried in EH TLV. > > options of IOAM and other OAM methods in SRv6, without needing to worry > about the extension header issue. > > GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows: > > In terms of the classification given > > in [RFC7799] IOAM could be portrayed as Hybrid Type 1. > > Does your proposal change that? > > > > HS>> In this particular case, IOAM is used for active measurement because > it=E2=80=99s not included in a user packet. > > > > Your comments, questions, and suggestions are very welcome. I=E2=80=99d l= ike to > know your opinion if you think this work is in scope and should be adopte= d > by the working group. If you are interested in contributing to this work= , > please also let me know. > https://datatracker.ietf.org/doc/draft-song-spring-siam/ > > > > > Thank you very much! > > > > Best regards, > > Haoyu > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > --000000000000753b9105d69b0984 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
        Hi Haoy= u,
        now, without in-lining my notes.
        It appears that you propo= se not to use draft-ietf-ippm-ioam-ipv6-options. Thus, your propos= al cannot be referred to as IOAM in SRv6. At best, it is IOAM-inspired, IOA= Mish. As a result, a node supporting standardized IOAM would not understand= your probe packet without an SW upgrade. In my book, that's a new prot= ocol.
        In closing, I'll reference two works by=C2=A0Ruediger Geib, where combining the defined techniques of steering te= st probes with standard IOAM might reveal a lot of useful information about= a network:
        Regards,
        Greg

        On Thu, Jan 27, 2022 at 5:44 PM Haoyu Song <haoyu.song@futurewei.com> wrote= :

        Hi Greg, please see Inline

        =C2=A0

        From: Greg Mirsky <gregimirsky@gmail.com>
        Sent: Thursday, January 27, 2022 2:01 PM
        To: Haoyu Song <haoyu.song@futurewei.com>
        Cc: spring@ietf= .org; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [spring] Active OAM in SRv6

        =C2=A0

        Hi Haoyu,

        thank you for your detailed reply. Please find my fo= llow-up notes in-lined below under the GIM2>> tag.

        =C2=A0

        Regards,

        Greg

        =C2=A0

        On Thu, Jan 27, 2022 at 11:00 AM Haoyu Song <haoyu.song@future= wei.com> wrote:

        Hi Greg,

        =C2=A0

        Thank you for your questions. Please see inline resp= onse.

        =C2=A0

        Best,

        Haoyu

        =C2=A0

        From: Greg Mirsky <gregimirsky@gmail.com>
        Sent: Wednesday, January 26, 2022 3:01 PM
        To: Haoyu Song <haoyu.song@futurewei.com>
        Cc: spring@ietf= .org; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [spring] Active OAM in SRv6

        =C2=A0

        Hi Haoyu,

        thank you for bringing the topic of Active OAM to th= e discussion. As the concept of Active IOAM is introduced in the IPPM WG draft=C2=A0it seems to me like adding the IPPM WG community to = the discussion is the right thing to do.=C2=A0

        Please find my notes in-lined below under the GIM>= ;> tag.

        =C2=A0

        Regards,

        Greg

        =C2=A0

        On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song <haoyu.song@futurew= ei.com> wrote:

        Hi SPRING WG,

        =C2=A0

        Real time monitor on every node and every link on a = network is necessary to detect =C2=A0gray failures, which are the key culpr= it for poor QoS but hard to catch. SR provides an ideal mechanism, when working with some efficient planning algorithm, to achieve= that with low cost. =C2=A0=C2=A0Our proposal SRv6 In-situ Active Measureme= nt (SIAM) suggests a simple =C2=A0active measurement approach which can sup= port different

        GIM>> I wonder what gaps you find in the exist= ing active measurement protocols, e.g., STAMP and RFC 6734 (would be more c= onvenient to use an acronym). It appears to me that, for example, STAMP and its extensions, including the SRPM draft, comprehensively address the PM OAM requirements for SRv6.= =C2=A0

        =C2=A0

        HS>> Let=E2=80=99s give a few features of our = proposal: (1) it=E2=80=99s session-less and we don=E2=80=99t need assign an= y roles (e.g., =C2=A0reflector); (2) no needs for a return path. The measur= ement can start and end at any node (solely determined by the SRH); (3) udp-based wh= ich can support any existing IOAM modes and potentially other OAM methods.<= u>

        GIM2>> I don't think adding a protocol tha= t can generate a test probe from an arbitrary node to arbitrary targets (SR= v6 supports multicast) is as simple as you present. If an operator needs to= monitor the performance of the SR policy used by data packets, IOAM can be applied to data packets. If the operator want= s to explore a policy that is not used for data traffic, I imagine IOAM can= be added to a test packet of the existing OAM protocol, e.g., ICMP. Am I m= issing some of the requirements?

        =C2=A0

        HS2>> For the first point: I don=E2=80=99t thi= nk a protocol is needed here. If one wants to test the path a->b->c-&= gt;d->e, he doesn=E2=80=99t need to find a user packet on that path to c= arry IOAM (there could be no such packet at all). Instead, he can generate a probe packet with an SRH for the path and use the probe packet to carry = IOAM. At the path end, it simply extracts and exports the IOAM data using t= he mechanism defined for IOAM and drops the probe packet. =C2=A0<= /u>

        For the second point: I don=E2=80=99t think ICMP can= achieve what IOAM can do. IOAM is much more powerful in terms of the data = it can collect. Moreover, the proposal can be easily extended to support ot= her kinds of OAM methods. One just carry it in UDP payload using different port. No need to worry about the size if su= ch info has to be carried in EH TLV.

        options of IOAM and other OAM methods in SRv6, witho= ut needing to worry about the extension header issue. =C2=A0<= /p>

        GIM>> draft-ietf-ippm-ioam-data classifies IOA= M as follows:

        =C2=A0 =C2=A0In terms of the classification given=

        =C2=A0 =C2=A0in [RFC7799] IOAM could be portrayed as= Hybrid Type 1.

        Does your proposal change=C2=A0that?

        =C2=A0

        HS>> In this particular case, IOAM is used for= active measurement because it=E2=80=99s not included in a user packet.

        =C2=A0

        Your comments, questions, and suggestions are very w= elcome. I=E2=80=99d like to know your opinion if you think this work is in = scope and should be adopted by the working group.=C2=A0 If you are interested in contributing to this work, please also let me know. https://datatracker.ietf.org/doc/draft-song-spring-siam/<= /p>

        =C2=A0

        Thank you very much!

        =C2=A0

        Best regards,

        Haoyu

        _______________________________________________
        spring mailing list
        spring@ietf.org https://www.ietf.org/mailman/listinfo/spring<= /u>

        --000000000000753b9105d69b0984-- From nobody Fri Jan 28 00:51:22 2022 Return-Path: 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 37FDB3A247B for ; Fri, 28 Jan 2022 00:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.672 X-Spam-Level: X-Spam-Status: No, score=-2.672 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2qXTV90qqWi for ; Fri, 28 Jan 2022 00:51:12 -0800 (PST) Received: from mailout41.telekom.de (mailout41.telekom.de [194.25.225.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B0B03A2479 for ; Fri, 28 Jan 2022 00:51:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1643359871; x=1674895871; h=from:to:cc:subject:date:message-id:mime-version; bh=/VHyMigKX1/63j6BVivfod5ykxmK2qULrcBUAx5ohZs=; b=HRIJfsmCuC1u45sAF2OoY6n7CXASOBTjrmM7Vz+tp/bsSlC3gH319fZE X+MW7XmSfVPz5lLZwVB3ZxOTi/dBWam8pddYPtVYPJu0IQuP05oUtNa2I d/7paK8ljAGVb9qNmZvMbnZdlXr++8dnTaNd/FMhnBHnMeS2aADgxOigS BS+AvQdidqAMChiQW5zrZHNsmuwvsIHFBs6W6dEBIvmHpSRKh4r3Qb5Mj EJ9w90OEx7HMvb/Jr35PEttTqbDX+3/nNmW/o/B8v68Ry4RypNTiI0BbW vBcFBSzobKzXi9s8Y2yBJzSuRpWna9WCsZ7+ArMv6Y1AGuZROwCxuOe7w Q==; IronPort-SDR: rtIbaH0CMwcQH9uXYXzPIKM4jfRTnPUp/zA6TNR0eX4/QYmlCvG2xCK8RP7RCPA4ifacKQZQ5w utV8mVq06aqA== IronPort-Data: =?us-ascii?q?A9a23=3ApQ/+NKuaViK8FEbh1VM9p9T/9+fnVHJcMUV32?= =?us-ascii?q?f8akzHdYApBsoF/qtZmKT3UP/vYZGTxc40kPtm/80kH7MeAyodnG1NuqS83E?= =?us-ascii?q?i4apJueD7x1DKtQ0wB+jyH7ocoOA/w2MrEsF+hpCC+MzvuRGuK59yMkjPvYH?= =?us-ascii?q?uGU5NPsYUideyc1EU/Ntjozw4bVsqYw6TSIK1vlVeHa+qUzC3f5s9JACV/43?= =?us-ascii?q?orYwP9ZUFQejxtD1rA2TagjUFYzDBD5BrpHTU26ByOQroW5goeHq+j/ILGRp?= =?us-ascii?q?gs1/j8UJv70ooe9fkBMXvvTOxSDkHxfX+6phR0qSi4ai/59baVFLx0K13PSx?= =?us-ascii?q?bidy/0U3XC0YT00M6HNl+kHFTZVEitWIaBC9bzAJD6zvKR/ymWdKyK8m64zU?= =?us-ascii?q?inaOqVdoI6bG1pm9OQALRgMYwyNweWsz9qGpkNE7ig4BNDnMdIPqzdswHfFS?= =?us-ascii?q?PcgXZ3ZRazOo9Rf2V8Nagl1Na62T6IkhfBHNnwsuyFyB2o=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AxIEyGqjYC5THnvzgLWoT+lVMdXBQXuAji2?= =?us-ascii?q?hC6mlwRA09TyX+rayTdZUguiMc7Qx7ZJhOo7690cW7IE80l6QFgrX5TI3DYO?= =?us-ascii?q?COggLBRuxfBODZsl/d8kPFh4lg/JYlX69iCMDhSXhW5PyKhjVQyuxQpeVvJp?= =?us-ascii?q?rY4dvj8w=3D=3D?= Received: from qde9xy.de.t-internal.com ([10.171.254.32]) by mailout41.dmznet.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 28 Jan 2022 09:51:08 +0100 IronPort-SDR: nZabAc++bYCEXwavKnx5a5KZr2gA5W2GxyerWwbruTdBbcrduQ10cjPf/aeEkA3k0Lb+gcRn2t 8/iedeGCkSvRdackAJlMfRO7w8xgCIO4M= X-IronPort-AV: E=Sophos;i="5.88,323,1635199200"; d="scan'208,217";a="450710621" X-MGA-submission: =?us-ascii?q?MDE8P4DJ8xJpm6YIqIsHXH0M7NEVsjVQLcMINT?= =?us-ascii?q?ADtHBL0y0XlPebX4nvOhMPmfAxiSIeM8gZbplPROsCRvosiY2EsLvIUS?= =?us-ascii?q?3NPdmDax566+FS35G9TPWkB6Cfn0LsvuPaTHrpfVXvWQ6Wxaj4IutNvB?= =?us-ascii?q?YFgQKwOj0yivee9rM0Kh/FDw=3D=3D?= Received: from he199743.emea1.cds.t-internal.com ([10.169.119.51]) by QDE9Y1.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-SHA256; 28 Jan 2022 09:51:09 +0100 Received: from HE199743.EMEA1.cds.t-internal.com (10.169.119.51) by HE199743.emea1.cds.t-internal.com (10.169.119.51) with Microsoft SMTP Server (TLS) id 15.0.1497.28; Fri, 28 Jan 2022 09:51:07 +0100 Received: from HE104162.emea1.cds.t-internal.com (10.171.40.37) by HE199743.EMEA1.cds.t-internal.com (10.169.119.51) with Microsoft SMTP Server (TLS) id 15.0.1497.28 via Frontend Transport; Fri, 28 Jan 2022 09:51:07 +0100 Received: from DEU01-FR2-obe.outbound.protection.outlook.com (104.47.11.171) by O365mail04.telekom.de (172.30.0.231) with Microsoft SMTP Server (TLS) id 15.0.1497.28; Fri, 28 Jan 2022 09:51:08 +0100 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Kro24U567uAfIeB8dl4xBYaGNpvx4BzZYEV/xZRAsbCCSvOh4EUxzX5Zxq6r8u+BQ/HsmseSptfKpFtQOyJp4sDc8EpK3XbxFoedRbN+ZmsN4P3Jap1S56giRvbzieTSWKMhw3knsMfbLsL5COUkZ3NSgMZqluQUGafkCKJQQqRPnHLsDmqfEcvRrqg3dKfxm+fCTV7tzfwl8e0nSjUgtFOUBBObIl6i29QlGuNPX5pzKukSD6xMHTHJvA7LPMA/UvcfLfvaN49NUuJLq5MeNZhSxhyuQ8PePWUeN3Y27AIV9UDqbz9mXfC/8Aq+dZohFuHZbtzWcXl9tAO6gSwK5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/VHyMigKX1/63j6BVivfod5ykxmK2qULrcBUAx5ohZs=; b=eZGpye0wmpl6/24y+wEFRFH4ZTv6s239IcGzUPCSOCp4PZwlTsnFHslXSrP0Kv4nqJPWIq/sAITHUuy5SL/PEgSMeq1T88/w6Kojoo2+VEMC5xSsQVmLFU2lxutjPjPc0Y7SZ8xCurB1I616CySmcFW0FehbI/xUnGrky5hdQf2moyRZoD/AISVOyoM9LYtv7sv875iZRbaOYKqcagkLUHHVXQeeXfzYxobO2NcpuKtaIYufH3z8t5HPtfXzN0GjUG8apeJlDGbTUepkas0p16a7yQgiDtrjAqNnJKkesb4IXYeTOPmpslGB8B2SpX/L/53a5NXVNAWeh1C8VvVwOA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:2c::12) by BE1P281MB1604.DEUP281.PROD.OUTLOOK.COM (2603:10a6:b10:1b::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.5; Fri, 28 Jan 2022 08:51:05 +0000 Received: from FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM ([fe80::b811:77c:d23c:7437]) by FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM ([fe80::b811:77c:d23c:7437%5]) with mapi id 15.20.4951.006; Fri, 28 Jan 2022 08:51:05 +0000 From: To: CC: Thread-Topic: Re: [ippm] draft-morton-ippm-capacity-metric-protocol Thread-Index: AdgUHhuHrIQIhUOsSdWaY99B1Bg0dw== Date: Fri, 28 Jan 2022 08:51:05 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=telekom.de; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b7d6b2f0-9cde-4521-45ab-08d9e23b5209 x-ms-traffictypediagnostic: BE1P281MB1604:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: tobqqLZKjiiS9Rrys5/r0/QdpIJ2KbAAIM1satR1vTh+UNbIj3qBTMdutawizHOiUtnClRaPTYqrZ0Lr0AAHp/Satq7ryeQr6jYaGcuuTrN5KCrbulxulUZj3fe0DJy2mql0S0lrAHLLxALiZt54Dy6ZPOSO9OYLohJLfb0pl4o01gsJwfDB22YUhV4i8Y8MIHto0EDraHi2FY7ZLcqEeUogHimJZcX3A97aTzV6ZeJwVyEHUeQmCGJGBIKtvWQr+DCCsjvZA0AFEkDUrBEm0d3P3VEBCixf62wJffvVRSqezXKOnV+HTdgI/y6pd9o8Xc+wLGvCBVF9mUK/R9vV7JHQqgQ020IM7M8nrgqNtXRxd7FkKfH6j9Ye8QtSMVdTSBFPplgdytjFliJIol9+d0ABIjheQTYmwiRZoitEQxlCmPD8FDHsoR5r3P0nGDx93gRi6T1iw8Su6c9Y6yP0mPtwlq5REAAQY1GfvvtCQJUh+4BPRZe47ETftbIj9Z0Je6L0JxpZXuZxvTO25lPNuSmlnTfqgZg2lklX88MJ1YsF9OcwSsFT7wHqlwQYnBgL6+wgaUue8BFYvVFKIQvvGsdluqUuXBGXRgRF1+chSY1E9+s4WOoQKW6Ekl0snHYCqTtC5nUzYp9/ZTJa302g6okF7U0+D35b8hLNXip0mgV+3dB31Z2MBmXNGaJxBO1/47abztjBl/4SOG2LYViZi93M8YVHU0Zvox0XFQM+cXI91pMh50sfDPS0+4WH97CGYtMnwBLS4xPTHZ4C98QvdmMlm59Ec+P041UXQnstkts= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(122000001)(82960400001)(316002)(2906002)(66574015)(83380400001)(38100700002)(5660300002)(30864003)(9326002)(52536014)(64756008)(86362001)(6916009)(166002)(4326008)(966005)(186003)(26005)(76116006)(8676002)(8936002)(508600001)(38070700005)(66446008)(66556008)(9686003)(6506007)(7696005)(66476007)(66946007)(53546011)(55016003)(71200400001)(33656002)(20210929001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?5TjbfWYQ7pC5Ys9N5/MEZU0l6Em0yZpmQ9EThj1Ee3pATegBuEFs1XSz08?= =?iso-8859-1?Q?YGGGbs42FnInybP62fEp598I0gu0S5u0ghhDd7Y0ub3/yh8KKKBNVoF/VG?= =?iso-8859-1?Q?+B5BoPz/02UyhPjP8ZAeJi/BM8sZhPtoAChznWk1hgXK+UuXz+388MhJcF?= =?iso-8859-1?Q?2CoJ1RC5yl6KAbfh4Mccoff1MIv7DV22IVv4SmP5JejhcvAbEB2roxcfCM?= =?iso-8859-1?Q?ksceUu2caJQ5AjQMszC/D/4JiFYQnjv3lhSZOcIG8QiyPMb0rULHBgRUiD?= =?iso-8859-1?Q?ybccQGYJ2FTT0AlxSoGgmcItSANAZfspJKLo30y4vkPZ/h3Ps4Joxf+cqn?= =?iso-8859-1?Q?kW3J2dgHANzqiokHzH8vzdxfoBnjBGEz87+h94tMTTSKNylsuko5Rz/yNE?= =?iso-8859-1?Q?PjRL30LEhh+n8zRuRXK2X05KqKrkMNp4ZpMZ6FZKjStVEcQlrON+ERJ3Xi?= =?iso-8859-1?Q?Zz/HTas8Sa7sHKA9kqNxMOo5+1IzthFOrs+uR06mLVojqlJOkxPch+0Gvg?= =?iso-8859-1?Q?dTviEgcYER6CpdTNz6mte7Odt28OhQry610EYrb5XzQZVQ7ZKqdZvP+XvM?= =?iso-8859-1?Q?TsuJ5ne6/JJMDTt2svGWaaoihsginAYR3jQVdZ6RZaVGZEjO/EV61rUwfR?= =?iso-8859-1?Q?5wPNObbR3N2MIa7hjpxHeZMUeBoLMgE7DBwVAwR16SNZaRj9YKLy6Cl0/p?= =?iso-8859-1?Q?v/ugsPoCU1XkJMeCZZb/9dneHjRvo3eX1h3NKk8bxdyYsqDERGAUptlJt0?= =?iso-8859-1?Q?OT6XdTkMgGXTZ8z7D9Yqp+Pb8a09lOGLPpl0giWNtmshMjzSQVNlPPIRIc?= =?iso-8859-1?Q?wv0zqktzym0QDO76VP3HaSJNFksePZ8ojCiCdVg1n8FBLpMdo+xqVT4Zhs?= =?iso-8859-1?Q?g5y6zWxe1YT5EEbDxp0AVh2Fbtp4i4plD56ju2LeU0VqIq/tVQ0LU9FC5F?= =?iso-8859-1?Q?XjWTnH153SMF1IckZxuSCV07NoAl4k+Hs2dFhJr1Aufd+IiQpxrASjcgrG?= =?iso-8859-1?Q?Yx6TyfB6AS+i1N5fYmKPNapprfeQA7oEIC3oYGB6tdvX40h703bLnrSGAN?= =?iso-8859-1?Q?2JQaMgAmZ9pm4rZgndob20ewf6rG0LLJZJJbVXRBfk5zU3Qws6REF83e/P?= =?iso-8859-1?Q?GNLs4gbb+mWIQIshyn9o2aMS5X+zM6YfZI+qp5X25pGQ2S2LRhD8NtBS9K?= =?iso-8859-1?Q?TdcfaaiAMB7rzPcWd99yTBtqp0dooyYGQ5KJHiAnMi4Yx4pI7L+rRMKr/X?= =?iso-8859-1?Q?lgfJkhrf8pcjumKbCqGqBPGzNTNWmF8A5YOKl+m0g6FM+v7LG4ug12oI6l?= =?iso-8859-1?Q?s3tqRJFeapuBRWCB9yW1eNow0Me10SZ5Z/PpG2rJKC7dDPSSDOgnplo52A?= =?iso-8859-1?Q?qaLrELX3xVhiX3j8XNg+f8wLfpuWAlgwDBuO/V6UUr+r4FYY7Dd0/VpyLm?= =?iso-8859-1?Q?JpLEhvOzlVDJ/HEaAUrPEpTcJzJwG40Z6TD1MQCSuiSHxU8ErBWVhdQbI8?= =?iso-8859-1?Q?LtAphvu9plOORFCf6vLg7LYW03SrCDM0F5m8cO/V5Ul5Abm9rBRNZY8YeT?= =?iso-8859-1?Q?lSjL7OTyQ47Q88A8pmjUUWSwiVhhBJACVYEnr2r4bWBjxFajLdNj/Futsx?= =?iso-8859-1?Q?nxYrSBa1JBGMRVd+P4276XXHqOHcq6TgN62tmH8Led08ZJrrYukP2uVRHd?= =?iso-8859-1?Q?5FrbMHztHfI67M5XKF5XwyRois/SkrFfj7K62VK+jnXCrvrOIP8REI2iWj?= =?iso-8859-1?Q?PAAA=3D=3D?= Content-Type: multipart/alternative; boundary="_000_FR2P281MB06118B01D6536BEE41D7A6749C229FR2P281MB0611DEUP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: b7d6b2f0-9cde-4521-45ab-08d9e23b5209 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2022 08:51:05.6298 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9L/NxRw6D4BYo8h7xrhpPOxFjBiR20+MDt0eVNsrGp0gEsca0tMA4lJJmUgeth+FQ3snIN8fcrBBurthk7eZxtIn//nO6E9GF5z+Tw/PWGs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BE1P281MB1604 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [ippm] draft-morton-ippm-capacity-metric-protocol X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2022 08:51:20 -0000 --_000_FR2P281MB06118B01D6536BEE41D7A6749C229FR2P281MB0611DEUP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Al, Thanks for clarifications, I agree to your proposals. Yes, if a test running for 10 sec at line-speed can reliably only be invoke= d willingly by the party having to cope with the congested link, then an em= ergency-stop likely isn't required. Regards, Ruediger ################## Hi R=FCdiger, Thanks again for your comments! We discussed some of them at our coding project meeting today. Please see [acm] for replies. All proposals below are implemented in the working text. Al ############ Some comments: Section 3. Protocol Overview The client requires configuration of a test direction parameter (upstream or downstream test) as well as the hostname or IP address of the server in order to begin the setup and configuration exchanges with the server. RG: The draft also mentions a sender and a receiver. Both, client and serve= r may act as sender and receiver. This depends on the test direction, upstream or downstream. Words to that appear in "9. Method of Measurement", at the end of the doc. [acm] OK. Let's try this for the paragraph above: The client requires configuration of a test direction parameter (upstream or downstream test, where the client performs the role of ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ sender or receiver, respectively) as well as the hostname or IP address ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ of the server in order to begin the setup and configuration exchanges with the server. 4. Stopping the Test: The server initiates the phase to stop the test by setting the STOP1 indication in load PDUs or sstatus feedback messages. ( ^^^^) RG: Would it be worth a thought to enable the client to terminate a test? [acm] This sentence in section 3 might benefit from some clarification. I added: 4. Stopping the Test: When the specified test duration has been reached, th= e server ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ initiates the phase to stop the test by setting the STOP1 indication in = load PDUs or status feedback messages. The client acknowledges by setting the= STOP2 in load PDUs or status feedback messages. ... IOW, neither the server nor the client can stop a test prematurely in norma= l operation. Note that the protocol overlays the STOP indication on existing measurement and feedback traffic. It's very simple to implement. Alternatively, a client (or server) can stop sending traffic (load PDUs or status feedback messages, depending on its role). An activity timer will expire at the opposite end, and both client and server will close the connection. The timer value can be set to expire as quickly as needed (some may be sensitive to the amount of load PDUs sent after a test appears to fail). ########## 5. Setup Request and Response Exchange The message format isn't "TLV". Is the protocol extensible (e.g. could secu= rity be adapted to future needs)? [acm] All the message formats/PDUs are extensible. A specific set of formats matc= h a protocol version number (currently 8 in the draft you reviewed). Our goal is to make version 9 and higher backward-compatible. We should be able to add fields to the PDUs and leave earlier parts untouched... ########## 6.2. Test Activation Request - server response .....The remaining 28 octets of the Test Activation Request (normally read RG: A bit worrying, seems to be set by the sender in the reply to a request= only. See editorials... [acm] Here's the full context: If the client has requested an upstream test, the server SHALL include the transmission parameters from the first row of the sending rate table= . The remaining 28 octets of the Test Activation Request (normally read from the first row of the sending rate table) are called the Sending Rate Structure, and SHALL be organized as follows: ... So, the Test Activation Response (the new name for section 6.2) uses the Sending Rate Structure to communicate a starting send rate for the test, IF the client is the sender, as in an upstream test. Perhaps we can clarify: If the client has requested an upstream test, the server SHALL include the transmission parameters from the first row of the sending rate table in the Sending Rate Structure (defined below). ########## 7.1. Test Packet PDU and Roles .... On the other hand, the test configuration MAY use a fixed sending rate requested by the client, RG: contains descriptive text about the method (e.g. decision on the sending rate). The text there certainly is correct. I wonder, whether a reference replacing the text would be sufficient? [acm] Actually, I don't see anything except protocol details near the OTOH sentence above. We can add a second clarifying sentence in the paragraph below: The client MAY communicate the desired fixed rate in its activation request. The reasons to conduct a fixed-rate test include stable measure= ment at the maximum determined by the load adjustment (search) algorithm, or the desire to test at a known subscribed rate without searching. RG: Does the MAY here introduce a new method? If it does, would that requi= re to update the RFC specifying the method? [acm] I don't think an update is necessary. We mentioned this possibility immediately, in RFC 9097 Section 2: * If a network operator is certain of the IP-Layer Capacity to be validated, then testing MAY start with a fixed-rate test at the IP-Layer Capacity and avoid activating the load adjustment algorithm. ########### 10. Security Considerations RG: would a receiver (client and host) require an "Emergency Stop" message? [acm] When would the client or server send this message? As mentioned above, either end can initiate a premature stop, and timer expiration takes care of the test termination at the opposite end. RG: If yes, should it require authentication in order to avoid an attacker from unwanted test termination? [acm] No "Emergency Stop" message, no attack. ######### RG: Would a three-way-handshake make sense to activate testing? (noting that the sender in that case also must be protected against opening of unbounded numbers of tests). A three way handshake protects against forged test set up messages. [acm] The combination of Test Setup and Test Activation define a 4-way handshake. RG: What else could be forged? [acm] everything in the current version, except the Authentication string. RG: Do these require authentication or at least a discussion? Response message feedback (indicating ramp-up/no drop where there's con= gestion or the other way around, congestion where there is none). Stop messages (unwanted termination) Could a host or a client be tricked into persistently acting as a sende= r? [acm] Yes, of course! We want to supply sufficient AUTH and integrity options whe= n needed. That's partly why we petitioned for WG Adoption, to get an early S= EC-DIR review or two. However: I have begin to think that we only need 4 security modes of operation: 1. Unauthenticated (in the protocol now) 2. Password-protected test setup (in the protocol now) 3. Encrypted Test Setup exchanges 4. Run the protocol inside an encrypted tunnel #4 will have performance implications for high capacity measurements on small hosts (in residences, GWs, WLAN devices, etc.) FYI - a client cannot be tricked into persistently acting as a sender. The command that starts the client process determines this role. ######## Editorials [acm] Thanks for these! I'll get to them in a second pass... From: ippm On= Behalf Of Ruediger.Geib@telekom.de Sent: Tuesday, December 7, 2021 3:01 AM To: marcus.ihlar=3D40ericsson.com@dmarc.ietf.org Cc: ippm@ietf.org Subject: Re: [ippm] draft-morton-ippm-capacity-metric-protocol Hi Marcus, I support adoption. Regards, Ruediger Some comments: Section 3. Protocol Overview The client requires configuration of a test direction parameter (upstream or downstream test) as well as the hostname or IP address of the server in order to begin the setup and configuration exchanges with the server. RG: The draft also mentions a sender and a receiver. Both, client and serve= r may act as sender and receiver. This depends on the test direction, upstream or downstream. Words to that appear in "9. Method of Measurement", at the end of the doc. 4. Stopping the Test: The server initiates the phase to stop the test by setting the STOP1 indication in load PDUs or sstatus feedback messages. = ( ^^^^) RG: Would it be worth a thought to enable the client to terminate a test? ########## 5. Setup Request and Response Exchange The message format isn't "TLV". Is the protocol extensible (e.g. could secu= rity be adapted to future needs)? ########## 6.2. Test Activation Request - server response .....The remaining 28 octets of the Test Activation Request (normally read RG: A bit worrying, seems to be set by the sender in the reply to a request= only. See editorials... ########## 7.1. Test Packet PDU and Roles .... On the other hand, the test configuration MAY use a fixed sending rate requested by the client, RG: contains descriptive text about the method (e.g. decision on the sendin= g rate). The text there certainly is correct. I wonder, whether a reference replacing the tex= t would be sufficient? RG: Does the MAY here introduce a new method? If it does, would that requi= re to update the RFC specifying the method? ########### 10. Security Considerations RG: would a receiver (client and host) require an "Emergency Stop" message?= If yes, should it require authentication in order to avoid an attacker fro= m unwanted test termination? Would a three-way-handshake make sense to activate testing? (noting that th= e sender in that case also must be protected against opening of unbounded n= umbers of tests). A three way handshake protects against forged test set up= messages. What else could be forged? Do these require authentication or at least a di= scussion? * Response message feedback (indicating ramp-up/no drop where there's c= ongestion or the other way around, congestion where there is none). * Stop messages (unwanted termination) * Could a host or a client be tricked into persistently acting as a sen= der? ######## Editorials 6.2. Test Activation Request - server response ... When the server sends the Test Activation response back, it SHALL set the cmd Response field to: RG: Server Test Activation Reply (or Response - please apply stringently th= rough the text) When the server responds by a Test Activation Reply, it... ---- The server SHALL include all the test parameters again to make the client aware of any changes. RG: The server SHALL repeat all test parameters to indicate changes to the = client. ---- 8. Stopping the Test When the test duration timer on the server expires, it SHALL set the connection test action to STOP and also starts marking all outgoing load or status PDUs with a test action of STOP1. RG: ...and mark all outgoing load... ---- 10. Security Considerations A. Unathenticated mode (for all phases) Unauthenticated ^^^^ Von: ippm ippm-bounces@ietf.org> Im Auftrag von Marcus Ihlar Gesendet: Montag, 6. Dezember 2021 16:53 An: ippm@ietf.org> Betreff: [ippm] draft-morton-ippm-capacity-metric-protocol Hi IPPM, This email starts an adoption call for draft-morton-ippm-capacity-metric-pr= otocol, " Test Protocol for One-way IP Capacity Measurement". This documen= t is intended for Standards Track and defines a protocol for measuring Netw= ork Capacity metrics defined in RFC 9097 (https://datatracker.ietf.org/doc/= rfc9097/<= https://datatracker.ietf.org/doc/rfc9097/%3Chttps:/urldefense.com/v3/__http= s:/datatracker.ietf.org/doc/rfc9097/__;!!BhdT!0XFagPVddMPqLtUl1ej6zNK69Ogn2= sgujZ23jLU92MHMnHJnppFGox6tI3-r$%3E>)$>). https://datatracker.ietf.org/doc/draft-morton-ippm-capacity-metric-protocol= / https://datatracker.ietf.org/doc/html/draft-morton-ippm-capacity-metric-pro= tocol-02 This adoption call will last until Monday, December 20. Please review the d= ocument, and reply to this email thread to indicate if you think IPPM shoul= d adopt this document. BR, Marcus --_000_FR2P281MB06118B01D6536BEE41D7A6749C229FR2P281MB0611DEUP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 
        Hi Al,
         
        Thanks for clarifications, I agree to your proposals.
         
        Yes, if a test running for 10 sec at line-speed can reliably only be i=
nvoked willingly by the party having to cope with the congested link, then =
an emergency-stop likely isn’t required. 
         
        Regards,
         
        Ruediger
         
         
         
         
        ##################
         
        Hi R=FCdiger, Thanks again for your comments!
         
        We discussed some of them at our coding project meeting today.
        Please see [acm] for replies.
         
        All proposals below are implemented in the working text.

         
        

        Al
        

         
        

        ############
        

         
        

        Some comments:
        

         
        

        Section  3.  Protocol Overview
        

         
        

           The client requires configuration of a test direction par=
ameter
        

           (upstream or downstream test) as well as the hostname or =
IP address
        

           of the server in order to begin the setup and configurati=
on exchanges
        

           with the server.
        

         
        

        RG: The draft also mentions a sender and a receiver. Both, client and =
server
        

        may act as sender and receiver. This depends on the test direction,
        

        upstream or downstream.
        

         
        

        Words to that appear in "9.  Method of Measurement", at=
 the end of the doc.
        

         
        

        [acm]
        

        OK. Let's try this for the paragraph above:
        

         
        

        The client requires configuration of a test direction parameter
        

        (upstream or downstream test, where the client performs the role of
        

                   &nbs=
p;            &=
nbsp;     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        

        sender or receiver, respectively) as well as the hostname or IP addres=
s
        

        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        

        of the server in order to begin the setup and configuration exchanges<=
o:p>
        

        with the server.
        

         
        

         
        

        4.  Stopping the Test: The server initiates the phase to stop the=

        

               test by setting the STOP1 indicat=
ion in load PDUs or sstatus
        

               feedback messages.  &nb=
sp;            =
            &nb=
sp;      ( ^^^^)
        

         
        

        RG: Would it be worth a thought to enable the client to terminate a te=
st?
        

         
        

        [acm]
        

        This sentence in section 3 might benefit from some clarification. I ad=
ded:
        

         
        

        4. Stopping the Test: When the specified test duration has been reache=
d, the server
        

                   &nbs=
p;          ^^^^^^^^^^^^^^^^^^=
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        

           initiates the phase to stop the test by setting the STOP1=
 indication in load
        

           PDUs or status feedback messages. The client acknowledges=
 by setting the STOP2
        

           in load PDUs or status feedback messages. ...<=
/pre>

         
        

        IOW, neither the server nor the client can stop a test prematurely in =
normal
        

        operation. Note that the protocol overlays the STOP indication on exis=
ting
        

        measurement and feedback traffic. It's very simple to implement.<=
/o:p>
        

         
        

        Alternatively, a client (or server) can stop sending traffic
        

        (load PDUs or status feedback messages, depending on its role).
        

        An activity timer will expire at the opposite end, and both=

        

        client and server will close the connection. The timer value
        

        can be set to expire as quickly as needed (some may be sensitive<=
/o:p>
        

        to the amount of load PDUs sent after a test appears to fail).
        

         
        

         
        

        ##########
        

         
        

         
        

        5.  Setup Request and Response Exchange
        

         
        

         
        

        The message format isn't "TLV". Is the protocol extensible (=
e.g. could security be adapted to future needs)?
        

         
        

        [acm]
        

        All the message formats/PDUs are extensible. A specific set of formats=
 match a
        

        protocol version number (currently 8 in the draft you reviewed).<=
/o:p>
        

        Our goal is to make version 9 and higher backward-compatible.
        

        We should be able to add fields to the PDUs and leave earlier parts
        

        untouched...
        

         
        

         
        

        ##########
        

         
        

        6.2.  Test Activation Request - server response
        

         
        

        .....The remaining 28 octets of the Test Activation Request (normally =
read
        

         
        

        RG: A bit worrying, seems to be set by the sender in the reply to a re=
quest only. See editorials...
        

         
        

        [acm]
        

        Here's the full context:
        

           If the client has requested an upstream test, the server =
SHALL include
        

           the transmission parameters from the first row of the sen=
ding rate table.
        

         
        

           The remaining 28 octets of the Test Activation Request (n=
ormally read
        

           from the first row of the sending rate table) are called =
the
        

           Sending Rate Structure, and SHALL be organized as follows=
:
        

        ...
        

         
        

        So, the Test Activation Response (the new name for section 6.2)
        

        uses the Sending Rate Structure to communicate a starting send rate
        

        for the test, IF the client is the sender, as in an upstream test.
        

         
        

        Perhaps we can clarify:
        

           If the client has requested an upstream test, the server =
SHALL include
        

           the transmission parameters from the first row of the sen=
ding rate table
        

           in the Sending Rate Structure (defined below).=

        

         
        

         
        

        ##########
        

         
        

         
        

        7.1.  Test Packet PDU and Roles
        

         
        

        .... On the other hand, the test configuration MAY use a fixed sending=

        

           rate requested by the client,
        

         
        

        RG: contains descriptive text about the method (e.g. decision on the
        

        sending rate). The text there certainly is correct. I wonder, whether<=
o:p>
        

        a reference replacing the text would be sufficient?
        

         
        

        [acm]
        

        Actually, I don't see anything except protocol details near the OTOH
        

        sentence above.
        

         
        

        We can add a second clarifying sentence in the paragraph below:
        

           The client MAY communicate the desired fixed rate in its =
activation
        

           request. The reasons to conduct a fixed-rate test include=
 stable measurement
        

           at the maximum determined by the load adjustment (search)=
 algorithm,
        

           or the desire to test at a known subscribed rate without =
searching.
        

         
        

         
        

        RG:  Does the MAY here introduce a new method? If it does, would =
that require
        

        to update the RFC specifying the method?
        

         
        

        [acm]
        

        I don't think an update is necessary. We mentioned this possibility
        

        immediately, in RFC 9097 Section 2:
        

         
        

           *  If a network operator is certain of the IP-Layer =
Capacity to be
        

              validated, then testing MAY start with =
a fixed-rate test at the
        

              IP-Layer Capacity and avoid activating =
the load adjustment
        

              algorithm.
        

         
        

        ###########
        

         
        

        10.  Security Considerations
        

         
        

         
        

        RG: would a receiver (client and host) require an "Emergency Stop=
" message?
        

         
        

        [acm]
        

        When would the client or server send this message?
        

         
        

        As mentioned above, either end can initiate a premature stop, and time=
r
        

        expiration takes care of the test termination at the opposite end.
        

         
        

        RG: If yes, should it require authentication in order to avoid an atta=
cker
        

        from unwanted test termination?
        

         
        

        [acm]
        

        No "Emergency Stop" message, no attack.
        

         
        

        #########
        

         
        

         
        

        RG: Would a three-way-handshake make sense to activate testing?
        

        (noting that the sender in that case also must be protected against
        

        opening of unbounded numbers of tests). A three way handshake protects=

        

        against forged test set up messages.
        

         
        

        [acm]
        

        The combination of Test Setup and Test Activation define a 4-way hands=
hake.
        

         
        

         
        

        RG: What else could be forged?
        

        [acm] everything in the current version, except the Authentication str=
ing.
        

         
        

         
        

        RG: Do these require authentication or at least a discussion?
        

         
        

            Response message feedback (indicating ramp-up/no dr=
op where there's congestion or the other way around, congestion where there=
 is none).
        

            Stop messages (unwanted termination)

            Could a host or a client be tricked into persistent=
ly acting as a sender?
        

         
        

        [acm]
        

        Yes, of course! We want to supply sufficient AUTH and integrity option=
s when
        

        needed.  That's partly why we petitioned for WG Adoption, to get =
an early SEC-DIR
        

        review or two.
        

         
        

        However:
        

         
        

        I have begin to think that we only need 4 security modes of operation:=

        

        1. Unauthenticated (in the protocol now)
        

        2. Password-protected test setup (in the protocol now)

        3. Encrypted Test Setup exchanges
        

        4. Run the protocol inside an encrypted tunnel
        

         
        

        #4 will have performance implications for high capacity measurements
        

        on small hosts (in residences, GWs, WLAN devices, etc.)

         
        

        FYI -  a client cannot be tricked into persistently acting as a s=
ender.
        

        The command that starts the client process determines this role.<=
/o:p>
        

         
        

         
        

        ########
        

         
        

         
        

        Editorials
        

         
        

        [acm]
        

        Thanks for these!  I'll get to them in a second pass...
        

         
        

        From: ippm &l=
t;ippm-bounces@ietf.org> On Behalf Of Ruediger.Geib@telekom.de
        

        Sent: Tuesday, December 7, 2021 3:01 AM
        

        To: ma=
rcus.ihlar=3D40ericsson.com@dmarc.ietf.org
        

        Cc: ippm@ietf.org

        Subject: Re: [ippm] draft-morton-ippm-capacity-metric-protocol
        

         
        

        Hi Marcus,
        

         
        

        I support adoption.
        

         
        

        Regards, Ruediger
        

         
        

         
        

        Some comments:
        

         
        

        Section  3.  Protocol Overview
        

         
        

           The client requires configuration of a test direction par=
ameter
        

           (upstream or downstream test) as well as the hostname or =
IP address
        

           of the server in order to begin the setup and configurati=
on exchanges
        

           with the server.
        

         
        

        RG: The draft also mentions a sender and a receiver. Both, client and =
server
        

        may act as sender and receiver. This depends on the test direction,
        

        upstream or downstream.
        

        Words to that appear in "9.  Method of Measurement", at=
 the end of the doc.
        

         
        

         
        

        4.  Stopping the Test: The server initiates the phase to stop the=

        

               test by setting the STOP1 indicat=
ion in load PDUs or sstatus
        

               feedback messages.  &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp; ( ^^^^)
        

         
        

        RG: Would it be worth a thought to enable the client to terminate a te=
st?
        

         
        

        ##########
        

         
        

        5.  Setup Request and Response Exchange
        

         
        

        The message format isn't "TLV". Is the protocol extensible (=
e.g. could security be adapted to future needs)?
        

         
        

        ##########
        

         
        

        6.2.  Test Activation Request - server response
        

         
        

        .....The remaining 28 octets of the Test Activation Request (normally =
read
        

         
        

        RG: A bit worrying, seems to be set by the sender in the reply to a re=
quest only. See editorials...
        

         
        

        ##########
        

         
        

        7.1.  Test Packet PDU and Roles
        

         
        

        .... On the other hand, the test configuration MAY use a fixed sending=

        

           rate requested by the client,
        

         
        

        RG: contains descriptive text about the method (e.g. decision on the s=
ending rate). The text
        

        there certainly is correct. I wonder, whether a reference replacing th=
e text would be sufficient?
        

         
        

        RG:  Does the MAY here introduce a new method? If it does, would =
that require to update the
        

        RFC specifying the method?
        

         
        

        ###########
        

         
        

        10.  Security Considerations
        

         
        

        RG: would a receiver (client and host) require an "Emergency Stop=
" message? If yes, should it require authentication in order to avoid =
an attacker from unwanted test termination?
        

         
        

        Would a three-way-handshake make sense to activate testing? (noting th=
at the sender in that case also must be protected against opening of unboun=
ded numbers of tests). A three way handshake protects against forged test s=
et up messages.
        

         
        

        What else could be forged? Do these require authentication or at least=
 a discussion?
        

         
        

          *   Response message feedback (indicating ramp-up/no =
drop where there's congestion or the other way around, congestion where the=
re is none).
        

          *   Stop messages (unwanted termination)

          *   Could a host or a client be tricked into persiste=
ntly acting as a sender?
        

        ########
        

         
        

         
        

        Editorials
        

         
        

        6.2.  Test Activation Request - server response
        

         
        

        ...   When the server sends the Test Activation response bac=
k, it SHALL set
        

           the cmd Response field to:
        

         
        

        RG: Server Test Activation Reply (or Response - please apply stringent=
ly through the text)
        

        When the server responds by a Test Activation Reply, it...<=
/pre>

         
        

        ----
        

         
        

           The server SHALL include all the test parameters again to=
 make the
        

           client aware of any changes.
        

         
        

        RG: The server SHALL repeat all test parameters to indicate changes to=
 the client.
        

         
        

        ----
        

         
        

        8.  Stopping the Test
        

         
        

           When the test duration timer on the server expires, it SH=
ALL set the
        

           connection test action to STOP and also starts marking al=
l outgoing
        

           load or status PDUs with a test action of STOP1.
        

         
        

        RG: ...and mark all outgoing load...
        

         
        

        ----
        

         
        

        10.  Security Considerations
        

         
        

        A. Unathenticated mode (for all phases)
        

         
        

        Unauthenticated
        

            ^^^^
        

         
        

        Von: ippm ippm-bounces@ietf.or=
g<mailto:ippm-bounces@ietf.org> Im Auftr=
ag von Marcus Ihlar
        

        Gesendet: Montag, 6. Dezember 2021 16:53<=
/span>
        

        An: ippm@ietf.org<mailto:ippm@ietf.org>
        

        Betreff: [ippm] draft-morton-ippm-capacity-metric-protocol<=
/pre>

         
        

        Hi IPPM,
        

         
        

        This email starts an adoption call for draft-morton-ippm-capacity-metr=
ic-protocol, " Test Protocol for One-way IP Capacity Measurement"=
.  This document is intended for Standards Track and defines a protoco=
l for measuring Network Capacity metrics defined in RFC 9097 (https://datatracker.ietf.org/doc/rfc9097=
/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/rfc9097/__=
;!!BhdT!0XFagPVddMPqLtUl1ej6zNK69Ogn2sgujZ23jLU92MHMnHJnppFGox6tI3-r$>)$>).
        

         
        

        https://datatracker.ietf.or=
g/doc/draft-morton-ippm-capacity-metric-protocol/<https://urldefense.com=
/v3/__https:/datatracker.ietf.org/doc/draft-morton-ippm-capacity-metric-pro=
tocol/__;!!BhdT!0XFagPVddMPqLtUl1ej6zNK69Ogn2sgujZ23jLU92MHMnHJnppFGoww_Z_I=
Z$>
        

        https://datat=
racker.ietf.org/doc/html/draft-morton-ippm-capacity-metric-protocol-02<h=
ttps://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-morto=
n-ippm-capacity-metric-protocol-02__;!!BhdT!0XFagPVddMPqLtUl1ej6zNK69Ogn2sg=
ujZ23jLU92MHMnHJnppFGo-rAHSKU$>
        

         
        

        This adoption call will last until Monday, December 20. Please review =
the document, and reply to this email thread to indicate if you think IPPM =
should adopt this document.
        

         
        

        BR,
        

        Marcus
        

         
        

         
        --_000_FR2P281MB06118B01D6536BEE41D7A6749C229FR2P281MB0611DEUP_-- From nobody Fri Jan 28 03:03:56 2022 Return-Path: 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 983CE3A0B9A for ; Fri, 28 Jan 2022 03:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vF6uxmSGVxEf for ; Fri, 28 Jan 2022 03:03:35 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B338B3A0B8B for ; Fri, 28 Jan 2022 03:03:33 -0800 (PST) Received: from fraeml715-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JlZG10Wv8z686pS; Fri, 28 Jan 2022 18:59:05 +0800 (CST) Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml715-chm.china.huawei.com (10.206.15.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Fri, 28 Jan 2022 12:03:30 +0100 Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.2308.021; Fri, 28 Jan 2022 12:03:29 +0100 From: Giuseppe Fioccola To: Tianran Zhou , "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt Thread-Index: AQHYEOoOM8BWGUje9EistfVjjUvI2qxxspuggAaJ0xA= Date: Fri, 28 Jan 2022 11:03:29 +0000 Message-ID: <698f9da1d04143688c36c6be1a895f19@huawei.com> References: <164300504281.12619.16642699818590435984@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.48.216.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2022 11:03:51 -0000 Hi Tianran, All, I think that this is a useful work. For LAG, the use of active methods (OWAMP, TWAMP, STAMP) can also complemen= t passive and hybrid methods. Indeed, the extensions proposed in this draft= allow to monitor all the links and not only the link crossed by the observ= ed packet stream. Maybe, you can also highlight this point in the introduction section. Minor nits: s/Reflector Member Link ID fields/Reflector Member Link ID field/ s/When sending a response to the received Test packet, the micro TWAMP Sess= ion-Sender/ When sending a response to the received Test packet, the micro = TWAMP Session- Reflector/ Regards, Giuseppe -----Original Message----- From: ippm On Behalf Of Tianran Zhou Sent: Monday, January 24, 2022 7:23 AM To: IETF IPPM WG (ippm@ietf.org) Subject: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-la= g-02.txt Hi WG, We think this is an useful work on adapting OWAMP/TWAMP in LAG performance = measurement. We updated this draft based on the comments from the meeting discussion and= mailing list. Thanks for all the suggestions. More reviews and comments are welcome. Cheers, Tianran -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Monday, January 24, 2022 2:17 PM To: Greg Mirsky ; Guo Jun ; Jun= Guo ; Rakesh Gandhi ; Tianran Zhou= ; Zhenqiang Li Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt A new version of I-D, draft-li-ippm-otwamp-on-lag-02.txt has been successfully submitted by Tianran Zhou and posted to the IETF repo= sitory. Name: draft-li-ippm-otwamp-on-lag Revision: 02 Title: One-way/Two-way Active Measurement Protocol Extensions for Performa= nce Measurement on LAG Document date: 2022-01-24 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/archive/id/draft-li-ippm-otwamp-on-lag= -02.txt Status: https://datatracker.ietf.org/doc/draft-li-ippm-otwamp-on-la= g/ Htmlized: https://datatracker.ietf.org/doc/html/draft-li-ippm-otwamp-= on-lag Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-li-ippm-otwamp-on= -lag-02 Abstract: This document defines extensions to One-way Active Measurement Protocol (OWAMP), and Two-way Active Measurement Protocol (TWAMP) to implement performance measurement on every member link of a Link Aggregation Group (LAG). Knowing the measured metrics of each member link of a LAG enables operators to enforce the performance based traffic steering policy across the member links. = =20 The IETF Secretariat _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From nobody Fri Jan 28 03:15:01 2022 Return-Path: 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 81C913A0C4E for ; Fri, 28 Jan 2022 03:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.897 X-Spam-Level: X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1zFsxSDXllW for ; Fri, 28 Jan 2022 03:14:55 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B83EE3A0C4F for ; Fri, 28 Jan 2022 03:14:54 -0800 (PST) Received: from fraeml742-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JlZbj2DgMz67x0l for ; Fri, 28 Jan 2022 19:14:25 +0800 (CST) Received: from kwepeml100004.china.huawei.com (7.221.188.19) by fraeml742-chm.china.huawei.com (10.206.15.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Fri, 28 Jan 2022 12:14:51 +0100 Received: from kwepeml500004.china.huawei.com (7.221.188.141) by kwepeml100004.china.huawei.com (7.221.188.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Fri, 28 Jan 2022 19:14:49 +0800 Received: from kwepeml500004.china.huawei.com ([7.221.188.141]) by kwepeml500004.china.huawei.com ([7.221.188.141]) with mapi id 15.01.2308.021; Fri, 28 Jan 2022 19:14:49 +0800 From: Tianran Zhou To: Giuseppe Fioccola , Tianran Zhou , "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt Thread-Index: AQHYEOoOM8BWGUje9EistfVjjUvI2qxxspuggAaJ0xCAABG/IA== Date: Fri, 28 Jan 2022 11:14:49 +0000 Message-ID: References: <164300504281.12619.16642699818590435984@ietfa.amsl.com> <698f9da1d04143688c36c6be1a895f19@huawei.com> In-Reply-To: <698f9da1d04143688c36c6be1a895f19@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.112.40.195] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2022 11:15:00 -0000 Hi Giuseppe, Thanks very much for your review. I will incorporate your suggestions in the next revision. Cheers, Tianran -----Original Message----- From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Giuseppe Fioccola Sent: Friday, January 28, 2022 7:03 PM To: Tianran Zhou ; IETF IPPM WG = (ippm@ietf.org) Subject: Re: [ippm] New Version Notification for draft-li-ippm-otwamp-on-la= g-02.txt Hi Tianran, All, I think that this is a useful work. For LAG, the use of active methods (OWAMP, TWAMP, STAMP) can also complemen= t passive and hybrid methods. Indeed, the extensions proposed in this draft= allow to monitor all the links and not only the link crossed by the observ= ed packet stream. Maybe, you can also highlight this point in the introduction section. Minor nits: s/Reflector Member Link ID fields/Reflector Member Link ID field/ s/When sending a response to the received Test packet, the micro TWAMP Sess= ion-Sender/ When sending a response to the received Test packet, the micro = TWAMP Session- Reflector/ Regards, Giuseppe -----Original Message----- From: ippm On Behalf Of Tianran Zhou Sent: Monday, January 24, 2022 7:23 AM To: IETF IPPM WG (ippm@ietf.org) Subject: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-la= g-02.txt Hi WG, We think this is an useful work on adapting OWAMP/TWAMP in LAG performance = measurement. We updated this draft based on the comments from the meeting discussion and= mailing list. Thanks for all the suggestions. More reviews and comments are welcome. Cheers, Tianran -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Monday, January 24, 2022 2:17 PM To: Greg Mirsky ; Guo Jun ; Jun= Guo ; Rakesh Gandhi ; Tianran Zhou= ; Zhenqiang Li Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt A new version of I-D, draft-li-ippm-otwamp-on-lag-02.txt has been successfully submitted by Tianran Zhou and posted to the IETF repo= sitory. Name: draft-li-ippm-otwamp-on-lag Revision: 02 Title: One-way/Two-way Active Measurement Protocol Extensions for Performa= nce Measurement on LAG Document date: 2022-01-24 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/archive/id/draft-li-ippm-otwamp-on-lag= -02.txt Status: https://datatracker.ietf.org/doc/draft-li-ippm-otwamp-on-la= g/ Htmlized: https://datatracker.ietf.org/doc/html/draft-li-ippm-otwamp-= on-lag Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-li-ippm-otwamp-on= -lag-02 Abstract: This document defines extensions to One-way Active Measurement Protocol (OWAMP), and Two-way Active Measurement Protocol (TWAMP) to implement performance measurement on every member link of a Link Aggregation Group (LAG). Knowing the measured metrics of each member link of a LAG enables operators to enforce the performance based traffic steering policy across the member links. = =20 The IETF Secretariat _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From nobody Fri Jan 28 03:57:23 2022 Return-Path: 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 487993A0E60 for ; Fri, 28 Jan 2022 03:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=accedian.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-DJIZirq7ir for ; Fri, 28 Jan 2022 03:57:11 -0800 (PST) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBFF73A0E59 for ; Fri, 28 Jan 2022 03:57:10 -0800 (PST) Received: by mail-yb1-xb2d.google.com with SMTP id j2so4492615ybu.0 for ; Fri, 28 Jan 2022 03:57:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=accedian.com; s=corp1; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0ekaGrEOgkWl5A8ARkIxmHuJRvcezYbOJbfctTH5bn8=; b=EFeVnGlxH640JUGGAc1HPqPe7f5VvstiB1HkiAp82bXkUyOxJsRBVgT5qcuSo/nCiH zx4QoeduXgMiGdpl35qDBZXnOpC/J8FEVfkPoVoxcP0EJWFAgTCOyDZjC4i6+GeT04pB 5UYgify/QZExipB+IVM5Jdo6G48xr4IiBuEkpzEOJtuFwcB0Oj7HVpmE0p72iFOXEzcu 226nwSgclTTQc5abwtwvVy6W847Ee5q4uNzGJka4mgSLA1qoXWTTjqsrLHGLYthX1/G/ mFlhvEKgL8J1MGoywo2Ny6UKSWJBIqKo6u2GQziNrNckEP/SCRxII6YPbxC4GKSHm/fB mW3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0ekaGrEOgkWl5A8ARkIxmHuJRvcezYbOJbfctTH5bn8=; b=TMOc4D1IZvytfDKZHR++Pt+14Wc2Tiansv4hbZVJdq5nT+lNSfryO6wVdDtbohVUjc Ia5nASniR6HCOfL/H7YUO7X+GQ5a7wkzgyGKtpYLtjQ3vVEk2B1egP3kajNoruPy0JfB k9RAwtbmgNmnMtX8KxRY+hYljEdGKxbBhRau8U9F45PjOPIVDopw/xrD+nwMXEcDMlRP Xg/jjb1YvfYLcqlo4yw7PDdDkLzptNT6cT8CNLdl4K9p+QGKzc9XvhRc58oP2nJ0AMTH y9krDplXCIKwpvIQrevNBidHI6D1Uh4/pgfjl5ZeCYWCWSfZGvhzRC8WefBvfw8UPy8A ADAw== X-Gm-Message-State: AOAM530MvunBJVvmTgc+7cYAaWXVXy0IVMgvR4Ri930ai9zMF/samNPN r7xN2ZMSzdpXPyGFqBeT98lPnFgTLGpigSgq2lMSyJN0fIHcy/OtPUgwVJgloEKMJ9mzdEjmjIk ffhimuUVwjEMTxqg= X-Google-Smtp-Source: ABdhPJw7uhIXgjWBsZNx56VPavF6U/KkKa5rc6mGAE9dReHEGtXihhsReJPHCJcMbkcHjqsUwmNia8Y7LtXbd+Dx1rI= X-Received: by 2002:a25:b706:: with SMTP id t6mr12126238ybj.206.1643371028940; Fri, 28 Jan 2022 03:57:08 -0800 (PST) MIME-Version: 1.0 References: <164300504281.12619.16642699818590435984@ietfa.amsl.com> <698f9da1d04143688c36c6be1a895f19@huawei.com> In-Reply-To: From: Henrik Nydell Date: Fri, 28 Jan 2022 12:56:51 +0100 Message-ID: To: Tianran Zhou Cc: Giuseppe Fioccola , "IETF IPPM WG (ippm@ietf.org)" Content-Type: multipart/alternative; boundary="0000000000006a249d05d6a32206" Archived-At: Subject: Re: [ippm] New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2022 11:57:18 -0000 --0000000000006a249d05d6a32206 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I still think it would be much better to generalize this micro TWAMP concept and not tie this to LAG, since that will be implementation specific - only if you implement TWAMP directly on a LAG-device this draft would apply. Better then to generalize the concept and call the added identifier "Substream ID" or something similar. Then this draft would also apply to for example a vendor that implements routing over different paths or as Tianran pointed out, MPLS-SR uses. Thus I would propose removing all references to LAG in this draft and widen the scope to any situation where there would be uses for labelled (ID:ed) substreams between the same TWAMP-sender and session-reflector. On Fri, Jan 28, 2022 at 12:15 PM Tianran Zhou wrote: > Hi Giuseppe, > > Thanks very much for your review. > I will incorporate your suggestions in the next revision. > > Cheers, > Tianran > > -----Original Message----- > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Giuseppe Fioccola > Sent: Friday, January 28, 2022 7:03 PM > To: Tianran Zhou ; IETF IPPM W= G ( > ippm@ietf.org) > Subject: Re: [ippm] New Version Notification for > draft-li-ippm-otwamp-on-lag-02.txt > > Hi Tianran, All, > I think that this is a useful work. > For LAG, the use of active methods (OWAMP, TWAMP, STAMP) can also > complement passive and hybrid methods. Indeed, the extensions proposed in > this draft allow to monitor all the links and not only the link crossed b= y > the observed packet stream. > Maybe, you can also highlight this point in the introduction section. > > Minor nits: > s/Reflector Member Link ID fields/Reflector Member Link ID field/ > > s/When sending a response to the received Test packet, the micro TWAMP > Session-Sender/ When sending a response to the received Test packet, the > micro TWAMP Session- Reflector/ > > > Regards, > > Giuseppe > > > -----Original Message----- > From: ippm On Behalf Of Tianran Zhou > Sent: Monday, January 24, 2022 7:23 AM > To: IETF IPPM WG (ippm@ietf.org) > Subject: [ippm] FW: New Version Notification for > draft-li-ippm-otwamp-on-lag-02.txt > > Hi WG, > > We think this is an useful work on adapting OWAMP/TWAMP in LAG performanc= e > measurement. > We updated this draft based on the comments from the meeting discussion > and mailing list. > Thanks for all the suggestions. > More reviews and comments are welcome. > > Cheers, > Tianran > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, January 24, 2022 2:17 PM > To: Greg Mirsky ; Guo Jun ; > Jun Guo ; Rakesh Gandhi ; Tianran > Zhou ; Zhenqiang Li > Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt > > > A new version of I-D, draft-li-ippm-otwamp-on-lag-02.txt > has been successfully submitted by Tianran Zhou and posted to the IETF > repository. > > Name: draft-li-ippm-otwamp-on-lag > Revision: 02 > Title: One-way/Two-way Active Measurement Protocol Extensions fo= r > Performance Measurement on LAG > Document date: 2022-01-24 > Group: Individual Submission > Pages: 13 > URL: > https://www.ietf.org/archive/id/draft-li-ippm-otwamp-on-lag-02.txt > Status: > https://datatracker.ietf.org/doc/draft-li-ippm-otwamp-on-lag/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-li-ippm-otwamp-on-lag > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-li-ippm-otwamp-on-lag-02 > > Abstract: > This document defines extensions to One-way Active Measurement > Protocol (OWAMP), and Two-way Active Measurement Protocol (TWAMP) to > implement performance measurement on every member link of a Link > Aggregation Group (LAG). Knowing the measured metrics of each member > link of a LAG enables operators to enforce the performance based > traffic steering policy across the member links. > > > > > > The IETF Secretariat > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --=20 *Henrik Nydell* *Sr Product Manager* 1.866.685.8181 hnydell@accedian.com *accedian.com * --=20 Avis de confidentialit=C3=A9 Les informations contenues dans le pr=C3=A9sent=20 message et dans toute pi=C3=A8ce qui=20 lui est jointe sont confidentielles et=20 peuvent =C3=AAtre prot=C3=A9g=C3=A9es par le=20 secret professionnel. Ces informations sont=20 =C3=A0 l=E2=80=99usage exclusif de son ou de ses destinataires. Si vous recevez ce=20 message par erreur, veuillez=20 s=E2=80=99il vous plait communiquer imm=C3=A9diatement=20 avec l=E2=80=99exp=C3=A9diteur et en=20 d=C3=A9truire tout exemplaire. De plus, il vous est=20 strictement interdit de=20 le divulguer, de le distribuer ou de le reproduire=20 sans l=E2=80=99autorisation=20 de l=E2=80=99exp=C3=A9diteur. Merci. Confidentiality notice This e-mail message and any attachment hereto contain confidential=20 information=20 which may be privileged and which is intended for the=20 exclusive use of its=20 addressee(s). If you receive this message in error, please inform sender=20 immediately and destroy any copy thereof.=20 Furthermore, any disclosure,=20 distribution or copying of this message=20 and/or any attachment hereto=20 without the consent of the sender is=20 strictly prohibited. Thank you. --0000000000006a249d05d6a32206 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
        I s= till think it would be much better to generalize this micro TWAMP concept a= nd not tie this to LAG, since that will be implementation specific - only i= f you implement TWAMP directly on a LAG-device this draft would apply.
        Better then to gene= ralize the concept and call the added identifier "Substream ID" o= r something similar. Then this draft would also apply to for example a vend= or that implements routing over different paths or as Tianran pointed out, = MPLS-SR uses. Thus I would propose removing all references to LAG in this d= raft and widen the scope to any situation where there would be uses for lab= elled=C2=A0(ID:ed) substreams between the same TWAMP-sender and session-ref= lector.

        =C2=A0

        On Fr= i, Jan 28, 2022 at 12:15 PM Tianran Zhou <zhoutianran=3D40huawei.com@dmarc.ietf.org> wrote:
        Hi Giuseppe,

        Thanks very much for your review.
        I will incorporate your suggestions in the next revision.

        Cheers,
        Tianran

        -----Original Message-----
        From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Giuseppe Fioccola
        Sent: Friday, January 28, 2022 7:03 PM
        To: Tianran Zhou <zhoutianran=3D40huawei.com@dmarc.ietf.org>; IETF IPPM WG = (ippm@ietf.org) <= ippm@ietf.org> Subject: Re: [ippm] New Version Notification for draft-li-ippm-otwamp-on-la= g-02.txt

        Hi Tianran, All,
        I think that this is a useful work.
        For LAG, the use of active methods (OWAMP, TWAMP, STAMP) can also complemen= t passive and hybrid methods. Indeed, the extensions proposed in this draft= allow to monitor all the links and not only the link crossed by the observ= ed packet stream.
        Maybe, you can also highlight this point in the introduction section.

        Minor nits:
        s/Reflector Member Link ID fields/Reflector Member Link ID field/

        s/When sending a response to the received Test packet, the micro TWAMP Sess= ion-Sender/ When sending a response to the received Test packet, the micro = TWAMP Session- Reflector/


        Regards,

        Giuseppe


        -----Original Message-----
        From: ippm <i= ppm-bounces@ietf.org> On Behalf Of Tianran Zhou
        Sent: Monday, January 24, 2022 7:23 AM
        To: IETF IPPM WG (ippm@i= etf.org) <ippm@ie= tf.org>
        Subject: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-la= g-02.txt

        Hi WG,

        We think this is an useful work on adapting OWAMP/TWAMP in LAG performance = measurement.
        We updated this draft based on the comments from the meeting discussion and= mailing list.
        Thanks for all the suggestions.
        More reviews and comments are welcome.

        Cheers,
        Tianran

        -----Original Message-----
        From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
        Sent: Monday, January 24, 2022 2:17 PM
        To: Greg Mirsky <gregimirsky@gmail.com>; Guo Jun <guo.jun2@zte.com.cn>; Jun Guo <guo.jun2@zte.com.cn= >; Rakesh Gandhi <rgandhi@cisco.com>; Tianran Zhou <zhoutianran@huawei.com>; Zhenqiang = Li <li_zhe= nqiang@hotmail.com>
        Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

        A new version of I-D, draft-li-ippm-otwamp-on-lag-02.txt
        has been successfully submitted by Tianran Zhou and posted to the IETF repo= sitory.

        Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-li-ippm-otwamp-on-lag Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
        Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 One-way/Two-way Active Measurement= Protocol Extensions for Performance Measurement on LAG
        Document date:=C2=A0 2022-01-24
        Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
        Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 13
        URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/archive/id/draft-li-ippm-otwamp-on-lag-02.= txt
        Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-li-ippm-otwamp-on-lag/
        Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-li-ippm-otwamp-on-lag
        Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-li-ippm-otwamp-on-lag= -02

        Abstract:
        =C2=A0 =C2=A0This document defines extensions to One-way Active Measurement=
        =C2=A0 =C2=A0Protocol (OWAMP), and Two-way Active Measurement Protocol (TWA= MP) to
        =C2=A0 =C2=A0implement performance measurement on every member link of a Li= nk
        =C2=A0 =C2=A0Aggregation Group (LAG).=C2=A0 Knowing the measured metrics of= each member
        =C2=A0 =C2=A0link of a LAG enables operators to enforce the performance bas= ed
        =C2=A0 =C2=A0traffic steering policy across the member links.





        The IETF Secretariat


        _______________________________________________
        ippm mailing list
        ippm@ietf.org
        https://www.ietf.org/mailman/listinfo/ippm

        _______________________________________________
        ippm mailing list
        ippm@ietf.org
        https://www.ietf.org/mailman/listinfo/ippm

        _______________________________________________
        ippm mailing list
        ippm@ietf.org
        https://www.ietf.org/mailman/listinfo/ippm


        --

        Henrik Nydell
        Sr Product Manager
        1.866.685.8181
        hnydell@accedian.= com
        3D""
        =3D""=C2=A03D""=C2=A03D""
        3D""
        accedian.com=

        Avis de confidentialit=C3=A9

        Les informations contenues dans le pr=C3=A9sent message et dans toute pi=C3=A8= ce qui=20 lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9e= s par le=20 secret professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif= de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez=20 s=E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp= =C3=A9diteur et en=20 d=C3=A9truire tout exemplaire. De plus, il vous est strictement interdit de= =20 le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisat= ion=20 de l=E2=80=99exp=C3=A9diteur. Merci.

        Confidentiality notice

        This e-mail message and any attachment hereto contain confidential=20 information which may be privileged and which is intended for the=20 exclusive use of its addressee(s). If you receive this message in error, please inform sender immediately and destroy any copy thereof.=20 Furthermore, any disclosure, distribution or copying of this message=20 and/or any attachment hereto without the consent of the sender is=20 strictly prohibited. Thank you.

        --0000000000006a249d05d6a32206-- From nobody Fri Jan 28 05:09:00 2022 Return-Path: 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 7FD713A12C8 for ; Fri, 28 Jan 2022 05:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOU4tga9xqjx for ; Fri, 28 Jan 2022 05:08:53 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6183E3A12C5 for ; Fri, 28 Jan 2022 05:08:53 -0800 (PST) Received: from fraeml714-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Jld3c3tBQz67ySD; Fri, 28 Jan 2022 21:05:16 +0800 (CST) Received: from kwepeml500004.china.huawei.com (7.221.188.141) by fraeml714-chm.china.huawei.com (10.206.15.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Fri, 28 Jan 2022 14:08:49 +0100 Received: from kwepeml500004.china.huawei.com ([7.221.188.141]) by kwepeml500004.china.huawei.com ([7.221.188.141]) with mapi id 15.01.2308.021; Fri, 28 Jan 2022 21:08:48 +0800 From: Tianran Zhou To: Henrik Nydell CC: Giuseppe Fioccola , "IETF IPPM WG (ippm" Thread-Topic: [ippm] New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt Thread-Index: AQHYEOoOM8BWGUje9EistfVjjUvI2qxxspuggAaJ0xCAABG/IP//hiiAgACaNv0= Date: Fri, 28 Jan 2022 13:08:47 +0000 Message-ID: <9b14ec8b237f4a448d7c70eb6473326c@huawei.com> References: <164300504281.12619.16642699818590435984@ietfa.amsl.com> <698f9da1d04143688c36c6be1a895f19@huawei.com> , In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_9b14ec8b237f4a448d7c70eb6473326chuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2022 13:08:59 -0000 --_000_9b14ec8b237f4a448d7c70eb6473326chuaweicom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgSGVucmlrLA0KDQpUaGFua3MgZm9yIHlvdXIgaW50ZXJlc3QuDQpUaGlzIGRyYWZ0IGlzIG5v dCBhaW1pbmcgZm9yIGEgYmlnIGFtYml0aW9uLCBidXQgdG8gc29sdmUgYSBzcGVjaWZpYyByZXF1 aXJlbWVudCBmcm9tIGV4aXN0aW5nIG5ldHdvcmsgb3BlcmF0aW9ucy4gV2l0aG91dCB3ZWxsIHRo b3VnaHQgYW5kIGRlc2lnbiwgSSBhbSBub3Qgc3VyZSBpZiB3ZSBjYW4gc2ltcGx5IHJlbW92ZSB0 aGUgTEFHIGFzc3VtcHRpb24uDQoNCkhvdyBhYm91dCB3ZSB3b3JrIHRvZ2V0aGVyIG9uIGEgbmV3 IGRyYWZ0IHRvIGdlbmVyYWxpemUgdGhpcyBmb3IgdGhlIG1vcmUgY29tbW9uIHVzZT8gQW5kIGhl bmNlIHRoZSB0d28gd29yayBjYW4gY29tcGxlbWVudC4NCg0KQmVzdCwNClRpYW5yYW4NCg0KDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KU2VudCBmcm9tIFdlTGluaw0K t6K8/sjLo7ogSGVucmlrIE55ZGVsbDxobnlkZWxsQGFjY2VkaWFuLmNvbTxtYWlsdG86aG55ZGVs bEBhY2NlZGlhbi5jb20+Pg0KytW8/sjLo7ogVGlhbnJhbiBaaG91PHpob3V0aWFucmFuQGh1YXdl aS5jb208bWFpbHRvOnpob3V0aWFucmFuQGh1YXdlaS5jb20+Pg0Ks63LzaO6IEdpdXNlcHBlIEZp b2Njb2xhPGdpdXNlcHBlLmZpb2Njb2xhQGh1YXdlaS5jb208bWFpbHRvOmdpdXNlcHBlLmZpb2Nj b2xhQGh1YXdlaS5jb20+PjtJRVRGIElQUE0gV0cgKGlwcG08aXBwbUBpZXRmLm9yZzxtYWlsdG86 aXBwbUBpZXRmLm9yZz4+DQrW98zio7ogUmU6IFtpcHBtXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWxpLWlwcG0tb3R3YW1wLW9uLWxhZy0wMi50eHQNCsqxvOSjuiAyMDIyLTAx LTI4IDE5OjU3OjI4DQoNCkkgc3RpbGwgdGhpbmsgaXQgd291bGQgYmUgbXVjaCBiZXR0ZXIgdG8g Z2VuZXJhbGl6ZSB0aGlzIG1pY3JvIFRXQU1QIGNvbmNlcHQgYW5kIG5vdCB0aWUgdGhpcyB0byBM QUcsIHNpbmNlIHRoYXQgd2lsbCBiZSBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYyAtIG9ubHkgaWYg eW91IGltcGxlbWVudCBUV0FNUCBkaXJlY3RseSBvbiBhIExBRy1kZXZpY2UgdGhpcyBkcmFmdCB3 b3VsZCBhcHBseS4NCkJldHRlciB0aGVuIHRvIGdlbmVyYWxpemUgdGhlIGNvbmNlcHQgYW5kIGNh bGwgdGhlIGFkZGVkIGlkZW50aWZpZXIgIlN1YnN0cmVhbSBJRCIgb3Igc29tZXRoaW5nIHNpbWls YXIuIFRoZW4gdGhpcyBkcmFmdCB3b3VsZCBhbHNvIGFwcGx5IHRvIGZvciBleGFtcGxlIGEgdmVu ZG9yIHRoYXQgaW1wbGVtZW50cyByb3V0aW5nIG92ZXIgZGlmZmVyZW50IHBhdGhzIG9yIGFzIFRp YW5yYW4gcG9pbnRlZCBvdXQsIE1QTFMtU1IgdXNlcy4gVGh1cyBJIHdvdWxkIHByb3Bvc2UgcmVt b3ZpbmcgYWxsIHJlZmVyZW5jZXMgdG8gTEFHIGluIHRoaXMgZHJhZnQgYW5kIHdpZGVuIHRoZSBz Y29wZSB0byBhbnkgc2l0dWF0aW9uIHdoZXJlIHRoZXJlIHdvdWxkIGJlIHVzZXMgZm9yIGxhYmVs bGVkIChJRDplZCkgc3Vic3RyZWFtcyBiZXR3ZWVuIHRoZSBzYW1lIFRXQU1QLXNlbmRlciBhbmQg c2Vzc2lvbi1yZWZsZWN0b3IuDQoNCg0KDQpPbiBGcmksIEphbiAyOCwgMjAyMiBhdCAxMjoxNSBQ TSBUaWFucmFuIFpob3UgPHpob3V0aWFucmFuPTQwaHVhd2VpLmNvbUBkbWFyYy5pZXRmLm9yZzxt YWlsdG86NDBodWF3ZWkuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQpIaSBHaXVzZXBwZSwN Cg0KVGhhbmtzIHZlcnkgbXVjaCBmb3IgeW91ciByZXZpZXcuDQpJIHdpbGwgaW5jb3Jwb3JhdGUg eW91ciBzdWdnZXN0aW9ucyBpbiB0aGUgbmV4dCByZXZpc2lvbi4NCg0KQ2hlZXJzLA0KVGlhbnJh bg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaXBwbSBbbWFpbHRvOmlwcG0t Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86aXBwbS1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxm IE9mIEdpdXNlcHBlIEZpb2Njb2xhDQpTZW50OiBGcmlkYXksIEphbnVhcnkgMjgsIDIwMjIgNzow MyBQTQ0KVG86IFRpYW5yYW4gWmhvdSA8emhvdXRpYW5yYW49NDBodWF3ZWkuY29tQGRtYXJjLmll dGYub3JnPG1haWx0bzo0MGh1YXdlaS5jb21AZG1hcmMuaWV0Zi5vcmc+PjsgSUVURiBJUFBNIFdH IChpcHBtQGlldGYub3JnPG1haWx0bzppcHBtQGlldGYub3JnPikgPGlwcG1AaWV0Zi5vcmc8bWFp bHRvOmlwcG1AaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtpcHBtXSBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LWxpLWlwcG0tb3R3YW1wLW9uLWxhZy0wMi50eHQNCg0KSGkgVGlh bnJhbiwgQWxsLA0KSSB0aGluayB0aGF0IHRoaXMgaXMgYSB1c2VmdWwgd29yay4NCkZvciBMQUcs IHRoZSB1c2Ugb2YgYWN0aXZlIG1ldGhvZHMgKE9XQU1QLCBUV0FNUCwgU1RBTVApIGNhbiBhbHNv IGNvbXBsZW1lbnQgcGFzc2l2ZSBhbmQgaHlicmlkIG1ldGhvZHMuIEluZGVlZCwgdGhlIGV4dGVu c2lvbnMgcHJvcG9zZWQgaW4gdGhpcyBkcmFmdCBhbGxvdyB0byBtb25pdG9yIGFsbCB0aGUgbGlu a3MgYW5kIG5vdCBvbmx5IHRoZSBsaW5rIGNyb3NzZWQgYnkgdGhlIG9ic2VydmVkIHBhY2tldCBz dHJlYW0uDQpNYXliZSwgeW91IGNhbiBhbHNvIGhpZ2hsaWdodCB0aGlzIHBvaW50IGluIHRoZSBp bnRyb2R1Y3Rpb24gc2VjdGlvbi4NCg0KTWlub3Igbml0czoNCnMvUmVmbGVjdG9yIE1lbWJlciBM aW5rIElEIGZpZWxkcy9SZWZsZWN0b3IgTWVtYmVyIExpbmsgSUQgZmllbGQvDQoNCnMvV2hlbiBz ZW5kaW5nIGEgcmVzcG9uc2UgdG8gdGhlIHJlY2VpdmVkIFRlc3QgcGFja2V0LCB0aGUgbWljcm8g VFdBTVAgU2Vzc2lvbi1TZW5kZXIvIFdoZW4gc2VuZGluZyBhIHJlc3BvbnNlIHRvIHRoZSByZWNl aXZlZCBUZXN0IHBhY2tldCwgdGhlIG1pY3JvIFRXQU1QIFNlc3Npb24tIFJlZmxlY3Rvci8NCg0K DQpSZWdhcmRzLA0KDQpHaXVzZXBwZQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBpcHBtIDxpcHBtLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlwcG0tYm91bmNlc0BpZXRm Lm9yZz4+IE9uIEJlaGFsZiBPZiBUaWFucmFuIFpob3UNClNlbnQ6IE1vbmRheSwgSmFudWFyeSAy NCwgMjAyMiA3OjIzIEFNDQpUbzogSUVURiBJUFBNIFdHIChpcHBtQGlldGYub3JnPG1haWx0bzpp cHBtQGlldGYub3JnPikgPGlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+Pg0KU3Vi amVjdDogW2lwcG1dIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpLWlw cG0tb3R3YW1wLW9uLWxhZy0wMi50eHQNCg0KSGkgV0csDQoNCldlIHRoaW5rIHRoaXMgaXMgYW4g dXNlZnVsIHdvcmsgb24gYWRhcHRpbmcgT1dBTVAvVFdBTVAgaW4gTEFHIHBlcmZvcm1hbmNlIG1l YXN1cmVtZW50Lg0KV2UgdXBkYXRlZCB0aGlzIGRyYWZ0IGJhc2VkIG9uIHRoZSBjb21tZW50cyBm cm9tIHRoZSBtZWV0aW5nIGRpc2N1c3Npb24gYW5kIG1haWxpbmcgbGlzdC4NClRoYW5rcyBmb3Ig YWxsIHRoZSBzdWdnZXN0aW9ucy4NCk1vcmUgcmV2aWV3cyBhbmQgY29tbWVudHMgYXJlIHdlbGNv bWUuDQoNCkNoZWVycywNClRpYW5yYW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPiBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnPl0NClNlbnQ6IE1vbmRheSwgSmFudWFyeSAyNCwgMjAyMiAyOjE3IFBNDQpU bzogR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbTxtYWlsdG86Z3JlZ2ltaXJza3lA Z21haWwuY29tPj47IEd1byBKdW4gPGd1by5qdW4yQHp0ZS5jb20uY248bWFpbHRvOmd1by5qdW4y QHp0ZS5jb20uY24+PjsgSnVuIEd1byA8Z3VvLmp1bjJAenRlLmNvbS5jbjxtYWlsdG86Z3VvLmp1 bjJAenRlLmNvbS5jbj4+OyBSYWtlc2ggR2FuZGhpIDxyZ2FuZGhpQGNpc2NvLmNvbTxtYWlsdG86 cmdhbmRoaUBjaXNjby5jb20+PjsgVGlhbnJhbiBaaG91IDx6aG91dGlhbnJhbkBodWF3ZWkuY29t PG1haWx0bzp6aG91dGlhbnJhbkBodWF3ZWkuY29tPj47IFpoZW5xaWFuZyBMaSA8bGlfemhlbnFp YW5nQGhvdG1haWwuY29tPG1haWx0bzpsaV96aGVucWlhbmdAaG90bWFpbC5jb20+Pg0KU3ViamVj dDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saS1pcHBtLW90d2FtcC1vbi1s YWctMDIudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWxpLWlwcG0tb3R3YW1w LW9uLWxhZy0wMi50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVGlhbnJh biBaaG91IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAgICAg ICAgIGRyYWZ0LWxpLWlwcG0tb3R3YW1wLW9uLWxhZw0KUmV2aXNpb246ICAgICAgIDAyDQpUaXRs ZTogICAgICAgICAgT25lLXdheS9Ud28td2F5IEFjdGl2ZSBNZWFzdXJlbWVudCBQcm90b2NvbCBF eHRlbnNpb25zIGZvciBQZXJmb3JtYW5jZSBNZWFzdXJlbWVudCBvbiBMQUcNCkRvY3VtZW50IGRh dGU6ICAyMDIyLTAxLTI0DQpHcm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQ YWdlczogICAgICAgICAgMTMNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9h cmNoaXZlL2lkL2RyYWZ0LWxpLWlwcG0tb3R3YW1wLW9uLWxhZy0wMi50eHQNClN0YXR1czogICAg ICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1saS1pcHBtLW90d2Ft cC1vbi1sYWcvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvaHRtbC9kcmFmdC1saS1pcHBtLW90d2FtcC1vbi1sYWcNCkRpZmY6ICAgICAgICAgICBodHRw czovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbGktaXBwbS1vdHdhbXAtb24tbGFn LTAyDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGV4dGVuc2lvbnMgdG8g T25lLXdheSBBY3RpdmUgTWVhc3VyZW1lbnQNCiAgIFByb3RvY29sIChPV0FNUCksIGFuZCBUd28t d2F5IEFjdGl2ZSBNZWFzdXJlbWVudCBQcm90b2NvbCAoVFdBTVApIHRvDQogICBpbXBsZW1lbnQg cGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQgb24gZXZlcnkgbWVtYmVyIGxpbmsgb2YgYSBMaW5rDQog ICBBZ2dyZWdhdGlvbiBHcm91cCAoTEFHKS4gIEtub3dpbmcgdGhlIG1lYXN1cmVkIG1ldHJpY3Mg b2YgZWFjaCBtZW1iZXINCiAgIGxpbmsgb2YgYSBMQUcgZW5hYmxlcyBvcGVyYXRvcnMgdG8gZW5m b3JjZSB0aGUgcGVyZm9ybWFuY2UgYmFzZWQNCiAgIHRyYWZmaWMgc3RlZXJpbmcgcG9saWN5IGFj cm9zcyB0aGUgbWVtYmVyIGxpbmtzLg0KDQoNCg0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmlwcG0g bWFpbGluZyBsaXN0DQppcHBtQGlldGYub3JnPG1haWx0bzppcHBtQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQppcHBtIG1haWxpbmcgbGlzdA0KaXBwbUBp ZXRmLm9yZzxtYWlsdG86aXBwbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaXBwbQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KaXBwbSBtYWlsaW5nIGxpc3QNCmlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1A aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0NCg0K DQotLQ0KDQpIZW5yaWsgTnlkZWxsDQpTciBQcm9kdWN0IE1hbmFnZXINCjEuODY2LjY4NS44MTgx DQpobnlkZWxsQGFjY2VkaWFuLmNvbTxtYWlsdG86aG55ZGVsbEBhY2NlZGlhbi5jb20+DQpbaHR0 cHM6Ly9pLnhpbmsuaW8vSW1hZ2VzL0dldC9ONjM4MzIvYTY1LnBuZ108aHR0cDovL2FjY2VkaWFu LmNvbT4NCltodHRwczovL2kueGluay5pby9JbWFnZXMvR2V0L042MzgzMi9mOTcucG5nXTxodHRw czovL3d3dy5mYWNlYm9vay5jb20vYWNjZWRpYW4vPiBbaHR0cHM6Ly9pLnhpbmsuaW8vSW1hZ2Vz L0dldC9ONjM4MzIvdDk5LnBuZ10gPGh0dHBzOi8vdHdpdHRlci5jb20vQWNjZWRpYW4+ICBbaHR0 cHM6Ly9pLnhpbmsuaW8vSW1hZ2VzL0dldC9ONjM4MzIvbDU0LnBuZ10gPGh0dHBzOi8vY2EubGlu a2VkaW4uY29tL2NvbXBhbnkvYWNjZWRpYW4+DQo8aHR0cDovL3d3dy5hY2NlZGlhbi5jb20+DQph Y2NlZGlhbi5jb208aHR0cDovL2FjY2VkaWFuLmNvbT4NCg0KDQpBdmlzIGRlIGNvbmZpZGVudGlh bGl0qKYNCg0KTGVzIGluZm9ybWF0aW9ucyBjb250ZW51ZXMgZGFucyBsZSBwcqimc2VudCBtZXNz YWdlIGV0IGRhbnMgdG91dGUgcGmoqGNlIHF1aSBsdWkgZXN0IGpvaW50ZSBzb250IGNvbmZpZGVu dGllbGxlcyBldCBwZXV2ZW50IKi6dHJlIHByb3SopmeopmVzIHBhciBsZSBzZWNyZXQgcHJvZmVz c2lvbm5lbC4gQ2VzIGluZm9ybWF0aW9ucyBzb250IKikIGyhr3VzYWdlIGV4Y2x1c2lmIGRlIHNv biBvdSBkZSBzZXMgZGVzdGluYXRhaXJlcy4gU2kgdm91cyByZWNldmV6IGNlIG1lc3NhZ2UgcGFy IGVycmV1ciwgdmV1aWxsZXogc6GvaWwgdm91cyBwbGFpdCBjb21tdW5pcXVlciBpbW2opmRpYXRl bWVudCBhdmVjIGyhr2V4cKimZGl0ZXVyIGV0IGVuIGSopnRydWlyZSB0b3V0IGV4ZW1wbGFpcmUu IERlIHBsdXMsIGlsIHZvdXMgZXN0IHN0cmljdGVtZW50IGludGVyZGl0IGRlIGxlIGRpdnVsZ3Vl ciwgZGUgbGUgZGlzdHJpYnVlciBvdSBkZSBsZSByZXByb2R1aXJlIHNhbnMgbKGvYXV0b3Jpc2F0 aW9uIGRlIGyhr2V4cKimZGl0ZXVyLiBNZXJjaS4NCg0KQ29uZmlkZW50aWFsaXR5IG5vdGljZQ0K DQpUaGlzIGUtbWFpbCBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudCBoZXJldG8gY29udGFpbiBj b25maWRlbnRpYWwgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgYW5kIHdoaWNo IGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiBpdHMgYWRkcmVzc2VlKHMpLiBJ ZiB5b3UgcmVjZWl2ZSB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBpbmZvcm0gc2VuZGVy IGltbWVkaWF0ZWx5IGFuZCBkZXN0cm95IGFueSBjb3B5IHRoZXJlb2YuIEZ1cnRoZXJtb3JlLCBh bnkgZGlzY2xvc3VyZSwgZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBtZXNzYWdlIGFu ZC9vciBhbnkgYXR0YWNobWVudCBoZXJldG8gd2l0aG91dCB0aGUgY29uc2VudCBvZiB0aGUgc2Vu ZGVyIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIFRoYW5rIHlvdS4NCg== --_000_9b14ec8b237f4a448d7c70eb6473326chuaweicom_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
        Hi Henrik,

        Thanks for your&n= bsp;interest.
        This draft is&nbs= p;not aiming for a big ambition, but to&= nbsp;solve a specific requirement from existing&nb= sp;network operations. Without well thought and&nb= sp;design, I am not sure if we can = simply remove the LAG assumption.

        How about we = ;work together on a new draft to general= ize this for the more common use? And&nb= sp;hence the two work can complement.

        Best,
        Tianran 





        Sent from WeLink<= /span>
        =B7=A2=BC=FE=C8=CB=A3=BA Henrik Nydell<hnydell@accedian.com>
        =CA=D5=BC=FE=C8=CB=A3=BA Tianran Zhou<zhoutianran@huawei.com>
        =B3=AD=CB=CD=A3=BA Giuseppe Fioccola<giuseppe.fioccola@huawei.com>;IETF IPPM WG = (ippm<ippm@ietf.org>
        =D6=F7=CC=E2=A3=BA Re: [ippm] New Version Notification for draf= t-li-ippm-otwamp-on-lag-02.txt
        =CA=B1=BC=E4=A3=BA 2022-01-28 19:57:28

        I still think it wou= ld be much better to generalize this micro TWAMP concept and not tie this t= o LAG, since that will be implementation specific - only if you implement T= WAMP directly on a LAG-device this draft would apply.
        Better then to gener= alize the concept and call the added identifier "Substream ID" or= something similar. Then this draft would also apply to for example a vendo= r that implements routing over different paths or as Tianran pointed out, MPLS-SR uses. Thus I would propose removing all= references to LAG in this draft and widen the scope to any situation where= there would be uses for labelled (ID:ed) substreams between the same = TWAMP-sender and session-reflector.

         

        On Fri, Jan 28, 2022 at 12:15 PM Tian= ran Zhou <zhoutianran=3D4= 0huawei.com@dmarc.ietf.org> wrote:
        Hi Giuseppe,

        Thanks very much for your review.
        I will incorporate your suggestions in the next revision.

        Cheers,
        Tianran

        -----Original Message-----
        From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Giuseppe Fioccola
        Sent: Friday, January 28, 2022 7:03 PM
        To: Tianran Zhou <zhoutianran=3D40huawei.com@dmarc.ietf.org>; IETF IPPM WG = (ippm@ietf.org) <= ippm@ietf.org> Subject: Re: [ippm] New Version Notification for draft-li-ippm-otwamp-on-la= g-02.txt

        Hi Tianran, All,
        I think that this is a useful work.
        For LAG, the use of active methods (OWAMP, TWAMP, STAMP) can also complemen= t passive and hybrid methods. Indeed, the extensions proposed in this draft= allow to monitor all the links and not only the link crossed by the observ= ed packet stream.
        Maybe, you can also highlight this point in the introduction section.

        Minor nits:
        s/Reflector Member Link ID fields/Reflector Member Link ID field/

        s/When sending a response to the received Test packet, the micro TWAMP Sess= ion-Sender/ When sending a response to the received Test packet, the micro = TWAMP Session- Reflector/


        Regards,

        Giuseppe


        -----Original Message-----
        From: ippm <i= ppm-bounces@ietf.org> On Behalf Of Tianran Zhou
        Sent: Monday, January 24, 2022 7:23 AM
        To: IETF IPPM WG (ippm@i= etf.org) <ippm@ie= tf.org>
        Subject: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-la= g-02.txt

        Hi WG,

        We think this is an useful work on adapting OWAMP/TWAMP in LAG performance = measurement.
        We updated this draft based on the comments from the meeting discussion and= mailing list.
        Thanks for all the suggestions.
        More reviews and comments are welcome.

        Cheers,
        Tianran

        -----Original Message-----
        From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
        Sent: Monday, January 24, 2022 2:17 PM
        To: Greg Mirsky <gregimirsky@gmail.com>; Guo Jun <guo.jun2@zte.com.cn>; Jun Guo <guo.jun2@zte.com.cn= >; Rakesh Gandhi <r= gandhi@cisco.com>; Tianran Zhou <zhoutianran@huawei.com>; Zhenqiang Li &l= t;li_zhenqian= g@hotmail.com>
        Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

        A new version of I-D, draft-li-ippm-otwamp-on-lag-02.txt
        has been successfully submitted by Tianran Zhou and posted to the IETF repo= sitory.

        Name:           draft-li-ippm-otwamp-on-lag Revision:       02
        Title:          One-way/Two-way Active Measurement= Protocol Extensions for Performance Measurement on LAG
        Document date:  2022-01-24
        Group:          Individual Submission
        Pages:          13
        URL:            https://www.ietf.org/archive/id/draft-li-ippm-otwamp-on-lag-02.txt
        Status:         https://datatracker.ietf.org/doc/draft-li-ippm-otwamp-on-lag/
        Htmlized:       https://datatracker.ietf.org/doc/html/draft-li-ippm-otwamp-on-lag
        Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-li-ippm-otwamp-on-lag= -02

        Abstract:
           This document defines extensions to One-way Active Measurement=
           Protocol (OWAMP), and Two-way Active Measurement Protocol (TWA= MP) to
           implement performance measurement on every member link of a Li= nk
           Aggregation Group (LAG).  Knowing the measured metrics of= each member
           link of a LAG enables operators to enforce the performance bas= ed
           traffic steering policy across the member links.





        The IETF Secretariat


        _______________________________________________
        ippm mailing list
        ippm@ietf.org
        https://www.ietf.org/mailman/listinfo/ippm

        _______________________________________________
        ippm mailing list
        ippm@ietf.org
        https://www.ietf.org/mailman/listinfo/ippm

        _______________________________________________
        ippm mailing list
        ippm@ietf.org
        https://www.ietf.org/mailman/listinfo/ippm


        --

        Henrik Nydell
        Sr Product Manager
        1.866.685.8181
        hnydell@accedian.= com
        3D""
        =3D"" 3D"" 3D""
        3D""
        accedian.com=

        Avis de confidentialit=A8=A6

        Les informations contenues dans le= pr=A8=A6sent message et dans toute pi=A8=A8ce qui lui est jointe sont conf= identielles et peuvent =A8=BAtre prot=A8=A6g=A8=A6es par le secret professi= onnel. Ces informations sont =A8=A4 l=A1=AFusage exclusif de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez s=A1=AF= il vous plait communiquer imm=A8=A6diatement avec l=A1=AFexp=A8=A6diteur et= en d=A8=A6truire tout exemplaire. De plus, il vous est strictement interdi= t de le divulguer, de le distribuer ou de le reproduire sans l=A1=AFautorisation de l=A1=AFexp=A8=A6diteur. Merci.

        Confidentiality notice

        This e-mail message and any attachment hereto contain c= onfidential information which may be privileged and which is intended for t= he exclusive use of its addressee(s). If you receive this message in error,= please inform sender immediately and destroy any copy thereof. Furthermore, any disclosure, distribution or= copying of this message and/or any attachment hereto without the consent o= f the sender is strictly prohibited. Thank you.

        --_000_9b14ec8b237f4a448d7c70eb6473326chuaweicom_-- From nobody Fri Jan 28 11:10:31 2022 Return-Path: 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 273CC3A0B01; Fri, 28 Jan 2022 11:10:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dfd9Pr3A6O3c; Fri, 28 Jan 2022 11:10:23 -0800 (PST) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2118.outbound.protection.outlook.com [40.107.94.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A6223A0B00; Fri, 28 Jan 2022 11:10:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gNn9uEFikU9svILRwKDxgQVc6lJ/84i+LpiUwUnTzWZYlqd6KTXQtyJbbJIiwkKFftsFvj84RHtQmS+DYgSlilt8ypiBv9tqSnilg0o9HY+W9jORjIGndgESKI7JwKmMiVoV+I9WoD3vZuaH9Qy18HUEBCzrYX34xIayAduX8H0Cueap51qtBmI4zI6s54bG0LacsAZATIBJdIgUOm7d63gEwveMGmYUnjMhHIlvHZkBRmywqBaj5mWbxKTZBEIKggBKBwoFF4Ep/8NQNbHq02CPMpHe+3X3tZmTNKAlSPP8GMJoQ4734U0ar0N6FS52As3mU/8wEp64mkxoxkB5HQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=JD1ZUvkdwqBZUj4Hts3BqaiQ/ZI7qAHfjHGJK86k7l8=; b=Gj2Fe/yJVarWlnPbmkEdYCDuuTeSuFonRmEBxCLdge5BychGd+pkMJceatI428PEd8zPQPISnVpP0wUVUVCnYZMfwCtPTSPyR8TB0mHcr1MWKHA3EXMfNAKS067RiwXuNLijSB+FUALDim5VYh6MCLRH4hPh7ZH4Pr/UjQqJZbOtUoCvXX3HBCG71QpbyNxwbgnDFo8A4WX7zXkf3teH49MOcneG7GHE7SB8YRlardlPZhTPBlmUzAdvtP31G0y91YDt1ecqxe4kxqwo+FB/uq8JfSvwuBcq1EzqsGMTwrhGM0krVS5E3QtOh4LnpegxFAM1WdMvKrj6oLq9kr34mg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JD1ZUvkdwqBZUj4Hts3BqaiQ/ZI7qAHfjHGJK86k7l8=; b=bkgzQhkK5gQmTI7zW6a8WVlgmkaXvIHSYVD/qc1eYdGDNliuNYbTbWlVRztsoFDKWbU0z0zIqDlpaSBT/lThheqLlQb0bOQDZMxWfbPS1ERcJyzrd4T8zhkZI6cQiY5K2M9sXaVxt+njDF14uz9iX9sMQvukE5Lt93ikKkDrnaE= Received: from BY3PR13MB4787.namprd13.prod.outlook.com (2603:10b6:a03:357::13) by CO1PR13MB4966.namprd13.prod.outlook.com (2603:10b6:303:f1::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.7; Fri, 28 Jan 2022 19:10:18 +0000 Received: from BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::e07d:da86:9082:d264]) by BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::e07d:da86:9082:d264%6]) with mapi id 15.20.4951.007; Fri, 28 Jan 2022 19:10:18 +0000 From: Haoyu Song To: Greg Mirsky CC: "spring@ietf.org" , IETF IPPM WG Thread-Topic: [spring] Active OAM in SRv6 Thread-Index: AdgTBAVv6vallEwgQVCAy2m6n5m7fAABJueAACmK42AABqLOgAAHd+IgAAF9aIAAIn5YMA== Date: Fri, 28 Jan 2022 19:10:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6b29fa86-04ae-4944-bd12-08d9e291d2d2 x-ms-traffictypediagnostic: CO1PR13MB4966:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: y55HajBhpDTjQZjNOd9OyfcwOP+mf+z3b3yRJci9J4915aC7gWQLzi38cEHMRdo1tPKa6Y3t3xh/1lAFUtDQCLM280ld+eRypy9xIcUkV4KTHiZdmvS3KrYDh6ZXAOLsVV7x069WT8eT350c5s5pmIhWr4kUoSyY/HdfuOM3wziyW8Wxo9BRub8z30e1bpCaH4MA50tSYse2LVjO7dCBEZfxWqrFNQa/Xq4+p/BPvqQbzaDiQ2ZI7N+IXkqrv4Yr9opuUxx2CuZooyEtUpdezzqInwR1Tgn+m1FjV61yTwijIqEp8vZGfguQqj4hUzywO3Unq+Dn0NUAnWohz2y0CyNtUUThAJnDym1aElyNTYgckuRNfsydE2ly0fAwJ3ZbaB4MXztXTyMJbcWkcFBvwVOnypZnA7Pe7yDciM2EaOVBAo7ShMJW6rNT70nH8eh6PHEKSMv3r8WimBdB1lv3CE0CFuY/DPlyhdR9tyTv2uvdE4JXXYd/0zHLl85sjZ0m9KJpT/Hhtbe7aduBCe1OuxO9cP1AeDrfSqLvICrPi1gtnWzAkajDbarN0sutTIgj+rP1qRNMd1LZM4pV2UqzXi5fDxzfIfeaSr4mjX93Q/iUNIfbb5vjq3wIJYKLtqdqiblEJKpNfpqRsdwwU4ELL/GODE6xkjEBIKRj/yNtA1+jN3UtPvMHJlNDRNVk0nzjI3z+3QOqCCdTRqQHAlzPgK0rvk7iA0x5IscOjl2/Qw5oLS+glxUX6xzxZKofdvt9m21qLSxyTHl4+FVhkwGRwsZ8I+iGrV615PAD5BsfcnSeaevryZ1JmpsM9olXLl2D9OChfharJ9MDHzgIZDxyjwQgNmvD8CTUyRX1ovtSZC8UhRldrWbanbhv4EtRYAcu x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR13MB4787.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(7696005)(9686003)(2906002)(166002)(6506007)(53546011)(966005)(26005)(186003)(86362001)(55016003)(508600001)(83380400001)(38070700005)(44832011)(76116006)(38100700002)(54906003)(66476007)(64756008)(66556008)(9326002)(8676002)(66446008)(66946007)(8936002)(52536014)(5660300002)(33656002)(122000001)(316002)(6916009)(71200400001)(4326008)(20210929001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?wLc1fiupEV2ibUe8fM3RNa+6NYsIJgyDI7L86Z3yGLn4lpG6z0D3nyN91lzi?= =?us-ascii?Q?1QKRgWKpJNDkMf59RU6gunXmHl6wsysWyd4SbB5sSqW1SBHIHvMgaGTXWm1r?= =?us-ascii?Q?3Hz2g1/e8phZ7h1fFSs094J1OXZFDT1QP4Kqb1OZ7gJIsXuD8/M9yZ/qbuWI?= =?us-ascii?Q?Fx43QVeWgHJA4bFuHg7V8OV1g8FXYKskVl5seKfiyyu6IekjKBEwVSN8I+zR?= =?us-ascii?Q?ErAgoHVe9QnVxbQeeXSJyLC0ZmA4qTdxv9upZmUKiP/dpPrVkRtX55paxd+P?= =?us-ascii?Q?vh2OI+Zz9c4aLdEoi0EJxF8b4nd3hfQA+2hruLZmSyPJMyeplo+sQdEscHhR?= =?us-ascii?Q?wKCQqXoSUpdrNOradUFDmdHP4bY6dcifozKVjYOkcLHOL4ndysiH+GUeswCH?= =?us-ascii?Q?2FfBJDyNvD7+4kSR3I1DCdWlduKwgRJoewMl7VuR4tMVV9TRnYpInaX7sdvz?= =?us-ascii?Q?hRhxWoBcQ1pBRyUEp6/aHc7NVasgWiyshou53k45rnTZZI7b0K+nh5jCcrS2?= =?us-ascii?Q?yWZamo6E4LDu51VVgCieBqn3UEnlCZHRShPHhOvaHThIflQX3nVJHh6ZglzP?= =?us-ascii?Q?CwP6JtqLy3Ya7FJXlXhmLmUOcxi72Tv6OaTKFoRvmmhefBpIDdOmMOsN7mHn?= =?us-ascii?Q?fj1p5wwAvbd/jj25nyhqM3YGIA/7jgyrfVWfFuxa0DvXtXCKJI/rfuQjH/yk?= =?us-ascii?Q?XnaW8XWh80YyS4GkyeOST/SqHJm6TShxd45/dVO+WTy0WjTGPIQi9cVooPgi?= =?us-ascii?Q?dVUPrhKxH35ULXxSNa6csaMl04AlDPzoX3xxWGNQbgNr3+aw9UxQPufgYGM2?= =?us-ascii?Q?yzD2rSxI28Z0oV6D6E0mz9NdeH+JUXOdX07op30vDAeu9fUzQtQhoMEtAIZ8?= =?us-ascii?Q?gMm84A0xdfMslcZHjqy7PPU1f/EiOtNgx3owHP5xhc/7Qac+brwbt0wRH9K8?= =?us-ascii?Q?6/Ht8ug//RQPx5Jm9gQpLdlecDsfXdIkSDFUH1Ycrog4qHWZm2CTlt1lhFA/?= =?us-ascii?Q?ZBiFUhp5dLWbvr9I7PxIz6YBDOj2JR2pWyrjmbZdNo8JOacp2lLOIvn/XI4C?= =?us-ascii?Q?nYoFU6JyHESWct6eOU/0A3fBlWZAAzGMLsD6teUyb3gGAWnR+XloFFU1gaj8?= =?us-ascii?Q?tuH6IGEwCodWWRUPiWA18zDhHF9+eYI6iMJnbfkj8Was2jOsx6gN8WPo+k44?= =?us-ascii?Q?cHAgzVvkj4ebg1z8NePDWWaz8joeOq6f8ifDUb/FJqWEwlHeeAUx2DseKShj?= =?us-ascii?Q?p7oWYtitkjYa7iYrm52SimvsNYQ6Q3kq2PZuuRyVm4Rmy9c6vtWd9gAmT1yR?= =?us-ascii?Q?svzsSfVsM5qLoqzDGMtT5Mv35WlgO373ARip68Julg9JLKdy8l+VKA0Gg14X?= =?us-ascii?Q?jUVpTaE/Zq7pTO21JNe5SaXlHhxBgGpPIqctcBEfnI7JkSSDsLb3RyVfI3HM?= =?us-ascii?Q?I6k6Hm29Py8tFwCTlVa8Xaoh3QdsHq+EzSEkphqUePIGcX+Q3GhFP/qgQJII?= =?us-ascii?Q?EvvEyfzW/zIaRV6/XA7hOVr2VWUcFP+KLasBvb5yg2BxwUJX2SiND/G/S7Rk?= =?us-ascii?Q?m7csBukv8YGTnHsQ2iWuyY9u+MLF+S3On/D7rYq5Tn/BjRRJwesJB2C0/6XD?= =?us-ascii?Q?vQ=3D=3D?= Content-Type: multipart/alternative; boundary="_000_BY3PR13MB478724D6BEFFED706F23FC699A229BY3PR13MB4787namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB4787.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6b29fa86-04ae-4944-bd12-08d9e291d2d2 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2022 19:10:18.3860 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: QcIHRK87JsXd4agreOdC9VPqO10m3FAgkDL3xeOkCYVdOWGDgrUhEgbWfnuBqndSU2R3gKFrOJgD0F90oG5rCw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR13MB4966 Archived-At: Subject: Re: [ippm] [spring] Active OAM in SRv6 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2022 19:10:28 -0000 --_000_BY3PR13MB478724D6BEFFED706F23FC699A229BY3PR13MB4787namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, Thanks for the info. I'd like to clarify this work means to use the standar= dized IOAM options to support active measurement, so it's fair to say we us= e IOAM in SRv6 for active measurement. Another point I'd like to mention is= that draft-ietf-ippm-ioam-ipv6-options is for IPv6 in general but not for SRv6 s= pecifically. Moreover, it also use EH TLVs and we propose to use UDP, and i= t means to support in-band measurement for user traffic. In my view, SRv6 is the way to steer traffic. If SRv6 networks prevail, it'= s natural to use the traffic steering feature for probing and measurements = as well. If we have a unified method to cover as many techniques as possibl= e, we can imagine new techniques can also be introduced easily. Without nee= ding to set up any sessions and maintain any states, the controller can inj= ect probing packets from any node, steer them on any path, terminate them a= t any node, and collect any data we like. Such in-network measurement doesn= 't need to involve end hosts like PING. It can be used for traffic engineer= ing (e.g., evaluating different paths at background) and for gray failure d= etection and prevention. I hope the WG can see the simplicity, extensibility, and great application = potential of the proposed scheme, and provide constructive suggestions to i= mprove it. Thanks! Haoyu From: Greg Mirsky Sent: Thursday, January 27, 2022 6:17 PM To: Haoyu Song Cc: spring@ietf.org; IETF IPPM WG Subject: Re: [spring] Active OAM in SRv6 Hi Haoyu, now, without in-lining my notes. It appears that you propose not to use draft-ietf-ippm-ioam-ipv6-options. Thus, y= our proposal cannot be referred to as IOAM in SRv6. At best, it is IOAM-ins= pired, IOAMish. As a result, a node supporting standardized IOAM would not = understand your probe packet without an SW upgrade. In my book, that's a ne= w protocol. In closing, I'll reference two works by Ruediger Geib, where combining the defined= techniques of steering test probes with standard IOAM might reveal a lot o= f useful information about a network: * RFC 8403 * draft-ietf-ippm-connectivity-monitoring Regards, Greg On Thu, Jan 27, 2022 at 5:44 PM Haoyu Song > wrote: Hi Greg, please see Inline From: Greg Mirsky > Sent: Thursday, January 27, 2022 2:01 PM To: Haoyu Song > Cc: spring@ietf.org; IETF IPPM WG > Subject: Re: [spring] Active OAM in SRv6 Hi Haoyu, thank you for your detailed reply. Please find my follow-up notes in-lined = below under the GIM2>> tag. Regards, Greg On Thu, Jan 27, 2022 at 11:00 AM Haoyu Song > wrote: Hi Greg, Thank you for your questions. Please see inline response. Best, Haoyu From: Greg Mirsky > Sent: Wednesday, January 26, 2022 3:01 PM To: Haoyu Song > Cc: spring@ietf.org; IETF IPPM WG > Subject: Re: [spring] Active OAM in SRv6 Hi Haoyu, thank you for bringing the topic of Active OAM to the discussion. As the co= ncept of Active IOAM is introduced in the IPPM WG draft it seems to me like adding t= he IPPM WG community to the discussion is the right thing to do. Please find my notes in-lined below under the GIM>> tag. Regards, Greg On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song > wrote: Hi SPRING WG, Real time monitor on every node and every link on a network is necessary to= detect gray failures, which are the key culprit for poor QoS but hard to = catch. SR provides an ideal mechanism, when working with some efficient pla= nning algorithm, to achieve that with low cost. Our proposal SRv6 In-situ= Active Measurement (SIAM) suggests a simple active measurement approach w= hich can support different GIM>> I wonder what gaps you find in the existing active measurement protoc= ols, e.g., STAMP and RFC 6734 (would be more convenient to use an acronym).= It appears to me that, for example, STAMP and its extensions, including th= e SRPM draft, comprehensively address the PM OAM requirements for SRv6. HS>> Let's give a few features of our proposal: (1) it's session-less and w= e don't need assign any roles (e.g., reflector); (2) no needs for a return= path. The measurement can start and end at any node (solely determined by = the SRH); (3) udp-based which can support any existing IOAM modes and poten= tially other OAM methods. GIM2>> I don't think adding a protocol that can generate a test probe from = an arbitrary node to arbitrary targets (SRv6 supports multicast) is as simp= le as you present. If an operator needs to monitor the performance of the S= R policy used by data packets, IOAM can be applied to data packets. If the = operator wants to explore a policy that is not used for data traffic, I ima= gine IOAM can be added to a test packet of the existing OAM protocol, e.g.,= ICMP. Am I missing some of the requirements? HS2>> For the first point: I don't think a protocol is needed here. If one = wants to test the path a->b->c->d->e, he doesn't need to find a user packet= on that path to carry IOAM (there could be no such packet at all). Instead= , he can generate a probe packet with an SRH for the path and use the probe= packet to carry IOAM. At the path end, it simply extracts and exports the = IOAM data using the mechanism defined for IOAM and drops the probe packet. For the second point: I don't think ICMP can achieve what IOAM can do. IOAM= is much more powerful in terms of the data it can collect. Moreover, the p= roposal can be easily extended to support other kinds of OAM methods. One j= ust carry it in UDP payload using different port. No need to worry about th= e size if such info has to be carried in EH TLV. options of IOAM and other OAM methods in SRv6, without needing to worry abo= ut the extension header issue. GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows: In terms of the classification given in [RFC7799] IOAM could be portrayed as Hybrid Type 1. Does your proposal change that? HS>> In this particular case, IOAM is used for active measurement because i= t's not included in a user packet. Your comments, questions, and suggestions are very welcome. I'd like to kno= w your opinion if you think this work is in scope and should be adopted by = the working group. If you are interested in contributing to this work, ple= ase also let me know. https://datatracker.ietf.org/doc/draft-song-spring-si= am/ Thank you very much! Best regards, Haoyu _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_BY3PR13MB478724D6BEFFED706F23FC699A229BY3PR13MB4787namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

        Hi Greg,

         

        Thanks for the info. I’d like to clarify this = work means to use the standardized IOAM options to support active measureme= nt, so it’s fair to say we use IOAM in SRv6 for active measurement. A= nother point I’d like to mention is that draft-ietf-ippm-ioam-ipv6-options is for IPv6 in general but not for SR= v6 specifically. Moreover, it also use EH TLVs and we propose to use UDP, a= nd it means to support in-band measurement for user traffic.

         

        In my view, SRv6 is the way to steer traffic. If SRv= 6 networks prevail, it’s natural to use the traffic steering feature = for probing and measurements as well. If we have a unified method to cover = as many techniques as possible, we can imagine new techniques can also be introduced easily. Without needing to set up an= y sessions and maintain any states, the controller can inject probing packe= ts from any node, steer them on any path, terminate them at any node, and c= ollect any data we like. Such in-network measurement doesn’t need to involve end hosts like PING. It can be u= sed for traffic engineering (e.g., evaluating different paths at background= ) and for gray failure detection and prevention.   

         

        I hope the WG can see the simplicity, extensibility,= and great application potential of the proposed scheme, and provide constr= uctive suggestions to improve it.

         

        Thanks!

        Haoyu  

         

        From: Greg Mirsky <gregimirsky@gmail.com&g= t;
        Sent: Thursday, January 27, 2022 6:17 PM
        To: Haoyu Song <haoyu.song@futurewei.com>
        Cc: spring@ietf.org; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [spring] Active OAM in SRv6

         

        Hi Haoyu,

        now, without in-lining my notes.

        It appears that you propose not to use draft-ietf-ippm-ioam-ipv6-options. Thus, your proposal cannot be referr= ed to as IOAM in SRv6. At best, it is IOAM-inspired, IOAMish. As a result, = a node supporting standardized IOAM would not understand your probe packet = without an SW upgrade. In my book, that's a new protocol.

        In closing, I'll reference two works by Ruediger Geib, where combining the defined techniques of steering test p= robes with standard IOAM might reveal a lot of useful information about a n= etwork:

        Regards,

        Greg

         

        On Thu, Jan 27, 2022 at 5:44 PM Haoyu Song <haoyu.song@futurewei.com> wro= te:

        Hi Greg, please see Inline

         

        From: Greg Mirsky <gregimirsky@gmail.com>
        Sent: Thursday, January 27, 2022 2:01 PM
        To: Haoyu Song <haoyu.song@futurewei.com>
        Cc: spring@ietf= .org; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [spring] Active OAM in SRv6

         

        Hi Haoyu,

        thank you for your detailed reply. Please find my follow-up notes = in-lined below under the GIM2>> tag.

         

        Regards,

        Greg

         

        On Thu, Jan 27, 2022 at 11:00 AM Haoyu Song <haoyu.song@futurewei.com>= ; wrote:

        Hi Greg,

         

        Thank you for your questions. Please see inline response.

         

        Best,

        Haoyu

         

        From: Greg Mirsky <gregimirsky@gmail.com>
        Sent: Wednesday, January 26, 2022 3:01 PM
        To: Haoyu Song <haoyu.song@futurewei.com>
        Cc: spring@ietf= .org; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [spring] Active OAM in SRv6

         

        Hi Haoyu,

        thank you for bringing the topic of Active OAM to the discussion. = As the concept of Active IOAM is introduced in the IPPM WG draft it seems to me like adding the IPPM WG community to = the discussion is the right thing to do. 

        Please find my notes in-lined below under the GIM>> tag.

         

        Regards,

        Greg

         

        On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song <haoyu.song@futurewei.com>= wrote:

        Hi SPRING WG,

         

        Real time monitor on every node and every link on a network is nec= essary to detect  gray failures, which are the key culprit for poor Qo= S but hard to catch. SR provides an ideal mechanism, when working with some efficient planning algorithm, to achieve= that with low cost.   Our proposal SRv6 In-situ Active Measureme= nt (SIAM) suggests a simple  active measurement approach which can sup= port different

        GIM>> I wonder what gaps you find in the existing active mea= surement protocols, e.g., STAMP and RFC 6734 (would be more convenient to u= se an acronym). It appears to me that, for example, STAMP and its extensions, including the SRPM draft, comprehensively address the PM OAM requirements for SRv6.&n= bsp;

         

        HS>> Let’s give a few features of our proposal: (1) it= ’s session-less and we don’t need assign any roles (e.g.,  = ;reflector); (2) no needs for a return path. The measurement can start and end at any node (solely determined by the SRH); (3) udp-based wh= ich can support any existing IOAM modes and potentially other OAM methods.<= o:p>

        GIM2>> I don't think adding a protocol that can generate a t= est probe from an arbitrary node to arbitrary targets (SRv6 supports multic= ast) is as simple as you present. If an operator needs to monitor the performance of the SR policy used by data packets, IO= AM can be applied to data packets. If the operator wants to explore a polic= y that is not used for data traffic, I imagine IOAM can be added to a test = packet of the existing OAM protocol, e.g., ICMP. Am I missing some of the requirements?

         

        HS2>> For the first point: I don’t think a protocol is= needed here. If one wants to test the path a->b->c->d->e, he d= oesn’t need to find a user packet on that path to carry IOAM (there could be no such packet at all). Instead, he can generate a probe p= acket with an SRH for the path and use the probe packet to carry IOAM. At t= he path end, it simply extracts and exports the IOAM data using the mechani= sm defined for IOAM and drops the probe packet.  

        For the second point: I don’t think ICMP can achieve what IO= AM can do. IOAM is much more powerful in terms of the data it can collect. = Moreover, the proposal can be easily extended to support other kinds of OAM methods. One just carry it in UDP payload us= ing different port. No need to worry about the size if such info has to be = carried in EH TLV.

        options of IOAM and other OAM methods in SRv6, without needing to = worry about the extension header issue.  

        GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows:<= o:p>

           In terms of the classification given

           in [RFC7799] IOAM could be portrayed as Hybrid Type 1= .

        Does your proposal change that?

         

        HS>> In this particular case, IOAM is used for active measur= ement because it’s not included in a user packet.

         

        Your comments, questions, and suggestions are very welcome. I̵= 7;d like to know your opinion if you think this work is in scope and should= be adopted by the working group.  If you are interested in contributing to this work, please also let me know. https://datatracker.ietf.org/doc/draft-song-spring-siam/

         

        Thank you very much!

         

        Best regards,

        Haoyu

        _______________________________________________
        spring mailing list
        spring@ietf.org https://www.ietf.org/mailman/listinfo/spring

        --_000_BY3PR13MB478724D6BEFFED706F23FC699A229BY3PR13MB4787namp_-- From nobody Fri Jan 28 11:23:05 2022 Return-Path: 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 E4C243A0BFF; Fri, 28 Jan 2022 11:23:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uy_hWMsHKSvo; Fri, 28 Jan 2022 11:22:59 -0800 (PST) Received: from NAM04-MW2-obe.outbound.protection.outlook.com (mail-mw2nam08on2133.outbound.protection.outlook.com [40.107.101.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8F523A0BF6; Fri, 28 Jan 2022 11:22:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=obv3XYEDfGromFrW46SsT40dgeo/52Q9hhz7deDSIDzRAqahp+cD91E7wq9b+ttkiXr987KIDNWjmbSlsvWi6TtxdJcWcL7wEpyHFLWRotE9TruU9wNfPoTQDf3YQ1QkuwMAhoBHCMPdJ1PEvaMXAbU6jiMme2+qfLm4zLElMLS4sNLh/ZqVQjkETPg00sYQU7PNjB87FqX4doVeDqm0usWcUpuxYZ7DuPsaNBXd9j3nWMDVIHfYCMZGcnYW0RFEtOKXHCPR8tvETw82XXodXTfjCz5+4SJIzIdSuVryEI4hv1Tage9tHRodIFF8j7jSxic65aFs9JjLoK/ylh3zFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=mSjTwLhPtknDNDXtvCA4gqo0MXl1IwKoMh6k1ba247Q=; b=lRmoHwmKfOZi3y4jAqYm5qxqxOJC+BNCQDVgLnxi140agKCc0A18kuhXSuUr9ZCvudJ5jyQmdPSPSx4U/vFavjWS4Ajsgqghhg5pEpukzMJIJH/ey5+Q7bxrZIbCHX2ywtQafS56XSmCDcLjCp1CfTlcbumjl2hweA9UAMfoHZqqkR9g0xrmqPHcjCnKQMzMMm6qxWn19ELcQRGTXZNjOI4KZyMRGQlScSMhFqFOh3SgPA1sOXs4CUggCI6YsC+CiwSSMTgJ22SWcEuvFEZHNfQcgY5kSagssW44DCLRPP5VkrNogdoCC2NfoA4TW+b/QlNxYNfegxRy6vDJ2YHNMw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mSjTwLhPtknDNDXtvCA4gqo0MXl1IwKoMh6k1ba247Q=; b=hYavZDNU/Hl3y4yfEnx3ZqHUsMW2jDxa/bOx43f2etibv1b607p2YhN6Intk4FZrzvUDuXTwBDcdi5lzptKTIhCy3OV58++kRFViBU9kI7JmZQB3XYzEKX7yf45SWT9jrKbOpZfCHR6Iuu6Vp22e1LLsQztn5Do2Z/UXhwxnW9A= Received: from BY3PR13MB4787.namprd13.prod.outlook.com (2603:10b6:a03:357::13) by MN2PR13MB3694.namprd13.prod.outlook.com (2603:10b6:208:1e5::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.6; Fri, 28 Jan 2022 19:22:56 +0000 Received: from BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::e07d:da86:9082:d264]) by BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::e07d:da86:9082:d264%6]) with mapi id 15.20.4951.007; Fri, 28 Jan 2022 19:22:56 +0000 From: Haoyu Song To: Tianran Zhou , Greg Mirsky CC: "spring@ietf.org" , IETF IPPM WG Thread-Topic: [ippm] [spring] Active OAM in SRv6 Thread-Index: AdgTBAVv6vallEwgQVCAy2m6n5m7fAABJueAACmK42AABqLOgAAD7wWAACh/aWA= Date: Fri, 28 Jan 2022 19:22:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2c23f706-2eb5-487d-32da-08d9e293965f x-ms-traffictypediagnostic: MN2PR13MB3694:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oeELu0kHGBa522leflKV+3e89PiS0xEJScYW5Ah2V3N7hnoUARNN8RYtgCtFSbEUJQrFatZVvEe0vj1UwrzNs/CygVZWw3I5tZOLScAszv0pcH/eFBOcu9B6c+pcVQNMklCnzZAwU+85ZFJsAX5f7OZRx/MysazieDSEQpBCmsuq5mAheCaPOgeBFs9HFDvwSPwg2ZmNNOF2Q6nLT3AuUXFYUE7o11DmNOimLN3KfjywsdPSMdghyx6uOy8T8VMCq/cRjMptmn70lgndgO3GxMU3Lo99sZ8K2tKfXRP3yYpFdIuxBP1DMzqzpobhq7pEUfu05UFsofjHTryBcj4N6L7WtwwnWPD/tHLr1T+AOuJzLhv7r/RUnvyVfzw7XnqkvOyen+Tty16HI4718pjPGkBWWNTRpYxKvR31gXx5xnd0QbMWLoWXGwkolTvy2myJ5dkJ1BBp0P8Kgk2Rbkh6YgRSesrlGG7yCByOWvlOrFZSNuYl7ZRxNRC9yfeFReHQNDeI2hJeAeSIoqF1dhWKTE120EL5HCwuWeytPD/ELoBeTbHwYzf9qq2sVp+v1AhkqRgjLOarS/9LmTxWEcj7qJ1S5AhTrx7Q9t0t9mGF0lwoNRj6k1Uj90LL+jN0vf4jmktO1TesO+pFJP1HgpDoYbVopqaV7ZYW/WhZxLTjMcUNdubhtxvyzgamHsEL6o+u9dlz2f4TSxWtQRQ4rE2jQhst4A5lWr/DVuVGJuOP+ZmJMp2b/qa3Rk17jZGRfe7iplf9W1kNfkhx+RA1TcwKlynWXH5320xpT54qeR2m5tCqQ9wYcxMKmGObSdmzJxhd98oWv1vKwtPg0yAa3Cpbc5IVsmiAKBQep6CfBtsnO8Vfmr09u1O86KgVNXyAYN/G x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR13MB4787.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(8936002)(64756008)(4326008)(66446008)(76116006)(33656002)(66476007)(8676002)(66556008)(66946007)(110136005)(508600001)(38070700005)(54906003)(966005)(83380400001)(86362001)(316002)(55016003)(38100700002)(9686003)(7696005)(186003)(53546011)(5660300002)(26005)(6506007)(122000001)(52536014)(166002)(2906002)(71200400001)(44832011)(20210929001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?BPCWyFUb1Q9JD9aDoKoN50xn0lEtIwJYDYagy5ZnOwYTuY0UqmYqiksM9t+N?= =?us-ascii?Q?7s3MwM22ZHsZJx0vUuZfwQEuko8ITRIr+vcfrQUDXE9ylCrx0oCXJ3lFoQT9?= =?us-ascii?Q?Be4DCdluDxZ8jeG2XTQLoAf0MIdJcpwz7FOHeyStiGvNWxVuIDT5wifcTSWk?= =?us-ascii?Q?MUCWdULdAkARO4XMoP8pTJz7GsfrR8Ngsnul0TLqaRX1UbgczaH+OokTZXOO?= =?us-ascii?Q?gGS+pIIT07iK/05GQhLgx8Se6S59KImEjZpRErjQauHT4TOSVgKmtzU31Uf3?= =?us-ascii?Q?r7Mse4RuMHzuaK+SIx1wwVfw+27taKOm5FFZPb4UnYEhUmOURn+cjZCdYc3t?= =?us-ascii?Q?nlSl9fgypcNvP1i81swP/+stZTErm9aCS/cMuu4az3D4IPnn1nNiSrAxMg8Z?= =?us-ascii?Q?xvXWXDXl6NXvEhBqDYBw+Jg6j8/7usKHAQ6a3MspLG7V1vSGO06hWstSfA3C?= =?us-ascii?Q?8GPNLR4UJI4kwbOg7mtfbBpnKmd56l6genAV8dBXD9RgdVVCV62vJDkcL7PI?= =?us-ascii?Q?JTSKBdrc1qLnPB1gXI0vBggCMVSpxyJ2Wx4FGYALIRSjXcNt/UuPyHuOb0fs?= =?us-ascii?Q?IFZiaHZVX0mUDuDmW5e+7qyqLNGjgWzL6P16kcNhiy6WmeoVQ4fEsbtTvofN?= =?us-ascii?Q?aIDt1FI8sXvTc5xhJWYMnS519qA29s+yJKsUpcJZlLnZieqWXLZ1AACRqWX7?= =?us-ascii?Q?kVbAeWZkPfwejlhlCEfZ8+iGGDi9gYD2XkKGN2gejF5WvnV2C7+50+x03tr9?= =?us-ascii?Q?qQKZsqiym4Fy3ZshgDXaWww3ofrNe3Xt0Q7McmIS8BoU83PLyl5c9e7tvPt1?= =?us-ascii?Q?trE7sjk9odW7yesQE5XkaDNIvy5pLIbL7PNev2mf8wx9Je+QH/UJkXS9PeLn?= =?us-ascii?Q?gWBgcpa6BIV704Dxh+AoKJE4jlwRR6FWj7qQ6qRpcw491pi2l/qgilo1nIUw?= =?us-ascii?Q?gY2lkp6mca4TMYpWivbQVzEP826bH7q3wR0kZkCQ87g1EAUHdXlHcNGGWfrL?= =?us-ascii?Q?V5B99LpAr8VR+rDRSESCrZrzJxpCAIk7a+uVZi5P+xwLQ0fZWmY9ycEDAvnU?= =?us-ascii?Q?he2nt4zFwdxFTRR483BwetNs12cgr/5KcGobZoR4zxAHBMgOJi3n/rS5j5ib?= =?us-ascii?Q?ID4VOktQnG1wuYuvJSuO6QDKavux3eT0i9hDiy+GZZDpz+z3G7EI0xm101lm?= =?us-ascii?Q?LFT8myOAUpPeZWY+CGLUQO8lZinqr+I0bu4cK2mtKooOt7pls0E/C69kEDeY?= =?us-ascii?Q?t3H7S3o4hQOj2rYuVRCnolBETdpczJOjjz0Jy50wUVYkHiVX1OlnDf1V44Fg?= =?us-ascii?Q?Q0AIjyK+RZvYFVlNhxgFn2bZpZYbo0rxIVRdPaZKwAJSIKZc9tr9VwtLSTz/?= =?us-ascii?Q?gtr4A66+Xq+r9xbQG6hRiuE4YFt8eZjQzocZceJ1YZxamGyUHlchosMAIaE7?= =?us-ascii?Q?P0rtmLCYm+xIiABIf7+ouuojOKkiat+P+7FxApWqS1BsDf0F8DhTY7NwgMNl?= =?us-ascii?Q?LOv2FaopzZjVIDOJqivuO6Pl0//TAxiPxWNU+ckOD02Rlnb2kaZLS6c1g187?= =?us-ascii?Q?O3um0ZX0SqFL05axUH2utpPgqpqgnD5HejybhzTwWr7YW03/4aVjQW+nVaMG?= =?us-ascii?Q?XQ=3D=3D?= Content-Type: multipart/alternative; boundary="_000_BY3PR13MB478770C4B53E19D5F06912569A229BY3PR13MB4787namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB4787.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2c23f706-2eb5-487d-32da-08d9e293965f X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2022 19:22:55.9433 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: iNL+AUXSdwFmBNhtlfRADC2RbOIDmRihY5r2XdTTtB1X3Ibq1W9Sd9Kl1GdlkVGfDzxRb0hYNUio6amXU1Dfkw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB3694 Archived-At: Subject: Re: [ippm] [spring] Active OAM in SRv6 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2022 19:23:04 -0000 --_000_BY3PR13MB478770C4B53E19D5F06912569A229BY3PR13MB4787namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable See inline -Haoyu From: Tianran Zhou Sent: Thursday, January 27, 2022 3:53 PM To: Greg Mirsky ; Haoyu Song Cc: spring@ietf.org; IETF IPPM WG Subject: RE: [ippm] [spring] Active OAM in SRv6 Hi Haoyu, I agree with Greg. I think IOAM with existing OAM protocol can address your= case. Again, I can show you some more details on your motivation. (1) it's session-less and we don't need assign any roles (e.g., reflector)= ; ZTR> I am not sure if I understand what the "session-less" mean. But I think in your application, the sender should keep the session state, = right? Reflector is not always required. OWAMP is one way, so no reflector. STAMP,= IMHO, could also be one way. In RFC8762, STAMP "enables the measurement of both one-way and round-trip p= erformance metrics". HS> It means "stateless". The state could be some identifier kept by the ne= twork device. Augmenting some existing protocols to cover new function requ= ire the same amount of work and in many cases, due to the limitations of th= e original protocol, the extensibility is seriously limited. The protocols = you mentioned were designed for e2e measurement. Each new patch adding to t= hem will raise the concern for the standard updates and eventually make the= protocol itself unwieldy because the new things are beyond the original de= sign scope. In other words, having the existing protocol doesn't help here = but exert unnecessary limitations. (2) no needs for a return path. The measurement can start and end at any no= de (solely determined by the SRH); ZTR> This is achieved by SRH, you did not create anything on OAM after UDP.= So this applies for any one way OAM protocol. On the other hand, many measurement need two ways (e.g., delay). Even data = collections need two ways, because the forward and backward are totally dif= ferent two paths. Of cause, you can use one way protocol to travel both way. Two way need a reflector, but will also reduce a lot of resources. For exam= ple the length of the SID list. HS> Two way can easily be supported by SRH itself (just add the round trip = path in segment list). There's no need to introduce any other mechanism. (3) udp-based which can support any existing IOAM modes and potentially oth= er OAM methods. ZTR> STAMP is UDP based. HS> If so, it can also be supported by our framework. But there's no need t= o force IOAM functions as a part of STAMP. That's like reinventing the whee= l. From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Greg Mirsky Sent: Friday, January 28, 2022 6:01 AM To: Haoyu Song > Cc: spring@ietf.org; IETF IPPM WG > Subject: Re: [ippm] [spring] Active OAM in SRv6 Hi Haoyu, thank you for your detailed reply. Please find my follow-up notes in-lined = below under the GIM2>> tag. Regards, Greg On Thu, Jan 27, 2022 at 11:00 AM Haoyu Song > wrote: Hi Greg, Thank you for your questions. Please see inline response. Best, Haoyu From: Greg Mirsky > Sent: Wednesday, January 26, 2022 3:01 PM To: Haoyu Song > Cc: spring@ietf.org; IETF IPPM WG > Subject: Re: [spring] Active OAM in SRv6 Hi Haoyu, thank you for bringing the topic of Active OAM to the discussion. As the co= ncept of Active IOAM is introduced in the IPPM WG draft it seems to me like adding= the IPPM WG community to the discussion is the right thing to do. Please find my notes in-lined below under the GIM>> tag. Regards, Greg On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song > wrote: Hi SPRING WG, Real time monitor on every node and every link on a network is necessary to= detect gray failures, which are the key culprit for poor QoS but hard to = catch. SR provides an ideal mechanism, when working with some efficient pla= nning algorithm, to achieve that with low cost. Our proposal SRv6 In-situ= Active Measurement (SIAM) suggests a simple active measurement approach w= hich can support different GIM>> I wonder what gaps you find in the existing active measurement protoc= ols, e.g., STAMP and RFC 6734 (would be more convenient to use an acronym).= It appears to me that, for example, STAMP and its extensions, including th= e SRPM draft, comprehensively address the PM OAM requirements for SRv6. HS>> Let's give a few features of our proposal: (1) it's session-less and w= e don't need assign any roles (e.g., reflector); (2) no needs for a return= path. The measurement can start and end at any node (solely determined by = the SRH); (3) udp-based which can support any existing IOAM modes and poten= tially other OAM methods. GIM2>> I don't think adding a protocol that can generate a test probe from = an arbitrary node to arbitrary targets (SRv6 supports multicast) is as simp= le as you present. If an operator needs to monitor the performance of the S= R policy used by data packets, IOAM can be applied to data packets. If the = operator wants to explore a policy that is not used for data traffic, I ima= gine IOAM can be added to a test packet of the existing OAM protocol, e.g.,= ICMP. Am I missing some of the requirements? options of IOAM and other OAM methods in SRv6, without needing to worry abo= ut the extension header issue. GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows: In terms of the classification given in [RFC7799] IOAM could be portrayed as Hybrid Type 1. Does your proposal change that? HS>> In this particular case, IOAM is used for active measurement because i= t's not included in a user packet. Your comments, questions, and suggestions are very welcome. I'd like to kno= w your opinion if you think this work is in scope and should be adopted by = the working group. If you are interested in contributing to this work, ple= ase also let me know. https://datatracker.ietf.org/doc/draft-song-spring-si= am/ Thank you very much! Best regards, Haoyu _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_BY3PR13MB478770C4B53E19D5F06912569A229BY3PR13MB4787namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

        See inline

         

        -Haoyu

         

        From: Tianran Zhou <zhoutianran@h= uawei.com>
        Sent: Thursday, January 27, 2022 3:53 PM
        To: Greg Mirsky <gregimirsky@gmail.com>; Haoyu Song <haoyu.= song@futurewei.com>
        Cc: spring@ietf.org; IETF IPPM WG <ippm@ietf.org>
        Subject: RE: [ippm] [spring] Active OAM in SRv6

         

        Hi Haoyu,

         

        I agree with Greg. I think IOAM with = existing OAM protocol can address your case.

        Again, I can show you some more detai= ls on your motivation.

        (1) it’s session-less and we don’t need = assign any roles (e.g.,  reflector);

        ZTR> I am not sure if I understand= what the “session-less” mean.

        But I think in your application, the = sender should keep the session state, right?

        Reflector is not always required. OWA= MP is one way, so no reflector. STAMP, IMHO, could also be one way.

        In RFC8762, STAMP “enables the = measurement of both one-way and round-trip performance metrics”.=

         

        HS> It means “stateless”. The state = could be some identifier kept by the network device. Augmenting some existi= ng protocols to cover new function require the same amount of work and in many cases, due to the limitations of the original protocol, t= he extensibility is seriously limited. The protocols you mentioned were des= igned for e2e measurement. Each new patch adding to them will raise the con= cern for the standard updates and eventually make the protocol itself unwieldy because the new things are be= yond the original design scope. In other words, having the existing protoco= l doesn’t help here but exert unnecessary limitations.  

         

        (2) no needs for a return path. The measurement can = start and end at any node (solely determined by the SRH);

        ZTR> This is achieved by SRH, you = did not create anything on OAM after UDP. So this applies for any one way O= AM protocol.

        On the other hand, many measurement n= eed two ways (e.g., delay). Even data collections need two ways, because th= e forward and backward are totally different two paths.

        Of cause, you can use one way protoco= l to travel both way.

        Two way need a reflector, but will al= so reduce a lot of resources. For example the length of the SID list.

         

        HS> Two way can easily be supported by SRH itsel= f (just add the round trip path in segment list). There’s no need to = introduce any other mechanism.

         

        (3) udp-based which can support any existing IOAM mo= des and potentially other OAM methods.

        ZTR> STAMP is UDP based.

         

        HS> If so, it can also be supported by our frame= work. But there’s no need to force IOAM functions as a part of STAMP.= That’s like reinventing the wheel.

         

        From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Greg Mirsky
        Sent: Friday, January 28, 2022 6:01 AM
        To: Haoyu Song <haoyu= .song@futurewei.com>
        Cc: spring@ietf.org; IETF IPP= M WG <ippm@ietf.org>
        Subject: Re: [ippm] [spring] Active OAM in SRv6

         

        Hi Haoyu,

        thank you for your detailed reply. Please find my fo= llow-up notes in-lined below under the GIM2>> tag.

         

        Regards,

        Greg

         

        On Thu, Jan 27, 2022 at 11:00 AM Haoyu Song <haoyu.song@futurewei.com> wr= ote:

        Hi Greg,

         

        Thank you for your questions. Please see inline response.

         

        Best,

        Haoyu

         

        From: Greg Mirsky <gregimirsky@gmail.com>
        Sent: Wednesday, January 26, 2022 3:01 PM
        To: Haoyu Song <haoyu.song@futurewei.com>
        Cc: spring@ietf= .org; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [spring] Active OAM in SRv6

         

        Hi Haoyu,

        thank you for bringing the topic of Active OAM to the discussion. = As the concept of Active IOAM is introduced in the IPPM WG draft it seems to me like adding the IPPM WG community to = the discussion is the right thing to do. 

        Please find my notes in-lined below under the GIM>> tag.

         

        Regards,

        Greg

         

        On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song <haoyu.song@futurewei.com>= wrote:

        Hi SPRING WG,

         

        Real time monitor on every node and every link on a network is nec= essary to detect  gray failures, which are the key culprit for poor Qo= S but hard to catch. SR provides an ideal mechanism, when working with some efficient planning algorithm, to achieve= that with low cost.   Our proposal SRv6 In-situ Active Measureme= nt (SIAM) suggests a simple  active measurement approach which can sup= port different

        GIM>> I wonder what gaps you find in the existing active mea= surement protocols, e.g., STAMP and RFC 6734 (would be more convenient to u= se an acronym). It appears to me that, for example, STAMP and its extensions, including the SRPM draft, comprehensively address the PM OAM requirements for SRv6.&n= bsp;

         

        HS>> Let’s give a few features of our proposal: (1) it= ’s session-less and we don’t need assign any roles (e.g.,  = ;reflector); (2) no needs for a return path. The measurement can start and end at any node (solely determined by the SRH); (3) udp-based wh= ich can support any existing IOAM modes and potentially other OAM methods.<= o:p>

        GIM2>> I don't think adding a protocol that ca= n generate a test probe from an arbitrary node to arbitrary targets (SRv6 s= upports multicast) is as simple as you present. If an operator needs to mon= itor the performance of the SR policy used by data packets, IOAM can be applied to data packets. If the operator want= s to explore a policy that is not used for data traffic, I imagine IOAM can= be added to a test packet of the existing OAM protocol, e.g., ICMP. Am I m= issing some of the requirements?

        options of IOAM and other OAM methods in SRv6, without needing to = worry about the extension header issue.  

        GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows:<= o:p>

           In terms of the classification given

           in [RFC7799] IOAM could be portrayed as Hybrid Type 1= .

        Does your proposal change that?

         

        HS>> In this particular case, IOAM is used for active measur= ement because it’s not included in a user packet.

         

        Your comments, questions, and suggestions are very welcome. I̵= 7;d like to know your opinion if you think this work is in scope and should= be adopted by the working group.  If you are interested in contributing to this work, please also let me know. https://datatracker.ietf.org/doc/draft-song-spring-siam/

         

        Thank you very much!

         

        Best regards,

        Haoyu

        _______________________________________________
        spring mailing list
        spring@ietf.org https://www.ietf.org/mailman/listinfo/spring

        --_000_BY3PR13MB478770C4B53E19D5F06912569A229BY3PR13MB4787namp_-- From nobody Fri Jan 28 12:03:28 2022 Return-Path: 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 C7D953A0F5E; Fri, 28 Jan 2022 12:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gH0Hjy15kWqW; Fri, 28 Jan 2022 12:03:16 -0800 (PST) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 748403A0F16; Fri, 28 Jan 2022 12:03:07 -0800 (PST) Received: by mail-ed1-x531.google.com with SMTP id w14so11978968edd.10; Fri, 28 Jan 2022 12:03:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kFTgn/uMtPjGHcwlgNAYMx+5UliDCla18+EWr8+MXLo=; b=KFEEc7GxKjc5vLRrQTZ6SjLOoyBoPzhSsyN6HQF2g8YeO1D2cBuND9YkOipFIm4uxp d1KYxdSXtXMESgtCsTqYXZ2HprYSNjgDk/CtOlj2qG+/g8ivFziHGOevSS1GAWTTSvKK bJZGlC6LCnjMBHQn0hJakbmcSILM6YDLwXSqFO9PdH/SfUsgy80Xt1DXcyyDBa/VBVhv IE5E5/Lpaz7m32+HlBZvJM/4SH/UdezGupp07PjVOWAruGg27gTTXf3ZXOOxR7kdzTh1 /YB6wTrD2MdbvFBvEr7ebN79UyN7jXfpxprkoldAdAMQfc/hZ6iHj0gARO4F8JyvO7Bx Et7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kFTgn/uMtPjGHcwlgNAYMx+5UliDCla18+EWr8+MXLo=; b=OezcEuo59i7pTOh0hYkrIgMSReVtuMhEjeCnYRQ6l2NpR6rhsOMLNB0NAAIqPQXiWx 47/WVcWwmFRhQbolxfqzl6Fdh3ZSelq4uHIyK0bUSPjdSwMWpm/z9UPCZkCQsm94F6Xm nt18/mlGfWqwFHYmDTyMXoqP+31OxJLAS4nn8rqL/nTefG4u6CI2GYgSV7yn4j2LDriS KtBknsTk2qIAFRjxDAACGQMHJRRoyllt/iSo43elzGmWm0XX5CYmBV6U6QlMsGEQjGv6 UJJZhg4VSYqzjkS2OGEqKgVQweLBP2ojEhkzhauSgXbWi+pL7BeBsUkS+pVvtigd1OQ8 8JdQ== X-Gm-Message-State: AOAM532LujyHH3JWiUsWgm+y8heyiy7jITHLed2ISKTcfpoR2BP8VcdV YTbm+Qm8a0fFuScsTmEC/m8HRo2zt8Crohp5U6Kh6sJy X-Google-Smtp-Source: ABdhPJyNxoLGRbgXoSfSqgIRFr2ehZzb86bfSk6sPLnAqQJ7LvGVc6ru/mnU2qB5SgUJxBE4gBSaZKdD0XOsF8PxB1A= X-Received: by 2002:a05:6402:2071:: with SMTP id bd17mr9727843edb.328.1643400184747; Fri, 28 Jan 2022 12:03:04 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Fri, 28 Jan 2022 12:02:53 -0800 Message-ID: To: Haoyu Song Cc: "spring@ietf.org" , IETF IPPM WG Content-Type: multipart/alternative; boundary="0000000000003c5c3705d6a9ec92" Archived-At: Subject: Re: [ippm] [spring] Active OAM in SRv6 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2022 20:03:21 -0000 --0000000000003c5c3705d6a9ec92 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Haoyu, I'm surprised that you suggest an alternative to the IPv6 way of collecting IOAM data. SRv6 must use all of IPv6 OAM. Would you agree? In some rare cases, SRv6-specific extensions to IPv6 OAMAs for the limited amount of information that can be collected using IPv6 extension headers, IOAM Direct Export , or the Hybrid Two-step provide the solution. Both solve this problem by separating the generation of the IOAM data set from the collection and transport. You are well-familiar with both drafts. Regards, Greg On Fri, Jan 28, 2022 at 11:10 AM Haoyu Song wrote: > Hi Greg, > > > > Thanks for the info. I=E2=80=99d like to clarify this work means to use t= he > standardized IOAM options to support active measurement, so it=E2=80=99s = fair to > say we use IOAM in SRv6 for active measurement. Another point I=E2=80=99d= like to > mention is that draft-ietf-ippm-ioam-ipv6-options > > is for IPv6 in general but not for SRv6 specifically. Moreover, it also u= se > EH TLVs and we propose to use UDP, and it means to support in-band > measurement for user traffic. > > > > In my view, SRv6 is the way to steer traffic. If SRv6 networks prevail, > it=E2=80=99s natural to use the traffic steering feature for probing and > measurements as well. If we have a unified method to cover as many > techniques as possible, we can imagine new techniques can also be > introduced easily. Without needing to set up any sessions and maintain an= y > states, the controller can inject probing packets from any node, steer th= em > on any path, terminate them at any node, and collect any data we like. Su= ch > in-network measurement doesn=E2=80=99t need to involve end hosts like PIN= G. It can > be used for traffic engineering (e.g., evaluating different paths at > background) and for gray failure detection and prevention. > > > > I hope the WG can see the simplicity, extensibility, and great applicatio= n > potential of the proposed scheme, and provide constructive suggestions to > improve it. > > > > Thanks! > > Haoyu > > > > *From:* Greg Mirsky > *Sent:* Thursday, January 27, 2022 6:17 PM > *To:* Haoyu Song > *Cc:* spring@ietf.org; IETF IPPM WG > *Subject:* Re: [spring] Active OAM in SRv6 > > > > Hi Haoyu, > > now, without in-lining my notes. > > It appears that you propose not to use draft-ietf-ippm-ioam-ipv6-options > . > Thus, your proposal cannot be referred to as IOAM in SRv6. At best, it is > IOAM-inspired, IOAMish. As a result, a node supporting standardized IOAM > would not understand your probe packet without an SW upgrade. In my book, > that's a new protocol. > > In closing, I'll reference two works by Ruediger Geib > , > where combining the defined techniques of steering test probes with > standard IOAM might reveal a lot of useful information about a network: > > - RFC 8403 > > - draft-ietf-ippm-connectivity-monitoring > > > > > Regards, > > Greg > > > > On Thu, Jan 27, 2022 at 5:44 PM Haoyu Song > wrote: > > Hi Greg, please see Inline > > > > *From:* Greg Mirsky > *Sent:* Thursday, January 27, 2022 2:01 PM > *To:* Haoyu Song > *Cc:* spring@ietf.org; IETF IPPM WG > *Subject:* Re: [spring] Active OAM in SRv6 > > > > Hi Haoyu, > > thank you for your detailed reply. Please find my follow-up notes in-line= d > below under the GIM2>> tag. > > > > Regards, > > Greg > > > > On Thu, Jan 27, 2022 at 11:00 AM Haoyu Song > wrote: > > Hi Greg, > > > > Thank you for your questions. Please see inline response. > > > > Best, > > Haoyu > > > > *From:* Greg Mirsky > *Sent:* Wednesday, January 26, 2022 3:01 PM > *To:* Haoyu Song > *Cc:* spring@ietf.org; IETF IPPM WG > *Subject:* Re: [spring] Active OAM in SRv6 > > > > Hi Haoyu, > > thank you for bringing the topic of Active OAM to the discussion. As the > concept of Active IOAM is introduced in the IPPM WG draft > it > seems to me like adding the IPPM WG community to the discussion is the > right thing to do. > > Please find my notes in-lined below under the GIM>> tag. > > > > Regards, > > Greg > > > > On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song > wrote: > > Hi SPRING WG, > > > > Real time monitor on every node and every link on a network is necessary > to detect gray failures, which are the key culprit for poor QoS but hard > to catch. SR provides an ideal mechanism, when working with some efficien= t > planning algorithm, to achieve that with low cost. Our proposal SRv6 > In-situ Active Measurement (SIAM) suggests a simple active measurement > approach which can support different > > GIM>> I wonder what gaps you find in the existing active measurement > protocols, e.g., STAMP and RFC 6734 (would be more convenient to use an > acronym). It appears to me that, for example, STAMP and its extensions, > including the SRPM draft > , > comprehensively address the PM OAM requirements for SRv6. > > > > HS>> Let=E2=80=99s give a few features of our proposal: (1) it=E2=80=99s = session-less and > we don=E2=80=99t need assign any roles (e.g., reflector); (2) no needs f= or a > return path. The measurement can start and end at any node (solely > determined by the SRH); (3) udp-based which can support any existing IOAM > modes and potentially other OAM methods. > > GIM2>> I don't think adding a protocol that can generate a test probe fro= m > an arbitrary node to arbitrary targets (SRv6 supports multicast) is as > simple as you present. If an operator needs to monitor the performance of > the SR policy used by data packets, IOAM can be applied to data packets. = If > the operator wants to explore a policy that is not used for data traffic,= I > imagine IOAM can be added to a test packet of the existing OAM protocol, > e.g., ICMP. Am I missing some of the requirements? > > > > HS2>> For the first point: I don=E2=80=99t think a protocol is needed her= e. If one > wants to test the path a->b->c->d->e, he doesn=E2=80=99t need to find a u= ser packet > on that path to carry IOAM (there could be no such packet at all). Instea= d, > he can generate a probe packet with an SRH for the path and use the probe > packet to carry IOAM. At the path end, it simply extracts and exports the > IOAM data using the mechanism defined for IOAM and drops the probe packet= . > > For the second point: I don=E2=80=99t think ICMP can achieve what IOAM ca= n do. > IOAM is much more powerful in terms of the data it can collect. Moreover, > the proposal can be easily extended to support other kinds of OAM methods= . > One just carry it in UDP payload using different port. No need to worry > about the size if such info has to be carried in EH TLV. > > options of IOAM and other OAM methods in SRv6, without needing to worry > about the extension header issue. > > GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows: > > In terms of the classification given > > in [RFC7799] IOAM could be portrayed as Hybrid Type 1. > > Does your proposal change that? > > > > HS>> In this particular case, IOAM is used for active measurement because > it=E2=80=99s not included in a user packet. > > > > Your comments, questions, and suggestions are very welcome. I=E2=80=99d l= ike to > know your opinion if you think this work is in scope and should be adopte= d > by the working group. If you are interested in contributing to this work= , > please also let me know. > https://datatracker.ietf.org/doc/draft-song-spring-siam/ > > > > > Thank you very much! > > > > Best regards, > > Haoyu > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > --0000000000003c5c3705d6a9ec92 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
        Hi Haoyu,
        I'm surprised that you suggest an altern= ative to the IPv6 way of collecting IOAM data. SRv6 must use all of IPv6 OA= M. Would you agree? In some rare cases, SRv6-specific extensions to IPv6 OA= MAs for the limited amount of information that can be collected using IPv6 = extension headers, IOAM Direct Export, or the Hybrid Two-ste= p provide the solution. Both solve this problem by separating the gener= ation of the IOAM data set from the collection and transport. You are well-= familiar with both drafts.

        Regards,
        Greg=

        On Fri, Jan 28, 2022 at 11:10 AM Haoyu Song <haoyu.song@futurewei.com> wrote:

        Hi Greg,

        =C2=A0

        Thanks for the info. I=E2=80=99d like to clarify thi= s work means to use the standardized IOAM options to support active measure= ment, so it=E2=80=99s fair to say we use IOAM in SRv6 for active measuremen= t. Another point I=E2=80=99d like to mention is that draft-ietf-ippm-ioam-ipv6-options is for IPv6 in general but not for SR= v6 specifically. Moreover, it also use EH TLVs and we propose to use UDP, a= nd it means to support in-band measurement for user traffic.<= /p>

        =C2=A0

        In my view, SRv6 is the way to steer traffic. If SRv= 6 networks prevail, it=E2=80=99s natural to use the traffic steering featur= e for probing and measurements as well. If we have a unified method to cove= r as many techniques as possible, we can imagine new techniques can also be introduced easily. Without needing to set up an= y sessions and maintain any states, the controller can inject probing packe= ts from any node, steer them on any path, terminate them at any node, and c= ollect any data we like. Such in-network measurement doesn=E2=80=99t need to involve end hosts like PING. It can be= used for traffic engineering (e.g., evaluating different paths at backgrou= nd) and for gray failure detection and prevention. =C2=A0=C2=A0

        =C2=A0

        I hope the WG can see the simplicity, extensibility,= and great application potential of the proposed scheme, and provide constr= uctive suggestions to improve it.

        =C2=A0

        Thanks!

        Haoyu =C2=A0

        =C2=A0

        From: Greg Mirsky <gregimirsky@gmail.com>
        Sent: Thursday, January 27, 2022 6:17 PM
        To: Haoyu Song <haoyu.song@futurewei.com>
        Cc: spring@ietf= .org; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [spring] Active OAM in SRv6

        =C2=A0

        Hi Haoyu,

        now, without in-lining my notes.

        It appears that you propose not to use draft-ietf-ippm-ioam-ipv6-options. Thus, your proposal cannot be referr= ed to as IOAM in SRv6. At best, it is IOAM-inspired, IOAMish. As a result, = a node supporting standardized IOAM would not understand your probe packet = without an SW upgrade. In my book, that's a new protocol.

        In closing, I'll reference two works by=C2=A0Ruediger Geib, where combining the defined techniques of steering test p= robes with standard IOAM might reveal a lot of useful information about a n= etwork:

        Regards,

        Greg

        =C2=A0

        On Thu, Jan 27, 2022 at 5:44 PM Haoyu Song <haoyu.song@futurew= ei.com> wrote:

        Hi Greg, please see Inline

        =C2=A0

        From: Greg Mirsky <gregimirsky@gmail.com>
        Sent: Thursday, January 27, 2022 2:01 PM
        To: Haoyu Song <haoyu.song@futurewei.com>
        Cc: spring@ietf= .org; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [spring] Active OAM in SRv6

        =C2=A0

        Hi Haoyu,

        thank you for your detailed reply. Please find my fo= llow-up notes in-lined below under the GIM2>> tag.

        =C2=A0

        Regards,

        Greg

        =C2=A0

        On Thu, Jan 27, 2022 at 11:00 AM Haoyu Song <haoyu.song@future= wei.com> wrote:

        Hi Greg,

        =C2=A0

        Thank you for your questions. Please see inline resp= onse.

        =C2=A0

        Best,

        Haoyu

        =C2=A0

        From: Greg Mirsky <gregimirsky@gmail.com>
        Sent: Wednesday, January 26, 2022 3:01 PM
        To: Haoyu Song <haoyu.song@futurewei.com>
        Cc: spring@ietf= .org; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [spring] Active OAM in SRv6

        =C2=A0

        Hi Haoyu,

        thank you for bringing the topic of Active OAM to th= e discussion. As the concept of Active IOAM is introduced in the IPPM WG draft=C2=A0it seems to me like adding the IPPM WG community to = the discussion is the right thing to do.=C2=A0

        Please find my notes in-lined below under the GIM>= ;> tag.

        =C2=A0

        Regards,

        Greg

        =C2=A0

        On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song <haoyu.song@futurew= ei.com> wrote:

        Hi SPRING WG,

        =C2=A0

        Real time monitor on every node and every link on a = network is necessary to detect =C2=A0gray failures, which are the key culpr= it for poor QoS but hard to catch. SR provides an ideal mechanism, when working with some efficient planning algorithm, to achieve= that with low cost. =C2=A0=C2=A0Our proposal SRv6 In-situ Active Measureme= nt (SIAM) suggests a simple =C2=A0active measurement approach which can sup= port different

        GIM>> I wonder what gaps you find in the exist= ing active measurement protocols, e.g., STAMP and RFC 6734 (would be more c= onvenient to use an acronym). It appears to me that, for example, STAMP and its extensions, including the SRPM draft, comprehensively address the PM OAM requirements for SRv6.= =C2=A0

        =C2=A0

        HS>> Let=E2=80=99s give a few features of our = proposal: (1) it=E2=80=99s session-less and we don=E2=80=99t need assign an= y roles (e.g., =C2=A0reflector); (2) no needs for a return path. The measur= ement can start and end at any node (solely determined by the SRH); (3) udp-based wh= ich can support any existing IOAM modes and potentially other OAM methods.<= u>

        GIM2>> I don't think adding a protocol tha= t can generate a test probe from an arbitrary node to arbitrary targets (SR= v6 supports multicast) is as simple as you present. If an operator needs to monitor the performance of the SR policy used by data packets, IO= AM can be applied to data packets. If the operator wants to explore a polic= y that is not used for data traffic, I imagine IOAM can be added to a test = packet of the existing OAM protocol, e.g., ICMP. Am I missing some of the requirements?

        =C2=A0

        HS2>> For the first point: I don=E2=80=99t thi= nk a protocol is needed here. If one wants to test the path a->b->c-&= gt;d->e, he doesn=E2=80=99t need to find a user packet on that path to c= arry IOAM (there could be no such packet at all). Instead, he can generate a probe p= acket with an SRH for the path and use the probe packet to carry IOAM. At t= he path end, it simply extracts and exports the IOAM data using the mechani= sm defined for IOAM and drops the probe packet. =C2=A0

        For the second point: I don=E2=80=99t think ICMP can= achieve what IOAM can do. IOAM is much more powerful in terms of the data = it can collect. Moreover, the proposal can be easily extended to support other kinds of OAM methods. One just carry it in UDP payload us= ing different port. No need to worry about the size if such info has to be = carried in EH TLV.

        options of IOAM and other OAM methods in SRv6, witho= ut needing to worry about the extension header issue. =C2=A0<= /p>

        GIM>> draft-ietf-ippm-ioam-data classifies IOA= M as follows:

        =C2=A0 =C2=A0In terms of the classification given=

        =C2=A0 =C2=A0in [RFC7799] IOAM could be portrayed as= Hybrid Type 1.

        Does your proposal change=C2=A0that?

        =C2=A0

        HS>> In this particular case, IOAM is used for= active measurement because it=E2=80=99s not included in a user packet.

        =C2=A0

        Your comments, questions, and suggestions are very w= elcome. I=E2=80=99d like to know your opinion if you think this work is in = scope and should be adopted by the working group.=C2=A0 If you are interested in contributing to this work, please also let me know. https://datatracker.ietf.org/doc/draft-song-spring-siam/<= /p>

        =C2=A0

        Thank you very much!

        =C2=A0

        Best regards,

        Haoyu

        _______________________________________________
        spring mailing list
        spring@ietf.org https://www.ietf.org/mailman/listinfo/spring

        --0000000000003c5c3705d6a9ec92-- From nobody Fri Jan 28 12:10:48 2022 Return-Path: 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 CFD803A1081; Fri, 28 Jan 2022 12:10:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1UaKY_a6vfN; Fri, 28 Jan 2022 12:10:35 -0800 (PST) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2113.outbound.protection.outlook.com [40.107.244.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079863A104C; Fri, 28 Jan 2022 12:10:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cWu6loKI2eLBa2a3bSeL4PmHl3+gljcW4vVJEV1uT8NhI7k5zftxRT5YOH9+HejCpCKuV4yo7rNYm23wxooE9kFeAoN08zudF1uNJ2YVbJFL9oSoLcM58PD+MrUgIKYnOFbrWnbrJfxiADhz2VKlMz1XCSJawqmotv8B6c24DirLswOjRKJ4BcZFC60734nxW4U0CLbDXPimqSPZLIao/fPmL/LQdsTDiptMTf6AEn44zPzoEJ64Z9bty3P5a2mf11bAZPCN76NbArgoyM98aU3eCL4Dt2bKBpmvtscvDuoXGvj2f4puDiADkvACLoZ8WzGlvZ/b6f+5bcRRe6SVAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=BZtp0pkGHBdCVb+VtiBgmQ0AMw/1jK1TIX9PtFrvc7s=; b=DbeBDe0yBo6zjFuA2GIujaozFELe4PzXXoUxMtWhmdtNaN+AgvadwEanvglUndw4Fo+bn9dahHkEnQczISOnHXpOa8yTCvIip2nWdGxH0SIgz/mLEVy43x66NjOB3/yusWJ9j2Po2echmpmRDJ7PUko4MknNwQdB0bjFVuYiqVRojstH/EyIzwEgt6Lt02GYXsRg4I286tE5SNhB5I9P/aCaCvqWR8CP7IfdzeOhjKObOeJwS92Js6E62MbQkN/AC9eQ/1F6GGcs1gHzl8S+mDyrWRuizlHsGwGVcniNuRLMqSFAskg5I8asWGDmyq7s6HXM1UfLDazdwlJEYPjJOA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BZtp0pkGHBdCVb+VtiBgmQ0AMw/1jK1TIX9PtFrvc7s=; b=hlbZT/lCdJX0g0OhF3OhAd3HGzpRaagKKyvyFGKKSkLjEUhnSMtW8Lrr5FZ+XbV87BLxmeYaiSprndzEo6ZVhwIJFkVn3iwVv43Xcg5CyKNIVm0fdeKJaCr5GAXQuysXur9SDQHR96Bh7W3xKfacHA0Vh0SfVatGwQCSs97IS/c= Received: from BY3PR13MB4787.namprd13.prod.outlook.com (2603:10b6:a03:357::13) by BYAPR13MB2389.namprd13.prod.outlook.com (2603:10b6:a02:cb::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4930.9; Fri, 28 Jan 2022 20:10:27 +0000 Received: from BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::e07d:da86:9082:d264]) by BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::e07d:da86:9082:d264%6]) with mapi id 15.20.4951.007; Fri, 28 Jan 2022 20:10:26 +0000 From: Haoyu Song To: Greg Mirsky CC: "spring@ietf.org" , IETF IPPM WG Thread-Topic: [spring] Active OAM in SRv6 Thread-Index: AdgTBAVv6vallEwgQVCAy2m6n5m7fAABJueAACmK42AABqLOgAAHd+IgAAF9aIAAIn5YMAACuJCAAAAMfaA= Date: Fri, 28 Jan 2022 20:10:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 75ea0576-e95f-4529-cb40-08d9e29a399b x-ms-traffictypediagnostic: BYAPR13MB2389:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: VPY5cxJuJ1M6wOog6vfnSwstN9p22JLD7SpwWbKrLQHXCSmnmGMx/pp/LRijp4Zn4cSCEuMIHG2D2cFIcHpxmMn2yWkDZdzBfc1Vy6pW2ebOUXOI+ZDqmveG3NHcYSYdlybwCZ3O9XwzLZu7Pmih5gzdEN6hkbGDx/dASLzsgSFT/5VqxJuwwo/3p9iAoe0F9q2worLz8ULrU+QSYWwXAgGpOucvEVeXpmOkTBuoZUX6PDkPfwaYHE2h3BhbWfM+UKI6G4QS2YxkRaAMGOYSm2u2bKbn0fNCyigVSAEjtoMlirr2dJbkLPe30ZKxkBhn+KxChnSh4IuJwiKzxLtp4NEX9f3AO9870K5P0Y8csJqcsZxOHNsnWTqwM7h3t/N9Pkk48Eh6od/koggM5RY2WQlJcGVoV22Yvus2vdrrEOCHVl8TTrPlRpY2wIHrZzEP+zkb7o35xD5zdhAH8repmkk96CAopn5xmhorO/2KCpFVz7Ip9so3nm2cSz+rrSAbDQ0i4oc5f2UhQr+g6p+HUBY54G9/dU0ZBdL7f97RV9dD6min0Z645rdXhcwwqInP4RAYjrqPqQbJocdP9VYKbrRb0gvHdtgbUnHDWH7tICioo1lSSn+gbpQFt9lqonssaz83OwJXiUMxlWq952M75Y4k0Vtx/TOWyu01+u1URXtNlDM9hKqTpL4yZF04adM/Hhtwnd90grwqcMyQdZGThbygS1xlHS2mJhfH1kUVSpIB/y5YIMznRLlZa0jkwTpxixTtKo72JTO64RWoR1vfYU6LgwCCR6fMo/PgK4u0Arihn+7h/GSu18oetTN+KhvenSAUfwQTZxxPhJ5tO6QVMQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR13MB4787.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(66476007)(76116006)(66556008)(9326002)(66946007)(122000001)(2906002)(66446008)(8676002)(5660300002)(4326008)(38100700002)(83380400001)(8936002)(64756008)(44832011)(52536014)(316002)(26005)(166002)(6506007)(86362001)(54906003)(71200400001)(33656002)(966005)(7696005)(38070700005)(55016003)(6916009)(186003)(9686003)(53546011)(508600001)(20210929001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?9EO1fvfJjBCQzl1IIK/qUqrc5Hn8zB9u1/j68pgIK5BdOoauClS+CpoFcs0W?= =?us-ascii?Q?y36uj4xJ8eTuOtMDV0eLyE8lbIEioweruRS73q6PaS0DFbxsYO56zr2YX9gl?= =?us-ascii?Q?SbYtBpKIOLeGND1dVp8z8RDzlwpUlUOnVu5ZxGZd7FSm+UHDQQHZMHNDp9fj?= =?us-ascii?Q?1JPe2vgf0F8Lnq0ggxb6TA7qmI1NCW3QrJYs4NTLRFBUV+F8VcrHysfIvo7b?= =?us-ascii?Q?W9ANSgvOMbGQ/l9TEBCjAy+Whaci0GdP2z0gUB3UJdu4kcZmZisw/YXQHwot?= =?us-ascii?Q?W0JRe6pG8/1FCPYL0JwX/r2uOfRbkixY6yGr+NPgipKJkr8spQx6S/N9q9Md?= =?us-ascii?Q?WwSQnAx/uOIWBOAg4nDWA62pdzVan58DuvjCqqOBZTfb3b2fDZ9ZY7aS5w1g?= =?us-ascii?Q?Ip5uMxBmYQISMN5kX2JPSTG/RjJBPc9ADSQzxK3JqUWX0DlaxWmzaadqXSJi?= =?us-ascii?Q?tl2uCGY1LtrmaI29IbjaF/5SRnkXbTWF4FwFLWdEr4SIXw72vtTTFGKMaF3f?= =?us-ascii?Q?3/Yw458kyUJn3JTZezF6/+8noGouZPtrkE4BHkHX28a+CMZzqxRswoP2Bb4c?= =?us-ascii?Q?4DbTKofUfY8ZcqfWvGuCIHqi8ylEYO9jBPXyNMxpj9ic01F87jns0mQ/ICky?= =?us-ascii?Q?AqhY15Gk+GIFlTyXsK8Xt7kxaJJOI4DpZytNauc+3/MkrdtQZIAMHpOOzne+?= =?us-ascii?Q?7sKcicQk9h/TDwLBh3mX4VrIRYhWjQVDTlYSDNGBj9PI27mtk00LF7srimMH?= =?us-ascii?Q?r4XHAzNMOfxqCih28mVHbtZRRM2tk47uQdqGtUKGPjczJmQD7Rmhf1n+jGUF?= =?us-ascii?Q?Y4n+rzuPSwHMUNzcV86zzZP16/Dpj9xI/k/qOcxU4zBmJhvOk60bLnb4uMI+?= =?us-ascii?Q?7xEc08mjOiV9K7sxOjqbrNstLaohFk3lQgOoNuoZ31XDeIOM89NWVMz6mR3o?= =?us-ascii?Q?oMIi1LQ/JDdX4FIEW7B1RKXvwZUKnvdbTPGij8gAwndvoCjFjA8QP/uqVyXN?= =?us-ascii?Q?BoarOZN25nFL8XwaWlXg421n0768Xp/F1fLYrUqknckueTUbkPx8SdOOuqls?= =?us-ascii?Q?Qi/OkYVHFDGUD6L7bE+6vwxatMOf7z0guMOS5IJpbTyic8nDvVnuaqfgSa2X?= =?us-ascii?Q?LKBAW5VW6s9X5j6t6X9A5A+g0t8y0uZvFtr0GtSa34xfk6DWw41E8c/LaiuU?= =?us-ascii?Q?VsXjqvgBAZegwm/SQjcunh+mGsrsswJE45iOmt5QJQ25GEN3f+SNUBxPySGH?= =?us-ascii?Q?lqzu48lLLSF2Lca/efDqFxnarw00WMWwsq9h370V80UOIkR72LNocNs+DgmR?= =?us-ascii?Q?7P513JKdt8lP6tjiek2llSRSvWKCB3YOFlJXPoIeoQOpBLFZsdAOIx+f43pN?= =?us-ascii?Q?oF02GciCJYT3MW44w6+DYLqH2xq8kPAKpSN5pgagcUck8I1Kp/mfkiKPeTT6?= =?us-ascii?Q?3VMKEzMz4lijIHdm+RgExNOWgpvA4qCEK63iBvUPu1/Got4W8RbQUan1Aq5+?= =?us-ascii?Q?w1shSYVeylvXaYtDE3CvAQ1CUysLDyxpaJGMDS3U4LPJXaeHeINgaqkHWalC?= =?us-ascii?Q?36g32XgEvDrTroTDbxJSkaD+euUf+gqEdMZzuuFfV6jUplyXvxtzUpBTNNAB?= =?us-ascii?Q?Ew=3D=3D?= Content-Type: multipart/alternative; boundary="_000_BY3PR13MB4787B727C76FE5B767E952049A229BY3PR13MB4787namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB4787.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 75ea0576-e95f-4529-cb40-08d9e29a399b X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2022 20:10:26.7894 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: G31B3k5pgORyBaNxwaBN7B1+DBJWHocvWXiPaZBGJ9OnKeCwX/lyRX7E1zutcVWbN5HkzynAdgyDXxky+JOCoQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR13MB2389 Archived-At: Subject: Re: [ippm] [spring] Active OAM in SRv6 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2022 20:10:47 -0000 --_000_BY3PR13MB4787B727C76FE5B767E952049A229BY3PR13MB4787namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, Sure, SRv6 is IPv6 but SRv6 doesn't equal to IPv6. If you define IOAM in IP= v6, then what's its behavior in SRv6? Shall it be applied on every node or = every SR node? But the more fundamental issue is that I don't think putting= all of such things in EH TLVs is a good idea. All of the discussions aroun= d this which you are also very familiar make me think we should avoid it if= we can. Best, Haoyu From: Greg Mirsky Sent: Friday, January 28, 2022 12:03 PM To: Haoyu Song Cc: spring@ietf.org; IETF IPPM WG Subject: Re: [spring] Active OAM in SRv6 Hi Haoyu, I'm surprised that you suggest an alternative to the IPv6 way of collecting= IOAM data. SRv6 must use all of IPv6 OAM. Would you agree? In some rare ca= ses, SRv6-specific extensions to IPv6 OAMAs for the limited amount of infor= mation that can be collected using IPv6 extension headers, IOAM Direct Expo= rt,= or the Hybrid Two-step provide the solution. Both solve this problem by separa= ting the generation of the IOAM data set from the collection and transport.= You are well-familiar with both drafts. Regards, Greg On Fri, Jan 28, 2022 at 11:10 AM Haoyu Song > wrote: Hi Greg, Thanks for the info. I'd like to clarify this work means to use the standar= dized IOAM options to support active measurement, so it's fair to say we us= e IOAM in SRv6 for active measurement. Another point I'd like to mention is= that draft-ietf-ippm-ioam-ipv6-options is for IPv6 in general but not for SRv6 s= pecifically. Moreover, it also use EH TLVs and we propose to use UDP, and i= t means to support in-band measurement for user traffic. In my view, SRv6 is the way to steer traffic. If SRv6 networks prevail, it'= s natural to use the traffic steering feature for probing and measurements = as well. If we have a unified method to cover as many techniques as possibl= e, we can imagine new techniques can also be introduced easily. Without nee= ding to set up any sessions and maintain any states, the controller can inj= ect probing packets from any node, steer them on any path, terminate them a= t any node, and collect any data we like. Such in-network measurement doesn= 't need to involve end hosts like PING. It can be used for traffic engineer= ing (e.g., evaluating different paths at background) and for gray failure d= etection and prevention. I hope the WG can see the simplicity, extensibility, and great application = potential of the proposed scheme, and provide constructive suggestions to i= mprove it. Thanks! Haoyu From: Greg Mirsky > Sent: Thursday, January 27, 2022 6:17 PM To: Haoyu Song > Cc: spring@ietf.org; IETF IPPM WG > Subject: Re: [spring] Active OAM in SRv6 Hi Haoyu, now, without in-lining my notes. It appears that you propose not to use draft-ietf-ippm-ioam-ipv6-options. Thus, y= our proposal cannot be referred to as IOAM in SRv6. At best, it is IOAM-ins= pired, IOAMish. As a result, a node supporting standardized IOAM would not = understand your probe packet without an SW upgrade. In my book, that's a ne= w protocol. In closing, I'll reference two works by Ruediger Geib, where combining the defined techn= iques of steering test probes with standard IOAM might reveal a lot of usef= ul information about a network: * RFC 8403 * draft-ietf-ippm-connectivity-monitoring Regards, Greg On Thu, Jan 27, 2022 at 5:44 PM Haoyu Song > wrote: Hi Greg, please see Inline From: Greg Mirsky > Sent: Thursday, January 27, 2022 2:01 PM To: Haoyu Song > Cc: spring@ietf.org; IETF IPPM WG > Subject: Re: [spring] Active OAM in SRv6 Hi Haoyu, thank you for your detailed reply. Please find my follow-up notes in-lined = below under the GIM2>> tag. Regards, Greg On Thu, Jan 27, 2022 at 11:00 AM Haoyu Song > wrote: Hi Greg, Thank you for your questions. Please see inline response. Best, Haoyu From: Greg Mirsky > Sent: Wednesday, January 26, 2022 3:01 PM To: Haoyu Song > Cc: spring@ietf.org; IETF IPPM WG > Subject: Re: [spring] Active OAM in SRv6 Hi Haoyu, thank you for bringing the topic of Active OAM to the discussion. As the co= ncept of Active IOAM is introduced in the IPPM WG draft it seems to me like adding= the IPPM WG community to the discussion is the right thing to do. Please find my notes in-lined below under the GIM>> tag. Regards, Greg On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song > wrote: Hi SPRING WG, Real time monitor on every node and every link on a network is necessary to= detect gray failures, which are the key culprit for poor QoS but hard to = catch. SR provides an ideal mechanism, when working with some efficient pla= nning algorithm, to achieve that with low cost. Our proposal SRv6 In-situ= Active Measurement (SIAM) suggests a simple active measurement approach w= hich can support different GIM>> I wonder what gaps you find in the existing active measurement protoc= ols, e.g., STAMP and RFC 6734 (would be more convenient to use an acronym).= It appears to me that, for example, STAMP and its extensions, including th= e SRPM draft, comprehensively address the PM OAM requirements for SRv6. HS>> Let's give a few features of our proposal: (1) it's session-less and w= e don't need assign any roles (e.g., reflector); (2) no needs for a return= path. The measurement can start and end at any node (solely determined by = the SRH); (3) udp-based which can support any existing IOAM modes and poten= tially other OAM methods. GIM2>> I don't think adding a protocol that can generate a test probe from = an arbitrary node to arbitrary targets (SRv6 supports multicast) is as simp= le as you present. If an operator needs to monitor the performance of the S= R policy used by data packets, IOAM can be applied to data packets. If the = operator wants to explore a policy that is not used for data traffic, I ima= gine IOAM can be added to a test packet of the existing OAM protocol, e.g.,= ICMP. Am I missing some of the requirements? HS2>> For the first point: I don't think a protocol is needed here. If one = wants to test the path a->b->c->d->e, he doesn't need to find a user packet= on that path to carry IOAM (there could be no such packet at all). Instead= , he can generate a probe packet with an SRH for the path and use the probe= packet to carry IOAM. At the path end, it simply extracts and exports the = IOAM data using the mechanism defined for IOAM and drops the probe packet. For the second point: I don't think ICMP can achieve what IOAM can do. IOAM= is much more powerful in terms of the data it can collect. Moreover, the p= roposal can be easily extended to support other kinds of OAM methods. One j= ust carry it in UDP payload using different port. No need to worry about th= e size if such info has to be carried in EH TLV. options of IOAM and other OAM methods in SRv6, without needing to worry abo= ut the extension header issue. GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows: In terms of the classification given in [RFC7799] IOAM could be portrayed as Hybrid Type 1. Does your proposal change that? HS>> In this particular case, IOAM is used for active measurement because i= t's not included in a user packet. Your comments, questions, and suggestions are very welcome. I'd like to kno= w your opinion if you think this work is in scope and should be adopted by = the working group. If you are interested in contributing to this work, ple= ase also let me know. https://datatracker.ietf.org/doc/draft-song-spring-si= am/ Thank you very much! Best regards, Haoyu _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_BY3PR13MB4787B727C76FE5B767E952049A229BY3PR13MB4787namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

        Hi Greg,

         

        Sure, SRv6 is IPv6 but SRv6 doesn’t equal to I= Pv6. If you define IOAM in IPv6, then what’s its behavior in SRv6? Sh= all it be applied on every node or every SR node? But the more fundamental = issue is that I don’t think putting all of such things in EH TLVs is a good idea. All of the discussions around this which= you are also very familiar make me think we should avoid it if we can.

         

        Best,

        Haoyu

        From: Greg Mirsky <gregimirsky@gmail.com&g= t;
        Sent: Friday, January 28, 2022 12:03 PM
        To: Haoyu Song <haoyu.song@futurewei.com>
        Cc: spring@ietf.org; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [spring] Active OAM in SRv6

         

        Hi Haoyu,

        I'm surprised that you suggest an alternative to the= IPv6 way of collecting IOAM data. SRv6 must use all of IPv6 OAM. Would you= agree? In some rare cases, SRv6-specific extensions to IPv6 OAMAs for the = limited amount of information that can be collected using IPv6 extension headers, IOAM Direct Export, or the Hybrid Two-step provide the solution. Both solve this problem by separa= ting the generation of the IOAM data set from the collection and transport.= You are well-familiar with both drafts.

         

        Regards,

        Greg

         

        On Fri, Jan 28, 2022 at 11:10 AM Haoyu Song <haoyu.song@futurewei.com> wr= ote:

        Hi Greg,

         

        Thanks for the info. I’d like to clarify this work means to = use the standardized IOAM options to support active measurement, so it̵= 7;s fair to say we use IOAM in SRv6 for active measurement. Another point I’d like to mention is that draft-ietf-ippm-ioam-ipv6-options is for IPv6 in general but not for SR= v6 specifically. Moreover, it also use EH TLVs and we propose to use UDP, a= nd it means to support in-band measurement for user traffic.

         

        In my view, SRv6 is the way to steer traffic. If SRv6 networks pre= vail, it’s natural to use the traffic steering feature for probing an= d measurements as well. If we have a unified method to cover as many techniques as possible, we can imagine new techniq= ues can also be introduced easily. Without needing to set up any sessions a= nd maintain any states, the controller can inject probing packets from any = node, steer them on any path, terminate them at any node, and collect any data we like. Such in-network measuremen= t doesn’t need to involve end hosts like PING. It can be used for tra= ffic engineering (e.g., evaluating different paths at background) and for g= ray failure detection and prevention.   

         

        I hope the WG can see the simplicity, extensibility, and great app= lication potential of the proposed scheme, and provide constructive suggest= ions to improve it.

         

        Thanks!

        Haoyu  

         

        From: Greg Mirsky <gregimirsky@gmail.com>
        Sent: Thursday, January 27, 2022 6:17 PM
        To: Haoyu Song <haoyu.song@futurewei.com>
        Cc: spring@ietf= .org; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [spring] Active OAM in SRv6

         

        Hi Haoyu,

        now, without in-lining my notes.

        It appears that you propose not to use draft-ietf-ippm-ioam-ipv6-options. Thus, your proposal cannot be referr= ed to as IOAM in SRv6. At best, it is IOAM-inspired, IOAMish. As a result, = a node supporting standardized IOAM would not understand your probe packet = without an SW upgrade. In my book, that's a new protocol.

        In closing, I'll reference two works by Ruediger Geib, where combining the defined techniques of steering test p= robes with standard IOAM might reveal a lot of useful information about a n= etwork:

        Regards,

        Greg

         

        On Thu, Jan 27, 2022 at 5:44 PM Haoyu Song <haoyu.song@futurewei.com>= wrote:

        Hi Greg, please see Inline

         

        From: Greg Mirsky <gregimirsky@gmail.com>
        Sent: Thursday, January 27, 2022 2:01 PM
        To: Haoyu Song <haoyu.song@futurewei.com>
        Cc: spring@ietf= .org; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [spring] Active OAM in SRv6

         

        Hi Haoyu,

        thank you for your detailed reply. Please find my follow-up notes = in-lined below under the GIM2>> tag.

         

        Regards,

        Greg

         

        On Thu, Jan 27, 2022 at 11:00 AM Haoyu Song <haoyu.song@futurewei.com>= ; wrote:

        Hi Greg,

         

        Thank you for your questions. Please see inline response.

         

        Best,

        Haoyu

         

        From: Greg Mirsky <gregimirsky@gmail.com>
        Sent: Wednesday, January 26, 2022 3:01 PM
        To: Haoyu Song <haoyu.song@futurewei.com>
        Cc: spring@ietf= .org; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [spring] Active OAM in SRv6

         

        Hi Haoyu,

        thank you for bringing the topic of Active OAM to the discussion. = As the concept of Active IOAM is introduced in the IPPM WG draft it seems to me like adding the IPPM WG community to = the discussion is the right thing to do. 

        Please find my notes in-lined below under the GIM>> tag.

         

        Regards,

        Greg

         

        On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song <haoyu.song@futurewei.com>= wrote:

        Hi SPRING WG,

         

        Real time monitor on every node and every link on a network is nec= essary to detect  gray failures, which are the key culprit for poor Qo= S but hard to catch. SR provides an ideal mechanism, when working with some efficient planning algorithm, to achieve= that with low cost.   Our proposal SRv6 In-situ Active Measureme= nt (SIAM) suggests a simple  active measurement approach which can sup= port different

        GIM>> I wonder what gaps you find in the existing active mea= surement protocols, e.g., STAMP and RFC 6734 (would be more convenient to u= se an acronym). It appears to me that, for example, STAMP and its extensions, including the SRPM draft, comprehensively address the PM OAM requirements for SRv6.&n= bsp;

         

        HS>> Let’s give a few features of our proposal: (1) it= ’s session-less and we don’t need assign any roles (e.g.,  = ;reflector); (2) no needs for a return path. The measurement can start and end at any node (solely determined by the SRH); (3) udp-based wh= ich can support any existing IOAM modes and potentially other OAM methods.<= o:p>

        GIM2>> I don't think adding a protocol that can generate a t= est probe from an arbitrary node to arbitrary targets (SRv6 supports multic= ast) is as simple as you present. If an operator needs to monitor the performance of the SR policy used by data packets, IO= AM can be applied to data packets. If the operator wants to explore a polic= y that is not used for data traffic, I imagine IOAM can be added to a test = packet of the existing OAM protocol, e.g., ICMP. Am I missing some of the requirements?

         

        HS2>> For the first point: I don’t think a protocol is= needed here. If one wants to test the path a->b->c->d->e, he d= oesn’t need to find a user packet on that path to carry IOAM (there could be no such packet at all). Instead, he can generate a probe p= acket with an SRH for the path and use the probe packet to carry IOAM. At t= he path end, it simply extracts and exports the IOAM data using the mechani= sm defined for IOAM and drops the probe packet.  

        For the second point: I don’t think ICMP can achieve what IO= AM can do. IOAM is much more powerful in terms of the data it can collect. = Moreover, the proposal can be easily extended to support other kinds of OAM methods. One just carry it in UDP payload us= ing different port. No need to worry about the size if such info has to be = carried in EH TLV.

        options of IOAM and other OAM methods in SRv6, without needing to = worry about the extension header issue.  

        GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows:<= o:p>

           In terms of the classification given

           in [RFC7799] IOAM could be portrayed as Hybrid Type 1= .

        Does your proposal change that?

         

        HS>> In this particular case, IOAM is used for active measur= ement because it’s not included in a user packet.

         

        Your comments, questions, and suggestions are very welcome. I̵= 7;d like to know your opinion if you think this work is in scope and should= be adopted by the working group.  If you are interested in contributing to this work, please also let me know. https://datatracker.ietf.org/doc/draft-song-spring-siam/

         

        Thank you very much!

         

        Best regards,

        Haoyu

        _______________________________________________
        spring mailing list
        spring@ietf.org https://www.ietf.org/mailman/listinfo/spring

        --_000_BY3PR13MB4787B727C76FE5B767E952049A229BY3PR13MB4787namp_-- From nobody Fri Jan 28 19:44:42 2022 Return-Path: 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 BD4783A10AB; Fri, 28 Jan 2022 19:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.896 X-Spam-Level: X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mc-LXhux6agM; Fri, 28 Jan 2022 19:44:30 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E28DC3A10A7; Fri, 28 Jan 2022 19:44:29 -0800 (PST) Received: from fraeml704-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Jm0Tv0dykz67lTK; Sat, 29 Jan 2022 11:40:51 +0800 (CST) Received: from kwepeml100001.china.huawei.com (7.221.188.249) by fraeml704-chm.china.huawei.com (10.206.15.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.21; Sat, 29 Jan 2022 04:44:26 +0100 Received: from kwepeml500004.china.huawei.com (7.221.188.141) by kwepeml100001.china.huawei.com (7.221.188.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Sat, 29 Jan 2022 11:44:24 +0800 Received: from kwepeml500004.china.huawei.com ([7.221.188.141]) by kwepeml500004.china.huawei.com ([7.221.188.141]) with mapi id 15.01.2308.021; Sat, 29 Jan 2022 11:44:24 +0800 From: Tianran Zhou To: Haoyu Song , Greg Mirsky CC: "spring@ietf.org" , IETF IPPM WG Thread-Topic: [spring] Active OAM in SRv6 Thread-Index: AQHYFHrEZbN+DRQ55k+LWpG4w0hByqx4VP+AgAACHACAAQPZQA== Date: Sat, 29 Jan 2022 03:44:24 +0000 Message-ID: <92572d9dd6b545c8993a9945f2e51f97@huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.112.40.195] Content-Type: multipart/alternative; boundary="_000_92572d9dd6b545c8993a9945f2e51f97huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] [spring] Active OAM in SRv6 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 29 Jan 2022 03:44:35 -0000 --_000_92572d9dd6b545c8993a9945f2e51f97huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Haoyu and Greg, I think we are getting clear, the discussion falls into two points: 1. new protocol vs reuse existing protocol 2. IPv6 EH vs UDP Best, Tianran From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Haoyu Song Sent: Saturday, January 29, 2022 4:10 AM To: Greg Mirsky Cc: spring@ietf.org; IETF IPPM WG Subject: Re: [ippm] [spring] Active OAM in SRv6 Hi Greg, Sure, SRv6 is IPv6 but SRv6 doesn't equal to IPv6. If you define IOAM in IP= v6, then what's its behavior in SRv6? Shall it be applied on every node or = every SR node? But the more fundamental issue is that I don't think putting= all of such things in EH TLVs is a good idea. All of the discussions aroun= d this which you are also very familiar make me think we should avoid it if= we can. Best, Haoyu From: Greg Mirsky > Sent: Friday, January 28, 2022 12:03 PM To: Haoyu Song > Cc: spring@ietf.org; IETF IPPM WG > Subject: Re: [spring] Active OAM in SRv6 Hi Haoyu, I'm surprised that you suggest an alternative to the IPv6 way of collecting= IOAM data. SRv6 must use all of IPv6 OAM. Would you agree? In some rare ca= ses, SRv6-specific extensions to IPv6 OAMAs for the limited amount of infor= mation that can be collected using IPv6 extension headers, IOAM Direct Expo= rt,= or the Hybrid Two-step provide the solution. Both solve this problem by separa= ting the generation of the IOAM data set from the collection and transport.= You are well-familiar with both drafts. Regards, Greg On Fri, Jan 28, 2022 at 11:10 AM Haoyu Song > wrote: Hi Greg, Thanks for the info. I'd like to clarify this work means to use the standar= dized IOAM options to support active measurement, so it's fair to say we us= e IOAM in SRv6 for active measurement. Another point I'd like to mention is= that draft-ietf-ippm-ioam-ipv6-options is for IPv6 in general but not for SRv6 s= pecifically. Moreover, it also use EH TLVs and we propose to use UDP, and i= t means to support in-band measurement for user traffic. In my view, SRv6 is the way to steer traffic. If SRv6 networks prevail, it'= s natural to use the traffic steering feature for probing and measurements = as well. If we have a unified method to cover as many techniques as possibl= e, we can imagine new techniques can also be introduced easily. Without nee= ding to set up any sessions and maintain any states, the controller can inj= ect probing packets from any node, steer them on any path, terminate them a= t any node, and collect any data we like. Such in-network measurement doesn= 't need to involve end hosts like PING. It can be used for traffic engineer= ing (e.g., evaluating different paths at background) and for gray failure d= etection and prevention. I hope the WG can see the simplicity, extensibility, and great application = potential of the proposed scheme, and provide constructive suggestions to i= mprove it. Thanks! Haoyu From: Greg Mirsky > Sent: Thursday, January 27, 2022 6:17 PM To: Haoyu Song > Cc: spring@ietf.org; IETF IPPM WG > Subject: Re: [spring] Active OAM in SRv6 Hi Haoyu, now, without in-lining my notes. It appears that you propose not to use draft-ietf-ippm-ioam-ipv6-options. Thus, y= our proposal cannot be referred to as IOAM in SRv6. At best, it is IOAM-ins= pired, IOAMish. As a result, a node supporting standardized IOAM would not = understand your probe packet without an SW upgrade. In my book, that's a ne= w protocol. In closing, I'll reference two works by Ruediger Geib, where combining the defined techn= iques of steering test probes with standard IOAM might reveal a lot of usef= ul information about a network: * RFC 8403 * draft-ietf-ippm-connectivity-monitoring Regards, Greg On Thu, Jan 27, 2022 at 5:44 PM Haoyu Song > wrote: Hi Greg, please see Inline From: Greg Mirsky > Sent: Thursday, January 27, 2022 2:01 PM To: Haoyu Song > Cc: spring@ietf.org; IETF IPPM WG > Subject: Re: [spring] Active OAM in SRv6 Hi Haoyu, thank you for your detailed reply. Please find my follow-up notes in-lined = below under the GIM2>> tag. Regards, Greg On Thu, Jan 27, 2022 at 11:00 AM Haoyu Song > wrote: Hi Greg, Thank you for your questions. Please see inline response. Best, Haoyu From: Greg Mirsky > Sent: Wednesday, January 26, 2022 3:01 PM To: Haoyu Song > Cc: spring@ietf.org; IETF IPPM WG > Subject: Re: [spring] Active OAM in SRv6 Hi Haoyu, thank you for bringing the topic of Active OAM to the discussion. As the co= ncept of Active IOAM is introduced in the IPPM WG draft it seems to me like adding= the IPPM WG community to the discussion is the right thing to do. Please find my notes in-lined below under the GIM>> tag. Regards, Greg On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song > wrote: Hi SPRING WG, Real time monitor on every node and every link on a network is necessary to= detect gray failures, which are the key culprit for poor QoS but hard to = catch. SR provides an ideal mechanism, when working with some efficient pla= nning algorithm, to achieve that with low cost. Our proposal SRv6 In-situ= Active Measurement (SIAM) suggests a simple active measurement approach w= hich can support different GIM>> I wonder what gaps you find in the existing active measurement protoc= ols, e.g., STAMP and RFC 6734 (would be more convenient to use an acronym).= It appears to me that, for example, STAMP and its extensions, including th= e SRPM draft, comprehensively address the PM OAM requirements for SRv6. HS>> Let's give a few features of our proposal: (1) it's session-less and w= e don't need assign any roles (e.g., reflector); (2) no needs for a return= path. The measurement can start and end at any node (solely determined by = the SRH); (3) udp-based which can support any existing IOAM modes and poten= tially other OAM methods. GIM2>> I don't think adding a protocol that can generate a test probe from = an arbitrary node to arbitrary targets (SRv6 supports multicast) is as simp= le as you present. If an operator needs to monitor the performance of the S= R policy used by data packets, IOAM can be applied to data packets. If the = operator wants to explore a policy that is not used for data traffic, I ima= gine IOAM can be added to a test packet of the existing OAM protocol, e.g.,= ICMP. Am I missing some of the requirements? HS2>> For the first point: I don't think a protocol is needed here. If one = wants to test the path a->b->c->d->e, he doesn't need to find a user packet= on that path to carry IOAM (there could be no such packet at all). Instead= , he can generate a probe packet with an SRH for the path and use the probe= packet to carry IOAM. At the path end, it simply extracts and exports the = IOAM data using the mechanism defined for IOAM and drops the probe packet. For the second point: I don't think ICMP can achieve what IOAM can do. IOAM= is much more powerful in terms of the data it can collect. Moreover, the p= roposal can be easily extended to support other kinds of OAM methods. One j= ust carry it in UDP payload using different port. No need to worry about th= e size if such info has to be carried in EH TLV. options of IOAM and other OAM methods in SRv6, without needing to worry abo= ut the extension header issue. GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows: In terms of the classification given in [RFC7799] IOAM could be portrayed as Hybrid Type 1. Does your proposal change that? HS>> In this particular case, IOAM is used for active measurement because i= t's not included in a user packet. Your comments, questions, and suggestions are very welcome. I'd like to kno= w your opinion if you think this work is in scope and should be adopted by = the working group. If you are interested in contributing to this work, ple= ase also let me know. https://datatracker.ietf.org/doc/draft-song-spring-si= am/ Thank you very much! Best regards, Haoyu _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_92572d9dd6b545c8993a9945f2e51f97huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

        Hi Haoyu and Greg,

         

        I think we are getting= clear, the discussion falls into two points:

        1. new protocol vs reu= se existing protocol

        2. IPv6 EH vs UDP=

         

        Best,

        Tianran

         

        From: ippm [mailto:ippm-bounces@ietf.org] = On Behalf Of Haoyu Song
        Sent: Saturday, January 29, 2022 4:10 AM
        To: Greg Mirsky <gregimirsky@gmail.com>
        Cc: spring@ietf.org; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [ippm] [spring] Active OAM in SRv6

         

        Hi Greg,

         

        Sure, SRv6 is IPv6 but SRv6 doesn’t equal to I= Pv6. If you define IOAM in IPv6, then what’s its behavior in SRv6? Sh= all it be applied on every node or every SR node? But the more fundamental = issue is that I don’t think putting all of such things in EH TLVs is a good idea. All of the discussions around this which= you are also very familiar make me think we should avoid it if we can.

         

        Best,

        Haoyu

        From: Greg Mirsky <gregimirsky@gmail.com>
        Sent: Friday, January 28, 2022 12:03 PM
        To: Haoyu Song <haoyu= .song@futurewei.com>
        Cc: spring@ietf.org; IETF IPP= M WG <ippm@ietf.org>
        Subject: Re: [spring] Active OAM in SRv6

         

        Hi Haoyu,

        I'm surprised that you suggest an alternative to the= IPv6 way of collecting IOAM data. SRv6 must use all of IPv6 OAM. Would you= agree? In some rare cases, SRv6-specific extensions to IPv6 OAMAs for the = limited amount of information that can be collected using IPv6 extension headers, IOAM Direct Export, or the Hybrid Two-step provide the solution. Both solve this problem by separa= ting the generation of the IOAM data set from the collection and transport.= You are well-familiar with both drafts.

         

        Regards,

        Greg

         

        On Fri, Jan 28, 2022 at 11:10 AM Haoyu Song <haoyu.song@futurewei.com> wr= ote:

        Hi Greg,

         

        Thanks for the info. I’d like to clarify this work means to = use the standardized IOAM options to support active measurement, so it̵= 7;s fair to say we use IOAM in SRv6 for active measurement. Another point I’d like to mention is that draft-ietf-ippm-ioam-ipv6-options is for IPv6 in general but not for SR= v6 specifically. Moreover, it also use EH TLVs and we propose to use UDP, a= nd it means to support in-band measurement for user traffic.

         

        In my view, SRv6 is the way to steer traffic. If SRv6 networks pre= vail, it’s natural to use the traffic steering feature for probing an= d measurements as well. If we have a unified method to cover as many techniques as possible, we can imagine new techniq= ues can also be introduced easily. Without needing to set up any sessions a= nd maintain any states, the controller can inject probing packets from any = node, steer them on any path, terminate them at any node, and collect any data we like. Such in-network measuremen= t doesn’t need to involve end hosts like PING. It can be used for tra= ffic engineering (e.g., evaluating different paths at background) and for g= ray failure detection and prevention.   

         

        I hope the WG can see the simplicity, extensibility, and great app= lication potential of the proposed scheme, and provide constructive suggest= ions to improve it.

         

        Thanks!

        Haoyu  

         

        From: Greg Mirsky <gregimirsky@gmail.com>
        Sent: Thursday, January 27, 2022 6:17 PM
        To: Haoyu Song <haoyu.song@futurewei.com>
        Cc: spring@ietf= .org; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [spring] Active OAM in SRv6

         

        Hi Haoyu,

        now, without in-lining my notes.

        It appears that you propose not to use draft-ietf-ippm-ioam-ipv6-options. Thus, your proposal cannot be referr= ed to as IOAM in SRv6. At best, it is IOAM-inspired, IOAMish. As a result, = a node supporting standardized IOAM would not understand your probe packet = without an SW upgrade. In my book, that's a new protocol.

        In closing, I'll reference two works by Ruediger Geib, where combining the defined techniques of steering test p= robes with standard IOAM might reveal a lot of useful information about a n= etwork:

        Regards,

        Greg

         

        On Thu, Jan 27, 2022 at 5:44 PM Haoyu Song <haoyu.song@futurewei.com>= wrote:

        Hi Greg, please see Inline

         

        From: Greg Mirsky <gregimirsky@gmail.com>
        Sent: Thursday, January 27, 2022 2:01 PM
        To: Haoyu Song <haoyu.song@futurewei.com>
        Cc: spring@ietf= .org; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [spring] Active OAM in SRv6

         

        Hi Haoyu,

        thank you for your detailed reply. Please find my follow-up notes = in-lined below under the GIM2>> tag.

         

        Regards,

        Greg

         

        On Thu, Jan 27, 2022 at 11:00 AM Haoyu Song <haoyu.song@futurewei.com>= ; wrote:

        Hi Greg,

         

        Thank you for your questions. Please see inline response.

         

        Best,

        Haoyu

         

        From: Greg Mirsky <gregimirsky@gmail.com>
        Sent: Wednesday, January 26, 2022 3:01 PM
        To: Haoyu Song <haoyu.song@futurewei.com>
        Cc: spring@ietf= .org; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [spring] Active OAM in SRv6

         

        Hi Haoyu,

        thank you for bringing the topic of Active OAM to the discussion. = As the concept of Active IOAM is introduced in the IPPM WG draft it seems to me like adding the IPPM WG community to = the discussion is the right thing to do. 

        Please find my notes in-lined below under the GIM>> tag.

         

        Regards,

        Greg

         

        On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song <haoyu.song@futurewei.com>= wrote:

        Hi SPRING WG,

         

        Real time monitor on every node and every link on a network is nec= essary to detect  gray failures, which are the key culprit for poor Qo= S but hard to catch. SR provides an ideal mechanism, when working with some efficient planning algorithm, to achieve= that with low cost.   Our proposal SRv6 In-situ Active Measureme= nt (SIAM) suggests a simple  active measurement approach which can sup= port different

        GIM>> I wonder what gaps you find in the existing active mea= surement protocols, e.g., STAMP and RFC 6734 (would be more convenient to u= se an acronym). It appears to me that, for example, STAMP and its extensions, including the SRPM draft, comprehensively address the PM OAM requirements for SRv6.&n= bsp;

         

        HS>> Let’s give a few features of our proposal: (1) it= ’s session-less and we don’t need assign any roles (e.g.,  = ;reflector); (2) no needs for a return path. The measurement can start and end at any node (solely determined by the SRH); (3) udp-based wh= ich can support any existing IOAM modes and potentially other OAM methods.<= o:p>

        GIM2>> I don't think adding a protocol that can generate a t= est probe from an arbitrary node to arbitrary targets (SRv6 supports multic= ast) is as simple as you present. If an operator needs to monitor the performance of the SR policy used by data packets, IO= AM can be applied to data packets. If the operator wants to explore a polic= y that is not used for data traffic, I imagine IOAM can be added to a test = packet of the existing OAM protocol, e.g., ICMP. Am I missing some of the requirements?

         

        HS2>> For the first point: I don’t think a protocol is= needed here. If one wants to test the path a->b->c->d->e, he d= oesn’t need to find a user packet on that path to carry IOAM (there could be no such packet at all). Instead, he can generate a probe p= acket with an SRH for the path and use the probe packet to carry IOAM. At t= he path end, it simply extracts and exports the IOAM data using the mechani= sm defined for IOAM and drops the probe packet.  

        For the second point: I don’t think ICMP can achieve what IO= AM can do. IOAM is much more powerful in terms of the data it can collect. = Moreover, the proposal can be easily extended to support other kinds of OAM methods. One just carry it in UDP payload us= ing different port. No need to worry about the size if such info has to be = carried in EH TLV.

        options of IOAM and other OAM methods in SRv6, without needing to = worry about the extension header issue.  

        GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows:<= o:p>

           In terms of the classification given

           in [RFC7799] IOAM could be portrayed as Hybrid Type 1= .

        Does your proposal change that?

         

        HS>> In this particular case, IOAM is used for active measur= ement because it’s not included in a user packet.

         

        Your comments, questions, and suggestions are very welcome. I̵= 7;d like to know your opinion if you think this work is in scope and should= be adopted by the working group.  If you are interested in contributing to this work, please also let me know. https://datatracker.ietf.org/doc/draft-song-spring-siam/

         

        Thank you very much!

         

        Best regards,

        Haoyu

        _______________________________________________
        spring mailing list
        spring@ietf.org https://www.ietf.org/mailman/listinfo/spring

        --_000_92572d9dd6b545c8993a9945f2e51f97huaweicom_-- From nobody Sat Jan 29 01:27:20 2022 Return-Path: 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 E7E683A160D for ; Sat, 29 Jan 2022 01:27:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jM6vKyVTBYHe for ; Sat, 29 Jan 2022 01:27:11 -0800 (PST) Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4A43A160B for ; Sat, 29 Jan 2022 01:27:10 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.83]) by rmmx-syy-dmz-app08-12008 (RichMail) with SMTP id 2ee861f5086bdbb-9cfb1; Sat, 29 Jan 2022 17:27:09 +0800 (CST) X-RM-TRANSID: 2ee861f5086bdbb-9cfb1 X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from cmcc-PC (unknown[183.243.251.193]) by rmsmtp-syy-appsvrnew02-12027 (RichMail) with SMTP id 2efb61f50811ff4-ed0c1; Sat, 29 Jan 2022 17:25:40 +0800 (CST) X-RM-TRANSID: 2efb61f50811ff4-ed0c1 Date: Sat, 29 Jan 2022 17:28:42 +0800 From: "lizhenqiang@chinamobile.com" To: Nydell , Zhou Cc: Fioccola , ippm X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.9.156[cn] Mime-Version: 1.0 Message-ID: <2022012917284150500611@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart787273616065_=----" Archived-At: Subject: Re: [ippm] New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 29 Jan 2022 09:27:17 -0000 This is a multi-part message in MIME format. ------=_001_NextPart787273616065_=---- Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGVsbG8gSGVucmlrIGFuZCBhbGwsDQoNCldlIGNvbnNpZGVyZWQgdGhlIHNpdHVhdGlvbiB5b3Ug bWVudGlvbmVkLiBCZWNhc2UgaXQgaXMgZGlmZmljdWx0IHRvIHRyYXZlcnNlIGFsbCB0aGUgcG9z c2libGUgbGluayBjb21iaW5hdGlvbnMsIGkuZS4gdGhlIG51bWJlciBvZiBwb3NzaWJsZSBzdWJz dHJlYW1zIGlzIGh1Z2UsIHdlIHRyeSB0byBhZGRyZXNzIExBRyB0aGF0IGRpcmVjdGx5IGNvbm5l Y3RzIHR3byBkZXZpY2VzIGZpcnN0Lg0KDQoNCg0KQmVzdCBSZWdhcmRzLA0KWmhlbnFpYW5nIExp DQoNCmxpX3poZW5xaWFuZ0Bob3RtYWlsLmNvbQ0KIA0KRnJvbTogSGVucmlrIE55ZGVsbA0KRGF0 ZTogMjAyMi0wMS0yOCAxOTo1Ng0KVG86IFRpYW5yYW4gWmhvdQ0KQ0M6IEdpdXNlcHBlIEZpb2Nj b2xhOyBJRVRGIElQUE0gV0cgXChpcHBtQGlldGYub3JnXCkNClN1YmplY3Q6IFJlOiBbaXBwbV0g TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saS1pcHBtLW90d2FtcC1vbi1sYWct MDIudHh0DQpJIHN0aWxsIHRoaW5rIGl0IHdvdWxkIGJlIG11Y2ggYmV0dGVyIHRvIGdlbmVyYWxp emUgdGhpcyBtaWNybyBUV0FNUCBjb25jZXB0IGFuZCBub3QgdGllIHRoaXMgdG8gTEFHLCBzaW5j ZSB0aGF0IHdpbGwgYmUgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMgLSBvbmx5IGlmIHlvdSBpbXBs ZW1lbnQgVFdBTVAgZGlyZWN0bHkgb24gYSBMQUctZGV2aWNlIHRoaXMgZHJhZnQgd291bGQgYXBw bHkuDQpCZXR0ZXIgdGhlbiB0byBnZW5lcmFsaXplIHRoZSBjb25jZXB0IGFuZCBjYWxsIHRoZSBh ZGRlZCBpZGVudGlmaWVyICJTdWJzdHJlYW0gSUQiIG9yIHNvbWV0aGluZyBzaW1pbGFyLiBUaGVu IHRoaXMgZHJhZnQgd291bGQgYWxzbyBhcHBseSB0byBmb3IgZXhhbXBsZSBhIHZlbmRvciB0aGF0 IGltcGxlbWVudHMgcm91dGluZyBvdmVyIGRpZmZlcmVudCBwYXRocyBvciBhcyBUaWFucmFuIHBv aW50ZWQgb3V0LCBNUExTLVNSIHVzZXMuIFRodXMgSSB3b3VsZCBwcm9wb3NlIHJlbW92aW5nIGFs bCByZWZlcmVuY2VzIHRvIExBRyBpbiB0aGlzIGRyYWZ0IGFuZCB3aWRlbiB0aGUgc2NvcGUgdG8g YW55IHNpdHVhdGlvbiB3aGVyZSB0aGVyZSB3b3VsZCBiZSB1c2VzIGZvciBsYWJlbGxlZCAoSUQ6 ZWQpIHN1YnN0cmVhbXMgYmV0d2VlbiB0aGUgc2FtZSBUV0FNUC1zZW5kZXIgYW5kIHNlc3Npb24t cmVmbGVjdG9yLg0KDQogDQoNCk9uIEZyaSwgSmFuIDI4LCAyMDIyIGF0IDEyOjE1IFBNIFRpYW5y YW4gWmhvdSA8emhvdXRpYW5yYW49NDBodWF3ZWkuY29tQGRtYXJjLmlldGYub3JnPiB3cm90ZToN CkhpIEdpdXNlcHBlLA0KDQpUaGFua3MgdmVyeSBtdWNoIGZvciB5b3VyIHJldmlldy4NCkkgd2ls bCBpbmNvcnBvcmF0ZSB5b3VyIHN1Z2dlc3Rpb25zIGluIHRoZSBuZXh0IHJldmlzaW9uLg0KDQpD aGVlcnMsDQpUaWFucmFuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpcHBt IFttYWlsdG86aXBwbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR2l1c2VwcGUgRmlv Y2NvbGENClNlbnQ6IEZyaWRheSwgSmFudWFyeSAyOCwgMjAyMiA3OjAzIFBNDQpUbzogVGlhbnJh biBaaG91IDx6aG91dGlhbnJhbj00MGh1YXdlaS5jb21AZG1hcmMuaWV0Zi5vcmc+OyBJRVRGIElQ UE0gV0cgKGlwcG1AaWV0Zi5vcmcpIDxpcHBtQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtpcHBt XSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpLWlwcG0tb3R3YW1wLW9uLWxh Zy0wMi50eHQNCg0KSGkgVGlhbnJhbiwgQWxsLA0KSSB0aGluayB0aGF0IHRoaXMgaXMgYSB1c2Vm dWwgd29yay4NCkZvciBMQUcsIHRoZSB1c2Ugb2YgYWN0aXZlIG1ldGhvZHMgKE9XQU1QLCBUV0FN UCwgU1RBTVApIGNhbiBhbHNvIGNvbXBsZW1lbnQgcGFzc2l2ZSBhbmQgaHlicmlkIG1ldGhvZHMu IEluZGVlZCwgdGhlIGV4dGVuc2lvbnMgcHJvcG9zZWQgaW4gdGhpcyBkcmFmdCBhbGxvdyB0byBt b25pdG9yIGFsbCB0aGUgbGlua3MgYW5kIG5vdCBvbmx5IHRoZSBsaW5rIGNyb3NzZWQgYnkgdGhl IG9ic2VydmVkIHBhY2tldCBzdHJlYW0uDQpNYXliZSwgeW91IGNhbiBhbHNvIGhpZ2hsaWdodCB0 aGlzIHBvaW50IGluIHRoZSBpbnRyb2R1Y3Rpb24gc2VjdGlvbi4NCg0KTWlub3Igbml0czoNCnMv UmVmbGVjdG9yIE1lbWJlciBMaW5rIElEIGZpZWxkcy9SZWZsZWN0b3IgTWVtYmVyIExpbmsgSUQg ZmllbGQvDQoNCnMvV2hlbiBzZW5kaW5nIGEgcmVzcG9uc2UgdG8gdGhlIHJlY2VpdmVkIFRlc3Qg cGFja2V0LCB0aGUgbWljcm8gVFdBTVAgU2Vzc2lvbi1TZW5kZXIvIFdoZW4gc2VuZGluZyBhIHJl c3BvbnNlIHRvIHRoZSByZWNlaXZlZCBUZXN0IHBhY2tldCwgdGhlIG1pY3JvIFRXQU1QIFNlc3Np b24tIFJlZmxlY3Rvci8NCg0KDQpSZWdhcmRzLA0KDQpHaXVzZXBwZQ0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpcHBtIDxpcHBtLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJl aGFsZiBPZiBUaWFucmFuIFpob3UNClNlbnQ6IE1vbmRheSwgSmFudWFyeSAyNCwgMjAyMiA3OjIz IEFNDQpUbzogSUVURiBJUFBNIFdHIChpcHBtQGlldGYub3JnKSA8aXBwbUBpZXRmLm9yZz4NClN1 YmplY3Q6IFtpcHBtXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saS1p cHBtLW90d2FtcC1vbi1sYWctMDIudHh0DQoNCkhpIFdHLA0KDQpXZSB0aGluayB0aGlzIGlzIGFu IHVzZWZ1bCB3b3JrIG9uIGFkYXB0aW5nIE9XQU1QL1RXQU1QIGluIExBRyBwZXJmb3JtYW5jZSBt ZWFzdXJlbWVudC4NCldlIHVwZGF0ZWQgdGhpcyBkcmFmdCBiYXNlZCBvbiB0aGUgY29tbWVudHMg ZnJvbSB0aGUgbWVldGluZyBkaXNjdXNzaW9uIGFuZCBtYWlsaW5nIGxpc3QuDQpUaGFua3MgZm9y IGFsbCB0aGUgc3VnZ2VzdGlvbnMuDQpNb3JlIHJldmlld3MgYW5kIGNvbW1lbnRzIGFyZSB3ZWxj b21lLg0KDQpDaGVlcnMsDQpUaWFucmFuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmddIA0KU2VudDogTW9uZGF5LCBKYW51YXJ5IDI0LCAyMDIyIDI6MTcgUE0NClRvOiBHcmVn IE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPjsgR3VvIEp1biA8Z3VvLmp1bjJAenRlLmNv bS5jbj47IEp1biBHdW8gPGd1by5qdW4yQHp0ZS5jb20uY24+OyBSYWtlc2ggR2FuZGhpIDxyZ2Fu ZGhpQGNpc2NvLmNvbT47IFRpYW5yYW4gWmhvdSA8emhvdXRpYW5yYW5AaHVhd2VpLmNvbT47IFpo ZW5xaWFuZyBMaSA8bGlfemhlbnFpYW5nQGhvdG1haWwuY29tPg0KU3ViamVjdDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saS1pcHBtLW90d2FtcC1vbi1sYWctMDIudHh0DQoN Cg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWxpLWlwcG0tb3R3YW1wLW9uLWxhZy0wMi50 eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVGlhbnJhbiBaaG91IGFuZCBw b3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAgICAgICAgIGRyYWZ0LWxp LWlwcG0tb3R3YW1wLW9uLWxhZw0KUmV2aXNpb246ICAgICAgIDAyDQpUaXRsZTogICAgICAgICAg T25lLXdheS9Ud28td2F5IEFjdGl2ZSBNZWFzdXJlbWVudCBQcm90b2NvbCBFeHRlbnNpb25zIGZv ciBQZXJmb3JtYW5jZSBNZWFzdXJlbWVudCBvbiBMQUcNCkRvY3VtZW50IGRhdGU6ICAyMDIyLTAx LTI0DQpHcm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAg ICAgMTMNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2Ry YWZ0LWxpLWlwcG0tb3R3YW1wLW9uLWxhZy0wMi50eHQNClN0YXR1czogICAgICAgICBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1saS1pcHBtLW90d2FtcC1vbi1sYWcvDQpI dG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFm dC1saS1pcHBtLW90d2FtcC1vbi1sYWcNCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbGktaXBwbS1vdHdhbXAtb24tbGFnLTAyDQoNCkFic3Ry YWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGV4dGVuc2lvbnMgdG8gT25lLXdheSBBY3Rp dmUgTWVhc3VyZW1lbnQNCiAgIFByb3RvY29sIChPV0FNUCksIGFuZCBUd28td2F5IEFjdGl2ZSBN ZWFzdXJlbWVudCBQcm90b2NvbCAoVFdBTVApIHRvDQogICBpbXBsZW1lbnQgcGVyZm9ybWFuY2Ug bWVhc3VyZW1lbnQgb24gZXZlcnkgbWVtYmVyIGxpbmsgb2YgYSBMaW5rDQogICBBZ2dyZWdhdGlv biBHcm91cCAoTEFHKS4gIEtub3dpbmcgdGhlIG1lYXN1cmVkIG1ldHJpY3Mgb2YgZWFjaCBtZW1i ZXINCiAgIGxpbmsgb2YgYSBMQUcgZW5hYmxlcyBvcGVyYXRvcnMgdG8gZW5mb3JjZSB0aGUgcGVy Zm9ybWFuY2UgYmFzZWQNCiAgIHRyYWZmaWMgc3RlZXJpbmcgcG9saWN5IGFjcm9zcyB0aGUgbWVt YmVyIGxpbmtzLg0KDQoNCg0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmlwcG0gbWFpbGluZyBsaXN0 DQppcHBtQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lw cG0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmlw cG0gbWFpbGluZyBsaXN0DQppcHBtQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lwcG0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCmlwcG0gbWFpbGluZyBsaXN0DQppcHBtQGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0NCg0KDQotLSANCg0KSGVucmlrIE55ZGVs bA0KU3IgUHJvZHVjdCBNYW5hZ2VyDQoxLjg2Ni42ODUuODE4MQ0KaG55ZGVsbEBhY2NlZGlhbi5j b20NCg0KICANCg0KYWNjZWRpYW4uY29tDQoNCkF2aXMgZGUgY29uZmlkZW50aWFsaXSopg0KTGVz IGluZm9ybWF0aW9ucyBjb250ZW51ZXMgZGFucyBsZSBwcqimc2VudCBtZXNzYWdlIGV0IGRhbnMg dG91dGUgcGmoqGNlIHF1aSBsdWkgZXN0IGpvaW50ZSBzb250IGNvbmZpZGVudGllbGxlcyBldCBw ZXV2ZW50IKi6dHJlIHByb3SopmeopmVzIHBhciBsZSBzZWNyZXQgcHJvZmVzc2lvbm5lbC4gQ2Vz IGluZm9ybWF0aW9ucyBzb250IKikIGyhr3VzYWdlIGV4Y2x1c2lmIGRlIHNvbiBvdSBkZSBzZXMg ZGVzdGluYXRhaXJlcy4gU2kgdm91cyByZWNldmV6IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1 aWxsZXogc6GvaWwgdm91cyBwbGFpdCBjb21tdW5pcXVlciBpbW2opmRpYXRlbWVudCBhdmVjIGyh r2V4cKimZGl0ZXVyIGV0IGVuIGSopnRydWlyZSB0b3V0IGV4ZW1wbGFpcmUuIERlIHBsdXMsIGls IHZvdXMgZXN0IHN0cmljdGVtZW50IGludGVyZGl0IGRlIGxlIGRpdnVsZ3VlciwgZGUgbGUgZGlz dHJpYnVlciBvdSBkZSBsZSByZXByb2R1aXJlIHNhbnMgbKGvYXV0b3Jpc2F0aW9uIGRlIGyhr2V4 cKimZGl0ZXVyLiBNZXJjaS4NCkNvbmZpZGVudGlhbGl0eSBub3RpY2UNClRoaXMgZS1tYWlsIG1l c3NhZ2UgYW5kIGFueSBhdHRhY2htZW50IGhlcmV0byBjb250YWluIGNvbmZpZGVudGlhbCBpbmZv cm1hdGlvbiB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBhbmQgd2hpY2ggaXMgaW50ZW5kZWQgZm9y IHRoZSBleGNsdXNpdmUgdXNlIG9mIGl0cyBhZGRyZXNzZWUocykuIElmIHlvdSByZWNlaXZlIHRo aXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5k IGRlc3Ryb3kgYW55IGNvcHkgdGhlcmVvZi4gRnVydGhlcm1vcmUsIGFueSBkaXNjbG9zdXJlLCBk aXN0cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlzIG1lc3NhZ2UgYW5kL29yIGFueSBhdHRhY2ht ZW50IGhlcmV0byB3aXRob3V0IHRoZSBjb25zZW50IG9mIHRoZSBzZW5kZXIgaXMgc3RyaWN0bHkg cHJvaGliaXRlZC4gVGhhbmsgeW91Lg0K ------=_001_NextPart787273616065_=---- Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable =0A
        =
        Hello Henrik and all,

        =
        We considered the situation you mentioned. Becase it is di= fficult to traverse all the possible link combinations, i.e. the number of= possible substreams is huge, we try to address LAG that directly connects= two devices first.

        Best Regards,
        Zhenqiang Li

        li_zhenqiang@hotmail.com
         
        From:=  Henrik Nydell
        Date: 2022-01-= 28 19:56
        =
        Subject: Re: [ippm] New Version Notification for draft-li= -ippm-otwamp-on-lag-02.txt
        <= div class=3D"gmail_default" style=3D"font-size: small;">I still think it w= ould be much better to generalize this micro TWAMP concept and not tie thi= s to LAG, since that will be implementation specific - only if you impleme= nt TWAMP directly on a LAG-device this draft would apply.
        Better then to generalize t= he concept and call the added identifier "Substream ID" or something simil= ar. Then this draft would also apply to for example a vendor that implemen= ts routing over different paths or as Tianran pointed out, MPLS-SR uses. T= hus I would propose removing all references to LAG in this draft and widen= the scope to any situation where there would be uses for labelled (I= D:ed) substreams between the same TWAMP-sender and session-reflector.

         

        <= div class=3D"gmail_quote">
        On Fri, Ja= n 28, 2022 at 12:15 PM Tianran Zhou <zhoutianran=3D40h= uawei.com@dmarc.ietf.org> wrote:
        Hi= Giuseppe,

        Thanks very much for your review.
        I will incorporate = your suggestions in the next revision.

        Cheers,
        Tianran

        --= ---Original Message-----
        From: ippm [mailto:40huawei.com@dmarc.ietf.org>; IETF IPPM= WG (ippm@ietf.org) <ippm= @ietf.org>
        Subject: Re: [ippm] New Version Notification for draf= t-li-ippm-otwamp-on-lag-02.txt

        Hi Tianran, All,
        I think that thi= s is a useful work.
        For LAG, the use of active methods (OWAMP, TWAMP, S= TAMP) can also complement passive and hybrid methods. Indeed, the extensio= ns proposed in this draft allow to monitor all the links and not only the = link crossed by the observed packet stream.
        Maybe, you can also highlig= ht this point in the introduction section.

        Minor nits:
        s/Reflect= or Member Link ID fields/Reflector Member Link ID field/

        s/When sen= ding a response to the received Test packet, the micro TWAMP Session-Sende= r/ When sending a response to the received Test packet, the micro TWAMP Se= ssion- Reflector/


        Regards,

        Giuseppe


        -----Orig= inal Message-----
        From: ippm <ippm-boun= ces@ietf.org> On Behalf Of Tianran Zhou
        Sent: Monday, January 24= , 2022 7:23 AM
        To: IETF IPPM WG (ippm@ietf.org= ) <ippm@ietf.org>
        Subject: [ippm] FW: Ne= w Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

        Hi WG= ,

        We think this is an useful work on adapting OWAMP/TWAMP in LAG pe= rformance measurement.
        We updated this draft based on the comments from= the meeting discussion and mailing list.
        Thanks for all the suggestion= s.
        More reviews and comments are welcome.

        Cheers,
        Tianran
        =
        -----Original Message-----
        From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
        Sent: Monday, January 24, 2022 2= :17 PM
        To: Greg Mirsky <gregimirsky@gma= il.com>; Guo Jun <guo.jun2@zte.com.c= n>; Jun Guo <guo.jun2@zte.com.cn&= gt;; Rakesh Gandhi <rgandhi@cisco.com>;= Tianran Zhou <zhoutianran@huawei.com= >; Zhenqiang Li <li_zhenqiang@hotma= il.com>
        Subject: New Version Notification for draft-li-ippm-otwa= mp-on-lag-02.txt


        A new version of I-D, draft-li-ippm-otwamp-on-= lag-02.txt
        has been successfully submitted by Tianran Zhou and posted t= o the IETF repository.

        Name:          &nbs= p;draft-li-ippm-otwamp-on-lag
        Revision:       02Title:          One-way/Two-way Active Measureme= nt Protocol Extensions for Performance Measurement on LAG
        Document date= :  2022-01-24
        Group:          Individual = Submission
        Pages:          13
        URL:  &n= bsp;         https://www.ietf.org/arc= hive/id/draft-li-ippm-otwamp-on-lag-02.txt
        Status:    &nb= sp;    https://datatracker.ietf.org/doc/draft-li-ippm-otw= amp-on-lag/
        Htmlized:       https://= datatracker.ietf.org/doc/html/draft-li-ippm-otwamp-on-lag
        Diff:&nbs= p;          https://www.ietf.org/rfcd= iff?url2=3Ddraft-li-ippm-otwamp-on-lag-02

        Abstract:
          &= nbsp;This document defines extensions to One-way Active Measurement
        &nb= sp;  Protocol (OWAMP), and Two-way Active Measurement Protocol (TWAMP= ) to
           implement performance measurement on every member lin= k of a Link
           Aggregation Group (LAG).  Knowing the mea= sured metrics of each member
           link of a LAG enables operato= rs to enforce the performance based
           traffic steering polic= y across the member links.





        The IETF Secretariat
        =

        _______________________________________________
        ippm mailing li= st
        ippm@ietf.org
        https://www.ietf.org/mailman/listinfo/= ippm

        _______________________________________________
        ippm ma= iling list
        ippm@ietf.org
        https://www.ietf.org/mailman/l= istinfo/ippm

        _______________________________________________ippm mailing list
        ippm@ietf.org
        https://www.ietf.org/m= ailman/listinfo/ippm


        =
        -- 

        Henrik Nydell
        Sr Product Manager
        1.866.685.8181
        hnydell@accedian.com
        3D""
        3D"" 3D"" 3D""
        3D""
        acced= ian.com

        Avis de confidentialit=A8=A6

        = Les informations contenues dans le p= r=A8=A6sent message et dans toute pi=A8=A8ce qui lui est jointe sont confi= dentielles et peuvent =A8=BAtre prot=A8=A6g=A8=A6es par le secret professi= onnel. Ces informations sont =A8=A4 l=A1=AFusage exclusif de son ou de ses= destinataires. Si vous recevez ce message par erreur, veuillez s=A1=AFil = vous plait communiquer imm=A8=A6diatement avec l=A1=AFexp=A8=A6diteur et e= n d=A8=A6truire tout exemplaire. De plus, il vous est strictement interdit= de le divulguer, de le distribuer ou de le reproduire sans l=A1=AFautoris= ation de l=A1=AFexp=A8=A6diteur. Merci.

        =

        Confidentiality notice

        This e-mail message and any attachment h= ereto contain confidential information which may be privileged and which i= s intended for the exclusive use of its addressee(s). If you receive this = message in error, please inform sender immediately and destroy any copy th= ereof. Furthermore, any disclosure, distribution or copying of this messag= e and/or any attachment hereto without the consent of the sender is strict= ly prohibited. Thank you.

        <= /div>
        =0A ------=_001_NextPart787273616065_=------ From nobody Sun Jan 30 09:40:51 2022 Return-Path: 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 302823A18D2; Sun, 30 Jan 2022 09:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KpNARkVG84r; Sun, 30 Jan 2022 09:40:44 -0800 (PST) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E7663A18D0; Sun, 30 Jan 2022 09:40:44 -0800 (PST) Received: by mail-pj1-x1036.google.com with SMTP id h12so11513845pjq.3; Sun, 30 Jan 2022 09:40:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=orrGPHaDnSO8jTer0BmE9CFa3yWBgxemxJd9RA2CqXs=; b=j07I/Qd9P0G8DRDx2ZfxzVT02iqyaoULv03s55Q9bNO5Yg0T1s2hicW2wUBeRsbuVs h6gnxWTMMeJElUEJGLvtTbqCAtv8VThMEHZHPrLSL3NKGmXHwZNe5m+zKkDr5hoBW5gL jUCK3aWagay7Zjm6Dp3vQAIiR/gKyzGB613btdWh9u3nbYdfXxat54XhPm8+YIq+6KiF GATFtEo31XKd5Io3pCyURcywUdHDVmM4837HBz19vr0fWyo+Lr1kB3h3xg+UjmfliVyX gD3iyqRqmwl05zZhFAUUzfk3UPyjVOmK2Ic6lZSp+CHTXq1GycADKIn18QrIL7J6Gl/m VXoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=orrGPHaDnSO8jTer0BmE9CFa3yWBgxemxJd9RA2CqXs=; b=D53WUZptg0dDH5mIcLcKecAVU65qaR3o6Eh1Oswi2gBCI/S4UoDmMmxAlZf5FXIPCg LbB5G8H4b0DOEKZQpSSjCDoPSV3a4jzHOffmC8QDSxQZeer/miCm37QTiuyNE+hILIsg C6+X+YYcubVkFcE181boLEVJSN+O0puPgHJZjZOlqvemYf7AnsQPsFStYZQJcFr18wwP vWPCPBd9yeMeg6v3IFEISHpsFlTCYidfyVk9+o7q6iZWqHc8y6WpVsETpMOfRFhS/HKc lC4cusBzDwxCuZZgjL81jMInm1Z/Z4duho8Xf0wpZYul292240SObFw82F5IfFi3YThh PBtg== X-Gm-Message-State: AOAM530PoSkQ2/K3lo6mYWeIoFNUN6FjdzzJk2hu+MR+xij+jT3XBKQu M+YX4AeZgj8BuEkKqUiudtF04X89MABsjULqeSU= X-Google-Smtp-Source: ABdhPJy0dg9zN88pFHqdz/Ph1n+2XCVQascMO+rZ0FZesyyDcMOPiP9cN9Xd+TuH+bu09J8PcM4R3krWpPS4doXm99w= X-Received: by 2002:a17:90a:e7ce:: with SMTP id kb14mr30002991pjb.202.1643564442635; Sun, 30 Jan 2022 09:40:42 -0800 (PST) MIME-Version: 1.0 References: <97ee51feb17c4bcc84bc575768c06c3e@huawei.com> In-Reply-To: From: Gyan Mishra Date: Sun, 30 Jan 2022 12:40:31 -0500 Message-ID: To: Haoyu Song Cc: Greg Mirsky , IETF IPPM WG , Tianran Zhou , "spring@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c4d55905d6d02a91" Archived-At: Subject: Re: [ippm] [spring] Active OAM in SRv6 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2022 17:40:49 -0000 --000000000000c4d55905d6d02a91 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Haoyu On Thu, Jan 27, 2022 at 1:42 PM Haoyu Song wrote= : > Hi Gyan, > > > > Thank you for your comments! Please see inline for response marked with > [HS] > > > > Best, > > Haoyu > > > > *From:* Gyan Mishra > *Sent:* Wednesday, January 26, 2022 9:03 PM > *To:* Tianran Zhou > *Cc:* Greg Mirsky ; Haoyu Song < > haoyu.song@futurewei.com>; IETF IPPM WG ; spring@ietf.org > *Subject:* Re: [ippm] [spring] Active OAM in SRv6 > > > > Hi Haoyu > > > > I think it would be good to identify the problem statement and gap with > existing IPPM WG STAMP, TWAMP PM technologies and why they cannot be > utilized or fall short in what you are trying to achieve with Active OAM = in > SRv6. > > > > [HS] My understanding is that STAMP/TWAMP are for end-to-end measurements= , > here we want to collect data from every node and every link on any path, > without needing to set up any sessions. So the scope and coverage are > different. > > Gyan> Understood. STAMP/TWAMP can be used as well to collect from every > node as well. > > In-situ IOAM data packets is already possible with SRv6 as mentioned as > this draft mentions below as normative reference. > > > > https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-data-16 > > > > > [HS] There=E2=80=99s no accepted solution on how to support IOAM in SRv6 = yet. Our > proposal aims to provide such a solution, and (1) the solution avoids the > issues on encapsulating the IOAM trace in EHs and (2) it=E2=80=99s extens= ible to > include OAM methods beyond IOAM. > > Gyan> IPPM WG can speak to this document which has been adopted and been > developed since 2016 and provides in-situ OAM as you desire and supports > Segment Routing SRv6 as well as other encapsulations. > > This draft as well mentioned as normative reference draft below provides > OAM ping and traceroute with SRH O flag to SRv6 PGM endpoints and SID lis= t > tracing capabilities very handy for troubleshooting. > > > > https://datatracker.ietf.org/doc/html/draft-ietf-6man-spring-srv6-oam-1 > > 3 > > > > [HS] This is for in-band OAM for SRv6 user traffic and it only works for > triggering postcard exports (i.e., don=E2=80=99t allow the packet to carr= y data). > Our proposal support all the IOAM options and more important, it=E2=80=99= s an > active method which means one can generate and inject probing packets to > cover arbitrary paths by crafting an SRH. > > Gyan> Understood > > This draft as well also mentioned as normative reference draft below > provides in-situ IOAM for OAM and PM information can be piggybacked in da= ta > packets in SRH TLV SRv6 PGM SIF function SRv6.TLV recording the operation= al > and telemetry info in the data packets. > > > > https://datatracker.ietf.org/doc/html/draft-ali-spring-ioam-srv6-05 > > > > > [HS] This draft proposes to encapsulate IOAM in SRH TLV. Due to the > overhead concern (IOAM trace could be large) and other issues related to > EH, I don=E2=80=99t support such a solution. > > Gyan> Understood. Work is being done in 6MAN WG to address EH headers > issues below as well as other drafts to make EH viable and reduce overhea= d. > https://datatracker.ietf.org/doc/html/draft-herbert-6man-eh-limits-00.txt [HS] The three drafts you mentioned are all be reference in our draft and > discussed. We think our use cases are different and our approach is more > general and extensible to our use cases. > > Gyan> Understood. I think if you can add some additional verbiage as to > problem statement and why existing solutions drafts mentioned are not > sufficient for your requirements. Maybe listing out your requirements > would help couple to your proposed solution. > > Thanks > > > > Gyan > > > > On Wed, Jan 26, 2022 at 10:19 PM Tianran Zhou 40huawei.com@dmarc.ietf.org> wrote: > > Hi Haoyu, > > > > The application is really interesting and useful. > > I am not sure if it is necessary to create a new OAM protocol at transpor= t > layer. > > IMHO, a per hop/per segment extension based on STAMP could be more > practical. > > https://www.ietf.org/archive/id/draft-wang-ippm-stamp-hbh-extensions-03.t= xt > > > > > Best, > > Tianran > > > > *From:* ippm [mailto:ippm-bounces@ietf.org] *On Behalf Of *Greg Mirsky > *Sent:* Thursday, January 27, 2022 7:01 AM > *To:* Haoyu Song > *Cc:* spring@ietf.org; IETF IPPM WG > *Subject:* Re: [ippm] [spring] Active OAM in SRv6 > > > > Hi Haoyu, > > thank you for bringing the topic of Active OAM to the discussion. As the > concept of Active IOAM is introduced in the IPPM WG draft > it > seems to me like adding the IPPM WG community to the discussion is the > right thing to do. > > Please find my notes in-lined below under the GIM>> tag. > > > > Regards, > > Greg > > > > On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song > wrote: > > Hi SPRING WG, > > > > Real time monitor on every node and every link on a network is necessary > to detect gray failures, which are the key culprit for poor QoS but hard > to catch. SR provides an ideal mechanism, when working with some efficien= t > planning algorithm, to achieve that with low cost. Our proposal SRv6 > In-situ Active Measurement (SIAM) suggests a simple active measurement > approach which can support different > > GIM>> I wonder what gaps you find in the existing active measurement > protocols, e.g., STAMP and RFC 6734 (would be more convenient to use an > acronym). It appears to me that, for example, STAMP and its extensions, > including the SRPM draft > , > comprehensively address the PM OAM requirements for SRv6. > > options of IOAM and other OAM methods in SRv6, without needing to worry > about the extension header issue. > > GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows: > > In terms of the classification given > > in [RFC7799] IOAM could be portrayed as Hybrid Type 1. > > Does your proposal change that? > > > > Your comments, questions, and suggestions are very welcome. I=E2=80=99d l= ike to > know your opinion if you think this work is in scope and should be adopte= d > by the working group. If you are interested in contributing to this work= , > please also let me know. > https://datatracker.ietf.org/doc/draft-song-spring-siam/ > > > > > Thank you very much! > > > > Best regards, > > Haoyu > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > > -- > > > > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mishra@verizon.com * > > *M 301 502-1347* > > > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --000000000000c4d55905d6d02a91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
        Hi=C2=A0Haoyu

        On Thu, Jan 27, 2022 at 1:42 PM Haoyu S= ong <haoyu.song@futurewei.co= m> wrote:

        Hi Gyan,

        =C2=A0

        Thank you for your comments! Please see inline for r= esponse marked with [HS]

        =C2=A0

        Best,

        Haoyu

        =C2=A0

        From: Gyan Mishra <hayabusagsm@gmail.com>
        Sent: Wednesday, January 26, 2022 9:03 PM
        To: Tianran Zhou <zhoutianran=3D40huawei.com@dmarc.ietf.org>
        Cc: Greg Mirsky <gregimirsky@gmail.com>; Haoyu Song <haoyu.song@futurewei.com&g= t;; IETF IPPM WG <ipp= m@ietf.org>; sp= ring@ietf.org
        Subject: Re: [ippm] [spring] Active OAM in SRv6

        =C2=A0

        Hi Haoyu=C2=A0

        =C2=A0

        I think it would be good to identify the problem sta= tement and gap with existing IPPM WG STAMP, TWAMP PM technologies and why t= hey cannot be utilized or fall short in what you are trying to=C2=A0achieve= with Active OAM in SRv6.=C2=A0

        =C2=A0

        [HS] My understanding is that STAMP/TWAMP are for en= d-to-end measurements, here we want to collect data from every node and eve= ry link on any path, without needing to set up any sessions. So the scope a= nd coverage are different. =C2=A0

        =C2=A0Gyan> Understood.=C2=A0= STAMP/TWAMP can be used as well to collect from every node as well.=

        In-situ IOAM data packets is already possible with S= Rv6 as mentioned as this draft mentions below as normative reference.

        =C2=A0

        https://datatr= acker.ietf.org/doc/html/draft-ietf-ippm-ioam-data-16

        =C2=A0

        [HS] There=E2=80=99s no accepted solution on how to = support IOAM in SRv6 yet. Our proposal aims to provide such a solution, and= (1) the solution avoids the issues on encapsulating the IOAM trace in EHs = and (2) it=E2=80=99s extensible to include OAM methods beyond IOAM.

        =C2=A0Gyan> IPPM WG can speak= to this document which has been adopted and been developed since 2016 and = provides in-situ OAM as you desire and supports Segment Routing SRv6 as wel= l as other encapsulations.

        This draft as well mentioned as normative reference = draft below provides OAM ping and traceroute with SRH O flag to SRv6 PGM en= dpoints and SID list tracing capabilities very handy for troubleshooting.

        =C2=A0

        =C2=A0

        [HS] This is for in-band OAM for SRv6 user traffic a= nd it only works for triggering postcard exports (i.e., don=E2=80=99t allow= the packet to carry data). Our proposal support all the IOAM options and m= ore important, it=E2=80=99s an active method which means one can generate and inject probing packets to cover arbitrary paths= by crafting an SRH.

        =C2=A0Gyan> Understood=C2=A0<= u>

        This draft as well also mentioned as normative refer= ence draft below provides in-situ IOAM for OAM and PM information can be pi= ggybacked in data packets in SRH TLV SRv6 PGM SIF function SRv6.TLV recordi= ng the operational and telemetry info in the data packets.

        [HS] This draft proposes to encapsulate IOAM in SRH = TLV. Due to the overhead concern (IOAM trace could be large) and other issu= es related to EH, I don=E2=80=99t support such a solution.

        =C2=A0Gyan> Understood.=C2=A0= Work is being done in 6MAN WG to address EH headers issues below as well a= s other drafts to make EH viable and reduce overhead.

        =



        [HS] The three drafts you mentioned are all be refer= ence in our draft and discussed. We think our use cases are different and o= ur approach is more general and extensible to our use cases.<= /p>

        Gyan> Understood.=C2=A0 I thi= nk if you can add some additional verbiage as to problem statement and why = existing solutions drafts mentioned are not sufficient for your requirement= s.=C2=A0 Maybe listing out your requirements would help couple to your prop= osed solution.=C2=A0

        Thanks=C2=A0

        =C2=A0

        Gyan=C2=A0

        =C2=A0

        On Wed, Jan 26, 2022 at 10:19 PM Tianran Zhou <zh= outianran=3D40huawei.com@dmarc.ietf.org> wrote:

        Hi Haoyu,

        =C2=A0

        The application= is really interesting and useful.

        I am not sure i= f it is necessary to create a new OAM protocol at transport layer.

        IMHO, a per hop= /per segment extension based on STAMP could be more practical.

        https://www.ietf.org/archive/id/draft-wang-ippm= -stamp-hbh-extensions-03.txt

        =C2=A0

        Best,=

        Tianran =C2=A0<= /span>

        =C2=A0

        From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Greg Mirsky
        Sent: Thursday, January 27, 2022 7:01 AM
        To: Haoyu Song <haoyu.song@futurewei.com>
        Cc: spring@ietf= .org; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [ippm] [spring] Active OAM in SRv6

        =C2=A0

        Hi Haoyu,

        thank you for bringing the topic of Active OAM to th= e discussion. As the concept of Active IOAM is introduced in the IPPM WG draft=C2=A0it seems to me like adding the IPPM WG community to = the discussion is the right thing to do.=C2=A0

        Please find my notes in-lined below under the GIM>= ;> tag.

        =C2=A0

        Regards,

        Greg

        =C2=A0

        On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song <haoyu.song@futurew= ei.com> wrote:

        Hi SPRING WG,

        =C2=A0

        Real time monitor on every node and every link on a = network is necessary to detect =C2=A0gray failures, which are the key culpr= it for poor QoS but hard to catch. SR provides an ideal mechanism, when working with some efficient planning algorithm, to achieve= that with low cost. =C2=A0=C2=A0Our proposal SRv6 In-situ Active Measureme= nt (SIAM) suggests a simple =C2=A0active measurement approach which can sup= port different

        GIM>> I wonder what gaps you find in the exist= ing active measurement protocols, e.g., STAMP and RFC 6734 (would be more c= onvenient to use an acronym). It appears to me that, for example, STAMP and its extensions, including the SRPM draft, comprehensively address the PM OAM requirements for SRv6.= =C2=A0

        options of IOAM and other OAM methods in SRv6, witho= ut needing to worry about the extension header issue. =C2=A0<= /p>

        GIM>> draft-ietf-ippm-ioam-data classifies IOA= M as follows:

        =C2=A0 =C2=A0In terms of the classification given=

        =C2=A0 =C2=A0in [RFC7799] IOAM could be portrayed as= Hybrid Type 1.

        Does your proposal change=C2=A0that?

        =C2=A0

        Your comments, questions, and suggestions are very w= elcome. I=E2=80=99d like to know your opinion if you think this work is in = scope and should be adopted by the working group.=C2=A0 If you are interested in contributing to this work, please also let me know. https://datatracker.ietf.org/doc/draft-song-spring-siam/<= /p>

        =C2=A0

        Thank you very much!

        =C2=A0

        Best regards,

        Haoyu

        _______________________________________________
        spring mailing list
        spring@ietf.org https://www.ietf.org/mailman/listinfo/spring<= /u>

        _______________________________________________
        ippm mailing list
        ippm@ietf.org
        https://www.ietf.org/mailman/listinfo/ippm=

        --

        =

        Gyan Mishra

        Network Solutions Architect=C2=A0

        Email gyan.s.mishra@verizon.com

        M 301 502-1347

        =C2=A0

        --
        --000000000000c4d55905d6d02a91-- From nobody Mon Jan 31 04:56:28 2022 Return-Path: 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 910403A2FBC for ; Mon, 31 Jan 2022 04:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=accedian.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llJIMO6WFR0O for ; Mon, 31 Jan 2022 04:56:21 -0800 (PST) Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A99683A2FB4 for ; Mon, 31 Jan 2022 04:56:21 -0800 (PST) Received: by mail-yb1-xb29.google.com with SMTP id i62so40067395ybg.5 for ; Mon, 31 Jan 2022 04:56:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=accedian.com; s=corp1; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zssRB12KEo1KLpakrI7KKu37nj/0K+yoyIZ9+AsvSLM=; b=JTxpHDvXjgo+ckWRvsqBMqoYsIaV5A2ApDr9I0HnL5GpxmA8JgRu9qQois5mugJfAZ hMIllc1tkbuIfbLJUuObvoPDqxquvY55WmEo7/THC/yFpPwu3K5GOfpxjWoEbnR/kNcu d5VnHwtXDUgwfor9imymeyQ73wFfcL8tgV+IopxGt3z0TLVar7zNtktpt3QCNrp3WN81 qmS2X2JmAhnLGmakfR/Si9ALMHBjV7g0ncgTrksJiCkayVWt78AIGk6PQyGeRwIlaWiG HuujRJDZ3kGGtlushcwQKWtjinKvBKLvoI0UwUFfjv+QdqeSfNO/dNh+uBh5ccAJHWI8 dRvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zssRB12KEo1KLpakrI7KKu37nj/0K+yoyIZ9+AsvSLM=; b=aanSXKex8CLR9PEF7tS10G9yLz33grMs+U+itbicrPun5pWFJDbkT3jZCYcrADm7dP lNh1kHWDU2SM/uPXiIZtR9TCzxU7QOOhnCgqYVPiRpPO+nhtzw3fjyvHwE3HO+VwGq/C 8HnvA0FYXgMcFcJW4NUq9WmF6djz3d/d8/BJxiXpisDIy35PLV6WnPXZEpO+73ypZXN4 LkiX55HLLMguXq1HelABCnbo1c4E+I80dqI3kFF+VTIf/oZ40ZXhd6boh3syrWSOKsEv tMuZuLCTnkMOCAhOecwW3KWaWHewcC9Sci4n0wOr3YFA24owz+Ho8rtHiQgpMQC3IJXa 9NdA== X-Gm-Message-State: AOAM531ZgPyMMij/8kk2cnJZoVuVSUq9x4bF++ymMSjxd7N2OcwyYNXR eX/iytj5dXNq6rX69f/MNJlQzIcWzZZ/5Xi/+9auXKEqYsKv9mlzhCpbACg7S6yLCnFQJh0YWhj tSHKK2R5G7svbiOM= X-Google-Smtp-Source: ABdhPJy+TCVThm9ZE+/WHj4aTgkrpp+Y2CDI/Y+PMhCtKf68PrG5u7cvoC0fBCk6ZJXh9FtzuRpx1giPHyD7dn6Owpw= X-Received: by 2002:a25:ce92:: with SMTP id x140mr20739678ybe.623.1643633779412; Mon, 31 Jan 2022 04:56:19 -0800 (PST) MIME-Version: 1.0 References: <2022012917284150500611@chinamobile.com> In-Reply-To: <2022012917284150500611@chinamobile.com> From: Henrik Nydell Date: Mon, 31 Jan 2022 13:56:02 +0100 Message-ID: To: "lizhenqiang@chinamobile.com" Cc: Zhou , Fioccola , ippm Content-Type: multipart/alternative; boundary="0000000000009025f505d6e04f5e" Archived-At: Subject: Re: [ippm] New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2022 12:56:27 -0000 --0000000000009025f505d6e04f5e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, that is understood, which is why I think TWAMP (being layer-3) is an odd choice for this. A layer-2 test like Y.1731 would be more suitable to monitor performance of individual LAG links. On Sat, Jan 29, 2022 at 10:28 AM lizhenqiang@chinamobile.com < lizhenqiang@chinamobile.com> wrote: > Hello Henrik and all, > > We considered the situation you mentioned. Becase it is difficult to > traverse all the possible link combinations, i.e. the number of possible > substreams is huge, we try to address LAG that directly connects two > devices first. > > ------------------------------ > Best Regards, > Zhenqiang Li > > li_zhenqiang@hotmail.com > > > *From:* Henrik Nydell > *Date:* 2022-01-28 19:56 > *To:* Tianran Zhou > *CC:* Giuseppe Fioccola = ; IETF > IPPM WG \(ippm@ietf.org\) > *Subject:* Re: [ippm] New Version Notification for > draft-li-ippm-otwamp-on-lag-02.txt > I still think it would be much better to generalize this micro TWAMP > concept and not tie this to LAG, since that will be implementation specif= ic > - only if you implement TWAMP directly on a LAG-device this draft would > apply. > Better then to generalize the concept and call the added identifier > "Substream ID" or something similar. Then this draft would also apply to > for example a vendor that implements routing over different paths or as > Tianran pointed out, MPLS-SR uses. Thus I would propose removing all > references to LAG in this draft and widen the scope to any situation wher= e > there would be uses for labelled (ID:ed) substreams between the same > TWAMP-sender and session-reflector. > > > > On Fri, Jan 28, 2022 at 12:15 PM Tianran Zhou 40huawei.com@dmarc.ietf.org> wrote: > >> Hi Giuseppe, >> >> Thanks very much for your review. >> I will incorporate your suggestions in the next revision. >> >> Cheers, >> Tianran >> >> -----Original Message----- >> From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Giuseppe Fioccola >> Sent: Friday, January 28, 2022 7:03 PM >> To: Tianran Zhou ; IETF IPPM = WG >> (ippm@ietf.org) >> Subject: Re: [ippm] New Version Notification for >> draft-li-ippm-otwamp-on-lag-02.txt >> >> Hi Tianran, All, >> I think that this is a useful work. >> For LAG, the use of active methods (OWAMP, TWAMP, STAMP) can also >> complement passive and hybrid methods. Indeed, the extensions proposed i= n >> this draft allow to monitor all the links and not only the link crossed = by >> the observed packet stream. >> Maybe, you can also highlight this point in the introduction section. >> >> Minor nits: >> s/Reflector Member Link ID fields/Reflector Member Link ID field/ >> >> s/When sending a response to the received Test packet, the micro TWAMP >> Session-Sender/ When sending a response to the received Test packet, the >> micro TWAMP Session- Reflector/ >> >> >> Regards, >> >> Giuseppe >> >> >> -----Original Message----- >> From: ippm On Behalf Of Tianran Zhou >> Sent: Monday, January 24, 2022 7:23 AM >> To: IETF IPPM WG (ippm@ietf.org) >> Subject: [ippm] FW: New Version Notification for >> draft-li-ippm-otwamp-on-lag-02.txt >> >> Hi WG, >> >> We think this is an useful work on adapting OWAMP/TWAMP in LAG >> performance measurement. >> We updated this draft based on the comments from the meeting discussion >> and mailing list. >> Thanks for all the suggestions. >> More reviews and comments are welcome. >> >> Cheers, >> Tianran >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Monday, January 24, 2022 2:17 PM >> To: Greg Mirsky ; Guo Jun ; >> Jun Guo ; Rakesh Gandhi ; >> Tianran Zhou ; Zhenqiang Li < >> li_zhenqiang@hotmail.com> >> Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt >> >> >> A new version of I-D, draft-li-ippm-otwamp-on-lag-02.txt >> has been successfully submitted by Tianran Zhou and posted to the IETF >> repository. >> >> Name: draft-li-ippm-otwamp-on-lag >> Revision: 02 >> Title: One-way/Two-way Active Measurement Protocol Extensions >> for Performance Measurement on LAG >> Document date: 2022-01-24 >> Group: Individual Submission >> Pages: 13 >> URL: >> https://www.ietf.org/archive/id/draft-li-ippm-otwamp-on-lag-02.txt >> Status: >> https://datatracker.ietf.org/doc/draft-li-ippm-otwamp-on-lag/ >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-li-ippm-otwamp-on-lag >> Diff: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-li-ippm-otwamp-on-lag-02 >> >> Abstract: >> This document defines extensions to One-way Active Measurement >> Protocol (OWAMP), and Two-way Active Measurement Protocol (TWAMP) to >> implement performance measurement on every member link of a Link >> Aggregation Group (LAG). Knowing the measured metrics of each member >> link of a LAG enables operators to enforce the performance based >> traffic steering policy across the member links. >> >> >> >> >> >> The IETF Secretariat >> >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> > > > -- > > *Henrik Nydell* > *Sr Product Manager* > 1.866.685.8181 > hnydell@accedian.com > > > > > *accedian.com * > > Avis de confidentialit=C3=A9 > > Les informations contenues dans le pr=C3=A9sent message et dans toute pi= =C3=A8ce qui > lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3= =A9es par le secret > professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de s= on ou de ses > destinataires. Si vous recevez ce message par erreur, veuillez s=E2=80=99= il vous > plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3=A9diteur et en= d=C3=A9truire tout > exemplaire. De plus, il vous est strictement interdit de le divulguer, de > le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80= =99exp=C3=A9diteur. > Merci. > > Confidentiality notice > > This e-mail message and any attachment hereto contain confidential > information which may be privileged and which is intended for the exclusi= ve > use of its addressee(s). If you receive this message in error, please > inform sender immediately and destroy any copy thereof. Furthermore, any > disclosure, distribution or copying of this message and/or any attachment > hereto without the consent of the sender is strictly prohibited. Thank yo= u. > > --=20 *Henrik Nydell* *Sr Product Manager* 1.866.685.8181 hnydell@accedian.com *accedian.com * --=20 Avis de confidentialit=C3=A9 Les informations contenues dans le pr=C3=A9sent=20 message et dans toute pi=C3=A8ce qui=20 lui est jointe sont confidentielles et=20 peuvent =C3=AAtre prot=C3=A9g=C3=A9es par le=20 secret professionnel. Ces informations sont=20 =C3=A0 l=E2=80=99usage exclusif de son ou de ses destinataires. Si vous recevez ce=20 message par erreur, veuillez=20 s=E2=80=99il vous plait communiquer imm=C3=A9diatement=20 avec l=E2=80=99exp=C3=A9diteur et en=20 d=C3=A9truire tout exemplaire. De plus, il vous est=20 strictement interdit de=20 le divulguer, de le distribuer ou de le reproduire=20 sans l=E2=80=99autorisation=20 de l=E2=80=99exp=C3=A9diteur. Merci. Confidentiality notice This e-mail message and any attachment hereto contain confidential=20 information=20 which may be privileged and which is intended for the=20 exclusive use of its=20 addressee(s). If you receive this message in error, please inform sender=20 immediately and destroy any copy thereof.=20 Furthermore, any disclosure,=20 distribution or copying of this message=20 and/or any attachment hereto=20 without the consent of the sender is=20 strictly prohibited. Thank you. --0000000000009025f505d6e04f5e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
        Yes= , that is understood, which is why I think TWAMP (being layer-3) is an odd = choice for this. A layer-2 test like Y.1731 would be more suitable to monit= or performance of individual LAG links.=C2=A0



        On Sat, Jan 29, 2022 at 10:28 AM lizhenqiang@chinamobile.com <lizhenqiang@chinamobile.com= > wrote:
        Hell= o Henrik and all,

        We considered the situation you mentioned. Becase it is difficult to trav= erse all the possible link combinations, i.e. the number of possible substr= eams is huge, we try to address LAG that directly connects two devices firs= t.

        Best R= egards,
        Zhenqiang Li

        Date:=C2=A02022-01-28=C2=A01= 9:56
        =
        Subject:=C2=A0Re: [ippm] New Version Notification for draft-li-= ippm-otwamp-on-lag-02.txt
        I still think it would be= much better to generalize this micro TWAMP concept and not tie this to LAG= , since that will be implementation specific - only if you implement TWAMP = directly on a LAG-device this draft would apply.
        Better then to generalize the concept and= call the added identifier "Substream ID" or something similar. T= hen this draft would also apply to for example a vendor that implements rou= ting over different paths or as Tianran pointed out, MPLS-SR uses. Thus I w= ould propose removing all references to LAG in this draft and widen the sco= pe to any situation where there would be uses for labelled=C2=A0(ID:ed) sub= streams between the same TWAMP-sender and session-reflector.

        =C2=A0

        On Fri, Jan 28, 2022 at 12:= 15 PM Tianran Zhou <zhoutianran=3D40huawei.com@dmar= c.ietf.org> wrote:
        Hi Giuseppe,

        Thanks very much for your review.
        I will incorpor= ate your suggestions in the next revision.

        Cheers,
        Tianran
        -----Original Message-----
        From: ippm [mailto:ippm-bounc= es@ietf.org] On Behalf Of Giuseppe Fioccola
        Sent: Friday, January 28= , 2022 7:03 PM
        To: Tianran Zhou <zhoutianran=3D4= 0huawei.com@dmarc.ietf.org>; IETF IPPM WG (ippm@ietf.org)= <ippm@ietf.org>
        Subject: Re: [ippm] New Version Notifi= cation for draft-li-ippm-otwamp-on-lag-02.txt

        Hi Tianran, All,
        I = think that this is a useful work.
        For LAG, the use of active methods (OW= AMP, TWAMP, STAMP) can also complement passive and hybrid methods. Indeed, = the extensions proposed in this draft allow to monitor all the links and no= t only the link crossed by the observed packet stream.
        Maybe, you can al= so highlight this point in the introduction section.

        Minor nits:
        = s/Reflector Member Link ID fields/Reflector Member Link ID field/

        s/= When sending a response to the received Test packet, the micro TWAMP Sessio= n-Sender/ When sending a response to the received Test packet, the micro TW= AMP Session- Reflector/


        Regards,

        Giuseppe


        ----= -Original Message-----
        From: ippm <ippm-bounces@ietf.o= rg> On Behalf Of Tianran Zhou
        Sent: Monday, January 24, 2022 7:23= AM
        To: IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org= >
        Subject: [ippm] FW: New Version Notification for draft-li-ippm-= otwamp-on-lag-02.txt

        Hi WG,

        We think this is an useful work o= n adapting OWAMP/TWAMP in LAG performance measurement.
        We updated this d= raft based on the comments from the meeting discussion and mailing list.Thanks for all the suggestions.
        More reviews and comments are welcome.<= br>
        Cheers,
        Tianran

        -----Original Message-----
        From:=C2=A0<= a href=3D"mailto:internet-drafts@ietf.org" style=3D"text-decoration:none" t= arget=3D"_blank">internet-drafts@ietf.org=C2=A0[mailto:internet-drafts@ietf.org]=C2=A0
        Sent: Monday, January 24, 2022 2:1= 7 PM
        To: Greg Mirsky <gregimirsky@gmail.com>; = Guo Jun <guo.jun2@zte.com.cn>; Jun Guo <guo.jun2@zte.com.cn>; Rakesh Gandhi <rgandhi@cis= co.com>; Tianran Zhou <zhoutianran@huawei.com= >; Zhenqiang Li <li_zhenqiang@hotmail.com>Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt<= br>

        A new version of I-D, draft-li-ippm-otwamp-on-lag-02.txt
        has = been successfully submitted by Tianran Zhou and posted to the IETF reposito= ry.

        Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-li-ippm-otwa= mp-on-lag
        Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
        Title:=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 One-way/Two-way Active Measurement Protocol Extensions= for Performance Measurement on LAG
        Document date:=C2=A0 2022-01-24
        G= roup:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
        Pages:=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 13
        URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0=C2=A0https://www.ietf.org/archive/id/draft-li-ippm-otwamp-on-lag-02= .txt
        Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/d= oc/draft-li-ippm-otwamp-on-lag/
        Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0= http= s://datatracker.ietf.org/doc/html/draft-li-ippm-otwamp-on-lag
        Diff:= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Dd= raft-li-ippm-otwamp-on-lag-02

        Abstract:
        =C2=A0 =C2=A0This doc= ument defines extensions to One-way Active Measurement
        =C2=A0 =C2=A0Prot= ocol (OWAMP), and Two-way Active Measurement Protocol (TWAMP) to
        =C2=A0 = =C2=A0implement performance measurement on every member link of a Link
        = =C2=A0 =C2=A0Aggregation Group (LAG).=C2=A0 Knowing the measured metrics of= each member
        =C2=A0 =C2=A0link of a LAG enables operators to enforce the= performance based
        =C2=A0 =C2=A0traffic steering policy across the membe= r links.





        The IETF Secretariat


        ___________= ____________________________________
        ippm mailing list
        ippm@ie= tf.org
        https://www.i= etf.org/mailman/listinfo/ippm

        __________________________________= _____________
        ippm mailing list
        ippm@ietf.org
        https://www.ietf.org/mailman/listi= nfo/ippm

        _______________________________________________
        ippm= mailing list
        ippm@ietf.org
        https://www.ietf.org/mailman/listinfo/ippm


        --=C2=A0
        <= br>Henrik Nydell
        Sr Product Manager
        1.866.685.8181
        hnydell@accedian.com
        3D""
        3D""=C2=A0=C2= =A03D""
        3D""
        accedian.com

        Avis de confidentialit=C3=A9=

        Les informations= contenues dans le pr=C3=A9sent message et dans toute pi=C3=A8ce qui lui es= t jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9es par = le secret professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclu= sif de son ou de ses destinataires. Si vous recevez ce message par erreur, = veuillez s=E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2= =80=99exp=C3=A9diteur et en d=C3=A9truire tout exemplaire. De plus, il vous= est strictement interdit de le divulguer, de le distribuer ou de le reprod= uire sans l=E2=80=99autorisation de l=E2=80=99exp=C3=A9diteur. Merci.

        Confidentiality notice

        This e-mail m= essage and any attachment hereto contain confidential information which may= be privileged and which is intended for the exclusive use of its addressee= (s). If you receive this message in error, please inform sender immediately= and destroy any copy thereof. Furthermore, any disclosure, distribution or= copying of this message and/or any attachment hereto without the consent o= f the sender is strictly prohibited. Thank you.



        --

        Henrik Nydell
        Sr Product Manager
        1.866.685.8181
        hnydell@accedian.= com
        3D""
        =3D""=C2=A03D""=C2=A03D""
        3D""
        accedian.com=

        Avis de confidentialit=C3=A9

        Les informations contenues dans le pr=C3=A9sent message et dans toute pi=C3=A8= ce qui=20 lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9e= s par le=20 secret professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif= de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez=20 s=E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp= =C3=A9diteur et en=20 d=C3=A9truire tout exemplaire. De plus, il vous est strictement interdit de= =20 le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisat= ion=20 de l=E2=80=99exp=C3=A9diteur. Merci.

        Confidentiality notice

        This e-mail message and any attachment hereto contain confidential=20 information which may be privileged and which is intended for the=20 exclusive use of its addressee(s). If you receive this message in error, please inform sender immediately and destroy any copy thereof.=20 Furthermore, any disclosure, distribution or copying of this message=20 and/or any attachment hereto without the consent of the sender is=20 strictly prohibited. Thank you.

        --0000000000009025f505d6e04f5e-- From nobody Mon Jan 31 09:19:30 2022 Return-Path: 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 886C03A0E6B; Mon, 31 Jan 2022 09:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4L2yGDVSE4Fa; Mon, 31 Jan 2022 09:19:22 -0800 (PST) Received: from NAM02-BN1-obe.outbound.protection.outlook.com (mail-bn1nam07on2102.outbound.protection.outlook.com [40.107.212.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 778343A0E6C; Mon, 31 Jan 2022 09:19:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q4KlGbblAKJ4pN7qI9G5eWFwBBeeabxe2NuJKbf5fcYBhCTQkJ/pSpoyVAVrETMU1m9sD1LWLm5JYLHD6xFkQNMNJJGxesPgBx7fw7iI5kBYCweVhyk8FsxZk1S3fGXQjVVZ0EFy+y2gCvO7KU1675wnYvkN2bxwV0DR+41+wvjsAgZuPkXE3WCuKaMP44OFDK4JYJ2IAR0bfsEdexFDY4a+OfLrzVByYI9+vq2F++/diKXgwW+Jzxd4pbvvc2IhD43IoFspujOeqYHIRw8zhNJUZeB2EjG9IVCqNgsiePaptpcpI4z1yydPCc4kJujyL6Yw2WQx7RsGOPqAKp80pA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/kOr0NL6JZQaO29/FQD0UfhsgFFN9bLzApL7j+vbFeY=; b=AKqW7zOZGgt3O/2g60n0jJSBi6PAxT4P9a+DFndvW2OAIL8mlE7esefVY6DOZhPFDo4O69rXAVGnCdAmsY/epwC2/FAKY1Ox03IAg0q/GcSlQ88j6ZyzMsHu8suuFVCenAxR7yyeF2v47VW9vr7il5XzKdg+Ogt8P3dAYursPY2SfakEQeIfZmVnm/ZnUVCJXpEhVQoDv9S/Xy8Y1+ZsnH4hjwH3aJXro37/h302xFecsYCYAfNGMYgzDcETb/J5cGs+E9aH17HB/CpGAXLKpo38pri3u/UO4ZMCn038+0/YaYe8go9wV7/yGbo31W+J37WHnR4RzV2OM7nHl9Rlsg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/kOr0NL6JZQaO29/FQD0UfhsgFFN9bLzApL7j+vbFeY=; b=QKfsnJeu8/AUxWYvmx/vULRZfXQx87AD5LTMPHsAsD0iZOctQ5HEpycp35Q0jwb+gwaKt8wHQaeUfp84TYWR+rCe11K6h3VYE3lp0u6+kQArbDj34sdJjxoPU1JfayfOh42qtjpgGAmBN8t7GSwo8NRCt994jKEzVkTxPBWkadI= Received: from BY3PR13MB4787.namprd13.prod.outlook.com (2603:10b6:a03:357::13) by CO6PR13MB5355.namprd13.prod.outlook.com (2603:10b6:303:14b::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.5; Mon, 31 Jan 2022 17:19:20 +0000 Received: from BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::e07d:da86:9082:d264]) by BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::e07d:da86:9082:d264%6]) with mapi id 15.20.4951.011; Mon, 31 Jan 2022 17:19:18 +0000 From: Haoyu Song To: Tianran Zhou , Greg Mirsky CC: "spring@ietf.org" , IETF IPPM WG Thread-Topic: [spring] Active OAM in SRv6 Thread-Index: AdgTBAVv6vallEwgQVCAy2m6n5m7fAABJueAACmK42AABqLOgAAHd+IgAAF9aIAAIn5YMAACuJCAAAAMfaAAEBHLAACA2VtQ Date: Mon, 31 Jan 2022 17:19:18 +0000 Message-ID: References: <92572d9dd6b545c8993a9945f2e51f97@huawei.com> In-Reply-To: <92572d9dd6b545c8993a9945f2e51f97@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 513c7fd7-0a6c-4c4a-ee00-08d9e4ddd09a x-ms-traffictypediagnostic: CO6PR13MB5355:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8A5e+9ZWwgeIHAOCAkuRWvxZoX8N2pIwhBiSdVjF/o6LjdNBOxbxIOXQ42rDce6PZSqR2f/WQggiEyaKeFqecr/eG2HDqj50nvmNsivrbtvu+at6OTQKrQUmVRUkRVqG7WMMXLbVI3jPg/fo3/VdpxhHufM7Amr/u/WDrwtR6Yndg3KM4c7jJXVj1WDjgIKM6RNswsggY8pPN+NkRvk1i596PksxY1/SVJhqpDxWkzk7DWRLhx07LwGcW7nWwIUxBQYwHxur3dTMDwbUZotG81vXG4RG/wD0LWdv9ompmy/jIfGxMthOZs6D1gMNKTHhr6cmi6XU9iAeHTqMaTIODN/4u0jXZ9FYxS69shR1KnqhXjRw/biW0cHTKqAgCBz/Nk72VowK0EhJowXwWEJQ/mE1RfT7lg6vis2d974jxWRB+vlo0KzxtxAOehdpiRlIO9r6KG770Ekh/Xqwwo0CX5Mh9f7ftPqMMVMX7Z+LpaYbDy8OmATdsRgnM6u0/AU+paWd0dObl1CL2tGv0VUYOnQuz71QSmPahmeM4lanBbeMX8wERhcu2y9BDuaVs0BYLAc2b5dXvkoVzujn6TOYmDlbObA2X9n2YrRED4LFxh98zui7IkzIXnhLBCF3BfnCTsPp9SfezDTpsz3KSJ/UB2EZNiA6/dv24ymKbBB675JVWCVxghH/X1QB35EaT1ZKtchgJy3eoy3X+140LsQi5k4gGggoBQ+YTWjRzCiwALCfKAK/2w3O9VH+qt5w1lQg45nH1POL4UizTbEdBYApoTVC4LUneczQ+47B1iD/JbsRXah5p70/qKX7JXmEteu+ZOqGPdM3CsCJUVxYMvVE2y0RaL4HcnusKhrKamf2HH23yYtElTeWmH/SVCBMSLp1 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR13MB4787.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(5660300002)(55016003)(53546011)(7696005)(9686003)(52536014)(186003)(26005)(83380400001)(33656002)(6506007)(2906002)(44832011)(122000001)(38070700005)(86362001)(166002)(316002)(38100700002)(966005)(110136005)(54906003)(508600001)(71200400001)(4326008)(64756008)(66446008)(66946007)(76116006)(66556008)(8676002)(8936002)(66476007)(20210929001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?4t/grGF7Db1jesL6dioQVDWqqKh5GnEFhIW20Qte/NpfDqd9m40vNgATgqWT?= =?us-ascii?Q?yP9TbuJxSrBMUoInTh9adfidTIdJVg8uw+XTvqucyS+aNVrtBwBeQa/HAWKi?= =?us-ascii?Q?JTnjrQKol0iye2GonK8lwu2I3ZFv/yk/48OaOLP4rL7Bupsj3eisFGDB1RHi?= =?us-ascii?Q?CbP6ORGldCt6BTefu6ESQcWMYg7LsHRNIVVHoFITxpYeibD284B+mE6xVO8y?= =?us-ascii?Q?1GNQmB5yNg3x5QTe32MBVZUHsjKqrNy1UveyRDrxn/MPGiooPkOe6F7TMJIp?= =?us-ascii?Q?nqLMAMjzOHJWbKJaCbjy2s90jWxjB4lczBws5ohxa3TkBfrHUHH171AGAPDl?= =?us-ascii?Q?2ayzAbDWO7j12nCFHAKdmQH0y4g9cwmFdcZeA/gmRdhYDRnrKNEsoUKdZb7p?= =?us-ascii?Q?Lo/CI+YCfkrG36UsGBVjnnPltyB7rpWQqf1kxTiAyDg6+9fu2GwRkEVq6f9b?= =?us-ascii?Q?tC4hOE0+OAX1i5rFUE2lrxrNCiiLctrwb8ScGGLZu+w7Cp5ETKYkxsw7TtlJ?= =?us-ascii?Q?RetkKA2V3jNZs/55GMhEjTxOgO2DF2YsoPrHCmOuS/4LAiLK2Z0b40j+9CBj?= =?us-ascii?Q?CIHO2BiEJhkADU02sEjfBU/4ZPzeZM7fha6GI8ZaOAh+ui5YZjC0tMV150K6?= =?us-ascii?Q?++N4j0ELUWSioHWdtXRYpyROicI79rwRKMtoV475Z4LBOu508wMnVKhGG0UX?= =?us-ascii?Q?4Oau/ZG8jQk6OOzYiRwcw7FkCvi5fIMUaOewTOk3O3MAiog6Tr10dGUe1A4K?= =?us-ascii?Q?JSUUkovAeHdAaG+cYFwxLpFxm5h5Y0Yy6EJoWxGTosPxaxaaahu92r84yOvD?= =?us-ascii?Q?awEGFSYibHjR+JNSlyT4FBEdlaO9a5qkchaavAJl7ST2kAUQZttNoPIrJKlW?= =?us-ascii?Q?XDUMTeQpzRlf6FBFK4E4IlKG3vndW//chHMgtGBQW1MkHPLyaBcG+esWUNFW?= =?us-ascii?Q?zZOXJgUHg2wu8BSbzHpGIBxLw2tFxdKP2OAuWzUAbdY/QCT85Tt9fNF3jFSm?= =?us-ascii?Q?cF//vEylNei+WDnQKa9S8x+zz2/3QBr6Hb6sgpy344c6WHasi4+bts5mmtzb?= =?us-ascii?Q?W/ZvSVzmB8hL/W39e91UeDs3jnuUZnnwSdZFzOTgD20yEdYaBxJZF3vv4B/8?= =?us-ascii?Q?IPDpfsZ2gqlM3o6OZN3IUz9owTmsLEJfQMFZjyRCSStIzA0k7iyfISu/qSIU?= =?us-ascii?Q?eTmUgeZPrfQVW+vofZLYdwPxXn0ycVFf74TdhvNkieOiC+BMMGZEpvXrZkr3?= =?us-ascii?Q?9MtzQCIYP6gIcM5j14VATS9zWQwXw9I/5FXVF7OmE04YYSR77IgNQJ6ssl0/?= =?us-ascii?Q?KojS0OksXVvPRv6lZcohi0W3XiQaI5W9nDxkg0og+DBs3gNArPe9mfcS6iSF?= =?us-ascii?Q?D8WFK3O0pLIV4UJ3r8LupyiVA9ii/+mvjeupT2qPk95TnzSu0nHI7V4/ftqi?= =?us-ascii?Q?YzhAfEVLbNEP3kACvhfdv8Uy83bTs8h0KfMTdE/Fp6XsI8P13FdYZe95sNK5?= =?us-ascii?Q?FrbwSW5fJbnUdBtQiPwYQSVEHKP+HAMtJwHwRXQxlDg2AqtLB3F4iIFAt7fB?= =?us-ascii?Q?6E4yIKeFWv72xLBm1nTJnLKKCaUqYfS1s7b+N5jyd5oCuIu3w5aQYVEbxKgZ?= =?us-ascii?Q?FQ=3D=3D?= Content-Type: multipart/alternative; boundary="_000_BY3PR13MB4787502E904309D44AECE31B9A259BY3PR13MB4787namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB4787.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 513c7fd7-0a6c-4c4a-ee00-08d9e4ddd09a X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2022 17:19:18.7243 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9IXOlG63PfnwQBO7eiZ4NcctDGzeLJsJMxTOigh4q5Xp59l8t+WPXkyLcVfonfH9ZqGlN3eBEQLc5wv43aMebw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR13MB5355 Archived-At: Subject: Re: [ippm] [spring] Active OAM in SRv6 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2022 17:19:28 -0000 --_000_BY3PR13MB4787502E904309D44AECE31B9A259BY3PR13MB4787namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tianran, Your summary is basically correct. But for the first point, I don't think using UDP is a new protocol. And ext= ending an existing protocol beyond its original scope in many cases is like= designing a new protocol. The pros and cons all need to be carefully cons= idered. Best, Haoyu From: Tianran Zhou Sent: Friday, January 28, 2022 7:44 PM To: Haoyu Song ; Greg Mirsky Cc: spring@ietf.org; IETF IPPM WG Subject: RE: [spring] Active OAM in SRv6 Hi Haoyu and Greg, I think we are getting clear, the discussion falls into two points: 1. new protocol vs reuse existing protocol 2. IPv6 EH vs UDP Best, Tianran From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Haoyu Song Sent: Saturday, January 29, 2022 4:10 AM To: Greg Mirsky > Cc: spring@ietf.org; IETF IPPM WG > Subject: Re: [ippm] [spring] Active OAM in SRv6 Hi Greg, Sure, SRv6 is IPv6 but SRv6 doesn't equal to IPv6. If you define IOAM in IP= v6, then what's its behavior in SRv6? Shall it be applied on every node or = every SR node? But the more fundamental issue is that I don't think putting= all of such things in EH TLVs is a good idea. All of the discussions aroun= d this which you are also very familiar make me think we should avoid it if= we can. Best, Haoyu From: Greg Mirsky > Sent: Friday, January 28, 2022 12:03 PM To: Haoyu Song > Cc: spring@ietf.org; IETF IPPM WG > Subject: Re: [spring] Active OAM in SRv6 Hi Haoyu, I'm surprised that you suggest an alternative to the IPv6 way of collecting= IOAM data. SRv6 must use all of IPv6 OAM. Would you agree? In some rare ca= ses, SRv6-specific extensions to IPv6 OAMAs for the limited amount of infor= mation that can be collected using IPv6 extension headers, IOAM Direct Expo= rt, or the Hybrid Two-step provide the solution. Both solve this problem by sepa= rating the generation of the IOAM data set from the collection and transpor= t. You are well-familiar with both drafts. Regards, Greg On Fri, Jan 28, 2022 at 11:10 AM Haoyu Song > wrote: Hi Greg, Thanks for the info. I'd like to clarify this work means to use the standar= dized IOAM options to support active measurement, so it's fair to say we us= e IOAM in SRv6 for active measurement. Another point I'd like to mention is= that draft-ietf-ippm-ioam-ipv6-options is for IPv6 in general but not for SRv6 s= pecifically. Moreover, it also use EH TLVs and we propose to use UDP, and i= t means to support in-band measurement for user traffic. In my view, SRv6 is the way to steer traffic. If SRv6 networks prevail, it'= s natural to use the traffic steering feature for probing and measurements = as well. If we have a unified method to cover as many techniques as possibl= e, we can imagine new techniques can also be introduced easily. Without nee= ding to set up any sessions and maintain any states, the controller can inj= ect probing packets from any node, steer them on any path, terminate them a= t any node, and collect any data we like. Such in-network measurement doesn= 't need to involve end hosts like PING. It can be used for traffic engineer= ing (e.g., evaluating different paths at background) and for gray failure d= etection and prevention. I hope the WG can see the simplicity, extensibility, and great application = potential of the proposed scheme, and provide constructive suggestions to i= mprove it. Thanks! Haoyu From: Greg Mirsky > Sent: Thursday, January 27, 2022 6:17 PM To: Haoyu Song > Cc: spring@ietf.org; IETF IPPM WG > Subject: Re: [spring] Active OAM in SRv6 Hi Haoyu, now, without in-lining my notes. It appears that you propose not to use draft-ietf-ippm-ioam-ipv6-options. Thus, y= our proposal cannot be referred to as IOAM in SRv6. At best, it is IOAM-ins= pired, IOAMish. As a result, a node supporting standardized IOAM would not = understand your probe packet without an SW upgrade. In my book, that's a ne= w protocol. In closing, I'll reference two works by Ruediger Geib, where combining the defined t= echniques of steering test probes with standard IOAM might reveal a lot of = useful information about a network: * RFC 8403 * draft-ietf-ippm-connectivity-monitoring Regards, Greg On Thu, Jan 27, 2022 at 5:44 PM Haoyu Song > wrote: Hi Greg, please see Inline From: Greg Mirsky > Sent: Thursday, January 27, 2022 2:01 PM To: Haoyu Song > Cc: spring@ietf.org; IETF IPPM WG > Subject: Re: [spring] Active OAM in SRv6 Hi Haoyu, thank you for your detailed reply. Please find my follow-up notes in-lined = below under the GIM2>> tag. Regards, Greg On Thu, Jan 27, 2022 at 11:00 AM Haoyu Song > wrote: Hi Greg, Thank you for your questions. Please see inline response. Best, Haoyu From: Greg Mirsky > Sent: Wednesday, January 26, 2022 3:01 PM To: Haoyu Song > Cc: spring@ietf.org; IETF IPPM WG > Subject: Re: [spring] Active OAM in SRv6 Hi Haoyu, thank you for bringing the topic of Active OAM to the discussion. As the co= ncept of Active IOAM is introduced in the IPPM WG draft it seems to me like adding= the IPPM WG community to the discussion is the right thing to do. Please find my notes in-lined below under the GIM>> tag. Regards, Greg On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song > wrote: Hi SPRING WG, Real time monitor on every node and every link on a network is necessary to= detect gray failures, which are the key culprit for poor QoS but hard to = catch. SR provides an ideal mechanism, when working with some efficient pla= nning algorithm, to achieve that with low cost. Our proposal SRv6 In-situ= Active Measurement (SIAM) suggests a simple active measurement approach w= hich can support different GIM>> I wonder what gaps you find in the existing active measurement protoc= ols, e.g., STAMP and RFC 6734 (would be more convenient to use an acronym).= It appears to me that, for example, STAMP and its extensions, including th= e SRPM draft, comprehensively address the PM OAM requirements for SRv6. HS>> Let's give a few features of our proposal: (1) it's session-less and w= e don't need assign any roles (e.g., reflector); (2) no needs for a return= path. The measurement can start and end at any node (solely determined by = the SRH); (3) udp-based which can support any existing IOAM modes and poten= tially other OAM methods. GIM2>> I don't think adding a protocol that can generate a test probe from = an arbitrary node to arbitrary targets (SRv6 supports multicast) is as simp= le as you present. If an operator needs to monitor the performance of the S= R policy used by data packets, IOAM can be applied to data packets. If the = operator wants to explore a policy that is not used for data traffic, I ima= gine IOAM can be added to a test packet of the existing OAM protocol, e.g.,= ICMP. Am I missing some of the requirements? HS2>> For the first point: I don't think a protocol is needed here. If one = wants to test the path a->b->c->d->e, he doesn't need to find a user packet= on that path to carry IOAM (there could be no such packet at all). Instead= , he can generate a probe packet with an SRH for the path and use the probe= packet to carry IOAM. At the path end, it simply extracts and exports the = IOAM data using the mechanism defined for IOAM and drops the probe packet. For the second point: I don't think ICMP can achieve what IOAM can do. IOAM= is much more powerful in terms of the data it can collect. Moreover, the p= roposal can be easily extended to support other kinds of OAM methods. One j= ust carry it in UDP payload using different port. No need to worry about th= e size if such info has to be carried in EH TLV. options of IOAM and other OAM methods in SRv6, without needing to worry abo= ut the extension header issue. GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows: In terms of the classification given in [RFC7799] IOAM could be portrayed as Hybrid Type 1. Does your proposal change that? HS>> In this particular case, IOAM is used for active measurement because i= t's not included in a user packet. Your comments, questions, and suggestions are very welcome. I'd like to kno= w your opinion if you think this work is in scope and should be adopted by = the working group. If you are interested in contributing to this work, ple= ase also let me know. https://datatracker.ietf.org/doc/draft-song-spring-si= am/ Thank you very much! Best regards, Haoyu _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_BY3PR13MB4787502E904309D44AECE31B9A259BY3PR13MB4787namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

        Tianran,

         

        Your summary is basically correct.

        But for the first point, I don’t think using U= DP is a new protocol. And extending an existing protocol beyond its origina= l scope in many cases is like designing a new protocol.  The pros and = cons all need to be carefully considered.

         

        Best,

        Haoyu

         

         

        From: Tianran Zhou <zhoutianran@huawei.com= >
        Sent: Friday, January 28, 2022 7:44 PM
        To: Haoyu Song <haoyu.song@futurewei.com>; Greg Mirsky <gre= gimirsky@gmail.com>
        Cc: spring@ietf.org; IETF IPPM WG <ippm@ietf.org>
        Subject: RE: [spring] Active OAM in SRv6

         

        Hi Haoyu and Greg,

         

        I think we are getting= clear, the discussion falls into two points:

        1. new protocol vs reu= se existing protocol

        2. IPv6 EH vs UDP=

         

        Best,

        Tianran

         

        From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Haoyu Song
        Sent: Saturday, January 29, 2022 4:10 AM
        To: Greg Mirsky <gregimi= rsky@gmail.com>
        Cc: spring@ietf.org; IETF IPP= M WG <ippm@ietf.org>
        Subject: Re: [ippm] [spring] Active OAM in SRv6

         

        Hi Greg,

         

        Sure, SRv6 is IPv6 but SRv6 doesn’t equal to I= Pv6. If you define IOAM in IPv6, then what’s its behavior in SRv6? Sh= all it be applied on every node or every SR node? But the more fundamental = issue is that I don’t think putting all of such things in EH TLVs is a good idea. All of the discussions around this which= you are also very familiar make me think we should avoid it if we can.

         

        Best,

        Haoyu

        From: Greg Mirsky <gregimirsky@gmail.com>
        Sent: Friday, January 28, 2022 12:03 PM
        To: Haoyu Song <haoyu= .song@futurewei.com>
        Cc: spring@ietf.org; IETF IPP= M WG <ippm@ietf.org>
        Subject: Re: [spring] Active OAM in SRv6

         

        Hi Haoyu,

        I'm surprised that you suggest an alternative to the= IPv6 way of collecting IOAM data. SRv6 must use all of IPv6 OAM. Would you= agree? In some rare cases, SRv6-specific extensions to IPv6 OAMAs for the = limited amount of information that can be collected using IPv6 extension headers, IOAM Direct Export, or the Hybrid Two-step provide the solution. Both solve this problem by separa= ting the generation of the IOAM data set from the collection and transport.= You are well-familiar with both drafts.

         

        Regards,

        Greg

         

        On Fri, Jan 28, 2022 at 11:10 AM Haoyu Song <haoyu.song@futurewei.com> wr= ote:

        Hi Greg,

         

        Thanks for the info. I’d like to clarify this work means to = use the standardized IOAM options to support active measurement, so it̵= 7;s fair to say we use IOAM in SRv6 for active measurement. Another point I’d like to mention is that draft-ietf-ippm-ioam-ipv6-options is for IPv6 in general but not for SR= v6 specifically. Moreover, it also use EH TLVs and we propose to use UDP, a= nd it means to support in-band measurement for user traffic.

         

        In my view, SRv6 is the way to steer traffic. If SRv6 networks pre= vail, it’s natural to use the traffic steering feature for probing an= d measurements as well. If we have a unified method to cover as many techniques as possible, we can imagine new techniq= ues can also be introduced easily. Without needing to set up any sessions a= nd maintain any states, the controller can inject probing packets from any = node, steer them on any path, terminate them at any node, and collect any data we like. Such in-network measuremen= t doesn’t need to involve end hosts like PING. It can be used for tra= ffic engineering (e.g., evaluating different paths at background) and for g= ray failure detection and prevention.   

         

        I hope the WG can see the simplicity, extensibility, and great app= lication potential of the proposed scheme, and provide constructive suggest= ions to improve it.

         

        Thanks!

        Haoyu  

         

        From: Greg Mirsky <gregimirsky@gmail.com>
        Sent: Thursday, January 27, 2022 6:17 PM
        To: Haoyu Song <haoyu.song@futurewei.com>
        Cc: spring@ietf= .org; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [spring] Active OAM in SRv6

         

        Hi Haoyu,

        now, without in-lining my notes.

        It appears that you propose not to use draft-ietf-ippm-ioam-ipv6-options. Thus, your proposal cannot be referr= ed to as IOAM in SRv6. At best, it is IOAM-inspired, IOAMish. As a result, = a node supporting standardized IOAM would not understand your probe packet = without an SW upgrade. In my book, that's a new protocol.

        In closing, I'll reference two works by Ruediger Geib, where combining the defined techniques of steering test p= robes with standard IOAM might reveal a lot of useful information about a n= etwork:

        Regards,

        Greg

         

        On Thu, Jan 27, 2022 at 5:44 PM Haoyu Song <haoyu.song@futurewei.com>= wrote:

        Hi Greg, please see Inline

         

        From: Greg Mirsky <gregimirsky@gmail.com>
        Sent: Thursday, January 27, 2022 2:01 PM
        To: Haoyu Song <haoyu.song@futurewei.com>
        Cc: spring@ietf= .org; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [spring] Active OAM in SRv6

         

        Hi Haoyu,

        thank you for your detailed reply. Please find my follow-up notes = in-lined below under the GIM2>> tag.

         

        Regards,

        Greg

         

        On Thu, Jan 27, 2022 at 11:00 AM Haoyu Song <haoyu.song@futurewei.com>= ; wrote:

        Hi Greg,

         

        Thank you for your questions. Please see inline response.

         

        Best,

        Haoyu

         

        From: Greg Mirsky <gregimirsky@gmail.com>
        Sent: Wednesday, January 26, 2022 3:01 PM
        To: Haoyu Song <haoyu.song@futurewei.com>
        Cc: spring@ietf= .org; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [spring] Active OAM in SRv6

         

        Hi Haoyu,

        thank you for bringing the topic of Active OAM to the discussion. = As the concept of Active IOAM is introduced in the IPPM WG draft it seems to me like adding the IPPM WG community to = the discussion is the right thing to do. 

        Please find my notes in-lined below under the GIM>> tag.

         

        Regards,

        Greg

         

        On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song <haoyu.song@futurewei.com>= wrote:

        Hi SPRING WG,

         

        Real time monitor on every node and every link on a network is nec= essary to detect  gray failures, which are the key culprit for poor Qo= S but hard to catch. SR provides an ideal mechanism, when working with some efficient planning algorithm, to achieve= that with low cost.   Our proposal SRv6 In-situ Active Measureme= nt (SIAM) suggests a simple  active measurement approach which can sup= port different

        GIM>> I wonder what gaps you find in the existing active mea= surement protocols, e.g., STAMP and RFC 6734 (would be more convenient to u= se an acronym). It appears to me that, for example, STAMP and its extensions, including the SRPM draft, comprehensively address the PM OAM requirements for SRv6.&n= bsp;

         

        HS>> Let’s give a few features of our proposal: (1) it= ’s session-less and we don’t need assign any roles (e.g.,  = ;reflector); (2) no needs for a return path. The measurement can start and end at any node (solely determined by the SRH); (3) udp-based wh= ich can support any existing IOAM modes and potentially other OAM methods.<= o:p>

        GIM2>> I don't think adding a protocol that can generate a t= est probe from an arbitrary node to arbitrary targets (SRv6 supports multic= ast) is as simple as you present. If an operator needs to monitor the performance of the SR policy used by data packets, IO= AM can be applied to data packets. If the operator wants to explore a polic= y that is not used for data traffic, I imagine IOAM can be added to a test = packet of the existing OAM protocol, e.g., ICMP. Am I missing some of the requirements?

         

        HS2>> For the first point: I don’t think a protocol is= needed here. If one wants to test the path a->b->c->d->e, he d= oesn’t need to find a user packet on that path to carry IOAM (there could be no such packet at all). Instead, he can generate a probe p= acket with an SRH for the path and use the probe packet to carry IOAM. At t= he path end, it simply extracts and exports the IOAM data using the mechani= sm defined for IOAM and drops the probe packet.  

        For the second point: I don’t think ICMP can achieve what IO= AM can do. IOAM is much more powerful in terms of the data it can collect. = Moreover, the proposal can be easily extended to support other kinds of OAM methods. One just carry it in UDP payload us= ing different port. No need to worry about the size if such info has to be = carried in EH TLV.

        options of IOAM and other OAM methods in SRv6, without needing to = worry about the extension header issue.  

        GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows:<= o:p>

           In terms of the classification given

           in [RFC7799] IOAM could be portrayed as Hybrid Type 1= .

        Does your proposal change that?

         

        HS>> In this particular case, IOAM is used for active measur= ement because it’s not included in a user packet.

         

        Your comments, questions, and suggestions are very welcome. I̵= 7;d like to know your opinion if you think this work is in scope and should= be adopted by the working group.  If you are interested in contributing to this work, please also let me know. https://datatracker.ietf.org/doc/draft-song-spring-siam/

         

        Thank you very much!

         

        Best regards,

        Haoyu

        _______________________________________________
        spring mailing list
        spring@ietf.org https://www.ietf.org/mailman/listinfo/spring

        --_000_BY3PR13MB4787502E904309D44AECE31B9A259BY3PR13MB4787namp_-- From nobody Mon Jan 31 09:29:52 2022 Return-Path: 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 520DA3A0EF6; Mon, 31 Jan 2022 09:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_REMOTE_IMAGE=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X_a6n10C01dq; Mon, 31 Jan 2022 09:29:45 -0800 (PST) Received: from NAM02-BN1-obe.outbound.protection.outlook.com (mail-bn1nam07on2138.outbound.protection.outlook.com [40.107.212.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C07D3A0EF1; Mon, 31 Jan 2022 09:29:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MvzL4Xgktsi1pOaN22XeJ9tEGDmTdmqvHpAI6f0k8hZjAQWgEodDqQ7Wvbhr6MWf28GQHTIHkjjwZiseqLgS48jemyt5eKnfZ+IuQnGhz0VaHWqCF5x17X8ZvAHEgN9/bkzmeueuBAERfYr8lZEiTzBdhFeySrB+pXlWsIpn6NB6GBBu6t3cEVBp8m7j30dHZUI59Eq4CiNO5ziomCbUTUlny0CYoPpmiLsFQVo/lxUCR9iT6tbxnuvCT5eiiFgGQQZQL8FSaR7j8/LEUcDcxC4dWAMoU51S6zzS2WrtZNox3q2dAid2tdzdiSUg2CDHzvGncPj4Ydmt/GHUzL6gMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/MXbZ7sMpGh91WZk4q3yQUvKTXpkrYiTSDdBtx4H+CU=; b=Bika8hEw2RKz5UKREdq++AzfKijukVLwySceMhj36/P3WNvHM7R/ZZu6s6Xo2FlJsfV1RC4+DXuFKnXAkBTUTeUqAlipQGJ3PsHkKGn6f1J7c24rvchYROjYUzMxPWfl+2FPDMvS7w3deyOe8ytWvHIbqF+AE12Y/uELTb3HLsSw3HfquDhrebUWe52QJCWSsUrDb2pXK/56xlKkyJEa5g7OUDB5Xs84cwTxgPVtHPHZ4xr/dl37gohAgogqEyznU3U2DEZtqbpBAhAekvObgQmy12IxAUUTKzRyPMcAiuTG+AIpA0KVyB6dCX7u1ioohL8UKJbvX9sXA5Yh+r9FNw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/MXbZ7sMpGh91WZk4q3yQUvKTXpkrYiTSDdBtx4H+CU=; b=sC2DGYMMcT7QttN4N+PD6WUOFAOGQfQb3H0ctWYLeIyVWpa410I8S0gG/hGeBxSwR+XF0qjmFg4LKd9jmLGkZV/g9RYo/rw3utHQpoP5myprduR8WnE2Xmph7tk87uWzQKbzGCzUYxNugnBXacuRnWWas05dZncXcAhWKAZn2zA= Received: from BY3PR13MB4787.namprd13.prod.outlook.com (2603:10b6:a03:357::13) by MN2PR13MB3989.namprd13.prod.outlook.com (2603:10b6:208:262::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.5; Mon, 31 Jan 2022 17:29:37 +0000 Received: from BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::e07d:da86:9082:d264]) by BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::e07d:da86:9082:d264%6]) with mapi id 15.20.4951.011; Mon, 31 Jan 2022 17:29:37 +0000 From: Haoyu Song To: Gyan Mishra CC: Greg Mirsky , IETF IPPM WG , Tianran Zhou , "spring@ietf.org" Thread-Topic: [ippm] [spring] Active OAM in SRv6 Thread-Index: AdgTBAVv6vallEwgQVCAy2m6n5m7fAABJueAAAkAnYAAA6MGgAAb+IDAAJVaGoAAMdjOMA== Date: Mon, 31 Jan 2022 17:29:37 +0000 Message-ID: References: <97ee51feb17c4bcc84bc575768c06c3e@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 848dc415-8946-436d-8d73-08d9e4df416c x-ms-traffictypediagnostic: MN2PR13MB3989:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XdP3ztVkA7pHg+DIU5M5ps0PjbDiFWEUqOEBU3r+reHqlhxlpcrqFZkWXX4ohi0ZYnIKXlnjWU+REhDHGCwhtbz7q/eEbYnsTsLbmJJ5LxuUkQOlxFAsW0qdhkuAXBmi0Izf7Y2LXqg0R8RIuiqAg4vczMWLMX9n+77rhLLPJoUTp8hZc/x1pDBQl6qa38JM40jYvI0LygV4ZJRV/heriEzOK2D+mJjfWNQGH0b1C8ph+8CUBaifKnychQldHzGAMpeOL6kxNmiO/afPiAFXfvN0hY7FR6vpMRbug/f216oi5NTlujgMTkEJgY43HHaTz4TOCnCa8BzplEAVGvPTrhpdVQeSfeF0MiSMntOslFI0Pe/QxAT/z6xQc8y0WozQJLd8/U2QIRx4udIrnwmmfy8aKOz6z+O7x+Z1m4GiqWSEeDlW5bwexZUcHNXbqAvhLChpBSK9QUBTDTFPZbFowVqFE4y3pePAJ4Bt5MItm8wDNgTjaUrBxqREKCk4dIcA+97L9r1fgeaS3qTYy4GiIfQ7u06/3CQXVZvm1Io7gar3I4cZmNaR6BbjzqchOdaZuYPCPBrlaYvR1vioecCNmFbKfPDlCdXxBVOCvi0Poxwa85bo7Qqx4CeO23VLUQ1x42JwMKwEb0gTaINsL5G6fjYDaAbbSFxGAwe2MnpC+av1vWE8+2lVvxrZyUeAGWmVW8/6rzUdhcK8CGEVfYUy2FGZhQP+vNelQDhEf4ugE1V3LQ4XmN7plJtZu0z7VnCnZTM70mcX4gPVeVqc/ozTubXr+9+Z67TBP1tvrjBbofiphH0DG9uGRIpgXMpONMC3e6+XQmrjzDX/kHFPT43F0A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR13MB4787.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(122000001)(71200400001)(83380400001)(966005)(38070700005)(508600001)(52536014)(44832011)(38100700002)(26005)(186003)(5660300002)(8936002)(6506007)(53546011)(33656002)(166002)(9686003)(55016003)(6916009)(8676002)(54906003)(2906002)(316002)(4326008)(76116006)(66556008)(66476007)(86362001)(66946007)(64756008)(40140700001)(7696005)(66446008)(20210929001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?zJwTN0mohPa2E5yR1mx5lBfq/PAY7W2anYUVdzNEPBMuFANYr/rq7kdjaYXF?= =?us-ascii?Q?LCmw5WottdlifFD0bqnJzvMYEY5sZdz8mSqxwo6XKQNytz4F1cRguzsHrVDL?= =?us-ascii?Q?H/1u/UwGpclAMGe2cft+dgf4iw7ZBIbNdTvChjsP2v4lAoEUsi70zPcbT5uA?= =?us-ascii?Q?ahI5jzFP6Qnoy7L4OpeqJKeCSe1XZ62aSERiL/PFv0uML4DN+bCaDy9j060s?= =?us-ascii?Q?xqpEPhCi/CByIfOdCWyS9CBWmrr8vda1H2Qz5Co+7jP4h47+SAaWwfl8pFc7?= =?us-ascii?Q?+mSnl0RrKcCqEx0e2i5voPMCUhdw0+nSOthJoodAgE5x0nm20ZU57czhlN3N?= =?us-ascii?Q?ENYhsf5Skfs4aCzfysz4RVgUEGz6aSM9RV/TyrrA/a7/YnIj6hyN2VqPTM+2?= =?us-ascii?Q?QGgLjE3lhOYo6e0VDRH/AEJHKRMMlyyb68ckxLO6/kQfyoptT4dD/Hc6SxAE?= =?us-ascii?Q?AI7+xVU2iwZatS2FNmfQ6mfWCNTR+PiT2V3+8qawpWq/Sw89/P6YCXA4gcc7?= =?us-ascii?Q?gtsOwjkHEBxaXXYe8XkUrS+xB0AMGyb82CSRIEitvS7ZF1QZrMQKPQn6n1xt?= =?us-ascii?Q?4VuvSfsonfmLvFLyE3JpEuCUbhlSbg/tDkLz/CL9NwRsHNcW6jaulKFosbbN?= =?us-ascii?Q?47s+otDPJdLe4BzzFcJKc+VzEPnQieSpCXgZGRFPp9/yZ35GzwdVdf2mumOp?= =?us-ascii?Q?vfpOnKVeXjKU4AiapC0ApJ4LQDoYeiEcWGPXd4O0M4oZRnZhOnDsky/a9tUk?= =?us-ascii?Q?aSXvbLioWZb8WpeJyRL+fFvcD1fyAHBKePIq6nz+DVr3FIR8AcyUDZA6XAZq?= =?us-ascii?Q?colZASND0BkBb8ZSnug6CaKdEhM9tEo+lKcZtctBC0TqHHp8/SYwead8Edcs?= =?us-ascii?Q?V9UA6Ppaa021n1FPlVXDzKVZ6GYHABy8zM5Eb454PQq6OnUNSQCLWjTSuu2a?= =?us-ascii?Q?cbckk8Cjz3zM8DefXrDdQco8qzFx6j5C+gNsg+xGVp96lJxvnYVZssO1dcrB?= =?us-ascii?Q?2k0YUXFYLOIfigj5iBA0noYkFjheGwNm/mMydhta7wQJSKJZM/pDvaK+RbBH?= =?us-ascii?Q?p7B6SObbvKjTa65JekvioVYbw9W688+3inRPEryO0BYbYcS4yAcPsnrS0Nuo?= =?us-ascii?Q?mK36QwfAGurfWz3cC4s1pvpNHwV42b/8yGEiGssPETTiHhfVANSHIqblRSlr?= =?us-ascii?Q?zpx4j/9CU9OXRa9Xvqo/QKTRjddtwuHJk0HXabHueEjDa8gVeeWsFaUhHaxJ?= =?us-ascii?Q?9+1SFOeofAvgzzvN7lPR0EDztcQ4Wpda38tIoIdakU1cZGnsL6bRi+yGK6m5?= =?us-ascii?Q?CaEW+ktp2TeFczMTY9DsNeqOyzzvi4ZxpxrOB7UltGVSUvzmK8z9R+J7YzR+?= =?us-ascii?Q?4tnyr0Dd+LvtKpj0NT59Z1nGZvg/mtfPEAgFVTpMa5OOg3BmZH11BnJAnwt8?= =?us-ascii?Q?y+0OXGseLxMdGqImuvbtw0cBLbIu+PH35yjc3cJsBbSXKvJ+kKXlzf9zEoMW?= =?us-ascii?Q?E+TjSKitIUjXPsHHRoV+1rAx0th6UfgXWTzGeZvqEKpXeW4VgGA3kkeDUyMz?= =?us-ascii?Q?Y0iMnvoR/tXT7jjmMwjv0qSHxBHp85WxeNmOBmuRo/0cIankr5dvx8miHRnK?= =?us-ascii?Q?bQ=3D=3D?= Content-Type: multipart/alternative; boundary="_000_BY3PR13MB47877F5B9F4CAED75CD457C29A259BY3PR13MB4787namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB4787.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 848dc415-8946-436d-8d73-08d9e4df416c X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2022 17:29:37.4702 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: t7VfXE/7J5Ti0M64lq92/p+6dpn0cO21ot8Z1X/tCedpIjowWaiKLxr6/XugWHfyL5lrgqhsmxrW2YzS+oaiSA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB3989 Archived-At: Subject: Re: [ippm] [spring] Active OAM in SRv6 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2022 17:29:51 -0000 --_000_BY3PR13MB47877F5B9F4CAED75CD457C29A259BY3PR13MB4787namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Gyan! In the next revision, I'll add more information on the requirements and com= parisons with the other approaches. Best, Haoyu From: Gyan Mishra Sent: Sunday, January 30, 2022 9:41 AM To: Haoyu Song Cc: Greg Mirsky ; IETF IPPM WG ; Tian= ran Zhou ; spring@ietf.org Subject: Re: [ippm] [spring] Active OAM in SRv6 Hi Haoyu On Thu, Jan 27, 2022 at 1:42 PM Haoyu Song > wrote: Hi Gyan, Thank you for your comments! Please see inline for response marked with [HS= ] Best, Haoyu From: Gyan Mishra > Sent: Wednesday, January 26, 2022 9:03 PM To: Tianran Zhou > Cc: Greg Mirsky >; Haoy= u Song >; IETF IP= PM WG >; spring@ietf.org Subject: Re: [ippm] [spring] Active OAM in SRv6 Hi Haoyu I think it would be good to identify the problem statement and gap with exi= sting IPPM WG STAMP, TWAMP PM technologies and why they cannot be utilized = or fall short in what you are trying to achieve with Active OAM in SRv6. [HS] My understanding is that STAMP/TWAMP are for end-to-end measurements, = here we want to collect data from every node and every link on any path, wi= thout needing to set up any sessions. So the scope and coverage are differe= nt. Gyan> Understood. STAMP/TWAMP can be used as well to collect from every n= ode as well. In-situ IOAM data packets is already possible with SRv6 as mentioned as thi= s draft mentions below as normative reference. https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-data-16 [HS] There's no accepted solution on how to support IOAM in SRv6 yet. Our p= roposal aims to provide such a solution, and (1) the solution avoids the is= sues on encapsulating the IOAM trace in EHs and (2) it's extensible to incl= ude OAM methods beyond IOAM. Gyan> IPPM WG can speak to this document which has been adopted and been d= eveloped since 2016 and provides in-situ OAM as you desire and supports Seg= ment Routing SRv6 as well as other encapsulations. This draft as well mentioned as normative reference draft below provides OA= M ping and traceroute with SRH O flag to SRv6 PGM endpoints and SID list tr= acing capabilities very handy for troubleshooting. https://datatracker.ietf.org/doc/html/draft-ietf-6man-spring-srv6-oam-13 [HS] This is for in-band OAM for SRv6 user traffic and it only works for tr= iggering postcard exports (i.e., don't allow the packet to carry data). Our= proposal support all the IOAM options and more important, it's an active m= ethod which means one can generate and inject probing packets to cover arbi= trary paths by crafting an SRH. Gyan> Understood This draft as well also mentioned as normative reference draft below provid= es in-situ IOAM for OAM and PM information can be piggybacked in data packe= ts in SRH TLV SRv6 PGM SIF function SRv6.TLV recording the operational and = telemetry info in the data packets. https://datatracker.ietf.org/doc/html/draft-ali-spring-ioam-srv6-05 [HS] This draft proposes to encapsulate IOAM in SRH TLV. Due to the overhea= d concern (IOAM trace could be large) and other issues related to EH, I don= 't support such a solution. Gyan> Understood. Work is being done in 6MAN WG to address EH headers iss= ues below as well as other drafts to make EH viable and reduce overhead. https://datatracker.ietf.org/doc/html/draft-herbert-6man-eh-limits-00.txt [HS] The three drafts you mentioned are all be reference in our draft and d= iscussed. We think our use cases are different and our approach is more gen= eral and extensible to our use cases. Gyan> Understood. I think if you can add some additional verbiage as to pr= oblem statement and why existing solutions drafts mentioned are not suffici= ent for your requirements. Maybe listing out your requirements would help = couple to your proposed solution. Thanks Gyan On Wed, Jan 26, 2022 at 10:19 PM Tianran Zhou > wrote: Hi Haoyu, The application is really interesting and useful. I am not sure if it is necessary to create a new OAM protocol at transport = layer. IMHO, a per hop/per segment extension based on STAMP could be more practica= l. https://www.ietf.org/archive/id/draft-wang-ippm-stamp-hbh-extensions-03.txt= Best, Tianran From: ippm [mailto:ippm-bounces@ietf.org] On = Behalf Of Greg Mirsky Sent: Thursday, January 27, 2022 7:01 AM To: Haoyu Song > Cc: spring@ietf.org; IETF IPPM WG > Subject: Re: [ippm] [spring] Active OAM in SRv6 Hi Haoyu, thank you for bringing the topic of Active OAM to the discussion. As the co= ncept of Active IOAM is introduced in the IPPM WG draft it seems to me like addi= ng the IPPM WG community to the discussion is the right thing to do. Please find my notes in-lined below under the GIM>> tag. Regards, Greg On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song > wrote: Hi SPRING WG, Real time monitor on every node and every link on a network is necessary to= detect gray failures, which are the key culprit for poor QoS but hard to = catch. SR provides an ideal mechanism, when working with some efficient pla= nning algorithm, to achieve that with low cost. Our proposal SRv6 In-situ= Active Measurement (SIAM) suggests a simple active measurement approach w= hich can support different GIM>> I wonder what gaps you find in the existing active measurement protoc= ols, e.g., STAMP and RFC 6734 (would be more convenient to use an acronym).= It appears to me that, for example, STAMP and its extensions, including th= e SRPM draft, comprehensively address the PM OAM requirements for SRv6. options of IOAM and other OAM methods in SRv6, without needing to worry abo= ut the extension header issue. GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows: In terms of the classification given in [RFC7799] IOAM could be portrayed as Hybrid Type 1. Does your proposal change that? Your comments, questions, and suggestions are very welcome. I'd like to kno= w your opinion if you think this work is in scope and should be adopted by = the working group. If you are interested in contributing to this work, ple= ase also let me know. https://datatracker.ietf.org/doc/draft-song-spring-si= am/ Thank you very much! Best regards, Haoyu _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email] Gyan Mishra Network Solutions Architect Email gyan.s.mishra@verizon.com M 301 502-1347 -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email] Gyan Mishra Network Solutions Architect Email gyan.s.mishra@verizon.com M 301 502-1347 --_000_BY3PR13MB47877F5B9F4CAED75CD457C29A259BY3PR13MB4787namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

        Thanks Gyan!

        In the next revision, I’ll add more informatio= n on the requirements and comparisons with the other approaches.

         

        Best,

        Haoyu

         

        From: Gyan Mishra <hayabusagsm@gmail.com&g= t;
        Sent: Sunday, January 30, 2022 9:41 AM
        To: Haoyu Song <haoyu.song@futurewei.com>
        Cc: Greg Mirsky <gregimirsky@gmail.com>; IETF IPPM WG <ippm= @ietf.org>; Tianran Zhou <zhoutianran=3D40huawei.com@dmarc.ietf.org&g= t;; spring@ietf.org
        Subject: Re: [ippm] [spring] Active OAM in SRv6

         

        Hi Haoyu

         

        On Thu, Jan 27, 2022 at 1:42 PM Haoyu Song <haoyu.song@futurewei.com> wro= te:

        Hi Gyan,

         

        Thank you for your comments! Please see inline for response marked= with [HS]

         

        Best,

        Haoyu

         

        From: Gyan Mishra <hayabusagsm@gmail.com>
        Sent: Wednesday, January 26, 2022 9:03 PM
        To: Tianran Zhou <zhoutianran=3D40huawei.com@dmarc.ietf.org>
        Cc: Greg Mirsky <gregimirsky@gmail.com>; Haoyu Song <haoyu.song@futurewei.com&g= t;; IETF IPPM WG <ipp= m@ietf.org>; spring@ietf.org Subject: Re: [ippm] [spring] Active OAM in SRv6

         

        Hi Haoyu 

         

        I think it would be good to identify the problem statement and gap= with existing IPPM WG STAMP, TWAMP PM technologies and why they cannot be = utilized or fall short in what you are trying to achieve with Active OAM in SRv6. 

         

        [HS] My understanding is that STAMP/TWAMP are for end-to-end measu= rements, here we want to collect data from every node and every link on any= path, without needing to set up any sessions. So the scope and coverage are different.  

         Gyan> Understood.  STAMP/TWAMP can be used as well t= o collect from every node as well.

        In-situ IOAM data packets is already possible with SRv6 as mention= ed as this draft mentions below as normative reference.

         

        https://datatracker.ietf.org= /doc/html/draft-ietf-ippm-ioam-data-16

         

        [HS] There’s no accepted solution on how to support IOAM in = SRv6 yet. Our proposal aims to provide such a solution, and (1) the solutio= n avoids the issues on encapsulating the IOAM trace in EHs and (2) it’s extensible to include OAM methods beyond I= OAM.

         Gyan> IPPM WG can speak to this document which has been a= dopted and been developed since 2016 and provides in-situ OAM as you desire= and supports Segment Routing SRv6 as well as other encapsulations.

        This draft as well mentioned as normative reference draft below pr= ovides OAM ping and traceroute with SRH O flag to SRv6 PGM endpoints and SI= D list tracing capabilities very handy for troubleshooting.

         

         

        [HS] This is for in-band OAM for SRv6 user traffic and it only wor= ks for triggering postcard exports (i.e., don’t allow the packet to c= arry data). Our proposal support all the IOAM options and more important, it’s an active method which means one ca= n generate and inject probing packets to cover arbitrary paths by crafting = an SRH.

         Gyan> Understood 

        This draft as well also mentioned as normative reference draft bel= ow provides in-situ IOAM for OAM and PM information can be piggybacked in d= ata packets in SRH TLV SRv6 PGM SIF function SRv6.TLV recording the operational and telemetry info in the data= packets.

        [HS] This draft proposes to encapsulate IOAM in SRH TLV. Due to th= e overhead concern (IOAM trace could be large) and other issues related to = EH, I don’t support such a solution.

         Gyan> Understood.  Work is being done in 6MAN WG to = address EH headers issues below as well as other drafts to make EH viable a= nd reduce overhead.

         

         

         

        [HS] The three drafts you mentioned are all be reference in our dr= aft and discussed. We think our use cases are different and our approach is= more general and extensible to our use cases.

        Gyan> Understood.  I think if you can add some additional = verbiage as to problem statement and why existing solutions drafts mentione= d are not sufficient for your requirements.  Maybe listing out your requirements would help couple to your proposed sol= ution. 

        Thanks 

         

        Gyan 

         

        On Wed, Jan 26, 2022 at 10:19 PM Tianran Zhou <zhoutianran=3D40huawei.com= @dmarc.ietf.org> wrote:

        Hi Haoyu,

         

        The application is really interestin= g and useful.

        I am not sure if it is necessary to = create a new OAM protocol at transport layer.

        IMHO, a per hop/per segment extensio= n based on STAMP could be more practical.

        https://www.ietf.org/archive/id/draft-wang-ippm-stamp-hbh-extensio= ns-03.txt

         

        Best,

        Tianran  

         

        From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Greg Mirsky
        Sent: Thursday, January 27, 2022 7:01 AM
        To: Haoyu Song <haoyu.song@futurewei.com>
        Cc: spring@ietf= .org; IETF IPPM WG <ippm@ietf.org>
        Subject: Re: [ippm] [spring] Active OAM in SRv6

         

        Hi Haoyu,

        thank you for bringing the topic of Active OAM to the discussion. = As the concept of Active IOAM is introduced in the IPPM WG draft it seems to me like adding the IPPM WG community to = the discussion is the right thing to do. 

        Please find my notes in-lined below under the GIM>> tag.

         

        Regards,

        Greg

         

        On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song <haoyu.song@futurewei.com>= wrote:

        Hi SPRING WG,

         

        Real time monitor on every node and every link on a network is nec= essary to detect  gray failures, which are the key culprit for poor Qo= S but hard to catch. SR provides an ideal mechanism, when working with some efficient planning algorithm, to achieve= that with low cost.   Our proposal SRv6 In-situ Active Measureme= nt (SIAM) suggests a simple  active measurement approach which can sup= port different

        GIM>> I wonder what gaps you find in the existing active mea= surement protocols, e.g., STAMP and RFC 6734 (would be more convenient to u= se an acronym). It appears to me that, for example, STAMP and its extensions, including the SRPM draft, comprehensively address the PM OAM requirements for SRv6.&n= bsp;

        options of IOAM and other OAM methods in SRv6, without needing to = worry about the extension header issue.  

        GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows:<= o:p>

           In terms of the classification given

           in [RFC7799] IOAM could be portrayed as Hybrid Type 1= .

        Does your proposal change that?

         

        Your comments, questions, and suggestions are very welcome. I̵= 7;d like to know your opinion if you think this work is in scope and should= be adopted by the working group.  If you are interested in contributing to this work, please also let me know. https://datatracker.ietf.org/doc/draft-song-spring-siam/

         

        Thank you very much!

         

        Best regards,

        Haoyu

        _______________________________________________
        spring mailing list
        spring@ietf.org https://www.ietf.org/mailman/listinfo/spring

        _______________________________________________
        ippm mailing list
        ippm@ietf.org
        https://www.ietf.org/mailman/listinfo/ippm

        --

        <= o:p>

        Gyan Mishra

        Network Solutions Architect 

        Email gyan.s.mishr= a@verizon.com

        M 301 502-1347

         

        --

        <= span style=3D"color:#222222">

        Gyan Mishra=

        Network Solutions Architect&nb= sp;

        Email gyan.s.mishr= a@verizon.com

        M 301 = 502-1347

         

        --_000_BY3PR13MB47877F5B9F4CAED75CD457C29A259BY3PR13MB4787namp_--