Subject: comments on draft-ietf-rtgwg-net2cloud-problem-statement-01

From: Chris Bowers <[email-masked]>
Date: Fri, 14 Jun 2019 16:05:59 -0500

RTGWG and authors,

I think draft-ietf-rtgwg-net2cloud-problem-statement-01 covers an important
and interesting topic.  I think it needs some more work before we consider
it for WG LC and publication.  In general I think current text is not clear
enough about many of the details of the networking scenarios discussed.
These details are important for drawing conclusions about how to address
the problems presented.  Below are some specific comments on the draft.

Thanks,

Chris

=============

The title  “Seamless Interconnect Underlay to Cloud Overlay Problem
Statement” is not very clear.

The terms underlay and overlay need lots of context.  The abstract doesn’t
mention overlay or underlay, but provides a pretty good description of the
problems being discussed, ie. connecting enterprises to cloud DCs.

=============

Abstract:

Existing:

This document also

   describes some of the (network) problems that many enterprises face

Proposed:

This document also

   describes some of the network problems that many enterprises face

=============

Throughout:

“&” is used instead of “and” in many places.  I don’t think “&” should be
used.

=============

Table of contents:

   10. Security Considerations......................................17

   Solution drafts resulting from this work will address security

   concerns inherent to the solution(s), including both protocol

   aspects and the importance (for example) of securing workloads in

   cloud DCs and the use of secure interconnection mechanisms.......17

Something is causing the text of the security considerations section to
show up in the table of contents.

=============

Section 1.1:

Existing text:

   In addition, it is an uptrend with more enterprises instantiating

   their apps & workloads in different cloud DCs to maximize the

   benefits of geographical proximity, elasticity and special features

   offered by different cloud DCs.

The use of “uptrend” here is awkward.  It sounds like marketing copy.  Also,
is the assertion that enterprises  will be using multiple, geographically
diverse cloud DCs from the same provider or from different providers?

============

Section 2

