<?xml version="1.0" encoding="US-ASCII"?>

<!DOCTYPE rfc> 
<?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="3"?>
<!-- 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-song-mpls-flag-based-opt-03"
     ipr="trust200902">

<front>
  <title abbrev="MPLS OPT"> Flag-based MPLS On Path Telemetry Network Actions </title>

  <author fullname="Haoyu Song" initials="H." surname="Song">
    <organization>Futurewei Technologies</organization>
    <address>
      <postal>
        <street></street>
        <city></city>
        <region></region>
        <code></code>
        <country>United States of America</country>
      </postal>
      <email>haoyu.song@futurewei.com</email>
    </address>
  </author>

  <author fullname="Giuseppe Fioccola" initials="G." surname="Fioccola">
    <organization>Huawei Technologies</organization>
    <address>
      <postal>
        <street></street>
        <city></city>
        <region></region>
        <code></code>
        <country>Germany</country>
      </postal>
      <email>giuseppe.fioccola@huawei.com</email>
    </address>
  </author>
  
  <author fullname="Rakesh Gandhi" initials="R." surname="Gandhi">
		<organization>Cisco Systems</organization>
      <address>
        <postal>
          <street> </street>
          <city></city>
          <country>Canada</country>
        </postal>
		<email>rgandhi@cisco.com</email>
      </address>
    </author>

  <area>RTG</area>
  <workgroup>MPLS</workgroup>
  
  <!---->

  <keyword>OPT</keyword>
  <keyword>MPLS</keyword>
  <keyword>MNA</keyword>

  <abstract>
    <t>This document describes the scheme to support two on-path telemetry techniques, PBT-M and Alternate Marking, as flag-based MPLS Network Actions for OAM in MPLS networks.</t>
  </abstract>
 
</front>

<middle>

  <section anchor="Intro" title="Introduction">
  
	  <t>On-path telemetry, as described in <xref target="I-D.song-opsawg-ifit-framework"/>, is a kind of hybrid type I network OAM <xref target="RFC7799"/> which directly measure and monitor the user packets. Some on-path telemetry technique incur very little overhead but offer big benefits on network performance monitoring and troubleshooting.  <xref target="I-D.song-ippm-postcard-based-telemetry">PBT-M</xref>  (Postcard-Based On-Path Telemetry using Packet Marking) is such on-path telemetry technique which uses only a single flag bit to trigger the collection of the telemetry data regarding the packet. Alternate Marking Method <xref target="RFC9341"> </xref> is another on-path performance measurement method which uses only two flag bits to measure packet loss, delay, and jitter for live data traffic.</t>
  
    <t>In MPLS networks, MPLS Network Action (MNA) <xref target="I-D.ietf-mpls-mna-fwk"/> extends the MPLS label stack by supporting extra network actions encoded both in stack and post stack. The MNA header encoding is described in <xref target="I-D.ietf-mpls-mna-hdr"/>.</t>
	
	<t>This document describe the scheme to use flag-based MNAs to support PBT-M and Alternate Marking Method (AMM).</t>  

    <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><xref
    target="RFC8174"></xref> when, and only when, they appear in all
    capitals, as shown here.</t>
    
  </section>
  
  <section title="PBT-M Action">

    <t>A flag bit (TBA1) in the flag-based network action field is used as the PBT-M indicator. If the bit is set to '1', a configured node is triggered to collect and export the telemetry data as configured by the control plane. The detailed method on node configuration, data export and correlation are recommended in <xref target="I-D.song-ippm-postcard-based-telemetry"/>. </t>
      
  </section>	  
  
  <section title="Alternate Marking Action">
  
     <t>Two flag bits (TBA2) in the flag-based network action field are used to support the alternate marking method as described in <xref target="RFC9341"></xref>. </t>
    
  </section>

  <section title="Action Encoding">

    <t>The proposed action encoding is shown in <xref target="figure_1"/> adapted from <xref target="I-D.ietf-mpls-mna-hdr"/>.
	 In the figure, 'P' stands for PBT-M flag and 'AM' stands for alternate marking flags. </t>

    <t><figure anchor="figure_1" title="Action Encoding">
      <artwork align="center"><![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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      NASI=bSPL                        | TC  |S|    TTL        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |NAI-Opcode=2 |P|AM |                   |0|IHS|S| Res |U| NASL  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    (TBA)
 
 ]]></artwork>
   </figure></t>

   <t>The scope of the Network Action is carried in the IHS field for Ingress-To-Egress (I2E), Hop-By-Hop (HBH) or Select. </t>
   <t>Network Sub Stack Length is set to number of LSEs following this network action LSE which is 0 in this example. </t>
   <t>No Post Stack Network Action is required for this. </t>
 
   <t>Note that the in-stack MNA encoding may take different form, and these flag-based on-path telemetry use cases would adapt to it.</t>  

 </section>
 

  <section anchor="Security" title="Security Considerations">
    <t>Only the ingress edge node is allowed to set/reset these flag bits. The other on-path nodes can only react to the bit values. The tampering of these flag-based actions would result in DoS attack or unreliable measurements. Therefore, security measures must be taken to ensure the proper functioning of these actions. </t>
  </section>

  <section anchor="IANA" title="IANA Considerations">
    <t>This document requires IANA allocation a bit for PBT-M action (TBA1) and two bits for Alternate Marking (TBA2) from
   the MPLS "In-Stack MPLS Network Action Indicator Flags" registry created in <xref target="I-D.ietf-mpls-mna-hdr"/>. </t>
  </section>


 <section anchor="Acknowledgments" title="Acknowledgments">
 </section>

 </middle>

 <back>

 <references title="Normative References">
   
   <?rfc include='reference.RFC.2119'?>
   <?rfc include='reference.RFC.8174'?>
   <?rfc include='reference.RFC.7799'?>
   <?rfc include='reference.I-D.ietf-mpls-mna-hdr'?>

 </references>
      
 <references title="Informative References">
   <?rfc include='reference.RFC.9341'?>
   <?rfc include='reference.I-D.song-opsawg-ifit-framework'?>
   <?rfc include='reference.I-D.song-ippm-postcard-based-telemetry'?>
   <?rfc include='reference.I-D.ietf-mpls-mna-fwk'?>
   <?rfc include='reference.I-D.ietf-mpls-miad-mna-requirements'?>
 </references>

 </back>
</rfc>
