<?xml version='1.0' encoding='utf-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<rfc
      xmlns:xi="http://www.w3.org/2001/XInclude"
      category="std"
      docName="draft-liu-idr-bgp-network-slicing-02"
      ipr="trust200902"
      obsoletes=""
      updates=""
      submissionType="IETF"
      xml:lang="en"
      tocInclude="true"
      tocDepth="4"
      symRefs="true"
      sortRefs="true"
      version="3">

 <!-- ***** FRONT MATTER ***** -->

 <front>


   <title abbrev="BGP-LS SR Policy">BGP Extensions to Support Packet Network Slicing in SR Policy</title>
    <seriesInfo name="Internet-Draft" value="draft-liu-idr-bgp-network-slicing-02"/>


   <author fullname="Yao Liu" surname="Liu">
      <organization>ZTE</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city>Nanjing</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <phone></phone>
        <email>liu.yao71@zte.com.cn</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
	
   <author fullname="Shaofu Peng" surname="Peng">
      <organization>ZTE</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city>Nanjing</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <phone></phone>
        <email>peng.shaofu@zte.com.cn</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>	
	
    <date year="2023"/>

   <!-- Meta-data Declarations -->

   <area>Routing</area>
    <workgroup>IDR Working Group</workgroup>
    <!-- WG name at the upperleft corner of the doc,
        IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
        which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>SR Policy</keyword>
    <keyword>BGP</keyword>
    <keyword>Segment List</keyword>
    <!-- Keywords will be incorporated into HTML output
        files in a meta tag but they have no effect on text or nroff
        output. If you submit your draft to the RFC Editor, the
        keywords will be used for the search engine. -->

   <abstract>

<t>This document defines extensions to BGP in order to advertise Network Resource Partition (NRP) in SR policy. </t>

    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
	  
 <t><xref target="I-D.ietf-teas-ietf-network-slices"></xref> specified the definition of the IETF Network Slice and the general principles of network slicing in the IETF context. It introduced the concept of Network Resource Partition (NRP), which is is a subset of the forwarding resources and associated policies on each of a connected set of links in the underlay network.</t>
	  <t><xref target="I-D.ietf-teas-ns-ip-mpls"></xref> introduces the terminology NRP Identifier (NRP-ID) which is globally unique within an NRP domain and that can be used in the control or management plane to identify the resources associated with the NRP.</t>
	  	<t><xref target="RFC9256" format="default"></xref>  details the concepts of SR Policy and steering into an SR Policy.<xref target="I-D.ietf-idr-segment-routing-te-policy"/> specifies the way to use BGP to distribute one or more of the candidate paths of an SR Policy to the headend of that policy.
</t>
	  
	  <t>This document defines extensions to BGP in order to advertise NRP-ID in SR policy. </t>
 
	  
      <section numbered="true" toc="default">
        <name>Requirements Language</name>
	  <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119" format="default"></xref> <xref target="RFC8174" format="default"></xref> when, and only when, they appear in all capitals, as shown here.</t>
      </section>
    </section>
	
	
<section numbered="true" toc="default">
<name>SR policy with NRP</name>
	<t>
To distinguish forwarding behavior of different network slices, each segment lists in SR policy need to be computed within the scope of NRP identified by NRP-ID. As NRP has global significance, all segments of the same segment list can share a single NRP.
This document defines a new NRP sub-TLV in Segment List Sub-TLV to indicate which slice this segment list belongs to,
	</t>

		<figure>
		<name>NRP sub-TLV in Segment List Sub-TLV</name>
			<artwork align="center" ><![CDATA[
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type=TBD1   |   Length      |     Flags     |   RESERVED    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              NRP-ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ]]></artwork>		   
		</figure>
		
<t>where,</t>		
		
	<ul spacing="normal">	
        <li>Type: TBD1</li>
		<li>Length: 6</li>
		<li>Flags: 1 octet of flags.  None are defined at this stage. Flags SHOULD be set to zero on transmission and MUST be ignored on receipt</li>
		<li>RESERVED: 1 octet of reserved bits.  SHOULD be set to zero on transmission and MUST be ignored on receipt.</li>
		<li>NRP-ID: 4-octet identifier of Network Resource Partition of the segment list.</li>		
     </ul>

<t>The new SR Policy encoding structure with Path Segmentg sub-TLV is expressed as below:</t>
        <artwork align="center" name=""><![CDATA[
      SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
      Attributes:
         Tunnel Encaps Attribute (23)
            Tunnel Type: SR Policy
                Binding SID
                Preference
                Priority
                Policy Name
                Explicit NULL Label Policy (ENLP)
                Segment List
                    Weight
                    NRP-ID
                    Segment
                    Segment                    
                    Segment
                    ...
                    Segment
                    Segment
                    Segment
                    ...
                ...
           ]]></artwork>	
	
</section>	

 <section title="Operations">
 <t>The operations about advertisement and reception of SR policy can refer to <xref target="I-D.ietf-idr-segment-routing-te-policy"></xref>. Typically, a controller can compute SR path taking acount of NRP criteria, so that the SR path can be limited in the scope of NRP identified by NRP-ID. The controller can obtain the NRP virtual topology information through necessary tools such BGP-LS, netconf, etc, and maintain the database for the traffic engineering path computation. The proposal in this document supports that multiple segment list each with different NRP-ID, to meet the requirements that service flow is carried by multiple network slices. However, it also support that all segment list or all candidate path of the SR policy belongs to the same slice.</t>
 <t>The NRP information contained in Segment List Sub-TLV can help the headend to translate the segment to NRP related SID, if the Segment Sub-TLV has not provided optional SID information. Even if Segment Sub-TLV has provided valid SID information, it is also beneficial for the headend to know which slice this path belongs to, according to the NRP information contained in Segment List Sub-TLV.</t> 
 </section>

	
<section numbered="true" toc="default">
	<name>IANA Considerations</name>
	
	<t>TBD</t>

	   
	
</section>

	

<section numbered="true" toc="default">
	<name>Security Considerations</name>
		<t>Procedures and protocol extensions defined in this document do not affect the security considerations discussed in <xref target="I-D.ietf-idr-segment-routing-te-policy"></xref>.</t>
</section>	
	
	
  </middle>
  <!--  *****BACK MATTER ***** -->

 <back>

   <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
		<?rfc include="reference.RFC.2119.xml"?>
		<?rfc include="reference.RFC.8174.xml"?>			
		<?rfc include="reference.I-D.ietf-idr-segment-routing-te-policy.xml"?>
      </references>
      <references>
        <name>Informative References</name>
		<?rfc include="reference.RFC.9256.xml"?>		
	<?rfc include="reference.I-D.ietf-teas-ietf-network-slices.xml"?>
	<?rfc include="reference.I-D.ietf-teas-ns-ip-mpls.xml"?>	
	<?rfc include="reference.I-D.bestbar-spring-scalable-ns.xml"?>	
      </references>
    </references>


 </back>
</rfc>
