NVO3 WG T. Ao Internet-Draft ZTE Corporation Intended status: Standards Track G. Mirsky Expires: December 7, 2019 ZTE Corp. Y. Fan China Telecom June 5, 2019 Architecture for Overlay Virtual Sub-Network Interconnection draft-ao-nvo3-overlay-subnet-architecture-02 Abstract An virtualized overlay network may be divided into several subnets for the reasons of geographical location, management, or using different technologies being used. For example, different customer have their own preference. But all these subnets need to work together to provide an end-to-end connectionif in a virtual network, An extended architecture of the NVO3 and propose a new component to provide the connection fucntion are introduced in this document. 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 December 7, 2019. Copyright Notice Copyright (c) 2019 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. Please review these documents Ao, et al. Expires December 7, 2019 [Page 1] Internet-Draft overlay interconnect June 2019 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . 3 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 3. Architecture for subnet . . . . . . . . . . . . . . . . . . . 4 3.1. Stitching NVE . . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Normative References . . . . . . . . . . . . . . . . . . 7 5.2. Informational References . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Background Network virtualization using Overlays over Layer 3 (NVO3) is a technology that is used to address issues that arise in building large, multi-tenant data centers that make extensive use of server virtualization. As described [I-D.defoy-coms-subnet-interconnection] and [I-D.homma-coms-slice-gateway], for network slicing in 5G, there are number of reasons to compose an end-to-end network slice instance by using subnets and stitching operations, thus enabling hierarchical/ recursive management of slices. These subnets are the part of the network slice instance, but not isolate from network slice. An overlay virtual network may also be constructed of several subnets. In such scenario, subnets interconnection to a virtual network is required. We also can consider such interconnection as stitiching. With such stitiching, several subnets can provide a end to end connection in an overlay virtual network. Moreover, with the progress in NVO3 WG, some of the data plane encapsulations have been put forward, some are outstanding dataplane for an overlay network, such as VxLAN-GPE [I-D.ietf-nvo3-vxlan-gpe], GENEVE [I-D.ietf-nvo3-geneve] and GUE [I-D.ietf-nvo3-encap], etc. The consideration about these overlay encapsulations has been analyzed in [I-D.ietf-nvo3-encap]. The fact is that each of them has its custmers, and furthermore, some of them have been already deployed in the network. So that a problem arises: for a virtual network, all the hosts that connect to the same VN and want to Ao, et al. Expires December 7, 2019 [Page 2] Internet-Draft overlay interconnect June 2019 communicate with each other are required to have the same data plane encapsulation. This problem limits the network scalability and capacity. Especially, when the NVE is located on the vSwitch, the encapsulation method on the NVE is not predictable. Allowing as many types of accession as possible is more attractive for a virtualized overlay network. So in such a scenario, the NVEs using same techonology can be connected to the same subnet. To improve the scalability and capacity of the virtualized overlay network and to satisfy the subnet interconnection requirement in network slicing, we propose a subnet interconnection architecture in NVO3, and provide a stitching gateway between the subnets in a virtual network in this document. With such architecture, the subnets in an overlay virtual network with different technologies and with seperate management can be interconnected. The gateway that provides the connection between subnets is referred to as Stitching Gateway. In particular, the Stitching Gateway generally would be located in a certain kind of NVE, such NVE is called as S-NVE in the following descrption. 2. Conventions used in this document 2.1. Terminology NVO3: Network Virtualization using Overlay over Layer 3 NVA: Network Virtualization Authority TS: Tenant System VxLAN-GPE: Virtual extension LAN with Generic Protocol Extension GENEVE: Generic Network Virtualization Encapsulation GUE: Generic UDP Encapsulation S-GW: Stitching Gateway. A gateway that does the stitching for seperate subnet to enable them to communicate with each other. S-NVE: A NVE that complete the stitching functionn as a Stitching Gateway for subnets in an overlay virtual network. Subnet: An Overlay Virtual Network is combined with several Subnets which may use different technology or different management. Network slice in this document is used as shortened version of network slice instance. Ao, et al. Expires December 7, 2019 [Page 3] Internet-Draft overlay interconnect June 2019 2.2. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Architecture for subnet As Generic Reference Model desribed in [RFC7364], it's a DC reference model for network virtualization overlays where NVEs provide a logical interconnect between Tenant Systems that belong to a specific VN. But if we need to support a overlay virtual network, an extended reference model is shown as follows in the NVO3 architecture. +--------+ +-------+ | Tenant +--+ + TS | | System4| | /+-------+ +--------+ | .................. / | +---+ +---------------+ +--|NVE|---+ +---| Stitching NVE | +---+ | | | (S-NVE) | /. | | +---------------+ / . +-----+ . / . +--| NVA |--+ . / . | +-----+ \ . | . | \ . | . | Overlay +--+--++--------+ +--------+ | . | Network | NVE || Tenant | | Tenant +--+ . | | || System5| | System3| . \ +---+ +--+--++--------+ +--------+ .....|NVE|......... +---+ | | ===================== | | +--------+ +--------+ | Tenant | | Tenant | | System1| | System2| +--------+ +--------+ Figure 1 Reference Model supporting subnet Figure 1: Reference Model supporting subnet Ao, et al. Expires December 7, 2019 [Page 4] Internet-Draft overlay interconnect June 2019 In the above figure, a specific Stitching Gateway(S-Gateway) component is introduced. Generally, the gateway is located on a NVE, so we call it as S-NVE. For the TSs in the same virtual network, if the NVEs which they are connected to are using defferent overlay technology, want to communicate with each other, Stitching NVE(S-NVE) should take over responsibilityas a gateway to provide a "bridge" for the communication. Or for the TSs connecting to different subnets, but belonging to a virtual network, need to communicate with each other through S-NVE. The difference between NVE and S-NVE is that NVE is the connection between different VN, while S-NVE is the connection between subnet. From the view of NVE, S-NVE is a intermidiate relay node. For the two Tenant Systems belong to different subnet have to communicate through a S-NVE, even though they belong to a same virtual network. That is, when different NVEs want to set up tunnel, if they can't connect each other directly because they are on the different subnets, they can set up a tunnel with S-NVE seperately, so that the S-NVE connects the two tunnels as a stitcher. There could be more than one S-NVE in a virtual network. 3.1. Stitching NVE Stitching NVE(S-NVE) is a certain kind of NVE that maybe appointed by NVA or by the manager. As an essential component in the NVO supporting subnet, the requirements for a Stitching NVE is : 1. Provide the connection for the two subnet of a virtual network. 2. Provides identification/ classification of customer and service traffic, performs the mapping of the two tunnels. 3. Support at least two kinds of encapsulations, translation between technologies/encapsulations when it is stitching two subnets with two different technology . 4. Fault and performance monitoring for underlay and overlay networks. Regarding the [RFC8014], the Stitching NVE has a reference model as showed in Figure 2. Ao, et al. Expires December 7, 2019 [Page 5] Internet-Draft overlay interconnect June 2019 | | | Data-Center Network (IP) | +-----------------------------------------------------------+ | | | | | Tunnel Overlay | | Tunnel Overlay | +---------+----+ +--+----------+----+ +-----+--------+ | +----------+ | | +--------------+ | | +----------+ | | | Overlay | | | | Overlay | | | | Overlay | | | | Module | | | | Module | | | | Module | | | +----+-----+ | | +---+----------+ | | +----------+ | | | | | | | | | | | | NVE1 | | | tNVE| | | | NVE3 | | | +---+----+ | | +---+-+ +--+--+ | | +--------+ | | | VNI1 | | | |VNI1 | |VNI1 | | | | VNI1 | | | +-+------+ | | +-+---+ +-----+ | | +-+------+ | | | VAP1 | | |VAP1 |VAP2| | | VAP1 | +----+---------+ | +---------+ | +----+---------+ | +------------------+ | |\ | -----+-\------------------------------------------------------+------- TSI1 |TSI2\ Tenant TSI1 | +---+ +---+ +---+ |TS1| |TS2| |TS3| +---+ +---+ +---+ Figure 2 S-NVE Reference Model Figure 2: S-NVE reference model S-NVE is a key component of the connection between NVE1 and NVE2. It can be a dedicated device and be a NVE that also provide the overlay network for the TSs. When the NVE takes the role of stitching different subnets for different TSs, it will not forward the traffic to TS, but to another VAP that supports the encapsulation the destination NVE owned. Take the Figure 2 as an example to illustrate how does S-NVE work. NVE1 belongs to subnet1 and only support VxLAN-GPE, and NVE2 belongs to subnet2 and only support GENEVE. For the two communicating TSs: TS1 needs to send packets to TS3, and TS3 also needs to reply to TS1. They are in the same VNID1, but the NVE they are connected to is using a different encapsulation, and the they belongs to two different subnet. So if the two TSes want to communicate with each other, packets have to transfer at S-NVE first. For NVE1, it has no sense that TS3 is connecting to NVE3, instead of assuming that TS3 is connecting to S-NVE. In the same way, for NVE3, it has no sense that TS1 is connecting to NVE1, instead of assuming that TS1 is connecting to S-NVE. So because of the existence of the tNVE, no matter TS1/TS3 or NVE1/NVE3, they never perceive that they are in the different data Ao, et al. Expires December 7, 2019 [Page 6] Internet-Draft overlay interconnect June 2019 plane. NVE1 getting the packets from TS1 encapsulates them in Vxlan- GPE and then send the packets to S-NVE. The S-NVE receives the packets from the Vxlan-GPE tunnel and then de-encapsulate the vxLAN- GPE to VAP1. Next, the S-NVE forwards packets to the Overlay Module from VAP2 to have another encapsulation GENEVE on the packets. At last S-NVE forwards the packet in the GENEVE tunnel to NVE3. From the above, S-NVE is like a stitcher between TS1 and TS2. And owning to S-NVE, even though NVE1 and NVE2 which TS1 and TS2 connecting belong to separate subnets and seperately have different encapsulation, as long as they are in the same virtual network, they would communicate each other as a Larger L2 network and no need to know that they are in different subnets or using different technology. 4. IANA Considerations TBD. 5. References 5.1. Normative References [I-D.ietf-intarea-gue] Herbert, T., Yong, L., and O. Zia, "Generic UDP Encapsulation", draft-ietf-intarea-gue-07 (work in progress), March 2019. [I-D.ietf-nvo3-geneve] Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic Network Virtualization Encapsulation", draft-ietf- nvo3-geneve-13 (work in progress), March 2019. [I-D.ietf-nvo3-vxlan-gpe] Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-07 (work in progress), April 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. Rekhter, "Framework for Data Center (DC) Network Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 2014, . Ao, et al. Expires December 7, 2019 [Page 7] Internet-Draft overlay interconnect June 2019 [RFC8014] Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. Narten, "An Architecture for Data-Center Network Virtualization over Layer 3 (NVO3)", RFC 8014, DOI 10.17487/RFC8014, December 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 5.2. Informational References [I-D.ao-nvo3-multi-encap-interconnect] Ao, T., Mirsky, G., and F. Yongbing, "Multi-encapsulation interconnection for Overlay Virtual Network", draft-ao- nvo3-multi-encap-interconnect-00 (work in progress), March 2018. [I-D.defoy-coms-subnet-interconnection] Foy, X., Rahman, A., Galis, A., kiran.makhijani@huawei.com, k., Qiang, L., Homma, S., and P. Martinez-Julia, "Interconnecting (or Stitching) Network Slice Subnets", draft-defoy-coms-subnet-interconnection-03 (work in progress), March 2018. [I-D.homma-coms-slice-gateway] Homma, S., Foy, X., and A. Galis, "Gateway Function for Network Slicing", draft-homma-coms-slice-gateway-01 (work in progress), March 2018. [I-D.ietf-nvo3-encap] Boutros, S., "NVO3 Encapsulation Considerations", draft- ietf-nvo3-encap-02 (work in progress), September 2018. [RFC7364] Narten, T., Ed., Gray, E., Ed., Black, D., Fang, L., Kreeger, L., and M. Napierala, "Problem Statement: Overlays for Network Virtualization", RFC 7364, DOI 10.17487/RFC7364, October 2014, . Authors' Addresses Ao, et al. Expires December 7, 2019 [Page 8] Internet-Draft overlay interconnect June 2019 Ting Ao ZTE Corporation No.889, BiBo Road Shanghai 201203 China Phone: +86 17721209283 Email: 18555817@qq.com Greg Mirsky ZTE Corp. 1900 McCarthy Blvd. #205 Milpitas, CA 95035 USA Email: gregimirsky@gmail.com Yongbin China Telecom No.109, Zhongshan Avenue Guangzhou 510630 China Email: fanyb@gsta.com Ao, et al. Expires December 7, 2019 [Page 9]