<?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-lsr-mpls-inspection-msd-01"
      ipr="trust200902"
      obsoletes=""
      updates=""
      submissionType="IETF"
      xml:lang="en"
      tocInclude="true"
      tocDepth="4"
      symRefs="true"
      sortRefs="true"
      version="3">

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

 <front>


   <title abbrev="MPLS Inspection MSD">Signaling Base MPLS Inspection MSD</title>
    <seriesInfo name="Internet-Draft" value="draft-liu-lsr-mpls-inspection-msd-01"/>


   <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>	
	
    <date year="2023"/>

   <!-- Meta-data Declarations -->

   <area>Internet</area>
    <workgroup>LSR</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>MPLS</keyword>
   <keyword>MSD</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 new type of MSD, Base MPLS Inspection MSD to reflect the Readable Label Depth(RLD), and the mechanism to signal this MSD using IGP and BGP-LS.
    </t>
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
	  
	  <t><xref target="I-D.ietf-mpls-mna-fwk"></xref> 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.</t>
	  <t><xref target="I-D.ietf-mpls-mna-hdr"></xref> defines the MPLS Network Action sub-stack(NAS) solution for carrying Network Actions and Ancillary Data in the label stack. The node adding an NAS to the label stack will need to place a copy of the NAS where it can be read by the relevant nodes. In order to put the NAS at the appropriate place into the MPLS label stack, the need for signaling RLD by every participanting node is proposed in <xref target="I-D.ietf-mpls-mna-hdr"></xref>.</t>
	  <t>On the other hand, even if the MNA framework is not followed, as long as there're scenarios where at least part of the transit nodes are required to inspect beyond the top of stack, the requirement to obtain the maximum inspection depth of the nodes along the LSP exists.</t>
	<t>Maximum SID Depth (MSD)<xref target="RFC8491"></xref> is originally introduced for SR-MPLS to express the number of SIDs supported by a node or a link on a node. In a non-SR MPLS network, MSD defines the maximum label depth.</t>
	<t>This document defines a new type of MSD, Base MPLS Inspection MSD, and the mechanism to signal this MSD using IGP and BGP-LS.</t>	  
	  
	   
    </section>
	
<section numbered="true" toc="default">
<name>Conventions Used in This Document</name>

	<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 numbered="true" toc="default">
        <name>Abbreviations</name>
	  <t>MNA: MPLS Network Actions</t>
	  <t>NAS: Network Action sub-stack</t>
	  <t>EL: Entropy Label</t>
	  <t>ERLD: Entropy Readable Label Depth</t>
	  <t>RLD: Readable Label Depth</t>
      </section>      
	  
</section>	  



	  
<section numbered="true" toc="default">
<name>Base MPLS Inspection MSD</name>		  
<t>The Base MPLS Inspection MSD is defined as the maximum number of labels a router can read in an MPLS packet received on its incoming interface(s) (starting from the top of the stack).</t>
<t>The Base MPLS Inspection MSD MAY be used by ingress LSRs to determine the position of the NAS, and whether it's necessary to insert multiple NAS at different positions in the label stack. When the label stack are determined by a centralized controller, the MSD of each intermediate LSR SHOULD be sent to the controller.</t>
<t>With Base MPLS Inspection MSD, application/network action-specified MSD analogous to ERLD-MSD<xref target="RFC9088"></xref> <xref target="RFC9089"></xref> MAY not needed. For example, a node can signal certain network action capability and the Base MPLS Inspection MSD to indicate that it can process this network action within the MSD.</t>

<t>Editor's note: The reason why ERLD-MSD is not reused to reflect the RLD is that the definition of ERLD is strongly related the router's ability to process entropy label. As specified in <xref target="RFC8662"></xref>, the ERLD means that the router will perform load-balancing using the EL if the EL is placed within the first ERLD labels, and a router capable of reading N labels but not using an EL located within those N labels MUST consider its ERLD to be 0. Considering that implementations in strict accordance with the definition of ERLD may exist, defining a new MSD instead of reusing/updating ERLD is preferred in this document. </t>
 	
</section>		  
	  

