Network Working Group L. Li Internet-Draft J. Dong Intended status: Standards Track S. Chen Expires: 12 January 2023 Huawei 11 July 2022 Genralized IPv6 Tunnel for MPLS draft-li-mpls-gip6-mpls-00 Abstract 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. Requirements Language 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 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 12 January 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Li, et al. Expires 12 January 2023 [Page 1] Internet-Draft GIP6 for MPLS July 2022 Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 4. GIP6 Tunnel for MPLS . . . . . . . . . . . . . . . . . . . . 3 5. Control Plane Considerations . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction 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. 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. 2. Terminology APN: Application-Aware Networking GIP6: Generic Ipv6 Tunnel GRE: Generic Routing Encapsulation IFIT: In-situ Flow Information Telemetry MP2P: Multi Point To Point MPLS: Multiprotocol Label Switching PM: Performance Monitor Li, et al. Expires 12 January 2023 [Page 2] Internet-Draft GIP6 for MPLS July 2022 SFL: Synonymos Flow Labels SR-MPLS: Segment Routing Multiprotocol Label Switching VXLAN: Virtual eXtensible Local Area Network 3. Problem Statement With the development of new services, MPLS faces the following the technical problems and challenges of MPLS: 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( [RFC8957]) is defined, there is few implementation. 2. The payload type (for example, L2 or L3 packets) cannot be directly determined because there is no payload indication. 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. 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. 4. GIP6 Tunnel for MPLS [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: 1. The IPv6 source address is used to form a source identifier. 2. The IPv6 NH can indicate the payload type. 3. IPv6 flow labels are used to implement ECMP. 4. The encapsulations for the new features have been defined well in the IPv6 and can be reused easily. It is simple and can benefit forwarding performance. Moreover, there have been many implementations and deployments. Li, et al. Expires 12 January 2023 [Page 3] Internet-Draft GIP6 for MPLS July 2022 In order to support MPLS based on the GIP6 tunnel, the method to carry MPLS label stack information is defined as follows: 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. 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. 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) Special prefix: TBD MPLS Label Encap: For details, please refer to section 2.1 in [RFC3032]. 3. IPv6 MPLS SID (Type 1) can be placed in the IPv6 destination address. Processing of the first label following the special prefix is as follows: (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. Li, et al. Expires 12 January 2023 [Page 4] Internet-Draft GIP6 for MPLS July 2022 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 (2) If the local action of the MPLS label is SWAP, the label encapsulation is changed to the new label after swap. 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. (1) IPv6 MPLS SID (Type 2) is defined to house multiple (<= 4) label encapsulations. The format of the IPv6 MPLS SID (Type 2) is shown in the following figure. 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MPLS Label Encap: For details, see section 2.1 in [RFC3032]. (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: Li, et al. Expires 12 January 2023 [Page 5] Internet-Draft GIP6 for MPLS July 2022 -- 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. -- If the local action of the MPLS label is SWAP, the label encapsulation is changed to the new label after swap. 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. A new type of RH can be defined to contain IPv6 MPLS SID (Type 2) or SRv6 SRH can be reused for the purpose. 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. If an intermediate node requires to push a label or a label stack, there can be two modes: Encap mode and Inserting mode. 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. 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. 5. Control Plane Considerations 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. 6. Security Considerations TBD. Li, et al. Expires 12 January 2023 [Page 6] Internet-Draft GIP6 for MPLS July 2022 7. IANA Considerations TBD. 8. References [I-D.li-rtgwg-generalized-ipv6-tunnel] Zhenbin, Shuanglong, and Haibo, "Generalized IPv6 Tunnel (GIP6)", Work in Progress, Internet-Draft, draft-li-rtgwg- generalized-ipv6-tunnel-00, 10 July 2022, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, . [RFC8957] Bryant, S., Chen, M., Swallow, G., Sivabalan, S., and G. Mirsky, "Synonymous Flow Label Framework", RFC 8957, DOI 10.17487/RFC8957, January 2021, . Authors' Addresses Zhenbin Li Huawei 156 Beiqing Road Beijing, 100095 P.R. China Email: lizhenbin@huawei.com Jie Dong Huawei 156 Beiqing Road Beijing,100095 P.R. China Email: jie.dong@huawei.com Li, et al. Expires 12 January 2023 [Page 7] Internet-Draft GIP6 for MPLS July 2022 Shuanglong Chen Huawei 156 Beiqing Road Beijing,100095 P.R. China Email: chenshuanglong@huawei.com Li, et al. Expires 12 January 2023 [Page 8]