[mpls] SR-MPLS Service Programming usecase for Open DT
liu.yao71@zte.com.cn Thu, 16 September 2021 09:01 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 7D7903A210A for <mpls@ietfa.amsl.com>; Thu, 16 Sep 2021 02:01:58 -0700 (PDT)
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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 IY3kOgiAWMcD for <mpls@ietfa.amsl.com>; Thu, 16 Sep 2021 02:01:56 -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 14AA03A2109 for <mpls@ietf.org>; Thu, 16 Sep 2021 02:01:56 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.164.217]) by Forcepoint Email with ESMTPS id 46F71A362CB555F663C6 for <mpls@ietf.org>; Thu, 16 Sep 2021 17:01:53 +0800 (CST)
Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id 317E88FE05B1D29F3831 for <mpls@ietf.org>; Thu, 16 Sep 2021 17:01:53 +0800 (CST)
Received: from njxapp02.zte.com.cn ([10.41.132.201]) by mse-fl1.zte.com.cn with SMTP id 18G8dcOG034073 for <mpls@ietf.org>; Thu, 16 Sep 2021 16:39:38 +0800 (GMT-8) (envelope-from liu.yao71@zte.com.cn)
Received: from mapi (njxapp03[null]) by mapi (Zmail) with MAPI id mid203; Thu, 16 Sep 2021 16:39:37 +0800 (CST)
Date: Thu, 16 Sep 2021 16:39:37 +0800
X-Zmail-TransId: 2afb614302c9f6d441eb
X-Mailer: Zmail v1.0
Message-ID: <202109161639379790272@zte.com.cn>
Mime-Version: 1.0
From: liu.yao71@zte.com.cn
To: mpls@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 18G8dcOG034073
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/3nLqoyDCR-5j3MwjKXhpc77DLEk>
Subject: [mpls] 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: Thu, 16 Sep 2021 09:01:59 -0000
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