<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-andersson-mpls-mna-label-stack-operations-00"
     ipr="trust200902">
  <front>

    <title abbrev="MNA Label Stack Operations">MPLS Label Stack Operations in Networks with MNA Incremental Deployment</title>

    <author fullname="Loa Andersson" initials="L." surname="Andersson">
      <organization>Bronze Dragon Consulting</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country/>
        </postal>
        <email>loa@pi.nu</email>
      </address>
    </author>
    
    <author fullname="James N Guichard" initials="J." surname="Guichard">
      <organization>Futurewei Technologies</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country/>
        </postal>
        <email>james.n.guichard@futurewei.com</email>
      </address>
    </author>
    
<author fullname="Haoyu Song" initials="H." surname="Song">
      <organization>Futurewei Technologies</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country/>
        </postal>
        <email>haoyu.song@futurewei.com</email>
      </address>
    </author>
    
 <author fullname="Stewart Bryant" initials="S." surname="Bryant">
      <organization>University of Surrey</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country/>
        </postal>
        <email>stewart.bryant@gmail.com</email>
      </address>
    </author>   
       
    <date day="26" month="September" year="2022"/>
    
     <workgroup>MPLS Working Group</workgroup>
	 
<abstract>
<t>
   MPLS Network Action (MNA) allows MPLS packet to carry instruction and data for in-network services and
   functions in an MPLS network. This document describes the FEC-based optimized operations on
   the MPLS label stack when the network is mixed with LSRs which are capable or incapable of
   processing MNAs.
</t>
      
</abstract>

</front>

<middle>
  <!-- section 1 -->
    <section anchor="intro" title="Introduction">

<t>MPLS Network Actions (MNA) is used to
   support actions for Label Switched Paths (LSPs) and/or MPLS packets
   in addition to the normal forwarding. <xref target="I-D.ietf-mpls-mna-fwk" />
   provides the architectural framework for MNA and <xref target="I-D.ietf-mpls-mna-requirements" /> 
   provides the design requirements for MNA. MNA can support actions encoded within or below the label stack.
   <xref target="I-D.andersson-mpls-eh-architecture"/> describes some further 
   architectural concepts for MNA.</t>


<t>
   This document provides the operating procedures for MNA-capable and 
   non-MNA-capable LSRs where MNA encoding are carried within or below 
   the MPLS label stack.  We show that MNAs can be gradually 
   introduced into an existing MPLS network.
   The capability to handle MNAs is announced throughout the MPLS network, and 
   LSRs that do not understand this information simply ignore it.
</t>

<t>
   The MNAs are carried below the top label and the presence
   of MNAs are indicated by a bSPL in the label stack.
</t>
    
    <t>
   The MNA use cases can be found in <xref target="I-D.ietf-mpls-mna-usecases"/>.
   A post-stack extension header may for example be used when it is required that
   the packet carry a large instruction header and/or metadata for an MNA 
    <xref target="I-D.song-mpls-extension-header"/>. 
</t>

<t>
Only MNA capable LSRs will process MNAs, LSRs that are non-MNA-capable will ignore
the MNA and forward the packet as if the information was not there.
</t>

   <section anchor="requirement-language" title="Requirement 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 anchor="spec" title="Operations on an MPLS Label Stack in an MNA capable network">
<t>
   This document provides a set of examples to show the operations performed 
   on MPLS encapsulated packets in a network where MPLS MNAs are used. The
   document does also illustrated the 
   procedures for processing of the information carried within the MPLS label 
   stack to indicate the presence of MNAs below the top label.
   
   <!-- 
   For the purpose of
   illustration, we will assume that the indicator used to point to EHs is a 
   G-ACh Generic Associated Channel Label (GAL) <xref target="RFC5586"/>
   + G-Ach Associated Channel Header (ACH)<xref target="RFC5586"/> with a set 
   of new ACH types to indicate the EH types carried
   below the MPLS label stack.
   -->
</t>

<!--
<t>
   As discussed in <xref target="I-D.andersson-mpls-eh-architecture"/>,
   <xref target="I-D.song-mpls-extension-header"/> and 
   <xref target="I-D.song-mpls-eh-indicator"/>
   there are alternatives to 
   the use of
   GAL as the indicator; for example an Extension Label (XL) <xref target="RFC7274"/> 
   + one or more Extended Special Purpose Labels (eSPLs) <xref target="RFC7274"/>
   could also be
   used.
