[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

NVO3 WG                                                            T. Ao
Internet-Draft                                           ZTE Corporation
Intended status: Standards Track                               G. Mirsky
Expires: August 31, 2018                                       ZTE Corp.
                                                                  Y. Fan
                                                           China Telecom
                                                       February 27, 2018


    Multi-encapsulation interconnection for Overlay Virtual Network
               draft-ao-nvo3-multi-encap-interconnect-00

Abstract

   For an virtualized overlay network, there are many encapsulations
   that may be used.  Different customer have their own preference.  So
   if some of these different encapsulation can be interconnected
   together, the virtualized overlay network would be more compatible
   and have loose strict on access.  This document is going to provide
   an architecture of different overlay encapsulation interconnection
   and an tranformer gateway for these end station connected to the
   virtual network.

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 August 31, 2018.

Copyright Notice

   Copyright (c) 2018 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



Ao, et al.               Expires August 31, 2018                [Page 1]


Internet-Draft     multiple encapsulation interconnect     February 2018


   publication of this document.  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 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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   3
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   3.  Multi-encapsulation NVO architecture  . . . . . . . . . . . .   3
     3.1.  Transformer NVE . . . . . . . . . . . . . . . . . . . . .   5
   4.  Control Plane . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  NVE to NVA  . . . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  NVA to NVE  . . . . . . . . . . . . . . . . . . . . . . .   7
     4.3.  NVA to NVA  . . . . . . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     7.2.  Informational References  . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   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.

   With the progress in NVO3 WG, some of the data plane encapsulations
   have been put forward, some are outstanding dataplane for 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 analysised
   in [I-D.ietf-nvo3-encap].  The fact is that each of them have its
   custmers, and furthermore, some of them have been provisioned in the
   network.  So that a problem arises: for a virtual network, all the
   hosts that connect to the same VN and want to communicate with each
   other are required to have the same data plane encapsulation.  This
   problem limite 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 kinds of accession as
   possible is more attractive for a virtualized overlay network.




Ao, et al.               Expires August 31, 2018                [Page 2]


Internet-Draft     multiple encapsulation interconnect     February 2018


   To improve the scalability and capacity of the virtualized overlay
   network, we propose a multi-encapsulation access allowed interconnect
   NVO3 architecture, and a gateway in the network to perform the
   transformation for different encapsulation in this document, by which
   these hosts with different encapsulations can be interconnected.
   Here we call the gateway as Transformer Gateway 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

   Multi-encapsulation NVO: an virtualized overlay network that allow
   multiple different encapsulations interconnection.

   t-GW: Tranformation Gateway.  A gateway that do the transformer for
   different encapsulation to make them can communicate with each other.

   tNVE: A NVE that complete the functionn of a tranformer gateway.

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.  Multi-encapsulation NVO architecture

   In the multi-encapsulation interconnection allowed NVO, different NVE
   may support different encapsulation data plane.  As we have know that
   any two of the TS in the same VN should communicate with each other,
   but it is required that both of overaly encapsulation they are using
   to access to the virtual network have to be same.  In order to
   relieve the limitation and to support these encapsulation would



Ao, et al.               Expires August 31, 2018                [Page 3]


Internet-Draft     multiple encapsulation interconnect     February 2018


   interconnect together, a multi-encapsulation architecture is
   introdueced.  Figure 1 dipcts a reference architecture in VN.


                 +--------+
                 | Tenant +--+
                 | System4|  |
                 +--------+  |    ..................
                             |  +---+           +---------------+
                             +--|NVE|---+   +---|Transformer NVE|
                                +---+   |   |   |    (tNVE)     |
                                 /.     |   |   +---------------+
                                / .    +-----+      .
                               /  . +--| NVA |--+   .
                              /   . |  +-----+   \  .
                             |    . |             \ .
                             |    . |   Overlay   +--+--++--------+
                 +--------+  |    . |   Network   | NVE || Tenant |
                 | Tenant +--+    . |             |     || System5|
                 | System3|       .  \ +---+      +--+--++--------+
                 +--------+       .....|NVE|.........
                                       +---+
                                         |
                                         |
                               =====================
                                 |               |
                             +--------+      +--------+
                             | Tenant |      | Tenant |
                             | System1|      | System2|
                             +--------+      +--------+

                      Figure 1 Multi-encapsulation VN architecture

        Figure 1: Multi-encapsulation interconnection architecture

   In this figure, a Transformer Gateway component is introduced.
   Generally, the gateway is located on a NVE, so we call it as tNVE.
   For the TSs in the same virtual network, if the NVE they connecting
   have different encapsulation, want to communicate with each other,
   Transformer NVE(tNVE) will take over as a gateway to provide a
   "bridge" for the communication.  That is, when different NVEs want to
   set up tunnel, if they can't connect each other directly because of
   different encapsulation, they can set up a tunnel with tNVE
   seperately, so that the tNVE connects the two tunnels as a transfer.
   There could be more than one tNVE in a network.






Ao, et al.               Expires August 31, 2018                [Page 4]


Internet-Draft     multiple encapsulation interconnect     February 2018


3.1.  Transformer NVE

   Transformer NVE(tNVE) is a certain kind of NVE that maybe appointed
   by NVA or by manager.  As a very important component in the multi-
   encapsulation NVO, one requirement for NVE being a Transfomer NVE is
   that the NVE should support at least two kinds of encapsulations.

   With reference to the [RFC8014], the Transformer NVE has a reference
   model as showed in Figure 2.

         |                                                           |
         |                  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 tNVE Reference Model

                      Figure 2: tNVE reference model

   tNVE is a key component for 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 transform
   different encapsulation for different TSs, it will not forward the
   traffic to TS, but to another VAP that support the encapsulation the
   destination NVE owned.

   Take the Figure 2 as an example to illustrate how does tNVE work.
   NVE1 only support VxLAN-GPE, and NVE2 only support GENEVE.  For the
   two communiting TSs: TS1 wants to send packets to TS3, and TS3 also



Ao, et al.               Expires August 31, 2018                [Page 5]


Internet-Draft     multiple encapsulation interconnect     February 2018


   wants to reply to TS1.  They are in the same VNID1, but the NVE they
   are connecting using different encapsulation.  So if the two TS
   communicate with each other, packets have to transfer at tNVE.  For
   NVE1, it has no sense that TS3 is connecting to NVE3, instead
   assuming that TS3 is connecting to tNVE.  In the same way, for NVE3,
   it has no sense that TS1 is connecting to NVE1, instead of assuming
   that TS1 is connecting to tNVE.  So because of the existence of the
   tNVE, no matter TS1/TS3 or NVE1/NVE3, they never perceive that they
   are in different data plane.  NVE1 getting the packets from TS1
   encapsulates them in Vxlan-GPE and then send the packets to tNVE.
   The tNVE gets the packets from the Vxlan-GPE tunnel and then de-
   encapsulate the vxLAN-GPE to VAP1.  Next the tNVE forward packets to
   the Overlay Module from VAP2 to have another encapsulation GENEVE on
   the packets.  At last tNVE forward the packet in the GENEVE tunnel to
   NVE3.

   From the above, tNVE is like a tranformer between TS1 and TS2.  And
   owning to tNVE, even though NVE1 and NVE2 which TS1 and TS2
   connecting seperately have different encapsulation, as long as they
   are in the same virtual network, they would communicate each other
   and no need to have knowledge that they are in different data plane.

4.  Control Plane

   As stated in [RFC8014], an NVA is the entity that provides address
   mapping and other information to NVEs.  In addition, information
   flows between NVEs and NVAs in both directions.  The NVA maintains
   information about all VNs in the NV Domain so that NVEs do not need
   to do so themselves.  NVEs obtain information from the NVA about
   where a given remote TS destination resides.  NVAs, in turn, obtain
   information from NVEs about the individual TSs attached to those
   NVEs.

   Therefore, in order to make the tNVE works properly and to make sure
   that all the other network entities except tNVE don't detect the
   difference, NVA should detect the role of tNVE and take the
   coordination role among tNVE and other NVEs, maintain the information
   about the tNVEs and other NVEs, compute the tunnel connection, and
   notify tNVEs and NVEs about remote TS information.

4.1.  NVE to NVA

   NVE and tNVE should not only notify the NVA the address mapping
   between NVE and TSs, but also notify the NVA which encapsulation
   tunnel does this mapping use, so that NVA be able to decide which
   connection need tNVE participation.

   Information from tNVE to NVA:



Ao, et al.               Expires August 31, 2018                [Page 6]


Internet-Draft     multiple encapsulation interconnect     February 2018


   1.  Encapsulations the tNVE support.

   Information from NVE to NVA:

   1.  The address mapping between NVE and its attached TSs.

   2.  The encapsulation tunnel the address mapping will use.

   3.  The mandate metadata the address mapping must use.

4.2.  NVA to NVE

   NVA notify the NVE and tNVE the mapping information after computing
   and coordination.

   Information from NVA to NVE:

   1.  The address mapping information between remote NVE and TS.  The
   NVE here may not be the NVE that the TS is connecting.  It may be a
   tNVE.

   Information from NVA to tNVE:

   1.  The address mapping information between remote NVE and its
   connecting TS.

4.3.  NVA to NVA

   For NVA federate scenario.  To be added in the future updates.

5.  Security Considerations

   Will be added in the future updates.

6.  IANA Considerations

   TBD.

7.  References

7.1.  Normative References

   [I-D.ietf-intarea-gue]
              Herbert, T., Yong, L., and O. Zia, "Generic UDP
              Encapsulation", draft-ietf-intarea-gue-05 (work in
              progress), December 2017.





