[spring] Re: I-D Action: draft-dong-spring-sr-policy-with-nrp-00.txt

chen.ran@zte.com.cn Fri, 28 June 2024 07:10 UTC

Return-Path: <chen.ran@zte.com.cn>
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 8AC18C169423 for <spring@ietfa.amsl.com>; Fri, 28 Jun 2024 00:10:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.893
X-Spam-Level:
X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_TEMPERROR=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable 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 tO4YxGUfTTdt for <spring@ietfa.amsl.com>; Fri, 28 Jun 2024 00:10:12 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52065C151992 for <spring@ietf.org>; Fri, 28 Jun 2024 00:10:09 -0700 (PDT)
Received: from mse-fl1.zte.com.cn (unknown [10.5.228.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4W9RQj5y0gz4xth0; Fri, 28 Jun 2024 15:10:05 +0800 (CST)
Received: from njy2app02.zte.com.cn ([10.40.13.116]) by mse-fl1.zte.com.cn with SMTP id 45S79vU8087666; Fri, 28 Jun 2024 15:09:57 +0800 (+08) (envelope-from chen.ran@zte.com.cn)
Received: from mapi (njy2app04[null]) by mapi (Zmail) with MAPI id mid203; Fri, 28 Jun 2024 15:09:59 +0800 (CST)
Date: Fri, 28 Jun 2024 15:09:59 +0800
X-Zmail-TransId: 2afc667e61c7ffffffff8eb-37dbe
X-Mailer: Zmail v1.0
Message-ID: <202406281509596471ocX8aAyyMZh7XKNixpO3@zte.com.cn>
Mime-Version: 1.0
From: chen.ran@zte.com.cn
To: jie.dong=40huawei.com@dmarc.ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 45S79vU8087666
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 667E61CD.001/4W9RQj5y0gz4xth0
Message-ID-Hash: 35LBT6V6YWE477PQ3TOYVDZBWWHW4IEQ
X-Message-ID-Hash: 35LBT6V6YWE477PQ3TOYVDZBWWHW4IEQ
X-MailFrom: chen.ran@zte.com.cn
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
CC: spring@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [spring] Re: I-D Action: draft-dong-spring-sr-policy-with-nrp-00.txt
List-Id: "Source Packet Routing in NetworkinG (SPRING)" <spring.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/ec1tWisr_wjUiJiqO6aZLFX0h2o>
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 Jie,
The solution in the draft-dong-spring-sr-policy-with-nrp" (https://datatracker.ietf.org/doc/draft-dong-spring-sr-policy-with-nrp/  ) that you submitted yesterday,  seems to overlap with that of  "draft-jiang-spring-sr-policy-nrp-00"(https://datatracker.ietf.org/doc/html/draft-Jiang-spring-sr-policy-nrp-00)" we submitted last week.

Both drafts covers the relationship between NRP and SR policy, the position of NRP in SR policy, reporting and distribution under SR policy and packet encapsulation with NRP-ID.

The good news is you are the co-author of "draft-jiang-spring-sr-policy-nrp-00". So you are welcome to continue to improve "draft-jian-spring-sr-policy-nrp"  together. Thank you very much for your work.
Here is the submission history from last week:
发件人: internet-drafts@ietf.org <internet-drafts@ietf.org>发送时间: 2024年6月21日 14:59收件人: i-d-announce@ietf.org主题: I-D Action: draft-jiang-spring-sr-policy-nrp-00.txtInternet-Draft draft-jiang-spring-sr-policy-nrp-00.txt is now available.   Title:   Segment Routing Policy Extension for NRP   Authors: Wenying Jiang            Ran Chen            Jie Dong   Name:    draft-jiang-spring-sr-policy-nrp-00.txt   Pages:   11   Dates:   2024-06-18Abstract:   Network Resource Partition (NRP), which is a subset of the resources   and associated policies in the underlay network. In networks with   multiple NRPs, an SR Policy can be associated with a particular NRP.   This document describes how the SR Policy extension for associated   NRP and the operational mechanisms function together.The IETF datatracker status page for this Internet-Draft is:https://datatracker.ietf.org/doc/draft-jiang-spring-sr-policy-nrp/There is also an HTMLized version available at:https://datatracker.ietf.org/doc/html/draft-jiang-spring-sr-policy-nrp-00Best Regards,
Ran-----邮件原件-----发件人: internet-drafts@ietf.org <internet-drafts@ietf.org>发送时间: 2024年6月27日 20:14收件人: i-d-announce@ietf.org主题: I-D Action: draft-dong-spring-sr-policy-with-nrp-00.txtInternet-Draft draft-dong-spring-sr-policy-with-nrp-00.txt is now available.   Title:   Associating Segment Routing (SR) Policy with Network Resource Partition (NRP)   Authors: Jie Dong            Ran Pang            Ka Zhang   Name:    draft-dong-spring-sr-policy-with-nrp-00.txt   Pages:   9   Dates:   2024-06-27Abstract:   Segment Routing (SR) Policy is a set of candidate paths, each   consisting of one or more segment lists and the associated   information.  A Network Resource Partition (NRP) is a subset of the   network resources and associated policies in the underlay network,   which can be used to support one or a group of Enhanced VPN or RFC   9543 network slice services.  In SR networks where there are multiple   NRPs, an SR Policy may be associated with a particular NRP.  Within   an NRP, SR Policy can be used for forwarding traffic which is mapped   to the NRP, so that the traffic can be provided with the subset of   network resources and policy of the NRP for guaranteed performance.   The association between SR Policy and NRP needs to be specified.   This document defines extensions to the SR Policy Architecture to   allow the association of the SR Policy candidate paths with NRPs.The IETF datatracker status page for this Internet-Draft is:https://datatracker.ietf.org/doc/draft-dong-spring-sr-policy-with-nrp/There is also an HTML version available at:https://www.ietf.org/archive/id/draft-dong-spring-sr-policy-with-nrp-00.htmlInternet-Drafts are also available by rsync at:rsync.ietf.org::internet-drafts_______________________________________________I-D-Announce mailing list -- i-d-announce@ietf.org To unsubscribe send an email to i-d-announce-leave@ietf.org-------------------------------------------------------------------------------------------------------------------------------------