Should we merge the draft-ietf-rtgwg-net2cloud-problem-statement-03 with draft-ietf-rtgwg-net2cloud-gap-analysis

Linda Dunbar <linda.dunbar@futurewei.com> Fri, 25 October 2019 19:05 UTC

Return-Path: <linda.dunbar@futurewei.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA09812011C; Fri, 25 Oct 2019 12:05:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tk0YHjhEHJIg; Fri, 25 Oct 2019 12:05:12 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740115.outbound.protection.outlook.com [40.107.74.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B9B912003E; Fri, 25 Oct 2019 12:05:11 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fiAyrJA2ZnxODiT3wcqwd7cumFLmiDMHgJ1eLFshLgIbvqItkrDNjeoKTJqtzxf1NcPOJNGapKJaRYdr3v8eEQJFgIsDZXYcshvBgqxQDu+3Y640ozfxfM/OA/2fFPPdPfWHTZ05LGHkI9gaWjLBxgP9OP3RXxdb1O9yD64INAF52xuQcIatFvAqul8E8BTIejeEicBNW2+Ya/V7iT+SoM3LtjE/h7jxOqeiqZLRQaUyUw+LPCQyPeaW7/J1HLEmMUu+IRwBLx93A0QQIC2QiiEv5WW8MewsPidx0J3D9KwsQc0tegCLkWwNUux7QupvkdHZ7Wt5U49CoqSbbVzdRg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=l55V6il41Z23A7WUV03NVWl4VNH2BLfv/lts3nZfDVk=; b=HLiAwfaZii6Mucr4PYinbeDEl6TGeQzY9Iulenkx4H5mAoFrRZUNSPVjSlbEtd8+ttXqPupcBsajcfAGdcGqITiCbCFrZoAXGmGsMgbjCR0bIGzFTRQcyHg1OJ3svN7BmMcllxlpsLWKtTrXPC1hRYXDs1w+J2jixmile5MN8BAzWsnAfib+bcCcJROQFcH6SBtfgEc5KdN5T0mbsSaqZ/yPkyV9Vduba8n18jUsH6zo2c9aAjWwv2gLzQtSAnIVkXMe90W1qzSm7PP+KdZuUkVwIbKN4FkjESm0QG10cdUDc3KxSYtOn/ze6bdnKVNnXorz611pAaElQ/X/lpWw9A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=l55V6il41Z23A7WUV03NVWl4VNH2BLfv/lts3nZfDVk=; b=r+nWVrkJyeWMTVdfmBG7ss8B/UByGEVYfKOhhHv/C6HCL/bSjl4bdN6xRa7nKOofufwTjgnw1NowY40Zet5Wfk65N4cw7gv7kj2XWJy0jmA4QSle7Ya+DCCPXRswJCvCi76UlZ9b/sdUqD6dxjo5gDHMI/B2leLm0USMV09tpNU=
Received: from MN2PR13MB2637.namprd13.prod.outlook.com (20.178.250.82) by MN2PR13MB3807.namprd13.prod.outlook.com (10.186.147.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.10; Fri, 25 Oct 2019 19:05:06 +0000
Received: from MN2PR13MB2637.namprd13.prod.outlook.com ([fe80::85a2:fa45:1435:d5f7]) by MN2PR13MB2637.namprd13.prod.outlook.com ([fe80::85a2:fa45:1435:d5f7%7]) with mapi id 15.20.2387.023; Fri, 25 Oct 2019 19:05:06 +0000
From: Linda Dunbar <linda.dunbar@futurewei.com>
To: rtgwg-chairs <rtgwg-chairs@ietf.org>
CC: RTGWG <rtgwg@ietf.org>
Subject: Should we merge the draft-ietf-rtgwg-net2cloud-problem-statement-03 with draft-ietf-rtgwg-net2cloud-gap-analysis
Thread-Topic: Should we merge the draft-ietf-rtgwg-net2cloud-problem-statement-03 with draft-ietf-rtgwg-net2cloud-gap-analysis
Thread-Index: AdWLZBm6NGLv4dszSmKAu6kITE+rOg==
Date: Fri, 25 Oct 2019 19:05:06 +0000
Message-ID: <MN2PR13MB2637919CE387947332F16BC585650@MN2PR13MB2637.namprd13.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=linda.dunbar@futurewei.com;
x-originating-ip: [206.16.17.231]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e3c40efd-0585-4e59-7236-08d7597e3fb5
x-ms-traffictypediagnostic: MN2PR13MB3807:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <MN2PR13MB380769A96723BF1DE7A890F085650@MN2PR13MB3807.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02015246A9
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(136003)(376002)(346002)(366004)(39850400004)(51914003)(189003)(199004)(236005)(450100002)(5660300002)(486006)(102836004)(2906002)(316002)(30864003)(74316002)(8676002)(606006)(52536014)(66066001)(99936001)(71200400001)(186003)(71190400001)(81166006)(44832011)(26005)(33656002)(86362001)(7696005)(6506007)(53546011)(476003)(5024004)(14444005)(256004)(3846002)(8936002)(99286004)(6916009)(733005)(478600001)(76116006)(6436002)(861006)(4326008)(25786009)(66576008)(66946007)(14454004)(55016002)(54896002)(9686003)(7736002)(6306002)(6116002)(790700001)(966005)(66476007)(66556008)(64756008)(66446008)(45080400002)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR13MB3807; H:MN2PR13MB2637.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: futurewei.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: KzG4WiN0ENmSFR3/VbrDf/LJKvHwqs2EQkJqzAnzAAVdyAEnpf6iXVjHZSFcO3dLTV7A2plVGZUO6X0U/tvJlA+rCPjZAI07dX1jlrPUO4BndSheLzxCXqPsiWjZCpNPkdYSD3/EZpRa+dXMOrfIJSPihdzKdUEOuee+qXo8S1CX08KhWoh+pTb9e9eXWZcIp6UenwVHPpNrYOaMZNzi2NnT72sXvjVtaOUfSl3ZREpFHZRUQ3Q7SVU1rDiOBtXj4yxK9FMwNh52YFaQ47cV3Ya2DC2LQZPqoGcGk//45ldAAWVamWVt8NnZdK+VKcu+Fl2k5+JD1xhTU+q5qn2xF3WEjVoLymOLkZEaCaruUhqENaNRhUU+gQcGT7g+zxPMobxUdSRUQ2rWkQNZ/m48J/u6p+wgJRM0yOskEfbsed8bkJI2lvCBEjtRDOMp1/chZXdenQUZZz7g+hJfOixuEkZG5GvILE5cxdVd417c730=
x-ms-exchange-transport-forked: True
Content-Type: multipart/related; boundary="_010_MN2PR13MB2637919CE387947332F16BC585650MN2PR13MB2637namp_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e3c40efd-0585-4e59-7236-08d7597e3fb5
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2019 19:05:06.3263 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: /MmA7Ey8yJEMZ5je9oA6MGJ+0YU83whoBSnR51GoDwoj7PBPDhx+l729tjFhk4QeFfLYlsxrBj/8DRpL1XY91g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB3807
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/yXiD2K70956jhr9jjYbUaHg-Cck>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Oct 2019 19:05:16 -0000

Chris and Jeff,

I remember during IETF105  someone mentioned that it is better to merge the Problem Statement with the Gap Analysis because IESG doesn’t like to approve Gap Analysis draft. Is it a formal request? Do we have to do this merge in order to move the document to WGLC?

Thank you very much.

Linda

From: Linda Dunbar
Sent: Monday, October 21, 2019 4:05 PM
To: 'Alia Atlas' <akatlas@gmail.com<mailto:akatlas@gmail.com>>; 刘 鹏 <liupengyjy@outlook.com<mailto:liupengyjy@outlook.com>>
Cc: Robert Raszuk <rraszuk@gmail.com<mailto:rraszuk@gmail.com>>; Andrew G. Malis <agmalis@gmail.com<mailto:agmalis@gmail.com>>; draft-ietf-rtgwg-net2cloud-problem-statement@ietf.org<mailto:draft-ietf-rtgwg-net2cloud-problem-statement@ietf.org>; RTGWG <rtgwg@ietf.org<mailto:rtgwg@ietf.org>>
Subject: RE: RE: solicit feedback for adding Interconnection among different Cloud DCs to draft-ietf-rtgwg-net2cloud-problem-statement-03

Alia,

Thanks for the feedback.

Here are the updates from Last week’s ONUG on Cloud: Every ONUG have IT user communities voting for the use cases they care the most. The highest voted use case from ONUG Fall 2019 is Hybrid Multi-cloud deployments incorporating VPCs/VNETs hosted by multiple public cloud providers, access to many SaaS application & Integration with SD-WAN overlays.

I don’t mean that  “SDWAN as the unifying API for the network fabric”, instead, the network fabric would be combination of legacy VPNs (AWS’ DirectConnect, Azure’s Express Route) and over the top SDWAN.

[cid:image015.jpg@01D58B3D.31738D60]
[cid:image016.jpg@01D58B3D.31738D60]
[cid:image017.jpg@01D58B3D.31738D60]
[cid:image018.jpg@01D58B3D.31738D60]
[cid:image019.jpg@01D58B3D.31738D60]
[cid:image020.jpg@01D58B3D.31738D60]
[cid:image021.jpg@01D58B3D.31738D60]


Linda

From: Alia Atlas <akatlas@gmail.com<mailto:akatlas@gmail.com>>
Sent: Monday, October 14, 2019 4:57 PM
To: 刘 鹏 <liupengyjy@outlook.com<mailto:liupengyjy@outlook.com>>
Cc: Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>; Robert Raszuk <rraszuk@gmail.com<mailto:rraszuk@gmail.com>>; Andrew G. Malis <agmalis@gmail.com<mailto:agmalis@gmail.com>>; draft-ietf-rtgwg-net2cloud-problem-statement@ietf.org<mailto:draft-ietf-rtgwg-net2cloud-problem-statement@ietf.org>; RTGWG <rtgwg@ietf.org<mailto:rtgwg@ietf.org>>
Subject: Re: RE: solicit feedback for adding Interconnection among different Cloud DCs to draft-ietf-rtgwg-net2cloud-problem-statement-03

Hi Linda,

I think this is a good start.  I am not clear on how or why you see SDWAN as the unifying API for the network fabric?
Places where I see interesting requirements on multicloud are around authorization, how to indicate which VPC, consistent
APIs or abstractions, how it connects into other details like NAT or DNS, which DCs are connected, and so on.

Thanks for adding it,
Alia

On Sun, Oct 13, 2019 at 2:51 AM 刘 鹏 <liupengyjy@outlook.com<mailto:liupengyjy@outlook.com>> wrote:
Hi Linda,

The added section on hybrid cloud Interconnection is meaningful. I think there will be many new business models in the future, such as edge computing, which will involve the interconnection between hybrid clouds, so it is a very worthy topic to discuss!

Thanks,
Peng

________________________________
liupengyjy@outlook.com<mailto:liupengyjy@outlook.com>

From: Linda Dunbar<mailto:linda.dunbar@futurewei.com>
Date: 2019-09-23 23:32
To: Robert Raszuk<mailto:rraszuk@gmail.com>; Andrew G. Malis<mailto:agmalis@gmail.com>
CC: draft-ietf-rtgwg-net2cloud-problem-statement@ietf.org<mailto:draft-ietf-rtgwg-net2cloud-problem-statement@ietf.org>; RTGWG<mailto:rtgwg@ietf.org>
Subject: RE: solicit feedback for adding Interconnection among different Cloud DCs to draft-ietf-rtgwg-net2cloud-problem-statement-03
Robert,

Very good question.

All Cloud connectivity options are between Cloud providers’ DCs and the Enterprises, but not between cloud DCs (unless you instantiate your own virtual routers in different Cloud DCs and administer the IPsec tunnels among them yourselves, which by itself is a task) .

AWS’s DirectConnect allows enterprises to use 3rd party provided private Layer 2 path from enterprises’ GW to AWS DirectConnect GW. Microsoft’s ExpressRoute allows extension of a private network to any of the Microsoft cloud services, including Azure and Office365. ExpressRoute is configured using Layer 3 routing.
Therefore, to connect applications in AWS Cloud to applications in Azure Cloud, there must be a third-party gateway (physical or virtual) to interconnect the AWS’s Layer 2 DirectConnect path with Azure’s Layer 3 ExpressRoute, or hairpinned to the customer’s own GW.

Google’s Cloud Dedicated Interconnect offers similar network connectivity options as AWS and Microsoft. One distinct difference, however, is that Google’s service allows customers access to the entire global cloud network by default. It does this by connecting your on-premises network with the Google Cloud using BGP and Google Cloud Routers to provide optimal paths to the different regions of the global cloud infrastructure.

The purpose of adding this section (as requested by RTGwg Chair and Alia) is to make this problem clear as the document is about Network to interconnect Cloud. Many Enterprises today can instantiate their workloads or applications in Cloud DCs owned by different Cloud providers. Interconnecting those workloads involves three parties: The Enterprise, its network service providers, and the Cloud providers.

Hope my explanation is clear.

Thank you.

Linda

From: Robert Raszuk <rraszuk@gmail.com<mailto:rraszuk@gmail.com>>
Sent: Saturday, September 21, 2019 11:12 AM
To: Andrew G. Malis <agmalis@gmail.com<mailto:agmalis@gmail.com>>
Cc: Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>; draft-ietf-rtgwg-net2cloud-problem-statement@ietf.org<mailto:draft-ietf-rtgwg-net2cloud-problem-statement@ietf.org>; RTGWG <rtgwg@ietf.org<mailto:rtgwg@ietf.org>>
Subject: Re: solicit feedback for adding Interconnection among different Cloud DCs to draft-ietf-rtgwg-net2cloud-problem-statement-03

Hi Andrew,

Having been directly involved in interconnecting global enterprise to public clouds for over 2.5 years and having read your document I must ask - what is the objective here ?

Say ... Direct Connect it works seamlessly both from direct attachment of my routers to cloud edge or via private peering offered as a service via most if not all carriers to your doors or DCs.

Take - SDWAN - the one I have been personally using for few years now - as day one product focused on seamless interconnect to public cloud. It has multi tenancy build as root of the controller design from the very start. That offers flexible interconnect at scale with not only fixed sites but also mobile users.

IPSec to vGW also works pretty solid.

So I am not even asking what is missing ... but first what are you trying to really accomplish by this draft ?

Many thx,
Robert


On Sat, Sep 21, 2019 at 3:02 PM Andrew G. Malis <agmalis@gmail.com<mailto:agmalis@gmail.com>> wrote:
RTGwg,

As a co-author, may we interpret no responses as "quiet consensus" for the update?

Thanks,
Andy


On Tue, Sep 17, 2019 at 7:24 PM Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>> wrote:
RTGwg,

During IETF105, we got comments that draft-ietf-rtgwg-net2cloud-problem-statement-03 should expand to cover Interconnection between Cloud DCs owned and operated by different Cloud Operators, in addition to the current focusing on interconnecting Enterprises <-> Cloud DC.

Here is what we would like to add to the draft. Want to get some feedback on the mailing list. Thank you.
Linda

4.  Multiple Clouds Interconnection
4.1. Multi-Cloud Interconnection
Enterprises today can instantiate their workloads or applications in Cloud DCs owned by different Cloud providers, e.g. AWS, Azure, GoogleCloud, Oracle, etc. Interconnecting those workloads involves three parties: The Enterprise, its network service providers, and the Cloud providers.
All Cloud Operators offer secure ways to connect enterprises’ on-prem sites/DCs with their Cloud DCs. For example, Google Cloud has Cloud VPN, AWS has VPN/CloudHub, and Azure has VPN gateway.
Some Cloud Operators allow enterprises to connect via private networks. For example, AWS’s DirectConnect allows enterprises to use 3rd party provided private Layer 2 path from enterprises’ GW to AWS DirectConnect GW. Microsoft’s ExpressRoute allows extension of a private network to any of the Microsoft cloud services, including Azure and Office365. ExpressRoute is configured using Layer 3 routing. Customers can opt for redundancy by provisioning dual links from their location to two Microsoft Enterprise edge routers (MSEEs) located within a third-party ExpressRoute peering location. The BGP routing protocol is then setup over WAN links to provide redundancy to the cloud. This redundancy is maintained from the peering data center into Microsoft's cloud network.
Google’s Cloud Dedicated Interconnect offers similar network connectivity options as AWS and Microsoft. One distinct difference, however, is that Google’s service allows customers access to the entire global cloud network by default. It does this by connecting your on-premises network with the Google Cloud using BGP and Google Cloud Routers to provide optimal paths to the different regions of the global cloud infrastructure.
All those connectivity options are between Cloud providers’ DCs and the Enterprises, but not between cloud DCs.  For example, to connect applications in AWS Cloud to applications in Azure Cloud, there must be a third-party gateway (physical or virtual) to interconnect the AWS’s Layer 2 DirectConnect path with Azure’s Layer 3 ExpressRoute.
It is possible to establish IPsec tunnels between different Cloud DCs, for example, by leveraging open source VPN software such as strongSwan, you create an IPSec connection to the Azure gateway using a shared key. The strong swan instance within AWS not only can connect to Azure but can also be used to facilitate traffic to other nodes within the AWS VPC by configuring forwarding and using appropriate routing rules for the VPC. Most Cloud operators, such as AWS VPC or Azure VNET, use non-globally routable CIDR from private IPv4 address ranges as specified by RFC1918. To establish IPsec tunnel between two Cloud DCs, it is necessary to exchange Public routable addresses for applications in different Cloud DCs. [BGP-SDWAN] describes one method. Other methods are worth exploring.
In summary, here are some approaches, available now (which might change in the future), to interconnect workloads among different Cloud DCs:

a.      Utilize Cloud DC provided inter/intra-cloud connectivity services (e.g., AWS Transit Gateway) to connect workloads instantiated in multiple VPCs. Such services are provided with the cloud gateway to connect to external networks (e.g., AWS DirectConnect Gateway).

b.      Hairpin all traffic through the customer gateway, meaning all workloads are directly connected to the customer gateway, so that communications among workloads within one Cloud DC must traverse through the customer gateway.

c.      Establish direct tunnels among different VPCs (AWS’ Virtual Private Clouds) and VNET (Azure’s Virtual Networks) via client’s own virtual routers instantiated within Cloud DCs. DMVPN (Dynamic Multipoint Virtual Private Network) or DSVPN (Dynamic Smart VPN) techniques can be used to establish direct Multi-point-to-Point or multi-point-to multi-point tunnels among those client’s own virtual routers.


Approach a) usually does not work if Cloud DCs are owned and managed by different Cloud providers.
Approach b) creates additional transmission delay plus incurring cost when exiting Cloud DCs.
For the Approach c), DMVPN or DSVPN use NHRP (Next Hop Resolution Protocol) [RFC2735] so that spoke nodes can register their IP addresses & WAN ports with the hub node. The IETF ION (Internetworking over NBMA (non-broadcast multiple access) WG standardized NHRP for connection-oriented NBMA network (such as ATM) network address resolution more than two decades ago.
There are many differences between virtual routers in Public Cloud DCs and the nodes in an NBMA network. NHRP cannot be used for registering virtual routers in Cloud DCs unless an extension of such protocols is developed for that purpose, e.g. taking NAT or dynamic addresses into consideration. Therefore, DMVPN and/or DSVPN cannot be used directly for connecting workloads in hybrid Cloud DCs.
Other protocols such as BGP can be used, as described in [BGP-SDWAN].

4.2. Desired Properties for Multi-Cloud Interconnection
Different Cloud Operators have different APIs to access their Cloud resources. It is difficult to move applications built by one Cloud operator’s APIs to another. However, it is highly desirable to have a single and consistent way to manage the networks and respective security policies for interconnecting applications hosted in different Cloud DCs.
The desired property would be having a single network fabric to which different Cloud DCs and enterprise’s multiple sites can be attached or detached, with a common interface for setting desired policies. SDWAN is positioned to become that network fabric enabling Cloud DCs to be dynamically attached or detached. But the reality is that different Cloud Operators have different access methods, and Cloud DCs might be geographically far apart. More Cloud connectivity problems are described in the subsequent sections.

The difficulty of connecting applications in different Clouds might be stemmed from the fact that they are direct competitors. Usually traffic flow out of Cloud DCs incur charges. Therefore, direct communications between applications in different Cloud DCs can be more expensive than intra Cloud communications.

_______________________________________________
rtgwg mailing list
rtgwg@ietf.org<mailto:rtgwg@ietf.org>
https://www.ietf.org/mailman/listinfo/rtgwg<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frtgwg&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C195f9b031dc946a234b608d750f16c02%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637066870150628608&sdata=J%2FiGg%2FhFcsvWWxQCd3kD8EQgK5yw52y4TKDz7mbq%2BZs%3D&reserved=0>
_______________________________________________
rtgwg mailing list
rtgwg@ietf.org<mailto:rtgwg@ietf.org>
https://www.ietf.org/mailman/listinfo/rtgwg<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frtgwg&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C195f9b031dc946a234b608d750f16c02%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637066870150628608&sdata=J%2FiGg%2FhFcsvWWxQCd3kD8EQgK5yw52y4TKDz7mbq%2BZs%3D&reserved=0>