</t>
-->

<section anchor="physical-topology" title="Physical Topology">

<t>
Assume a physical topology that includes both MNA capable LSRs and non-MNA 
capable LSRs. The topology is intentionally kept quite simple.



              
      <figure title = "MNA topology I" align="left" anchor="topo-example">
                    <artwork align="left">
                        <![CDATA[
   +---+      +---+      +---+      +---+      +---+      +---+
   |   |      |   |      |   |      |   |      |   |      |   |
   | A +------+ b +------+ c +------+ D +------+ E +------+ F +
   |   |      |   |      |   |      |   |      |   |      |   |
   +---+      +---+      +---+      +---+      +---+      +---+
   

Legend:
A, D, E, and F are MNA capable LSRs

b and c are non-MNA capable LSRs.


                    ]]>
                    </artwork>
     </figure>
</t>
  
<t> 
   LDP Downstream on Demand (DoD) or Downstream Unsolicited (DU), RSVP-TE, 
   an IGP or a centralized controller could be used to create the label 
   mappings between the LSRs in an MNA capable network. Referring to Figure 1, 
   and using LDP DU for illustration, creation of an MNA path used by A to send 
   MPLS encapsulated packets with MNAs to F is as show below.
</t>

<t>
For prefix F reachable at LSR F:

<list style="symbols">
<t>
F advertises labels F:[ldp: implicit-null, MNA-FEC: implicit-null] to E
</t>

<t>
E advertises labels F:[ldp: 101, MNA-FEC: 201] to D
</t>

<t>
D advertises label F:[ldp: 102] to c
</t>

<t>
c advertises label F:[ldp: 103] to b
</t>

<t>
b advertises label F:[ldp: 104] to A
</t>
</list>
</t>

<t>
This will result in installed labels as shown in <xref target="mapping-example"/>.
</t>
      <figure title = "MNA topology II" align="left" anchor="mapping-example">
                    <artwork align="left">
                        <![CDATA[
    +---+       +---+       +---+       +---+       +---+       +---+
    |   |..104..|   |..103..|   |..102..|   |..101..|   |..php..|   |
    | A +-------+ b +-------+ c +-------+ D +-------+ E +-------+ F +
    |   |       |   |       |   |       |   |..201..|   |..php..|   |
    +---+       +---+       +---+       +---+       +---+       +---+

    Legend:
    A, D, E and F are MNA capable nodes.
    b and are non-MNA capable nodes.


                    ]]>
                    </artwork>
     </figure>

</section>


<section anchor="day" title="A day in the life of a packet">
<t>
This section provides examples of forwarding for some common scenarios in 
networks with a mix of MNA-capable and non-MNA-capable LSRs and packets with and
without MNAs encoded.
</t>

<t> The examples assume the use of post-stack extension headers. The process is equally applicable 
   to in-stack MNAs.
</t>

      <figure title = "Label Stack with MNA" align="left" anchor="label-stack-example">
                    <artwork align="left">
                        <![CDATA[

For reference the following shows the full MPLS MNA stack, i.e. 
including also the post-stack EH specific information and the payload.
0                                  31
+--------+--------+--------+--------+
|                                   |
~         MPLS Label Stack          ~
|                                   |
+--------+--------+--------+--------+
|           bSPL for MNA            |  
+--------+--------+--------+--------+   
|                                   |
~         MPLS Label Stack          ~
|                                   |  
+--------+--------+--------+--------+    
| Header of Extension Headers (HEH) |
+--------+--------+--------+--------+
|                                   |
~  Extension Header (EH) for MNA 1  ~
|                                   |
+--------+--------+--------+--------+
|                                   |
~  Extension Header (EH) for MNA N  ~
|                                   |
+--------+--------+--------+--------+
|                                   |
~   Upper Layer Protocols/Payload   ~
|                                   |
+--------+--------+--------+--------+


                    ]]>
                    </artwork>
     </figure>

<section anchor="non-vpn" title="Non-VPN Case">

<t>
For non-VPN there are two variants, either the MNA is present or it is not.
</t>

<section anchor="mna-vpn" title="Non-VPN with an MNA in the packet">

<t>

<list style="symbols">
<t>
A sends packet to b
<list style="symbols">
<t>
stack = [104, bSPL, HEH, EH, IP]
</t>
</list>
</t>
</list>
</t>

