<?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 SYSTEM "rfc2629.dtd">
<?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 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-li-mpls-gip6-mpls-00" ipr="trust200902">
  <front>
    <title abbrev="GIP6 for MPLS">Genralized IPv6 Tunnel for MPLS</title>

    <author fullname="Zhenbin Li" initials="L." surname="Li">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>156 Beiqing Road</street>

          <city>Beijing, 100095</city>

          <country>P.R. China</country>
        </postal>

        <email>lizhenbin@huawei.com</email>
      </address>
    </author>

    <author fullname="Jie Dong" initials="J." surname="Dong">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>156 Beiqing Road</street>

          <city>Beijing,100095</city>

          <country>P.R. China</country>
        </postal>

        <email>jie.dong@huawei.com</email>
      </address>
    </author>

    <author fullname="Shuanglong Chen" initials="S." surname="Chen">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>156 Beiqing Road</street>

          <city>Beijing,100095</city>

          <country>P.R. China</country>
        </postal>

        <email>chenshuanglong@huawei.com</email>
      </address>
    </author>

    <date day="11" month="July" year="2022"/>

    <!---->

    <abstract>
      <t>With the development of new services, MPLS faces many problems and
      technical challenges. This document defines the method to implement MPLS
      through the GIP6 tunnel.</t>

      <t/>
    </abstract>

    <note title="Requirements Language">
      <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"/>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>The GIP6 tunnel is defined in [draft-li-rtgwg-generic-ipv6-tunnel-00]
      which is to solve the challenges of the existing IP tunnels to support
      new features such as alternate marking, IOAM, network resource partition
      and APN.</t>

      <t>With the development of new services, MPLS also faces many problems
      and technical challenges. For example, it is difficult to encapsulate
      new forwarding attributes because of lack of the metadata extensibility.
      This document defines how to implement MPLS through the GIP6 tunnel
      which is to solve the possible problems effectively.</t>

      <t/>
    </section>

    <section title="Terminology">
      <t>APN: Application-Aware Networking</t>

      <t>GIP6: Generic Ipv6 Tunnel</t>

      <t>GRE: Generic Routing Encapsulation</t>

      <t>IFIT: In-situ Flow Information Telemetry</t>

      <t>MP2P: Multi Point To Point</t>

      <t>MPLS: Multiprotocol Label Switching</t>

      <t>PM: Performance Monitor</t>

      <t>SFL: Synonymos Flow Labels</t>

      <t>SR-MPLS: Segment Routing Multiprotocol Label Switching</t>

      <t>VXLAN: Virtual eXtensible Local Area Network</t>

      <t/>
    </section>

    <section title="Problem Statement">
      <t>With the development of new services, MPLS faces the following the
      technical problems and challenges of MPLS:</t>

      <t>1. MPLS is lack of the source indication and MP2P connections may
      occur. This causes the difficulty and complex process for OAM over MPLS.
      Although SFL<xref target="RFC8957">(</xref>) is defined, there is few
      implementation.</t>

      <t>2. The payload type (for example, L2 or L3 packets) cannot be
      directly determined because there is no payload indication.</t>

      <t>3. There is no metadata extensibility and it is difficult to
      encapsulate new forwarding attributes for the new features such as IETF
      network slicing, IFIT, and APN.</t>

      <t>4. The process of the ECMP function is complex and affects forwarding
      performance. Entropy labels or flow labels are placed at the bottom of
      the label stack for processing and the internal IP header information
      may have to be parsed for the purpose of ECMP.</t>

      <t/>
    </section>

    <section title="GIP6 Tunnel for MPLS">
      <t><xref target="I-D.li-rtgwg-generalized-ipv6-tunnel"/> defines the
      GIP6 tunnel to support both new features and the existing functions for
      the IP tunnels based on the extension of the IPv6 extension header. If
      the GIP6 tunnel is used for MPLS, there can be the following
      advantages:</t>

      <t>1. The IPv6 source address is used to form a source identifier.</t>

      <t>2. The IPv6 NH can indicate the payload type.</t>

      <t>3. IPv6 flow labels are used to implement ECMP.</t>

      <t>4. The encapsulations for the new features have been defined well in
      the IPv6 and can be reused easily.</t>

      <t>It is simple and can benefit forwarding performance. Moreover, there
      have been many implementations and deployments.</t>

      <t/>

      <t>In order to support MPLS based on the GIP6 tunnel, the method to
      carry MPLS label stack information is defined as follows:</t>

      <t>1. A special IPv6 prefix MUST be used to indicate that it is followed
      by MPLS label encapsulation. The special IPv6 prefix can be specified or
      a well-known IPv6 prefix to be assigned.</t>

      <t>2. The IPv6 special prefix can be followed by multiple MPLS label
      encapsulations to form a 128-bit IPv6 MPLS SID (Type 1). The format of
      the IPv6 MPLS SID (Type 1) is shown in the following figure.<figure>
          <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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Special Prefix(4 octets)                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               MPLS Label Encap (4 octets)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               MPLS Label Encap (4 octets)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               MPLS Label Encap (4 octets)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Figure 1. IPv6 MPLS SID (TYPE 1)          ]]></artwork>
        </figure></t>

      <t>Special prefix: TBD</t>

      <t>MPLS Label Encap: For details, please refer to section 2.1 in <xref
      target="RFC3032"/>.</t>

      <t>3. IPv6 MPLS SID (Type 1) can be placed in the IPv6 destination
      address.</t>

      <t>Processing of the first label following the special prefix is as
      follows:</t>

      <t>(1) If the local action of the MPLS label is POP, the followed label
      encapsulations are shifted left by 32 bits after the label is popped.
      The following figure shows the process.</t>

      <t/>

      <t><figure>
          <artwork><![CDATA[Before POP MPLS Label Encap:   

     uSID-Block     Active-Label      Next-Label       Last-Label
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Special Prefix | Lable-1 Encap | Label-2 Encap| Label-3 Encap(EOL)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

After POP MPLS Label Encap:

     uSID-Block     Active-Label      Next-Label       Last-Label
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Special Prefix | Lable-2 Encap | Label-3 Encap(EOL) | 0000...0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          Figure 2. Pop MPLS Label Encapsulation in IPv6 DA]]></artwork>
        </figure></t>

      <t/>

      <t>(2) If the local action of the MPLS label is SWAP, the label
      encapsulation is changed to the new label after swap.</t>

      <t/>

      <t>4. If all the MPLS label stack cannot be placed in the IPv6
      destination address, IPv6 RH can be used to house the remaining MPLS
      label stack.</t>

      <t>(1) IPv6 MPLS SID (Type 2) is defined to house multiple (&lt;= 4)
      label encapsulations. The format of the IPv6 MPLS SID (Type 2) is shown
      in the following figure.</t>

      <t><figure>
          <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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               MPLS Label Encap (4 octets)                   |  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               MPLS Label Encap (4 octets)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               MPLS Label Encap (4 octets)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               MPLS Label Encap (4 octets)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure>MPLS Label Encap: For details, see section 2.1 in <xref
      target="RFC3032"/>.</t>

      <t>(2) IPv6 MPLS SID (Type 2) is used as the segment in the RH. After
      all of the label encapsulations in the IPv6 destination address are
      popped, the first label encapsulation in the segment indicated by the SL
      of the RH will be processed as follows:</t>

      <t>-- If the local action of the MPLS label is POP, the followed label
      encapsulations are shifted left by 32 bits after the label is
      popped.</t>

      <t>-- If the local action of the MPLS label is SWAP, the label
      encapsulation is changed to the new label after swap.</t>

      <t>After all the label encapsulations in the segment are popped, SL
      minus 1. Then the first label encapsulation in the segment indicted by
      the new SL will go on to be processed as the above procedures.</t>

      <t>A new type of RH can be defined to contain IPv6 MPLS SID (Type 2) or
      SRv6 SRH can be reused for the purpose.</t>

      <t>5. When find the S flag of the label encapsulation in the IPv6
      destination address or the RH to be processed is set, this means the
      bottom of the label stack is reached and the process of the label stack
      in the GIP6 will end after the label is popped.</t>

      <t>If an intermediate node requires to push a label or a label stack,
      there can be two modes: Encap mode and Inserting mode.</t>

      <t>1) Encap mode: with this mode, a new IPv6 MPLS packet header is
      encapsulated outside the original MPLS packet, and the MPLS label
      (stack) is encapsulated in the new IPv6 MPLS packet header as the above
      procedures.</t>

      <t>2) Inserting mode: All the label encapsulations in the IPv6
      destination address and the IPv6 RH (if exist) need to be shifted right
      and the new label (stack) can be placed immediately following the
      special prefix in the IPv6 destination address. The process is complex
      and not recommended.</t>

      <t/>
    </section>

    <section title="Control Plane Considerations">
      <t>GIP6 only provides a way to carry MPLS label encapsulations in the
      data plane. The existing MPLS control plane does not need to be changed.
      That is, MPLS labels on the control plane can still be distributed for
      IPv4, IPv6, L2, etc.</t>

      <t/>
    </section>

    <section title="Security Considerations">
      <t>TBD.</t>

      <t/>
    </section>

    <section title="IANA Considerations">
      <t>TBD.</t>
    </section>
  </middle>

  <back>
    <references title="References">
      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.3032'?>

      <?rfc include='reference.RFC.8957'?>

      <?rfc include='reference.I-D.li-rtgwg-generalized-ipv6-tunnel'?>
    </references>
  </back>
</rfc>