Existing text:

   Hybrid Clouds: Hybrid Clouds (usually plural) refer to enterprises

               using their own premises DCs in addition to Cloud

               services provided by multiple cloud operators.  For

               example, an enterprise not only have applications

               running in their own DCs, but also have applications

               hosted in multiple third party cloud DCs ((AWS, Azure,

               Google, Salesforces, SAP, etc).  . ONUG also has a

               notion of heterogeneous cloud, refers to enterprises

               does not have its own DC, only uses services by 3rd

               party cloud operators.

This definition of hybrid cloud above implies that any hybrid cloud must
also be a heterogenous cloud.  I would rewrite the first sentence as

“Hybrid Cloud refers to an enterprise using its own on-premises DCs in
addition to Cloud

               services provided by one or more cloud operators.”

The last sentence about ONUG’s notion of heterogenous cloud is very
confusing here.

=============

Section 2

Existing text:

VPC:        Virtual Private Cloud. A service offered by Cloud DC

               operators to allocate logically-isolated cloud

               resources, including compute, networking and storage.

It seems to me that Virtual Private Cloud needs a much more detailed
definition or description.   For example, does the VPC use public or
private address space?  Later on in section 3.1 there is mention of
“transit gateways”.  Perhaps a more complete description of  the VPC would
describe transit gateways.

=============

Section 3.1

Existing text:

     - Internet gateway for any external entities to reach the

        workloads hosted in AWS Cloud DC via the Internet.

It is not clear what this option refers to.  Is the ability for the
enterprise to SSH and SCP into their server instances in the AWS cloud at
public IP addresses over the internet?  Or it the ability of, for example,
a customer of the enterprise to access an application on a web server run
by the enterprise?  Or is it access from the Internet to the VPC private
address space mediated by NAT.  This should be clarified.

============

Section 3.1

Existing text:

Via Direct Connect, an AWS Transit

        Gateway can be used to interconnect multiple VPCs in different

        Availability Zones.

The “transit gateway” needs a clearer description.  It is also not clear
what the transit gateway has to do with the Direct Connect option.

============

Section 3.1

Existing text:

  CPEs at one Enterprise branch office are connected to the Internet

   to reach AWS's vGW via IPsec tunnels. Other ports of such CPEs are

   connected to AWS DirectConnect via a private network (without any

   encryption).

Proposed text:

As an example, some branch offices of an enterprise can connect to over the
Internet to reach AWS's vGW via IPsec tunnels.

Other branch offices of the same enterprise can connect to AWS
DirectConnect via a private network (without any

   encryption).

=============

Figure 1.

Figure 1 needs more description and detail

What are TN-1 and TN-2?  Are they “Tenant Networks” or something else?  Are
they all part of the same VPC or do they represent different VPCs?

If the point of figure 1 is to show that a single enterprise can connect to
the same set of resources with some branches using IPSec Tunnels and others
branches using Direct Connect (since TN-1 and TN-2 are repeated in each
instance), then perhaps it would be better to just represent those
resources as a single instance, instead of multiple instances with the same
names.

Where is the “customer gateway” physically located in the Direct connect
case?

=============

Section 3.2

Existing Text:

   According to Gartner, by 2020 "hybrid will be the most common usage

   of the cloud" as more enterprises see the benefits of integrating

   public and private cloud infrastructures.

I personally don’t think that this reference to a Gartner report is very
useful.  By the time this draft is published, it will likely already be
2020.  However, it you do want to use the reference, then it needs a
citation in the References section so that someone can go look it up.

========

The division of the material in Sections 3.1  “Interconnect to Cloud DCs”
and section 3.2  “Interconnect to Hybrid Cloud DCs” is confusing and seems
somewhat arbitrary.  The content of section 3.1 seems like it mainly
applies to Hybrid Cloud DCs.    At the same time, the observation in
section 3.2  that “some enterprises prefer to instantiate their own virtual
 CPEs/routers inside the Cloud DC to connect the workloads within the Cloud
DC” doesn’t seem specific to Hybrid Clouds DCs.  I would suggest
reorganizing the content of these two sections.

========

Section 3.3 mentions three different approaches to interconnect workloads
among different Cloud DCs.  However, most of the discussion is about the
third option (establishing direct tunnels among different VPCs via client's
own virtual routers instantiated within Cloud DCs.)  It would the good to
provide more detail on the first two options.  Presumably the first option
(utilizing Cloud DC provided transit gateways) is reasonable if the
enterprise is using only one cloud provider. The current text is pretty
dismissive of this option.  The second option (Hairpin all the traffic
through the customer gateway) is not very clearly explained.  If these
different approaches are going to be discussed, there needs to be more
detail.

========

Section 3.3

Existing text:

   There are many differences between virtual routers in Public Cloud

   DCs and the nodes in an NBMA network. NHRP & DSVPN are not cannot be

   used for registering virtual routers in Cloud DCs unless an

   extension of such protocols is developed for that purpose.

The current text simply asserts that NHRP and DSVPN cannot be used for this
purpose.  It seems like more detail is needed in the text.  Does this
conclusion also apply to DMVPN?

========

Section 4

Existing text:

     - High availability at any time, whatever the duration of the

        connection to the cloud DC.

        Many enterprises include cloud infrastructures in their

        disaster recovery strategy, e.g., by enforcing periodic backup

        policies within the cloud, or by running backup applications in

        the Cloud, etc. Therefore, the connection to the cloud DCs may

        not be permanent, but rather needs to be on-demand.

This requirement is confusing.  Is the requirement for the network
connectivity to be highly available or is the requirement that it be
on-demand to support high availability in a cost-effective manner?

=========

Section 4

     - Elasticity and mobility, to instantiate additional applications

        at Cloud DCs when end-users' usages increase and shut down

        applications at locations when there are fewer end-users.

        Some enterprises have front-end web portals running in cloud

        DCs and database servers in their on-premises DCs. Those Front-

        end web portals need to be reachable from the public Internet.

        The backend connection to the sensitive data in database

        servers hosted in the on-premises DCs might need secure

        connections.

This seems like two different requirements in the same bullet point.

=============

Section 5. Problems with MPLS-based VPNs extending to Hybrid Cloud DCs

Existing text:

     - 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 workloads hosted inside.

This assertion seems to contradict the description of the AWS Direct
Connect option described in Section 3.1.

If this is true, please provide more detail about why it is true in the
context of a more complete description of VPCs.

=============

Section 5

There is something wrong with the formatting of the last list item.

In addition to the formatting, this last list item beginning with “Many
cloud DCs use an overlay to connect their gateways ..” is very confusing.  This
should be expanded into a section with a full explanation and a figure to
explain the problem,  as opposed to just a bullet item.

=============

Figure 2.

Where is the “customer gateway” physically located in the Direct connect
case?

What do TN-1, TN-2, TN-3, … TN-6 represent exactly?  Are they all part of
the same VPC or different VPCs?

========

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 17 Jun 2019 18:01:31 +0000

Chris,

Thank you very much for the detailed review and comments.
Changes to address your comments are inserted below. Attached is the changed document with the ChangeBar enabled.  Please let us know if you have more suggestions.

From: rtgwg <[email-masked]> On Behalf Of Chris Bowers
Sent: Friday, June 14, 2019 4:06 PM
To: RTGWG <[email-masked]>
Subject: comments on draft-ietf-rtgwg-net2cloud-problem-statement-01

RTGWG and authors,

I think draft-ietf-rtgwg-net2cloud-problem-statement-01 covers an important and interesting topic.  I think it needs some more work before we consider it for WG LC and publication.  In general I think current text is not clear enough about many of the details of the networking scenarios discussed.   These details are important for drawing conclusions about how to address the problems presented.  Below are some specific comments on the draft.

Thanks,
Chris

=============
The title  “Seamless Interconnect Underlay to Cloud Overlay Problem Statement” is not very clear.
The terms underlay and overlay need lots of context.  The abstract doesn’t mention overlay or underlay, but provides a pretty good description of the problems being discussed, ie. connecting enterprises to cloud DCs.

[Linda] This document discusses the issues associated with connecting enterprise to their workloads/applications instantiated in multiple third-party data centers (a.k.a. Cloud DCs). Very often, the actual Cloud DCs that host the workloads/applications can be transient.
Do you think a title along the line of “Dynamic Networks to Connect to Cloud DCs” is more appropriate?  Or simply “Dynamic Networks to Cloud DCs”?

=============
Abstract:

Existing:
This document also

Proposed:
This document also

[Linda] changed per your comment.

=============
Throughout:
“&” is used instead of “and” in many places.  I don’t think “&” should be used.

 [Linda] changed per your comment.

=============
Table of contents:

   10. Security Considerations.......................................17

   cloud DCs and the use of secure interconnection mechanisms........17

Something is causing the text of the security considerations section to show up in the table of contents.
 [Linda] changed.

=============
Section 1.1:
Existing text:

The use of “uptrend” here is awkward.  It sounds like marketing copy.  Also, is the assertion that enterprises  will be using multiple, geographically diverse cloud DCs from the same provider or from different providers?
[Linda] How about changing to the following?

In addition, more enterprises are moving towards hybrid cloud DCs, i.e. owned or operated by different Cloud operators, to maximize the benefits of geographical proximity, elasticity and special features offered by different cloud DCs.

============
Section 2

Existing text:

This definition of hybrid cloud above implies that any hybrid cloud must also be a heterogenous cloud.  I would rewrite the first sentence as
“Hybrid Cloud refers to an enterprise using its own on-premises DCs in addition to Cloud
               services provided by one or more cloud operators.”

[Linda] thanks for the suggestion. Changed accordingly.

The last sentence about ONUG’s notion of heterogenous cloud is very confusing here.

[Linda] Removed

=============
Section 2

Existing text:

It seems to me that Virtual Private Cloud needs a much more detailed definition or description.   For example, does the VPC use public or private address space?  Later on in section 3.1 there is mention of “transit gateways”.  Perhaps a more complete description of  the VPC would describe transit gateways.

=============
Section 3.1

Existing text:

It is not clear what this option refers to.  Is the ability for the enterprise to SSH and SCP into their server instances in the AWS cloud at public IP addresses over the internet?  Or it the ability of, for example, a customer of the enterprise to access an application on a web server run by the enterprise?  Or is it access from the Internet to the VPC private address space mediated by NAT.  This should be clarified.

[Linda] this is refereeing to AWS Internet Gateway.
How about changing to “AWS Internet Gateway allows communication between instances in AWS VPC and the internet”?

Here is the direct quote from AWS documentation:

Internet Gateways
An internet gateway is a horizontally scaled, redundant, and highly available VPC component that allows communication between instances in your VPC and the internet. It therefore imposes no availability risks or bandwidth constraints on your network traffic.
An internet gateway serves two purposes: to provide a target in your VPC route tables for internet-routable traffic, and to perform network address translation (NAT) for instances that have been assigned public IPv4 addresses.
An internet gateway supports IPv4 and IPv6 traffic.

============
Section 3.1

Existing text:

The “transit gateway” needs a clearer description.  It is also not clear what the transit gateway has to do with the Direct Connect option.

[Linda] it is referring to AWS Transit Gateway which is described in detail in AWS documentation: https://aws.amazon.com/transit-gateway/
 Transit Gateway acts as a hub that controls how traffic is routed among all the connected networks which act like spokes.

============
Section 3.1

Existing text:

   encryption).

