[spring] Re: spring Digest, Vol 129, Issue 43

Cheng Li <c.l@huawei.com> Fri, 06 September 2024 12:28 UTC

Return-Path: <c.l@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 CC20DC14F6E3 for <spring@ietfa.amsl.com>; Fri, 6 Sep 2024 05:28:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level:
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9C6WKl0eqW1W for <spring@ietfa.amsl.com>; Fri, 6 Sep 2024 05:28:18 -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 2B430C14CF12 for <spring@ietf.org>; Fri, 6 Sep 2024 05:28:18 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4X0b5V18XWz6J7lk; Fri, 6 Sep 2024 20:24:46 +0800 (CST)
Received: from frapeml100003.china.huawei.com (unknown [7.182.85.60]) by mail.maildlp.com (Postfix) with ESMTPS id A51EA140B2A; Fri, 6 Sep 2024 20:28:15 +0800 (CST)
Received: from frapeml500003.china.huawei.com (7.182.85.28) by frapeml100003.china.huawei.com (7.182.85.60) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Fri, 6 Sep 2024 14:28:15 +0200
Received: from frapeml500003.china.huawei.com ([7.182.85.28]) by frapeml500003.china.huawei.com ([7.182.85.28]) with mapi id 15.01.2507.039; Fri, 6 Sep 2024 14:28:15 +0200
From: Cheng Li <c.l@huawei.com>
To: Joel Halpern <jmh@joelhalpern.com>, LiJie Deng <denglijie1020@gmail.com>, "spring@ietf.org" <spring@ietf.org>
Thread-Topic: [spring] Re: spring Digest, Vol 129, Issue 43
Thread-Index: AQHa/3MpHaH27s/OUEeBFPwskpWXxLJJUzGA///7dwCAARfMEA==
Date: Fri, 06 Sep 2024 12:28:15 +0000
Message-ID: <83036747b21340b385bf4782e7ab5628@huawei.com>
References: <CAD3qVdHQSWagtdEhYcFX2v7CESpXOrpLaWbe3kUB7W0eeK3fdg@mail.gmail.com> <a2171475a6244a7aa4e3d90bfe9ba572@huawei.com> <46f24ceb-a19d-498a-bcee-5e8cf617dd1c@joelhalpern.com>
In-Reply-To: <46f24ceb-a19d-498a-bcee-5e8cf617dd1c@joelhalpern.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.203.70.229]
Content-Type: multipart/alternative; boundary="_000_83036747b21340b385bf4782e7ab5628huaweicom_"
MIME-Version: 1.0
Message-ID-Hash: XPM4SOCZQC4YGLHI2QHYYXOTNEJQ4WG3
X-Message-ID-Hash: XPM4SOCZQC4YGLHI2QHYYXOTNEJQ4WG3
X-MailFrom: c.l@huawei.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-spring.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [spring] Re: spring Digest, Vol 129, Issue 43
List-Id: "Source Packet Routing in NetworkinG (SPRING)" <spring.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/gjbKFVw9W-nYhSz5o8wv7zM5CkM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Owner: <mailto:spring-owner@ietf.org>
List-Post: <mailto:spring@ietf.org>
List-Subscribe: <mailto:spring-join@ietf.org>
List-Unsubscribe: <mailto:spring-leave@ietf.org>

Hi Joel,

Thank you for your email.
We might think about two type of cases here.


1.     A segment list use a single PSID(Segment list: PSID is 1:1): this is a normal case, can be covered by other text in the draft, no special text is needed. All the SR Policy use the same PSID for a specific segment list. Then we will get an aggregated statistics on the egress node. That is simple.

2.     A segment list can have multiple different value PSIDs(Segment list: PSID is 1:N). This design allows the operators to separate the statistics for separate subsets of traffic over a path. This is an object-oriented design, each SR policy has its own candidate path, own segment list, own path. Though the segment list may be the same with other ones in other SR policies, but a SR policy do not care about others, but only see its own segment list identified by a path segment. But in any case, we do not force people to do so, this draft only provide the capability to use different value of PSID for a segment list.  In other worlds, each SR policy has its own path with its PSID, and different SR policy’s path(with different PSID) might reuse the same segment list. In my point of view, it is the PSID.
We might add some text to explain more? You comment or text proposal will be very welcome!

Thanks,
Cheng



From: Joel Halpern <jmh@joelhalpern.com>
Sent: Thursday, September 5, 2024 7:18 PM
To: Cheng Li <c.l@huawei.com>; LiJie Deng <denglijie1020@gmail.com>; spring@ietf.org
Subject: Re: [spring] Re: spring Digest, Vol 129, Issue 43


I can understand why the operator may want separate statistics for separate subsets of traffic over a path.  But then the ID being used does not seem to be a path ID.  It identifies something, but I am not sure what.  If it identified just the path, then all the packets for all applications using the same path would be required to have the same ID, which you are explicitly saying is not the case.

Yours,

Joel
On 9/5/2024 11:44 AM, Cheng Li wrote:
Hi Lijie,

Yes, it is common for operators to carry multiple services with different policies over links.

That text is for the use cases that an operator would like to measure the packets for the paths(identified by its segment list) within its Policy. But on the egress node, the node will get the aggregated statistics of packets since different services may reuse the same segment list/path.

In the cases that operator would like to measure the paths in different policies/services, same segment list/path in a specific policy should be identified, and differentiated with the same segment list in other policies. By using different Path Segment ID, same segment List/path can be differentiated, so that the traffic can be measured alone. Otherwise, only the aggregated result will be produced on the egress node.

Hope I make it clear. Thank you for your comment. We may need to add some text in this section? You are welcome to share your proposal.

Thanks,
Cheng





From: LiJie Deng <denglijie1020@gmail.com><mailto:denglijie1020@gmail.com>
Sent: Thursday, September 5, 2024 11:08 AM
To: spring@ietf.org<mailto:spring@ietf.org>
Subject: [spring] Re: spring Digest, Vol 129, Issue 43

Hi Cheng,

  I have a question about the draft.
There is this sentence in the "introduction" section: "Furthermore, different SRv6 policies may use the same segment list for different candidate paths, so the traffic of different SRv6 policies are merged, resulting in the inability to measure the performance of the specific path."
- I don’t see the issue with "merged traffic of different SRv6 policies", and how it relates to "the inability to measure the performance of the specific path". For operators, it’s very common to carry multiple services with different policies over links. In addition, there are many methods to measure service performance, such as IOAM.
BR,
Lijie



_______________________________________________

spring mailing list -- spring@ietf.org<mailto:spring@ietf.org>

To unsubscribe send an email to spring-leave@ietf.org<mailto:spring-leave@ietf.org>