<t>
<list style="symbols">
<t>
b is a legacy router so just swaps [104] to [103], and sends the packet to c

<list style="symbols">
<t>
stack = [103, bSPL, HEH, EH, IP]
</t>
</list>
</t>
</list>
</t>

<t>
<list style="symbols">
<t>
c is a legacy router so just swaps [103] to [102], and sends the packet to D

<list style="symbols">
<t>
stack = [102, bSPL, HEH, EH, IP]
</t>
</list>
</t>
</list>
</t>

<t>
<list style="symbols">
<t>
D is an MNA capable LSR and receives the packet with [102] on top of the stack; 
D scans the packet for an MNA; D finds the MNA and processes it and then swaps the top 
label 
to [101] and then sends the packet on to E


<list style="format %i">
<t>
Note: this goes on the standard FEC because we only announce in the packet
there is NO MNA. In this case MNA is present.
</t>
</list>

<list style="symbols">
<t>
stack = [101, bSPL, HEH, EH, IP]
</t>
</list>
</t>
</list>
</t>

<t>
<list style="symbols">
<t>
E receives [101] and scans the packet for MNA; it finds the MNA and processes it and then 
pops the top label and send the packet to F


<list style="symbols">
<t>
stack = [bSPL, HEH, EH, IP]

<list style="symbols">
<t>
Note: E is the penultimate hop router so it pops the standard LDP label, and
send on the standard FEC to F.
</t>
</list>
</t>
</list>
</t>
</list>
</t>

<t>
<list style="symbols">
<t>
F receives the packet and scans the packet for MNA; it finds the MNA and processes it. 
As F is the ultimate hop it pops GAL, and removes bSPL, HEH and EH, processes IP 
and forwards the packet.
</t>
</list>
</t>

</section>



<section anchor="non-mna-vpn" title="Non-VPN without any MNA in the packet">
<t>
In this example there is no MNA present in the packet.
</t>
<t>
<list style="symbols">

<t>
A sends packet to b
<list style="symbols">
<t>
stack = [104, IP]
</t>
</list>
</t>
</list>
</t>

<t>
<list style="symbols">

<t>
b receives the packet, b is a legacy router so it just swaps [104] to [103] and
sends the packet to c

<list style="symbols">
<t>
stack = [103, IP]
</t>
</list>
</t>
</list>
</t>

<t>
<list style="symbols">

<t>
c receives the packet, c is a legacy router so it just swaps [103] to [102], and
sends the packet to D

<list style="symbols">
<t>
stack = [102, IP]
</t>
</list>
</t>
</list>
</t>

<t>
<list style="symbols">

<t>
D receives the packet. Since D is an MNA capable router, it searches the packet for 
MNA but finds nothing, so D swaps [102] to [201], and
sends the packet to E

<list style="symbols">
<t>
stack = [201, IP]

<list style="symbols">
<t> 
Note: in this case D sends the packet using the MNA-FEC as MNA is *not* present.
</t>

<t>
Note: If downstream is not MNA capable then D sends the packet on the standard FEC. 
</t>
</list>
</t>
</list>
</t>
</list>
</t>

<t>
<list style="symbols">