Proposed text:
As an example, some branch offices of an enterprise can connect to over the Internet to reach AWS's vGW via IPsec tunnels.
Other branch offices of the same enterprise can connect to AWS DirectConnect via a private network (without any
   encryption).

[Linda] thank you very much for the suggestion. Changed accordingly.

=============
Figure 1.

What are TN-1 and TN-2?  Are they “Tenant Networks” or something else?  Are they all part of the same VPC or do they represent different VPCs?

If the point of figure 1 is to show that a single enterprise can connect to the same set of resources with some branches using IPSec Tunnels and others branches using Direct Connect (since TN-1 and TN-2 are repeated in each instance), then perhaps it would be better to just represent those resources as a single instance, instead of multiple instances with the same names.

Where is the “customer gateway” physically located in the Direct connect case?

[Linda] Modified the figure per your suggestion. And add the following explanation:

Figure below shows an example of some tenants’ workloads are accessible via a virtual router connected by AWS Internet Gateway; some are accessible via AWS vGW, and others are accessible via AWS Direct Connect. The vR1 can have its own IPsec capability for secure tunnel over the internet to bypass paying additional price for the IPsec features provided by AWS vGW. Some tenants can deploy separate virtual routers to connect to internet traffic and to traffic from the secure channels from vGW and DirectConnect, e.g. vR1 & vR2. Others may have one virtual router connecting to both types of traffic. Customer Gateway can be customer owned router or ports physically connected to AWS Direct Connect GW.
.

