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

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

Date: Wed, 22 Sep 2021 10:06:58 +0800
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"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/e0PBO6n6IKYURr6AnpyzDpSb2O4>
Subject: Re: [mpls] SR-MPLS Service Programming usecase for Open DT
Precedence: list

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

[mpls] SR-MPLS Service Programming usecase for Op… liu.yao71
Re: [mpls] SR-MPLS Service Programming usecase fo… Haoyu Song
Re: [mpls] SR-MPLS Service Programming usecase fo… liu.yao71