<section numbered="true" toc="default">
<name>Advertising Base MPLS Inspection MSD Using IS-IS</name>		  
<t>A new MSD-Type <xref target="RFC8491"></xref>, called Base MPLS Inspection MSD, is defined. The MSD-Type code is to be assigned by IANA. The MSD-Value field is set to the maximum number of labels a router can read in the range between 0 to 255. The scope of the advertisement depends on the application.</t> 
<t>If a router has multiple interfaces with different capabilities of reading the maximum label stack depth, the router MUST advertise the smallest value found across all its interfaces.</t>
<t>The absence of Base MPLS Inspection MSD advertisements indicates only that the advertising node does not support advertisement of this capability.</t>
<t>If the Base MPLS Inspection MSD type is received in the Link MSD sub-TLV, it MUST be ignored.</t>	
</section>	
	
<section numbered="true" toc="default">
<name>Advertising Base MPLS Inspection MSD Using OSPF</name>		  
<t>The Base MPLS Inspection MSD is advertised in a Node MSD TLV <xref target="RFC8476"></xref> using the same MSD-Type code as defined in section 4.</t> 
<t>If a router has multiple interfaces with different capabilities of reading the maximum label stack depth, the router MUST advertise the smallest value found across all its interfaces.</t>
<t>The absence of Base MPLS Inspection MSD advertisements indicates only that the advertising node does not support advertisement of this capability.</t>
<t>If the Base MPLS Inspection MSD type is received in the Link MSD sub-TLV, it MUST be ignored.</t>	
</section>


<section numbered="true" toc="default">
<name>Signaling Base MPLS Inspection MSD in BGP-LS</name>		  
<t>The IS-IS and OSPF extensions defined in this document can be advertised via BGP-LS (distribution of Link-State and TE information using BGP) <xref target="RFC7752"></xref> using existing BGP-LS TLVs.</t> 
<t>The Base MPLS Inspection MSD is advertised using the Node MSD TLV as defined in <xref target="RFC8814"></xref>.</t>

</section>


<section numbered="true" toc="default">
<name>Security Considerations</name>		  
<t>This document specifies the ability to advertise additional node capabilities using IS-IS, OSPF and BGP-LS. As such, the security considerations as described in <xref target="RFC5340"></xref>, <xref target="RFC7684"></xref>, <xref target="RFC7752"></xref>, <xref target="RFC7770"></xref>, <xref target="RFC7794"></xref>, <xref target="RFC7981"></xref>, <xref target="RFC8476"></xref>, <xref target="RFC8491"></xref>, <xref target="RFC8662"></xref>, <xref target="RFC8814"></xref>, <xref target="RFC9085"></xref> are applicable to this document.</t>
<t>Incorrectly setting of the Base MPLS Inspection MSD value may lead to poor or no execution of the network action.</t>
	
</section>
	

	
<section numbered="true" toc="default">
	<name>IANA Considerations</name>
<t>This document requests the following allocation from IANA:</t>
<t>Type TBA in the IGP MSD-Types registry is requested to be assigned for the Base MPLS Inspection MSD.</t>
	</section>	



	
	
  </middle>
  <!--  *****BACK MATTER ***** -->

 <back>

   <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
<?rfc include="reference.RFC.5340.xml"?> 
<?rfc include="reference.RFC.7684.xml"?> 
<?rfc include="reference.RFC.7752.xml"?> 
<?rfc include="reference.RFC.7770.xml"?> 
<?rfc include="reference.RFC.7981.xml"?>
<?rfc include="reference.RFC.7794.xml"?> 
<?rfc include="reference.RFC.8476.xml"?> 
<?rfc include="reference.RFC.8491.xml"?> 
<?rfc include="reference.RFC.8662.xml"?> 
<?rfc include="reference.RFC.8814.xml"?>
<?rfc include="reference.RFC.9085.xml"?>
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.8174.xml"?>
	  
      </references>
      <references>
        <name>Informative References</name>
<?rfc include="reference.I-D.ietf-mpls-mna-fwk.xml"?>
<?rfc include="reference.I-D.ietf-mpls-mna-hdr.xml"?>	
<?rfc include="reference.RFC.9088.xml"?>
<?rfc include="reference.RFC.9089.xml"?>
	
      </references>
    </references>


 </back>
</rfc>
