<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc [
<!-- One method to get references from the online citation libraries.
    There has to be one entity for each item to be referenced. 
    An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3032 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3032.xml">
<!ENTITY RFC6790 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6790.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
    please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
    (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
    (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-li-mpls-mna-nrp-selector-00" ipr="trust200902" submissionType="IETF" consensus="true">
 <!-- category values: std, bcp, info, exp, and historic
    ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
       or pre5378Trust200902
    you can add the attributes updates="NNNN" and obsoletes="NNNN" 
    they will automatically be output with "(if approved)" -->

 <!-- ***** FRONT MATTER ***** -->

 <front>
   <!-- The abbreviated title is used in the page header - it is only necessary if the 
        full title is longer than 39 characters -->

   <title abbrev="MNA NRP Sel">MPLS Network Actions for Network Resource Partition Selector
   </title>

   <!-- add 'role="editor"' below for the editors if appropriate -->

   <!-- Another author who claims to be an editor -->

    
    <author initials="T." surname="Li" fullname="Tony Li">
	<organization>Juniper Networks</organization>
	<address>
          <postal>
             <street>1133 Innovation Way</street>
             <city>Sunnyvale</city>
             <region>CA</region>
             <code>94089</code>
             <country>US</country>
          </postal>
             <email>tony.li@tony.li</email>
	</address>
    </author>    
    
    <author initials="J." surname="Drake" fullname="John Drake">
	<organization>Juniper Networks</organization>
	<address>
          <postal>
             <street>1133 Innovation Way</street>
             <city>Sunnyvale</city>
             <region>CA</region>
             <code>94089</code>
             <country>US</country>
          </postal>
	    <email>jdrake@juniper.net</email>
	</address>
    </author>    
    
    <author initials="V.P." surname="Beeram" fullname="Vishnu Pavan Beeram">
	<organization>Juniper Networks</organization>
	<address>
          <postal>
             <street>1133 Innovation Way</street>
             <city>Sunnyvale</city>
             <region>CA</region>
             <code>94089</code>
             <country>US</country>
          </postal>
	    <email>vbeeram@juniper.net</email>
	</address>
    </author>    
    
    <author initials="T." surname="Saad" fullname="Tarek Saad">
	<organization>Cisco Systems</organization>
	<address>
	    <email>tsaad.net@gmail.com</email>
	</address>
    </author>
    
    <author initials="I." surname="Meilik" fullname="Israel Meilik">
	<organization>Broadcom</organization>
	<address>
	    <email>israel.meilik@broadcom.com</email>
	</address>
    </author>
    
   <date year="2023" />

   <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
        in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

   <!-- Meta-data Declarations -->

   <area>Routing</area>

   <workgroup>MPLS 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>template</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> 
   An IETF Network Slice service provides connectivity coupled with a set of
   network resource commitments and is expressed in terms of one or more
   connectivity constructs.  A Network Resource Partition (NRP) is a 
   collection of resources identified in the underlay network to support
   IETF Network Slice services. A Slice-Flow Aggregate refers to the set of
   traffic streams from one or more connectivity constructs belonging to  one
   or more IETF Network Slices that are mapped to a specific NRP
   and provided the same forwarding treatment. 
   The packets associated with a Slice-Flow Aggregate may carry a marking in
   the packet's network layer header to identify this association and this
   marking is referred to as NRP Selector. The NRP Selector is used
   to map the packet to the associated NRP and provide
   the corresponding forwarding treatment to the packet.
   </t>
   <t>
   MPLS Network Actions (MNA) technologies are used to
   indicate actions for Label Switched Paths (LSPs) and/or MPLS packets
   and to transfer data needed for these actions.
   This document discusses options for using MPLS Network Actions (MNAs) to carry
   the NRP Selector in MPLS packets.
   </t>
   </abstract>

 </front>

 <middle>
   <section title="Introduction">
   <t>
   An IETF Network Slice <xref target="I-D.ietf-teas-ietf-network-slices"/> service
   provides connectivity coupled with a set of specific commitments of network
   resources between a number of endpoints over a shared underlay network. The IETF
   Network Slice service is expressed in terms of one or more connectivity constructs.
   A Network Resource Partition (NRP) <xref target="I-D.ietf-teas-ietf-network-slices"/>
   is a collection of resources identified in the underlay network to support IETF
   Network Slice services (or any other services that need logical network structures
   with required characteristics to be created). An NRP Policy <xref target="I-D.ietf-teas-ns-ip-mpls"/>
   is a policy construct that enables instantiation of mechanisms in support of service
   specific control and data plane behaviors on select topological elements associated
   with the NRP.
   </t>

   <t>
   A Slice-Flow Aggregate refers to the set of traffic streams from one or more
   connectivity constructs belonging to one or more IETF Network Slices that are mapped to a
   specific NRP and are provided the same forwarding treatment. The NRP policy
   dictates the identification of the flow aggregate that the packet belongs to and
   the corresponding forwarding treatment that needs to be applied to the packet. The
   packets associated with a Slice-Flow Aggregate may carry a marking in the packet's
   network layer header to identify this association and this marking is referred to as
   NRP Selector (NRPS). <xref target="I-D.ietf-teas-ns-ip-mpls"/> discusses a
   few options for carrying the NRP Selector in MPLS packets, including overloading the semantics
   of forwarding/service labels and using a dedicated identifier field.
   </t>

   <t>
   <xref target="I-D.ietf-mpls-mna-fwk"/> specifies an architectural framework for the MPLS
   Network Actions (MNA) technologies.  MNA technologies are used to
   indicate actions for Label Switched Paths (LSPs) and/or MPLS packets
   and to transfer data needed for these actions. The MNA 
   architecture can facilitate carrying the dedicated identifier based NRP Selector in the MPLS label stack.
   This document discusses a few options for using MPLS network actions to carry the NRP Selector. The proposed encodings
   are compliant with the MNA header encoding formats defined in <xref target="I-D.ietf-mpls-mna-hdr"/>.
   </t>
   <t>
   The reader is expected to be familiar with terminology specified in <xref target="I-D.ietf-mpls-mna-fwk"/> and
   MNA header encoding formats defined in <xref target="I-D.ietf-mpls-mna-hdr"/>.
   </t>

   <section title="Requirements Language">
       <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
       "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
       document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
      appear in all capitals, as shown here.
       </t>
   </section>
</section>

<section title="MPLS Network Actions">
<section title = "13-bit NRP Selector (NRPS13) Action">
<t>
The format of the 13-bit NRP Selector (NRPS13) Action
(when encoded in the second label stack entry in the Network Action Sub-Stack):
       <figure>
       <artwork align="left"><![CDATA[
  0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Opcode=TBA1 |         NRPS            |R|IHS|S| Res |U|  NASL |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ]]></artwork>
           </figure>
  <list style="hanging">
   <t hangText="*"> Name: 13-bit NRP Selector (NRPS13) Action
   </t>
   <t hangText="*"> Network Action Indication: The NRPS13 Action indication is opcode TBA1.
   </t>
   <t hangText="*"> Scope: The NRPS13 Action is valid in all scopes.
   </t>
   <t hangText="*"> In-Stack Data: The NRPS13 Action carries 13 bits of ancillary data.
      The NRPS is encoded in the 13 bits. The packet carrying the
      NRPS13 action should be given the forwarding treatment specified by the
      associated policy.
   </t>
   <t hangText="*"> LSE Format: B.  
   </t>
   <t hangText="*"> Post-Stack Data: None.
   </t>
  </list>
</t>
</section>
<section title="20-bit NRP Selector (NRPS20) Action">
   <t>
The format of the 20-bit NRP Selector (NRPS20) Action:
       <figure>
       <artwork align="left"><![CDATA[
  0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Opcode=TBA2|             NRPS              |S|  NRPS |  NAL  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ]]></artwork>
           </figure>
  <list style="hanging">
   <t hangText="*"> Name: 20-bit NRP Selector (NRPS20) Action
   </t>
   <t hangText="*"> Network Action Indication: The NRPS20 Action indication is opcode TBA2.
   </t>
   <t hangText="*"> Scope: The NRPS20 Action is valid in all scopes.
   </t>
   <t hangText="*"> In-Stack Data: The NRPS20 Action carries 20 bits of ancillary data.
      The NRPS is encoded in the 20 bits. The packet carrying the
      NRPS20 action should be given the forwarding treatment specified by the 
      associated policy.
   </t>
   <t hangText="*"> LSE Format: C.  The Network Action Length (NAL) field SHOULD be	
      transmitted as zero.
   </t>
   <t hangText="*"> Post-Stack Data: None.
   </t>
  </list>
  </t>
</section>
<section title="20-bit Entropy and NRP Selector (ENRPS20) Action">
<t>
The format of the 20-bit Entropy and NRP Selector (ENRPS20) Action:
       <figure>
       <artwork align="left"><![CDATA[
 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Opcode=TBA3|        Entropy        | NRPS  |S| NRPS  |  NAL  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ]]></artwork>
           </figure>
  <list style="hanging">
   <t hangText="*"> Name: 20-bit Entropy and NRP Selector (ENRPS20) Action
   </t>
   <t hangText="*"> Network Action Indication: The ENRPS20 Action indication is opcode TBA3.
   </t>
   <t hangText="*"> Scope: The ENRPS20 Action is valid in all scopes.
   </t>
   <t hangText="*"> In-Stack Data: The ENRPS20 Action carries 20 bits of ancillary data.
      The most significant 12 bits of ancillary data is the Entropy
      Value.  The least significant 8 bits of ancillary data is the
      NRPS.  The Entropy Value has semantics consistent with the
      Entropy Label <xref target="RFC6790"/>.  While the RFC 6790 Entropy Label has
      some restrictions to avoid collisions with the reserved label
      space (0-15) <xref target="RFC3032"/>, those restrictions are not necessary for
      the Entropy Value and do not apply. 
      The packet carrying the ENRPS20 action should be
      given the forwarding treatment specified by the associated policy.
   </t>
   <t hangText="*"> LSE Format: C.  The Network Action Length (NAL) field SHOULD be	
      transmitted as zero.
   </t>
   <t hangText="*"> Post-Stack Data: None.
   </t>
  </list>
  </t>
</section>
</section>


  


   <!-- This PI places the pagebreak correctly (before the section title) in the text output. -->

   <?rfc needLines="8" ?>


   <section anchor="IANA" title="IANA Considerations">
   <section anchor ="IANA_NRPS13" title="13-bit NRP Selector Action">
   <t>
   This document requests that IANA allocate a codepoint (TBA1) from the
   "Multiprotocol Label Switching Architecture (MPLS)"/"MPLS Network
   Actions Parameters"/"Network Action Opcodes" registry for the 13-bit
   NRP Selector Action.  The allocation should reference this
   document.
   </t>
   </section>
   <section anchor ="IANA_NRPS20" title="20-bit NRP Selector Action">
   <t>
   This document requests that IANA allocate a codepoint (TBA2) from the
   "Multiprotocol Label Switching Architecture (MPLS)"/"MPLS Network
   Actions Parameters"/"Network Action Opcodes" registry for the 20-bit
   NRP Selector Action.  The allocation should reference this
   document.
   </t>
   </section>
   <section anchor ="IANA_ENRPS20" title="20-bit Entropy and NRP Selector Action">
   <t>
   This document requests that IANA allocate a codepoint (TBA3) from the
   "Multiprotocol Label Switching Architecture (MPLS)"/"MPLS Network
   Actions Parameters"/"Network Action Opcodes" registry for the 20-bit
   Entropy and NRP Selector Action.  The allocation should
   reference this document.
   </t>
   </section>
   </section>

   <section anchor="Security" title="Security Considerations">
   <t>
   The forwarding plane is insecure.  If an adversary can affect the
   forwarding plane, then they can inject data, remove data, corrupt
   data, or modify data.  MNA additionally allows an adversary to make
   packets perform arbitrary network actions.
   </t>
   <t>
   Link-level security mechanisms can help mitigate some on-link
   attacks, but does nothing to preclude hostile nodes.
   </t>
   </section>

   <section anchor="Contributors" title="Contributors">
     <t> The following individuals contributed to this document:</t>
     <t>
     Colby Barth<br></br>
     Juniper Networks<br></br>
     Email: cbarth@juniper.net
     </t>
     <t>
     Srihari R. Sangli<br></br>
     Juniper Networks<br></br>
     Email: ssangli@juniper.net
     </t>
     <t>
     Chandra Ramachandran<br></br>
     Juniper Networks<br></br>
     Email: csekar@juniper.net
     </t>
     <t>
     Kireeti Kompella<br></br>
     Juniper Networks<br></br>
     Email: kireeti@juniper.net
     </t>
</section>

 </middle>

 <back>
   <!-- References split into informative and normative -->

   <!-- There are 2 ways to insert reference entries from the citation libraries:
    1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
    2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
       (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

    Both are cited textually in the same manner: by using xref elements.
    If you use the PI option, xml2rfc will, by default, try to find included files in the same
    directory as the including file. You can also define the XML_LIBRARY environment variable
    with a value containing a set of directories to search.  These can be either in the local
    filing system or remote ones accessed by http (http://domain/dir/... ).-->

   <references title="Normative References">

     &RFC2119;
     &RFC8174;
     &RFC3032;
     &RFC6790;
     <?rfc include="reference.I-D.ietf-mpls-mna-hdr.xml"?>
   </references>

     <references title="Informative References">

     <?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.ietf-mpls-mna-fwk.xml"?>
   </references>

 </back>
</rfc>
