Re: [mpls] SR-MPLS Service Programming usecase for Open DT

liu.yao71@zte.com.cn Wed, 22 September 2021 02:07 UTC

Return-Path: <liu.yao71@zte.com.cn>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F743A1637 for <mpls@ietfa.amsl.com>; Tue, 21 Sep 2021 19:07:21 -0700 (PDT)
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, CTE_8BIT_MISMATCH=0.001, RCVD_IN_MSPIKE_H2=-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 28-RLC9_wcfy for <mpls@ietfa.amsl.com>; Tue, 21 Sep 2021 19:07:16 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 7D7713A1632 for <mpls@ietf.org>; Tue, 21 Sep 2021 19:07:15 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.164.217]) by Forcepoint Email with ESMTPS id 657B6648A0E37F5A1AD3 for <mpls@ietf.org>; Wed, 22 Sep 2021 10:07:12 +0800 (CST)
Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id 4C15DDFD37B0CF680F0C; Wed, 22 Sep 2021 10:07:12 +0800 (CST)
Received: from njxapp05.zte.com.cn ([10.41.132.204]) by mse-fl1.zte.com.cn with SMTP id 18M26xeB009316; Wed, 22 Sep 2021 10:06:59 +0800 (GMT-8) (envelope-from liu.yao71@zte.com.cn)
Received: from mapi (njxapp03[null]) by mapi (Zmail) with MAPI id mid203; Wed, 22 Sep 2021 10:06:58 +0800 (CST)
Date: Wed, 22 Sep 2021 10:06:58 +0800 (CST)
X-Zmail-TransId: 2afb614a8fc29fb8a782
X-Mailer: Zmail v1.0
Message-ID: <202109221006588688451@zte.com.cn>
In-Reply-To: <BY3PR13MB47875DF62B1F96EE85A7AA3B9AA09@BY3PR13MB4787.namprd13.prod.outlook.com>
References: 202109161639379790272@zte.com.cn, BY3PR13MB47875DF62B1F96EE85A7AA3B9AA09@BY3PR13MB4787.namprd13.prod.outlook.com
Mime-Version: 1.0
From: <liu.yao71@zte.com.cn>
To: <haoyu.song@futurewei.com>
Cc: <mpls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
X-MAIL: mse-fl1.zte.com.cn 18M26xeB009316
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/e0PBO6n6IKYURr6AnpyzDpSb2O4>
Subject: Re: [mpls] =?utf-8?q?SR-MPLS_Service_Programming_usecase_for_Open_DT?=
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Sep 2021 02:07:21 -0000

Hi Haoyu,

I think there're some differences between the SR-MPLS SFC usecase and the network programming usecase.
The purpose and the content of the data carried after the BOS of these two usecases are not the same. 
The purpose of SR-MPLS SFC usecase is to achieve SFC by SR-MPLS instead of NSH. The data required to be carried after the BOS is metadata for SFC. A new extension header may be defined for it or maybe we reuse existing header like NSH or SRH or something else.
The purpose of network programming usecase is to support the equivalent of FUNC::ARG in SRv6.  And the content of the data carried after the BOS contains FUNC:ARGs, segment count and pointers as for my understanding.

Regards,
Yao



------------------原始邮件------------------
发件人:HaoyuSong
日 期 :2021年09月20日 23:48
主 题 :RE: [mpls] SR-MPLS Service Programming usecase for Open DT
Hi Yao,
I think what you described has been covered in the "network programming" use case on the wiki page,
https://trac.ietf.org/trac/mpls/wiki/Usecases, which is more akin to SRH in SR.
Best,
Haoyu
-----Original Message-----
From: mpls <mpls-bounces@ietf.org> On Behalf Of liu.yao71@zte.com.cn
Sent: Thursday, September 16, 2021 1:40 AM
To: mpls@ietf.org
Subject: [mpls] SR-MPLS Service Programming usecase for Open DT
Hi DT,
Besides the requirement in NSH Based SFC usecase in the wiki to carry path ID and metadata by embedding NSH in EH.
There's also a need to carry metadata in SR service programming with SR-MPLS data plane.
The reference is draft-ietf-spring-sr-service-programming. SR service programming is a mechanism to achieve SFC in SR-MPLS and SRv6 networks without the use of NSH.
In this draft, there's a requirement to carry metadata in SR-MPLS data plane, some possible methods to carry metadata (e.g, defining an SRH-like header with only the mandatory fields required to carry metadata) and to indicate the presence of metadata(e.g, adding the indication in the semantic of the service SIDs, or introducing a protocol identifier in the MPLS packet) are proposed but not standardized.
As for the path ID, although not mentioned in this draft, I think there's a potential need for it to let the SFFs distinguish between different SFPs.
Maybe after discussion the solution for this usecase is similar to that for NSH Based SFC, but I think this usecase should be taken into consideration.
Regards,
Yao