< draft-ietf-rtgwg-net2cloud-problem-statement-00.txt   draft-ietf-rtgwg-net2cloud-problem-statement-01.txt >
Network Working Group L. Dunbar Network Working Group L. Dunbar
Internet Draft A. Malis Internet Draft A. Malis
Intended status: Informational Huawei Intended status: Informational Futurewei
Expires: July 2019 C. Jacquenet Expires: Dec 2019 C. Jacquenet
Orange Orange
M. Toy M. Toy
Verizon Verizon
February 12, 2019 June 5, 2019
Seamless Interconnect Underlay to Cloud Overlay Problem Statement Seamless Interconnect Underlay to Cloud Overlay Problem Statement
draft-ietf-rtgwg-net2cloud-problem-statement-00 draft-ietf-rtgwg-net2cloud-problem-statement-01
Abstract Abstract
This document describes the problems that enterprises face today This document describes the problems that enterprises face today
when connecting their branch offices to dynamic workloads in third when connecting their branch offices to dynamic workloads in third
party data centers (a.k.a. Cloud DCs). party data centers (a.k.a. Cloud DCs).
It examines some of the approaches interconnecting cloud DCs with It examines some of the approaches interconnecting cloud DCs with
enterprises' on-premises DCs & branch offices. This document also enterprises' on-premises DCs & branch offices. This document also
describes some of the (network) problems that many enterprises face describes some of the (network) problems that many enterprises face
skipping to change at page 2, line 13 skipping to change at page 2, line 13
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 6, 2019. This Internet-Draft will expire on December 5, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
1.1. On the evolution of Cloud DC connectivity.................3
1.2. The role of SD-WAN techniques in Cloud DC connectivity....4
2. Definition of terms............................................4 2. Definition of terms............................................4
3. Current Practices in Interconnecting Enterprise Sites with Cloud 3. Current Practices in Interconnecting Enterprise Sites with Cloud
DCs...............................................................5 DCs...............................................................5
3.1. Interconnect to Cloud DCs.................................5 3.1. Interconnect to Cloud DCs.................................5
3.2. Interconnect to Hybrid Cloud DCs..........................7 3.2. Interconnect to Hybrid Cloud DCs..........................8
3.3. Connecting workloads among hybrid Cloud DCs...............7 3.3. Connecting workloads among hybrid Cloud DCs...............8
4. Desired Properties for Networks that interconnect Hybrid Clouds8 4. Desired Properties for Networks that interconnect Hybrid Clouds9
5. Problems with MPLS-based VPNs extending to Hybrid Cloud DCs....9 5. Problems with MPLS-based VPNs extending to Hybrid Cloud DCs...10
6. Problem with using IPsec tunnels to Cloud DCs.................10 6. Problem with using IPsec tunnels to Cloud DCs.................11
6.1. Complexity of multi-point any-to-any interconnection.....10 6.1. Complexity of multi-point any-to-any interconnection.....12
6.2. Poor performance over long distance......................11 6.2. Poor performance over long distance......................12
6.3. Scaling Issues with IPsec Tunnels........................11 6.3. Scaling Issues with IPsec Tunnels........................13
7. Problems of Using SD-WAN to connect to Cloud DCs..............12
7.1. SD-WAN among branch offices vs. interconnect to Cloud DCs12
8. End-to-End Security Concerns for Data Flows...................15 7. Problems of Using SD-WAN to connect to Cloud DCs..............13
9. Requirements for Dynamic Cloud Data Center VPNs...............15 7.1. SD-WAN among branch offices vs. interconnect to Cloud DCs13
10. Security Considerations......................................16 8. End-to-End Security Concerns for Data Flows...................16
9. Requirements for Dynamic Cloud Data Center VPNs...............16
10. Security Considerations......................................17
Solution drafts resulting from this work will address security Solution drafts resulting from this work will address security
concerns inherent to the solution(s), including both protocol concerns inherent to the solution(s), including both protocol
aspects and the importance (for example) of securing workloads in aspects and the importance (for example) of securing workloads in
cloud DCs and the use of secure interconnection mechanisms.......16 cloud DCs and the use of secure interconnection mechanisms.......17
IANA Considerations..............................................16 11. IANA Considerations..........................................17
11. References...................................................16 12. References...................................................17
11.1. Normative References....................................16 12.1. Normative References....................................17
11.2. Informative References..................................16 12.2. Informative References..................................17
12. Acknowledgments..............................................17 13. Acknowledgments..............................................18
1. Introduction 1. Introduction
1.1. On the evolution of Cloud DC connectivity
The ever-increasing use of cloud applications for communication The ever-increasing use of cloud applications for communication
services change the way corporate business works and shares services change the way corporate business works and shares
information. Such cloud applications use resources hosted in third information. Such cloud applications use resources hosted in third
party DCs that also host services for other customers. party DCs that also host services for other customers.
With the advent of widely available third party cloud DCs in diverse With the advent of widely available third party cloud DCs in diverse
geographic locations and the advancement of tools for monitoring and geographic locations and the advancement of tools for monitoring and
predicting application behaviors, it is technically feasible for predicting application behaviors, it is technically feasible for
enterprises to instantiate applications and workloads in locations enterprises to instantiate applications and workloads in locations
that are geographically closest to their end-users. Such proximity that are geographically closest to their end-users. Such proximity
skipping to change at page 4, line 12 skipping to change at page 4, line 14
resources (without any assistance from the VPN service provider), or resources (without any assistance from the VPN service provider), or
wait for their VPN service provider to make new agreements with data wait for their VPN service provider to make new agreements with data
center providers to connect to the cloud resources. Either way has center providers to connect to the cloud resources. Either way has
additional infrastructure and operational costs. additional infrastructure and operational costs.
In addition, it is an uptrend with more enterprises instantiating In addition, it is an uptrend with more enterprises instantiating
their apps & workloads in different cloud DCs to maximize the their apps & workloads in different cloud DCs to maximize the
benefits of geographical proximity, elasticity and special features benefits of geographical proximity, elasticity and special features
offered by different cloud DCs. offered by different cloud DCs.
1.2. The role of SD-WAN techniques in Cloud DC connectivity
This document discusses issues raised by the connection of
enterprise premises to third party data centers (a.k.a. Cloud DCs)
for reaching dynamic workloads.
SD-WAN, initially launched to maximize bandwidths between locations
by aggregating multiple paths managed by different service
providers, has expanded to include flexible, on-demand, application-
based connections established over any networks to access dynamic
workloads in Cloud DCs.
As a consequence, this document discusses the use of SD-WAN
techniques as a means to improve enterprise-to-cloud DC
connectivity.
2. Definition of terms 2. Definition of terms
Cloud DC: Third party Data Centers that usually host applications Cloud DC: Third party Data Centers that usually host applications
and workload owned by different organizations or and workload owned by different organizations or
tenants. tenants.
Controller: Used interchangeably with SD-WAN controller to manage Controller: Used interchangeably with SD-WAN controller to manage
SD-WAN overlay path creation/deletion and monitoring the SD-WAN overlay path creation/deletion and monitoring the
path conditions between two or more sites. path conditions between two or more sites.
skipping to change at page 4, line 43 skipping to change at page 5, line 22
services provided by multiple cloud operators. For services provided by multiple cloud operators. For
example, an enterprise not only have applications example, an enterprise not only have applications
running in their own DCs, but also have applications running in their own DCs, but also have applications
hosted in multiple third party cloud DCs ((AWS, Azure, hosted in multiple third party cloud DCs ((AWS, Azure,
Google, Salesforces, SAP, etc). . ONUG also has a Google, Salesforces, SAP, etc). . ONUG also has a
notion of heterogeneous cloud, refers to enterprises notion of heterogeneous cloud, refers to enterprises
does not have its own DC, only uses services by 3rd does not have its own DC, only uses services by 3rd
party cloud operators. party cloud operators.
SD-WAN: Software Defined Wide Area Network. In this document, SD-WAN: Software Defined Wide Area Network. In this document,
"SD-WAN" refers to the solutions specified by ONUG (Open "SD-WAN" refers to the solutions of pooling WAN
Network User Group), https://www.onug.net/software- bandwidth from multiple underlay networks to get better
defined-wide-area-network-sd-wan/, which is about WAN bandwidth management, visibility & control. When the
pooling WAN bandwidth from multiple underlay networks to underlay networks are private networks, traffic can
get better WAN bandwidth management, visibility & traverse without additional encryption; when the
control. When the underlay networks are private underlay networks are public, such as Internet, some
networks, traffic can traverse without additional traffic needs to be encrypted when traversing through
encryption; when the underlay networks are public, such (depending on user provided policies).
as Internet, some traffic needs to be encrypted when
traversing through (depending on user provided
policies).
VPC: Virtual Private Cloud. A service offered by Cloud DC VPC: Virtual Private Cloud. A service offered by Cloud DC
operators to allocate logically-isolated cloud operators to allocate logically-isolated cloud
resources, including compute, networking and storage. resources, including compute, networking and storage.
3. Current Practices in Interconnecting Enterprise Sites with Cloud DCs 3. Current Practices in Interconnecting Enterprise Sites with Cloud DCs
3.1. Interconnect to Cloud DCs 3.1. Interconnect to Cloud DCs
Most Cloud operators offer some type of network gateway through Most Cloud operators offer some type of network gateway through
skipping to change at page 10, line 10 skipping to change at page 11, line 10
locations, where apps can be instantiated so that they can be locations, where apps can be instantiated so that they can be
as close to their end-users as possible. When the user base as close to their end-users as possible. When the user base
changes, the applications may be migrated to a new cloud DC changes, the applications may be migrated to a new cloud DC
location closest to the new user base. location closest to the new user base.
- Most of the cloud DCs do not expose their internal networks, so - Most of the cloud DCs do not expose their internal networks, so
the MPLS-based VPNs can only reach Cloud DC's Gateways, not to the MPLS-based VPNs can only reach Cloud DC's Gateways, not to
the workloads hosted inside. the workloads hosted inside.
- Many cloud DCs use an overlay to connect their gateways to the - Many cloud DCs use an overlay to connect their gateways to the
workloads located inside the DC. There has not been any workloads located inside the DC. There is currently no standard
standard to address the interworking between the Cloud Overlay that specifies the interworking between the Cloud Overlay and
and the enterprise' existing underlay networks. the enterprise' existing underlay networks. One of the
characteristics of overlay networks is that some of the WAN
rd ports of the edge nodes connect to 3 party networks. There is
therefore a need to propagate WAN port information to remote
rd authorized peers in 3 party network domains in addition to
route propagation. Such an exchange cannot happen before
communication between peers is properly secured.
Another roadblock is the lack of a standard way to express and Another roadblock is the lack of a standard way to express and
enforce consistent security policies for workloads that not only use enforce consistent security policies for workloads that not only use
virtual addresses, but in which are also very likely hosted in virtual addresses, but in which are also very likely hosted in
different locations within the Cloud DC [RFC8192]. The current VPN different locations within the Cloud DC [RFC8192]. The current VPN
path computation and bandwidth allocation schemes may not be path computation and bandwidth allocation schemes may not be
flexible enough to address the need for enterprises to rapidly flexible enough to address the need for enterprises to rapidly
connect to dynamically instantiated (or removed) workloads and connect to dynamically instantiated (or removed) workloads and
applications regardless of their location/nature (i.e., third party applications regardless of their location/nature (i.e., third party
cloud DCs). cloud DCs).
skipping to change at page 16, line 15 skipping to change at page 17, line 15
10. Security Considerations 10. Security Considerations
The draft discusses security requirements as a part of the problem The draft discusses security requirements as a part of the problem
space, particularly in sections 4, 5, and 8. space, particularly in sections 4, 5, and 8.
Solution drafts resulting from this work will address security Solution drafts resulting from this work will address security
concerns inherent to the solution(s), including both protocol concerns inherent to the solution(s), including both protocol
aspects and the importance (for example) of securing workloads in aspects and the importance (for example) of securing workloads in
cloud DCs and the use of secure interconnection mechanisms. cloud DCs and the use of secure interconnection mechanisms.
IANA Considerations 11. IANA Considerations
This document requires no IANA actions. RFC Editor: Please remove This document requires no IANA actions. RFC Editor: Please remove
this section before publication. this section before publication.
11. References 12. References
11.1. Normative References 12.1. Normative References
11.2. Informative References 12.2. Informative References
[RFC2735] B. Fox, et al "NHRP Support for Virtual Private [RFC2735] B. Fox, et al "NHRP Support for Virtual Private
networks". Dec. 1999. networks". Dec. 1999.
[RFC8192] S. Hares, et al "Interface to Network Security Functions [RFC8192] S. Hares, et al "Interface to Network Security Functions
(I2NSF) Problem Statement and Use Cases", July 2017 (I2NSF) Problem Statement and Use Cases", July 2017
[ITU-T-X1036] ITU-T Recommendation X.1036, "Framework for creation, [ITU-T-X1036] ITU-T Recommendation X.1036, "Framework for creation,
storage, distribution and enforcement of policies for storage, distribution and enforcement of policies for
network security", Nov 2007. network security", Nov 2007.
skipping to change at page 17, line 12 skipping to change at page 18, line 12
[RFC4364] E. Rosen and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] E. Rosen and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", Feb 2006 Networks (VPNs)", Feb 2006
[RFC4664] L. Andersson and E. Rosen, "Framework for Layer 2 Virtual [RFC4664] L. Andersson and E. Rosen, "Framework for Layer 2 Virtual
Private Networks (L2VPNs)", Sept 2006. Private Networks (L2VPNs)", Sept 2006.
[BGP-SDWAN] L. Dunbar, et al. "BGP Extension for SDWAN Overlay [BGP-SDWAN] L. Dunbar, et al. "BGP Extension for SDWAN Overlay
Networks", draft-dunbar-idr-bgp-sdwan-overlay-ext-03, Networks", draft-dunbar-idr-bgp-sdwan-overlay-ext-03,
work-in-progress, Nov 2018. work-in-progress, Nov 2018.
12. Acknowledgments 13. Acknowledgments
Many thanks to Ignas Bagdonas, Michael Huang, Liu Yuan Jiao, Many thanks to Ignas Bagdonas, Michael Huang, Liu Yuan Jiao,
Katherine Zhao, and Jim Guichard for the discussion and Katherine Zhao, and Jim Guichard for the discussion and
contributions. contributions.
Authors' Addresses Authors' Addresses
Linda Dunbar Linda Dunbar
Huawei Futurewei
Email: Linda.Dunbar@huawei.com Email: Linda.Dunbar@huawei.com
Andrew G. Malis Andrew G. Malis
Huawei Futurewei
Email: agmalis@gmail.com Email: agmalis@gmail.com
Christian Jacquenet Christian Jacquenet
Orange Orange
Rennes, 35000 Rennes, 35000
France France
Email: Christian.jacquenet@orange.com Email: Christian.jacquenet@orange.com
Mehmet Toy Mehmet Toy
Verizon Verizon
 End of changes. 19 change blocks. 
45 lines changed or deleted 68 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/