Ao, et al.               Expires August 31, 2018                [Page 7]


Internet-Draft     multiple encapsulation interconnect     February 2018


   [I-D.ietf-nvo3-geneve]
              Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic
              Network Virtualization Encapsulation", draft-ietf-
              nvo3-geneve-05 (work in progress), September 2017.

   [I-D.ietf-nvo3-vxlan-gpe]
              Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
              Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-05 (work
              in progress), October 2017.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [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, <https://www.rfc-editor.org/info/rfc7365>.

   [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,
              <https://www.rfc-editor.org/info/rfc8014>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

7.2.  Informational References

   [I-D.ietf-nvo3-encap]
              Boutros, S., Ganga, I., Garg, P., Manur, R., Mizrahi, T.,
              Mozes, D., Nordmark, E., Smith, M., Aldrin, S., and I.
              Bagdonas, "NVO3 Encapsulation Considerations", draft-ietf-
              nvo3-encap-01 (work in progress), October 2017.

   [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,
              <https://www.rfc-editor.org/info/rfc7364>.








Ao, et al.               Expires August 31, 2018                [Page 8]


Internet-Draft     multiple encapsulation interconnect     February 2018


Authors' Addresses

   Ting Ao
   ZTE Corporation
   No.889, BiBo Road
   Shanghai  201203
   China

   Phone: +86 21 68897642
   Email: ao.ting@zte.com.cn


   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 August 31, 2018                [Page 9]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/