<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?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. -->
<rfc
      xmlns:xi="http://www.w3.org/2001/XInclude"
      category="std"
      docName="draft-chen-lsr-mpls-mna-capability-04"
      ipr="trust200902"
      obsoletes=""
      updates=""
      submissionType="IETF"
      xml:lang="en"
      tocInclude="true"
      tocDepth="4"
      symRefs="true"
      sortRefs="true"
      version="3">
  <!-- xml2rfc v2v3 conversion 2.38.1 -->
  <!-- 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>
   <title abbrev="MNA Capability advertisement">Signaling MNA Capability Using IGP and BGP-LS</title>
    <seriesInfo name="Internet-Draft" value="draft-chen-lsr-mpls-mna-capability-04"/>
    <!-- add 'role="editor"' below for the editors if appropriate -->

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

   <author fullname="Ran Chen" initials="R." surname="Chen">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city>Nanjing</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <email>chen.ran@zte.com.cn</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>

	  <author fullname="Detao Zhao" initials="D." surname="Zhao">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->
         <city>Nanjing</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <email>zhao.detao@zte.com.cn</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
	
	     <date year="2026"/>
    <!-- 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>LSR 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>Internet Draft</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 a mechanism to signal MNA Capability using IGP and Border Gateway Protocol-Link State(BGP-LS).</t>
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
	  <t><xref target="RFC9789" format="default"></xref> describes the architectural framework for MPLS Network Action (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 specific encoding mechanisms and header formats for these actions are defined in <xref target="I-D.ietf-mpls-mna-hdr"/>.</t>
	  <t>Building upon these specifications, <xref target="I-D.ietf-mpls-mna-nrp-selector"/> and <xref target="I-D.ietf-mpls-mna-ioam"/> specify the mechanisms for carrying Network Resource Partition (NRP) Selectors and In-situ OAM (IOAM) data fields, respectively, using MPLS Network Actions.</t>
	  <t>The ingress node /Controller should obtain the network action of the nodes within the MNA infrastructure, which ensure that the encapsulated data packets by the ingress node can be correctly parsed by the on-path nodes. Specifically, while intermediate nodes can skip unsupported actions, the ingress node need to know whether the decapsulating node is capable of parsing and removing the MNA-related headers (e.g., NRP or IOAM data fields), thereby avoiding potential packet drops or forwarding errors</t>
      <t>This document defines how the ingress node knows of the network action all the on-path nodes within the MNA infrastructure. It defines a mechanism to signal the MPLS Network actions(MNA) using IGP and BGP-LS.</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", "NOT RECOMMENDED",
        "MAY", and "OPTIONAL" in this document are to be interpreted as
        described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/>
        when, and only when, they appear in all capitals, as shown here.</t>
      </section>
    </section>
   <section numbered="true" toc="default">
   <name>Advertising MNA Using IS-IS</name>
   <t>This section defines the MNA-Capabilities Sub-TLV that are inserted into the IS-IS Router Capability that is defined in <xref target="RFC7981" format="default"></xref>.</t>
   <t>The format of the MNA-Capabilities Sub-TLV is:</t>
   <artwork><![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             |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                     |P|I|C|N|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Figure 1. MNA-Capabilities Sub-TLV
           ]]></artwork>
	  <t>where:</t>
	  <t>Type: TBD1.</t>
	  <t>Length: 4.</t>
	  <t>Flags: 4 octet of flags. The following are defined:</t>	 
	  <ul spacing="normal">
        <li>S: 13-bit NRP Selector flag. If set, then the router is capable of processing 13-bit NRP Selector (NRPS13) (as defined in Section 2.1 of <xref target="I-D.ietf-mpls-mna-nrp-selector"/>) on all interfaces.</li>
		<li>N: 20-bit NRP Selector (NRPS20) flag. If set, then the router is capable of processing 20-bit NRP Selector (NRPS13)(as defined in Section 2.2 of <xref target="I-D.ietf-mpls-mna-nrp-selector"/>) on all interfaces.</li>
		<li>C: 20-bit Entropy and NRP Selector (ENRPS20) flag. If set, then the router is capable of processing 20-bit Entropy and NRP Selector (ENRPS20) (as defined in Section 2.3 of <xref target="I-D.ietf-mpls-mna-nrp-selector"/>)  on all interfaces.</li>
		<li>I: IOAM ISD flag. If set, it indicates that the router is capable of processing the IOAM option encoded as In-Stack Data (ISD) (as defined in Section 4.2 of <xref target="I-D.ietf-mpls-mna-ioam"/>) on all interfaces.</li>
	    <li>P: IOAM PSD flag. If set, it indicates that the router is capable of processing the IOAM option carried in the PSD (as defined in Section 4.1 of <xref target="I-D.ietf-mpls-mna-ioam"/>) on all interfaces.</li>
		 </ul>
		<t>The TLVs defined in this section are applicable to both OSPFv2, OSPFv3 and BGP-LS.</t>
      </section>

	 <section numbered="true" toc="default">
        <name>Advertising MNA Using OSPF</name> 
		<t>This section defines the MNA-Capabilities TLV that are inserted into the Router Information Opaque LSA（for OSPFv2）and OSPFv3 Router Information Opaque LSA（for OSPFv3）(defined in <xref target="RFC7770" format="default"></xref>). The format of the MNA-Capabilities TLV is the same as section 2.</t>
	 </section>
	 
	 <section numbered="true" toc="default">
        <name>Signaling MNA in BGP-LS</name> 
		<t>The IGP extensions defined in this document can be advertised via BGP-LS (distribution of Link-State and Traffic Engineering information using BGP) <xref target="RFC7752" format="default"></xref> using existing BGP-LS TLVs.</t>
		<t>This section defines the following Node Attribute TLV:</t>
		<artwork><![CDATA[   
    	
    +============+==============================+
    |    Type    |    Description               | 
    +============+==============================+
    |   TBD      |    the MNA-Capabilities TLV  | 
    +------------+------------------------------+
      
           ]]></artwork>
	 </section>
	 
    <section anchor="Acknowledgements" numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>TBD.</t>
    </section>
    <!-- Possibly a 'Contributors' section ... -->

   <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
	 <t>TBD.</t>
       </section>  
       
     <section anchor="Security" numbered="true" toc="default">
      <name>Security Considerations</name>
     <t>Procedures and protocol extensions defined in this document do not affect the IS-IS, OSPFv2 , OSPFv3 and BGP security model. See  Section 5 of <xref target="RFC7981" format="default"></xref> for a discussion of IS-IS security, Section 5 of <xref target="RFC7684" format="default"></xref> for a discussion of OSPFv2 TLV-encoding considerations, Section 7 of <xref target="RFC8362" format="default"></xref> for a discussion of OSPFv3 security and Section 8 of <xref target="RFC7752" format="default"></xref> for a discussion of BGP-LS security.</t>
    </section>
  </middle>
  <!--  *****BACK MATTER ***** -->

 <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>
        <name>Normative References</name>
        <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
      <?rfc include="reference.RFC.2119.xml"?>
	  <?rfc include="reference.RFC.7752.xml"?>
	  <?rfc include="reference.RFC.7770.xml"?>
	  <?rfc include="reference.RFC.7684.xml"?>
	  <?rfc include="reference.RFC.7981.xml"?>
	  <?rfc include="reference.RFC.8174.xml"?>
	  <?rfc include="reference.RFC.8362.xml"?>
	  <?rfc include="reference.RFC.9789.xml"?>
	  <?rfc include="reference.I-D.ietf-mpls-mna-hdr.xml"?>
	  <?rfc include="reference.I-D.ietf-mpls-mna-nrp-selector.xml"?>
	  <?rfc include="reference.I-D.ietf-mpls-mna-ioam.xml"?>
      </references>
       
    <!-- Change Log

v00 2006-03-15  EBD   Initial version

v01 2006-04-03  EBD   Moved PI location back to position 1 -
                     v3.1 of XMLmind is better with them at this location.
v02 2007-03-07  AH    removed extraneous nested_list attribute,
                     other minor corrections
v03 2007-03-09  EBD   Added comments on null IANA sections and fixed heading capitalization.
                     Modified comments around figure to reflect non-implementation of
                     figure indent control.  Put in reference using anchor="DOMINATION".
                     Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH     Major changes: shortened discussion of PIs,
                     added discussion of rfc include.
v05 2007-03-10 EBD    Added preamble to C program example to tell about ABNF and alternative 
                     images. Removed meta-characters from comments (causes problems).

v06 2010-04-01 TT     Changed ipr attribute values to latest ones. Changed date to
                     year only, to be consistent with the comments. Updated the 
                     IANA guidelines reference from the I-D to the finished RFC.
v07 2020-01-21 HL    Converted the template to use XML schema version 3.
    -->
 </back>
</rfc>