=============
Section 3.2

Existing Text:

I personally don’t think that this reference to a Gartner report is very useful.  By the time this draft is published, it will likely already be 2020.  However, it you do want to use the reference, then it needs a citation in the References section so that someone can go look it up.

[Linda] removed the reference.

========
The division of the material in Sections 3.1  “Interconnect to Cloud DCs” and section 3.2  “Interconnect to Hybrid Cloud DCs” is confusing and seems somewhat arbitrary.  The content of section 3.1 seems like it mainly applies to Hybrid Cloud DCs.    At the same time, the observation in section 3.2  that “some enterprises prefer to instantiate their own virtual  CPEs/routers inside the Cloud DC to connect the workloads within the Cloud DC” doesn’t seem specific to Hybrid Clouds DCs.  I would suggest reorganizing the content of these two sections.

[Linda] The section 3.1 is mainly about same workloads being accessible by multiple connections (Internet, Direct Connect, etc.).  It is important for enterprises to be able to observe the specific behaviors when connected by different connections.
How about Changing the Section 3.1 title to “Multiple connection to workloads in a Cloud DC”.

========
Section 3.3 mentions three different approaches to interconnect workloads among different Cloud DCs.  However, most of the discussion is about the third option (establishing direct tunnels among different VPCs via client's own virtual routers instantiated within Cloud DCs.)  It would the good to provide more detail on the first two options.  Presumably the first option (utilizing Cloud DC provided transit gateways) is reasonable if the enterprise is using only one cloud provider. The current text is pretty dismissive of this option.  The second option (Hairpin all the traffic through the customer gateway) is not very clearly explained.  If these different approaches are going to be discussed, there needs to be more detail.

[Linda] Added the following text to describe the issues associated with each of the bullets listed:

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.

========
Section 3.3
Existing text:

The current text simply asserts that NHRP and DSVPN cannot be used for this purpose.  It seems like more detail is needed in the text.  Does this conclusion also apply to DMVPN?
[Linda] Yes. Changed the text to the following:
 NHRP cannot be used for registering virtual routers in Cloud DCs unless an extension of such protocols is developed for that purpose. Therefore, DMVPN and/or DSVPN cannot be used directly for connecting workloads in hybrid Cloud DCs.

========
Section 4
Existing text:

This requirement is confusing.  Is the requirement for the network connectivity to be highly available or is the requirement that it be on-demand to support high availability in a cost-effective manner?
[Linda] Both. Changed to the following:

  *   High availability to access all workloads in the desired cloud DCs.

=========
Section 4

[Linda] changed the text to the following:

  *   Elasticity: prompt connection to newly instantiated applications at Cloud DCs when end-users’ usages increase and prompt release of connection after applications at locations being removed when demands change.

=============

Existing text:

This assertion seems to contradict the description of the AWS Direct Connect option described in Section 3.1.
If this is true, please provide more detail about why it is true in the context of a more complete description of VPCs.

[Linda] added this paragraph to explain:
Even with AWS DirectConnect, the connection only reaches the AWS DirectConnect Gateway.

=============

Section 5

In addition to the formatting, this last list item beginning with “Many cloud DCs use an overlay to connect their gateways ..” is very confusing.  This should be expanded into a section with a full explanation and a figure to explain the problem,  as opposed to just a bullet item.

[Linda] changed the bullet to “-  Extensive usage of Overlay by Cloud DCs”, and added the explanation.

=============
Figure 2.

Where is the “customer gateway” physically located in the Direct connect case?

What do TN-1, TN-2, TN-3, … TN-6 represent exactly?  Are they all part of the same VPC or different VPCs?

[Linda] Added the explanation. TN= Tenant Applications/workloads.
========

---

From: Chris Bowers <[email-masked]>
Date: Tue, 25 Jun 2019 16:52:06 -0500

Linda,

Thanks for the responses and updated draft.  See inline below with [CB].

Thanks,
Chris

On Mon, Jun 17, 2019 at 1:01 PM Linda Dunbar <[email-masked]> wrote:

> Changes to address your comments are inserted below. Attached is the
> changed document with the ChangeBar enabled.  Please let us know if you
> have more suggestions.
>
>
>
>
>
> *From:* rtgwg <[email-masked]> *On Behalf Of * Chris Bowers
> *Sent:* Friday, June 14, 2019 4:06 PM
> *To:* RTGWG <[email-masked]>
> *Subject:* comments on draft-ietf-rtgwg-net2cloud-problem-statement-01
>
>
>
> RTGWG and authors,
>
>
>
> I think draft-ietf-rtgwg-net2cloud-problem-statement-01 covers an
> important and interesting topic.  I think it needs some more work before we
> consider it for WG LC and publication.  In general I think current text is
> not clear enough about many of the details of the networking scenarios
> discussed.   These details are important for drawing conclusions about how
> to address the problems presented.  Below are some specific comments on the
> draft.
>
>
>
> Thanks,
>
> Chris
>
>
>
> =============
>
> [Linda] This document discusses the issues associated with connecting
> enterprise to their workloads/applications instantiated in multiple
> third-party data centers (a.k.a. Cloud DCs). Very often, the actual Cloud
> DCs that host the workloads/applications can be transient.
>
> Do you think a title along the line of “Dynamic Networks to Connect to
> Cloud DCs” is more appropriate?  Or simply “Dynamic Networks to Cloud DCs”?
>
> [CB] I'm OK with the title in -02.
>

> The use of “uptrend” here is awkward.  It sounds like marketing copy.
> Also, is the assertion that enterprises  will be using multiple,
> geographically diverse cloud DCs from the same provider or from different
> providers?
>
> In addition, more enterprises are moving towards hybrid cloud DCs, i.e.
> owned or operated by different Cloud operators, to maximize the benefits of
> geographical proximity, elasticity and special features offered by
> different cloud DCs.
>

[CB] That's seems OK.

[CB]  As far as I can tell, this request for a much more detailed
description of a VPC has not been addressed in -02.  The document makes
assertions about problems connnecting to VPCs without ever clearly defining
the properties of VPCs.

=============
> instances in AWS VPC and the internet”?
[CB] I think this should be addressed as part of a much more detailed
discussion of the properties of VPCs.   The quote below gives more
information about VPCs, which could help with the general description of
VPCs.  For example, so far the text of this draft hasn't said whether or
not the VPC uses public or private IPv4 addresses, so what the Internet
Gateway needs to do to connect a VPC to the public internet is not clear.

> *Internet Gateways*
> An internet gateway is a horizontally scaled, redundant, and highly
> available VPC component that allows communication between instances in your
> VPC and the internet. It therefore imposes no availability risks or
> bandwidth constraints on your network traffic.
>
> An internet gateway serves two purposes: to provide a target in your VPC
> route tables for internet-routable traffic, and to perform network address
> translation (NAT) for instances that have been assigned public IPv4
> addresses.
>

> [Linda] it is referring to AWS Transit Gateway which is described in
> detail in AWS documentation: https://aws.amazon.com/transit-gateway/
>
>  Transit Gateway acts as a hub that controls how traffic is routed among
> all the connected networks which act like spokes.
>
>
>
[CB] Again, I think this needs to be addressed as part of the more detailed
description of VPCs.

============
> As an example, some branch offices of an enterprise can connect to over
> the Internet to reach AWS's vGW via IPsec tunnels.
>
> What are TN-1 and TN-2?  Are they “Tenant Networks” or something else?
> Are they all part of the same VPC or do they represent different VPCs?
>
>
>
> If the point of figure 1 is to show that a single enterprise can connect
> to the same set of resources with some branches using IPSec Tunnels and
> others branches using Direct Connect (since TN-1 and TN-2 are repeated in
> each instance), then perhaps it would be better to just represent those
> *Figure below shows an example of some tenants’ workloads are accessible
> via a virtual router connected by AWS Internet Gateway; some are accessible
> via AWS vGW, and others are accessible via AWS Direct Connect. The vR1 can
> have its own IPsec capability for secure tunnel over the internet to bypass
> paying additional price for the IPsec features provided by AWS vGW. Some
> tenants can deploy separate virtual routers to connect to internet traffic
> and to traffic from the secure channels from vGW and DirectConnect, e.g.
> vR1 & vR2. Others may have one virtual router connecting to both types of
> traffic. Customer Gateway can be customer owned router or ports physically
> connected to AWS Direct Connect GW. *
>
> *. *
>
>
>
> =============
>
> Section 3.2
>
>
>
> Existing Text:
>
> [CB]  Reference was removed, but the prediction is now an assertion.  "
> Hybrid will be the most common usage of the cloud..."  How about
> something less strong like, "It is likely that hybrid will be a common
> usage of the cloud ..."
>

> [Linda] The section 3.1 is mainly about same workloads being accessible by
> multiple connections (Internet, Direct Connect, etc.).  It is important for
> enterprises to be able to observe the specific behaviors when connected by
> different connections.
> 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.
>
>
>
[CB]  This hasn't provided more detail on the first two options.  It is has
just rearranged the existing information.

========
> The current text simply asserts that NHRP and DSVPN cannot be used for
> this purpose.  It seems like more detail is needed in the text.  Does this
> * NHRP cannot be used for registering virtual routers in Cloud DCs unless
> an extension of such protocols is developed for that purpose. Therefore,
> DMVPN and/or DSVPN cannot be used directly for connecting workloads in
> hybrid Cloud DCs.*
>
>
>
> ========
>
> Section 4
>
> Existing text:
>
>    - High availability to access all workloads in the desired cloud DCs.
>
>
>
>
>
> =========
>
> Section 4
>
>    - Elasticity: prompt connection to newly instantiated applications at
>    Cloud DCs when end-users’ usages increase and prompt release of connection
>    after applications at locations being removed when demands change.
>
>
>
>
>
> =============
>
> *Even with AWS DirectConnect, the connection only reaches the AWS
> DirectConnect Gateway.*
>
>
>
[CB]  The sentence that was added does not clarify the problem being
highlighted here.  It seems like this bullet point is trying to highlight a
very significant limitation with using MPLS-based VPNs to reach VPCs.
However, from the current text, I am not able to figure out what that
limitation is.  Please make it clearer what the limitiation is in the
context of a more complete description of VPCs and the direct connect
option. Also, if BGP is used to exchange routes in the direct connect
option, that should be explained.

> cloud DCs use an overlay to connect their gateways ..” is very confusing.
> This should be expanded into a section with a full explanation and a figure
> to explain the problem,  as opposed to just a bullet item.
>
>
>
[CB] I think it would be useful to give detail on where the customer
gateway is physically.  Is it physically collocated with the Direct Connect
gateway, or could it be the MPLS VNP PE?