Re: [spring] Request for adoption https://datatracker.ietf.org/doc/html/draft-song-spring-siam-01 “SRv6 In-situ Active Measurement”

Tianran Zhou <zhoutianran@huawei.com> Thu, 08 July 2021 03:33 UTC

Return-Path: <zhoutianran@huawei.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570E73A0F35; Wed, 7 Jul 2021 20:33:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.086
X-Spam-Level:
X-Spam-Status: No, score=-4.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 O_JBr_ulFnU6; Wed, 7 Jul 2021 20:33:24 -0700 (PDT)
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 477783A0F2E; Wed, 7 Jul 2021 20:33:24 -0700 (PDT)
Received: from fraeml741-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GL1nM6Lyyz6M4Zp; Thu, 8 Jul 2021 11:22:31 +0800 (CST)
Received: from kwepeml100004.china.huawei.com (7.221.188.19) by fraeml741-chm.china.huawei.com (10.206.15.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Thu, 8 Jul 2021 05:33:20 +0200
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.2176.2; Thu, 8 Jul 2021 11:33:18 +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.2176.012; Thu, 8 Jul 2021 11:33:18 +0800
From: Tianran Zhou <zhoutianran@huawei.com>
To: Haoyu Song <haoyu.song@futurewei.com>, "spring-chairs@ietf.org" <spring-chairs@ietf.org>, "spring@ietf.org" <spring@ietf.org>
Thread-Topic: =?Windows-1252?Q?Request_for_adoption_https://datatracker.ietf.org/doc/ht?= =?Windows-1252?Q?ml/draft-song-spring-siam-01_=93SRv6_In-situ_Active_Meas?= =?Windows-1252?Q?urement=94?=
Thread-Index: AddynoWWDp6nAXgmTHOqFyIuRtcLbwAMr7OAACBKXeAAFJoSgA==
Date: Thu, 8 Jul 2021 03:33:18 +0000
Message-ID: <bef28dfe898a43c9a7ff80999bbc7bbb@huawei.com>
References: <BY3PR13MB478755757A264F91EC25F1369A1B9@BY3PR13MB4787.namprd13.prod.outlook.com> <7470b44235494dfd8614c7b127fb7a77@huawei.com> <BY3PR13MB4787A26E7EE36A9999E091779A1A9@BY3PR13MB4787.namprd13.prod.outlook.com>
In-Reply-To: <BY3PR13MB4787A26E7EE36A9999E091779A1A9@BY3PR13MB4787.namprd13.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.243.128]
Content-Type: multipart/alternative; boundary="_000_bef28dfe898a43c9a7ff80999bbc7bbbhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/m7NTMm2ldXlJ4O9RJa4QGFdFgUk>
Subject: Re: [spring] =?windows-1252?q?Request_for_adoption_https=3A//datatra?= =?windows-1252?q?cker=2Eietf=2Eorg/doc/html/draft-song-spring-siam-01_=93?= =?windows-1252?q?SRv6_In-situ_Active_Measurement=94?=
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Jul 2021 03:33:29 -0000

Hi Haoyu,

The STAMP extension is not in EH. Similar to your proposal, it’s after UDP and in STAMP.
The proposal did not specify how to trigger the intermediate node to process. So it could be hop by hop or per segment.
I think the major difference is on the metrics which relate to the use cases.
I am not sure how most of the IOAM data could be used for active probe.
For example, the node and interface id.
The SIAM is for designated path which is planned by the controller. The controller is topology aware. There is no need to collect node and interface again.
Another example, the queue depth.
It’s highly dynamic, I do not understand why an active probe need to collect this data. Then how to use it?

Best,
Tianran


From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Haoyu Song
Sent: Thursday, July 8, 2021 1:21 AM
To: Tianran Zhou <zhoutianran@huawei.com>om>; spring-chairs@ietf.org; spring@ietf.org
Subject: Re: [spring] Request for adoption https://datatracker.ietf.org/doc/html/draft-song-spring-siam-01 “SRv6 In-situ Active Measurement”

Hi Tianran,

Thanks for sharing.
A fundamental difference is either carrying the monitoring header in EH or in UDP payload. I think the latter is more extensible and it doesn’t have the compatibility issue therefore the deployment is easier.
The HBH or per-segment monitoring in SRv6 is important but missing today. I beleive we need a generic mechanism to support them, so we can collect more requirements and use cases to extend the draft.

Best,
Haoyu

From: Tianran Zhou <zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>>
Sent: Tuesday, July 6, 2021 6:48 PM
To: Haoyu Song <haoyu.song@futurewei.com<mailto:haoyu.song@futurewei.com>>; spring-chairs@ietf.org<mailto:spring-chairs@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>
Subject: RE: Request for adoption https://datatracker.ietf.org/doc/html/draft-song-spring-siam-01 “SRv6 In-situ Active Measurement”

Hi Haoyu,

Thanks for sharing your proposal.
I definitely have interest about this work.
We have a similar proposal which extends the STAMP.
https://datatracker.ietf.org/doc/draft-wang-ippm-stamp-hbh-extensions/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-wang-ippm-stamp-hbh-extensions%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Ce71e491aad3a4378aa5708d940e94c78%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637612193042616329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=0mKRgMw7Kn%2B3mGJabO2zPPcvxaDnR2SJTJKSrLSjs%2B4%3D&reserved=0>
It would be great if we can put the use cases, requirements, potential solutions in a plate, and have comprehensive discussions on this..

Best,
Tianran
From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Haoyu Song
Sent: Wednesday, July 7, 2021 3:40 AM
To: spring-chairs@ietf.org<mailto:spring-chairs@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>
Subject: [spring] Request for adoption https://datatracker.ietf.org/doc/html/draft-song-spring-siam-01 “SRv6 In-situ Active Measurement”

SPRING WG,
As the draft “draft-ietf-spring-stamp-srpm-01” has been adopted, I also ask the WG to consider the following related draft:

https://datatracker.ietf.org/doc/html/draft-song-spring-siam-01<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-song-spring-siam-01&data=04%7C01%7Chaoyu.song%40futurewei.com%7Ce71e491aad3a4378aa5708d940e94c78%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637612193042616329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Ln8TLJpLN%2BV2uJc0yBncqoGNjt1%2BJ7GJdIBXn0DKxUM%3D&reserved=0> “SRv6 In-situ Active Measurement”

We have presented this draft in the last meeting but we didn’t have much time to discuss it yet.
In essence, it proposes to carry IOAM in SR+UDP as well while using a flag bit in SRH to indicate the presence of the IOAM payload.
It achieves IOAM’s functionality but avoids the encapsulation issues. It doesn’t need to maintain sessions and it can monitor all the segment noes on an SR path.
I would also like to ask for feedbacks from the WG and request the adoption.  Thanks for consideration.

Best regards,
Haoyu