Re: [Idr] Adoption call for - draft-dong-idr-sr-policy-nrp-02 (3/1 to 3/14)

peng.shaofu@zte.com.cn Fri, 10 March 2023 09:35 UTC

Return-Path: <peng.shaofu@zte.com.cn>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2584DC1BED33 for <idr@ietfa.amsl.com>; Fri, 10 Mar 2023 01:35:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 EOZLdrXqOb6T for <idr@ietfa.amsl.com>; Fri, 10 Mar 2023 01:35:03 -0800 (PST)
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 E6605C1BED32 for <idr@ietf.org>; Fri, 10 Mar 2023 01:35:02 -0800 (PST)
Received: from mxct.zte.com.cn (unknown [192.168.251.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4PY19b2wW9z6FK2W for <idr@ietf.org>; Fri, 10 Mar 2023 17:34:59 +0800 (CST)
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 mxct.zte.com.cn (FangMail) with ESMTPS id 4PY1910mwjz4xq1d; Fri, 10 Mar 2023 17:34:29 +0800 (CST)
Received: from njy2app04.zte.com.cn ([10.40.12.64]) by mse-fl1.zte.com.cn with SMTP id 32A9YN3J074073; Fri, 10 Mar 2023 17:34:23 +0800 (+08) (envelope-from peng.shaofu@zte.com.cn)
Received: from mapi (njy2app02[null]) by mapi (Zmail) with MAPI id mid201; Fri, 10 Mar 2023 17:34:25 +0800 (CST)
Date: Fri, 10 Mar 2023 17:34:25 +0800
X-Zmail-TransId: 2afa640af9a1364bc113
X-Mailer: Zmail v1.0
Message-ID: <202303101734259783581@zte.com.cn>
In-Reply-To: <BYAPR08MB4872737894DA7507D4F54C2BB3AD9@BYAPR08MB4872.namprd08.prod.outlook.com>
References: BYAPR08MB4872737894DA7507D4F54C2BB3AD9@BYAPR08MB4872.namprd08.prod.outlook.com
Mime-Version: 1.0
From: peng.shaofu@zte.com.cn
To: shares@ndzh.com
Cc: idr@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 32A9YN3J074073
X-Fangmail-Gw-Spam-Type: 0
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 640AF9C3.000/4PY19b2wW9z6FK2W
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/NCuX2OxbrX9zRhTnZBg8Gp1dRm4>
Subject: Re: [Idr] Adoption call for - draft-dong-idr-sr-policy-nrp-02 (3/1 to 3/14)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Mar 2023 09:35:07 -0000

Hi Sue and WG,







I  draw you attention that there is another document  (please see https://www.ietf.org/archive/id/draft-liu-idr-bgp-network-slicing-01.txt) also describe how to advertise slice for SR policy through BGP.


The key difference between the two proposals is the level of SR policy, Candidate Path or Segment List, that bind slice.


I think there is valid use-case that customer traffic can be balanced distributed among multiple slice, and hope to hear more discussion about the use cases in WG.






Regards,


PSF











Original



From: SusanHares <shares@ndzh.com>
To: idr@ietf.org <idr@ietf.org>;
Date: 2023年03月01日 12:49
Subject: [Idr] Adoption call for - draft-dong-idr-sr-policy-nrp-02 (3/1 to 3/14)


_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

 

This begins a 2 week WG adoption call for


draft-dong-idr-sr-policy-nrp


https://datatracker.ietf.org/doc/draft-dong-idr-sr-policy-nrp/


 


Each of the authors should respond to this message with


an email indicating if they know of any IPR regarding this draft.


 


The draft specifies an extension to BGP SR policy to


Specify the NRP (network partition resources) that


Than an SR Policy candidate path is associated with.


 


In your discussion consider if this is a useful addition to the


SR Policy candidate path.


 


Cheerily, Sue


 


===========


Full description from the draft


 

  Segment Routing (SR) Policy is a set of candidate paths, each    consisting of one or more segment lists and the associated    information.  The header of a packet steered in an SR Policy is    augmented with an ordered list of segments associated with that SR    Policy.  A Network Resource Partition (NRP) is a subset of network    resources allocated in the underlay network which can be used to   support one or a group of IETF network slice services. 
 


   In networks where there are multiple NRPs, an SR Policy may be


   associated with a particular NRP.  The association between SR Policy


   and NRP needs to be specified, so that for service traffic which is


   steered into the SR Policy, the header of the packets can be


   augmented with the information associated with the NRP.  An SR Policy


   candidate path can be distributed using BGP SR Policy.  This document


   defines the extensions to BGP SR policy to specify the NRP which the


   SR Policy candidate path is associated with.