<t>
E receives the packet [201] and bypasses MNA searching and processing (received on the 
"no MNA present" FEC; E is penultimate node so it pops MNA-FEC label; and
send the packet to F.
<list style="symbols">
<t>
stack = [IP]; not exactly a "label stack", but listed here for symmetry
</t>
</list>
</t>
</list>
</t>

<t>
<list style="symbols">
<t>
F receives [IP] and routes the packet
</t>
</list>
</t>

</section>

</section>

</section>

<section anchor="vpn" title="The VPN case">

<t>
In these two examples there is VPN information in the label stack, in the 
first there also MNAs in the packet.
</t>
<section anchor="vpn-mna" title="VPN with MNA in the packet">
<t>
<list style="symbols">
<t>
A sends packet to b
<list style="symbols">
<t>
stack = [104, VPN, bSPL, HEH, EH, IP]
</t>
</list>
</t>
</list>
</t>

<t>
<list style="symbols">
<t>
b receives the packet; b is a legacy router and just swaps [104] to [103] and 
sends the packet to c
<list style="symbols">
<t>
stack = [103, VPN, bSPL, HEH, EH, IP]
</t>
</list>
</t>
</list>
</t>

<t>
<list style="symbols">
<t>
c receives the packet; c is a legacy router and just swaps [103] to [102] and 
sends the packet to D
<list style="symbols">
<t>
stack = [102, VPN, bSPL, HEH, EH, IP]
</t>
</list>
</t>
</list>
</t>

<t>
<list style="symbols">
<t>
D receives the packet; D is an MNA capable LSR; D will search the packet for
MNA and will find and process the MNA; D will then swap [102] to [101] and 
sends the packet to E
<list style="symbols">
<t>
stack = [101, VPN, bSPL, HEH, EH, IP]
<list style="symbols">
<t>
Note: This packet will be sent normal IP standard FEC; only packets that does
not include any MNA will be sent on the "no MNA present" FEC.
</t>
</list>
</t>
</list>
</t>
</list>
</t>

<t>
<list style="symbols">
<t>
E receives the packet; E is MNA capable LSR; E will search the packet for
MNA and will find and process the MNA; E will then pop [101] and 
sends the packet to F
<list style="symbols">
<t>
stack = [VPN, bSPL, HEH, EH, IP]
<list style="symbols">
<t>
Note: E is penultimate hop so pops the LDP label and send the packet on normal
IP standard FEC; only packets that does not include any MNA will be sent on the
"no MNA present" FEC.
</t>
</list>
</t>
</list>
</t>
</list>
</t>

<t>
<list style="symbols">
<t>
F receives and scans the packet for MNA; it finds an MNA and processes it. 
As F is the ultimate hop it pops the bSPL and removes HEH and EH, 
processes the VPN label and forwards the packet.
</t>
</list>
</t>

</section>

<section anchor="vpn-no-mna" title="VPN without MNA in the packet">
<t>
<list style="symbols">
<t>
A sends packet to b
<list style="symbols">
<t>
stack = [104, VPN, IP]
</t>
</list>
</t>
</list>
</t>

<t>
<list style="symbols">
<t>
b receives the packet; b is a legacy router and just swaps [104] to [103] and 
sends the packet to c
<list style="symbols">
<t>
stack = [103, VPN, IP]
</t>
</list>
</t>
</list>
</t>

<t>
<list style="symbols">
<t>
c receives the packet; c is a legacy router and just swaps [103] to [102] and 
sends the packet to D
<list style="symbols">
<t>
stack = [102, VPN, IP]
</t>
</list>
</t>
</list>
</t>

<t>
<list style="symbols">
<t>
D receives the packet; D is MNA capable LSR; D will search the packet for
MNA; D will not find any MNA; D will then swap [102] to [201] and 
sends the packet to E on the "no MNA present" FEC.

<list style="symbols">
<t>
stack = [101, VPN, IP]
<list style="symbols">
<t>
Note: This packet will be sent on the "no MNA pesent" FEC; 
</t>
</list>
</t>
</list>
</t>
</list>
</t>

<t>
<list style="symbols">
<t>
E receives the packet [201] and bypasses MNA processing (received
on the "no MNA present" FEC; E is the penultimate node so it pops MNA-
FEC label; and send the packet to F on the "no MNA present" FEC.
<list style="symbols">
<t>
stack = [VPN, IP]
<list style="symbols">
<t>
Note: E is penultimate hop so E pops the "no MNA present" label and send the
packet to F.
</t>
</list>
</t>
</list>
</t>
</list>
</t>

<t>
<list style="symbols">
<t>
F receives and scans the packet for MNA; finds no MNA and bypasses MNA processing. 
As F is the ultimate hop it processes the VPN label and forwards the packet.
</t>
</list>
</t>

</section>


</section>

<section anchor="tunnel" title="RSVP-TE Tunnel case">
<t>
The RSVP-TE  tunnel is not MNA capable or the capability has been disabled.
</t>

<t>
Assume a physical topology that includes both MNA capable LSRs and non-MNA 
capable LSRs, as in the earlier examples. This topology also includes a low cost RSVP-TE tunnel between 
b and D.
</t>

              
      <figure title = "MNA topology III" align="left" anchor="te-topo-example">
                    <artwork align="left">
                        <![CDATA[
   +---+      +---+      +---+      +---+      +---+      +---+
   |   |      |   |      |   |      |   |      |   |      |   |
   | A +------+ b +------+ c +------+ D +------+ E +------+ F +
   |   |      |   |      |   |      |   |      |   |      |   |
   +---+      +---+      +---+      +---+      +---+      +---+
               | |                   | |
               | |___________________| |
               |_______________________|
   

Legend:
A, D, E, and F are MNA capable LSRs

b and c are non-MNA capable LSRs.

Nodes that transport the RSVP-TE tunnel are not MNA capable, or the MNA
capability is disabled.

                    ]]>
                    </artwork>
     </figure>
     
<t>
For this example the following assumptions are made:

<list style="symbols">

<t>
An RSVP-TE tunnel has been established between b and D (packets will bypass c)
</t>
<t>
F is reachable at b through RSVP-TE tunnel
</t>
<t>
LDP is enabled on the RSVP-TE tunnel
</t>
</list>

</t>
<t>
For prefix [F]: The following label mappings are sent by the LSRs in the network.
</t>

<t>
<list style="symbols">
<t>
F advertises labels F: [ldp: implicit-null, MNA-FEC: implicit-null] to E 
</t>

<t>
E advertises labels F: [ldp: 101, MNA-FEC: 201] to D
</t>

<t>
D advertises label  F: [ldp: 102] to c and F:[ldp: 102] to b
</t>

<t>
c advertises label  F: [ldp: 103] to b
</t>

<t>
b advertises label  F: [ldp: 104] to A
</t>
</list>
</t>

<t>
This will result in label mappings like this.
</t>

              
      <figure title = "MNA topology IV" align="left" anchor="te-mapping-example">
                    <artwork align="left">
                        <![CDATA[
   +---+       +---+       +---+       +---+       +---+       +---+
   |   |--104..|   |..103..|   |..102..|   |..101..|   |..php..|   |
   | A +-------+ b +-------+ c +-------+ D +-- ----+ E +-------+ F +
   |   |       |   |       |   |       |   |..201..|   |..php..|   |
   +---+  -    +---+       +---+       +---+       +---+       +---+
                | |                     | |
                | +---------------------+ |
                |      [RSVP, 102]        |
                +-------------------------+
   

Legend:
A, D, E, and F are MNA capable LSRs

b and c are non-MNA capable LSRs.

Nodes that transport the RSVP-TE tunnel are not MNA capable, or the MNA
capability is disabled. [RSVP] represents the series of tunnel top
labels.

                    ]]>
                    </artwork>
     </figure>

<t>
To describe the label stack operations in this case the VPN label stack is 
used, starting with the case where an MNA is present in the packet.
</t>

<section anchor="rsvp-eh" title="RSVP Tunnel and MNA present in the packet">
<t>

<list style="symbols">
<t>
A sends packet to b
<list style="symbols">
<t>
stack = [104, VPN, bSPL, HEH, EH, IP]
</t>
</list>
</t>
</list>
</t>

<t>
<list style="symbols">
<t>
b receives the packet, since b is a legacy router it swaps [104] to [102],
the next-hop reachable through the RSVP-TE tunnel; push the ingress RSVP-TE 
tunnel label and send it via the tunnel to the tunnel endpoint D
<list style="symmbols">
<t>
stack = [RSVP, 102, VPN, bSPL, HEH, EH, IP]
</t>
</list>
</t>
</list>
</t>

<t>
<list style="symbols">
<t>
Intermediate tunnel LSRs will forward (swap) based on the RSVP-TE label.
</t>
</list>
</t>

<t>
<list style="symbols">
<t>
D receives the packet, D will pop the last RSVP-TE label; since D is an MNA 
capable router it will search the stack and find the MNA, after processing the 
MNA it will swap [102] to [101], and send the packet to E over the normal FEC
<list style="symmbols">
<t>
stack = [101, VPN, bSPL, HEH, EH, IP]
<list style="symmbols">
<t>
Note: this will be forwarded on the standard FEC because since the MNA
is present in the packet, only packet without any MNA is forwarded on the
"no MNA present" FEC.
</t>
</list>
</t>
</list>
</t>
</list>
</t>

<t>
<list style="symbols">
<t>
E receives the packet [101]; since E is an MNA 
capable router it will search the stack and find the MNA; after processing the 
MNA it will pop [101], and send the packet to E over the normal FEC
<list style="symmbols">
<t>
stack = [VPN, bSPL, HEH, EH, IP]
<list style="symmbols">
<t>
Note: As E is the penultimate hop it will pop the standard LDP label.
</t>
</list>

</t>
</list>
</t>
</list>
</t>

<t>
<list style="symbols">
<t>
F receives the packet with the VPN label on top [VPN]; E scans the packet for 
MNA; it finds the MNA and processes it. As F is the ultimate hop it pops bSPL, and removes 
HEH and EH, processes VPN label and forwards the packet.
</t>

</list>
</t>

</section>

<section anchor="rsvp-no-eh" title="RSVP Tunnel and no MNA present in the packet">
<t>

<list style="symbols">
<t>
A sends packet to b
<list style="symbols">
<t>
stack = [104, VPN, IP]
</t>
</list>
</t>
</list>
</t>

<t>

<list style="symbols">
<t>
b receives the packet [104]; be is legacy router and will not search for an MNA;
b swaps [104] to [102]; pushes [RSVP] sends packet to D over the RSVP-TE tunnel.
<list style="symbols">
<t>
stack = [RSVP, 102, VPN, IP]
</t>
</list>
</t>
</list>
</t>

<t>
<list style="symbols">
<t>
Intermediate tunnel LSRs will forward (swap) based on the RSVP-TE label.
</t>
</list>
</t>

<t>

<list style="symbols">
<t>
D receives pops the tunnel label [RSVP], D is MNA capable and scans the packet 
for MNA; D finds no MNA is present; pops RSVP-TE label, and then swaps LDP label 
[102 ]to [201] and sends the packet to E
<list style="symbols">
<t>
stack = [201, VPN, IP]
<list style="symbols">
<t>
Note: in this case D sends the packet using the "no MNA present" FEC, since
there is no MNA in the packet.
</t>

<t>
Note: If the downstream LSR is not MNA capable then D will sends the packet 
on the standard FEC.
</t>
</list>
</t>
</list>
</t>
</list>
</t>


<t>

<list style="symbols">
<t>
E receives [201] and bypasses MNA processing since the packet is received on
the "no MNA present" FEC; E is the pen-ultimate hop so it pops the MNA-FEC label and 
forward the packet to F
<list style="symbols">
<t>
stack = [VPN, IP]
</t>
</list>
</t>
</list>
</t>

<t>
<list style="symbols">
<t>
F receives the packet [VPN]; and scans the packet for MNA; it does not find any MNA, and it
processes VPN label and forwards the packet.
</t>
</list>
</t>

</section>

<section anchor="eh-tunnel" title="EH capable RSVP-TE tunnel">
<t>
The case where an RSVP-TE tunnel is both MNA capable and MNA enabled is for
further study.
</t>
</section>


</section>

</section>

<section anchor="security" title="Security Considerations">
    
<t>
    TBA
</t>
      
</section>

     
<section anchor="IANA" title="IANA Considerations">
    
<t>
   There are no requests for IANA actions in this document.    
</t>
    
<t>
  Note to the RFC Editor - this section can be removed before publication.
</t>
    
</section>    

<section anchor="Acknowledgments" title="Acknowledgments">
<t>
   TBA
</t>
   
<t>
   -
</t>
</section>
    
</middle>

<back>
 
    <references title="Normative References">

      <?rfc include="reference.RFC.2119"?>
 <!--     <?rfc include="reference.RFC.2385"?>
      <?rfc include="reference.RFC.5036"?>  -->  
      <?rfc include="reference.RFC.5586"?>
<!--      <?rfc include="reference.RFC.5036"?> -->
      <?rfc include="reference.I-D.song-mpls-extension-header"?>
      <?rfc include="reference.I-D.song-mpls-eh-indicator"?>
      <?rfc include="reference.I-D.andersson-mpls-eh-architecture"?>
	  <?rfc include="reference.I-D.ietf-mpls-mna-requirements"?>
	  <?rfc include="reference.I-D.ietf-mpls-mna-fwk"?>
	  <?rfc include="reference.I-D.ietf-mpls-mna-usecases"?>
    </references>

    <references title="Informative References"> 
    
     <?rfc include="reference.RFC.7274"?> 
 <!--
      <?rfc include="reference.RFC.6518"?> 
      <?rfc include="reference.RFC.6952"?>
      <?rfc include="reference.RFC.7349"?> 
      <?rfc include="reference.RFC.7454"?>        -->
      <?rfc include="reference.RFC.8174"?> 
    </references>

  </back>
</rfc>
