Re: complete done (RE: comments on draft-ietf-rtgwg-net2cloud-problem-statement-4)

[Linda Dunbar <[e-mail]>]

Chris,

Can you suggest what "more details" you are looking for on the VPC description?  It is the description from cloud providers:

> *"Virtual Private Cloud is a virtual network dedicated to one client
> account. It is logically isolated from other virtual networks in a Cloud
> DC. Each client can launch his/her desired resources, such as compute,
> storage, or network functions into his/her VPC. In Microsoft Azure, the
> term "Virtual Network (VNet)" is used for Virtual Private Cloud. Most Cloud
> Operators' VPCs only support private addresses, some support IPv4 only,
> others support IPv4/IPv6 dual stack."*
>
>
>
[CB2]  I think this is an improvement, but I still think the description of
the VPC in the document needs much more detail.

Please see below in [Linda2] as reply to your comments:

----------------------------------------------------------
Re: complete done (RE: comments on draft-ietf-rtgwg-net2cloud-problem-statement-01
Chris Bowers <[e-mail]> Thu, 11 July 2019 21:10 UTCShow header<https://mailarchive.ietf.org/arch/msg/rtgwg/A7jAg_U17jCQIdqL3zgRN0K42us>
Thanks.  Please see inline with [CB2].

[Snipped]
>
> --------------------------------------------------------------------------
>
>
>
> [Linda] I see many comments are related to not so clear definition on
> VPC. Do you think the following definition (quoted from a Cloud DC
> documentation) is clear enough?
>
>
>
> *"Virtual Private Cloud is a virtual network dedicated to one client
> account. It is logically isolated from other virtual networks in a Cloud
> DC. Each client can launch his/her desired resources, such as compute,
> storage, or network functions into his/her VPC. In Microsoft Azure, the
> term "Virtual Network (VNet)" is used for Virtual Private Cloud. Most Cloud
> Operators' VPCs only support private addresses, some support IPv4 only,
> others support IPv4/IPv6 dual stack."*
>
>
>
[CB2]  I think this is an improvement, but I still think the description of
the VPC in the document needs much more detail.

>
>
>
>
> *AWS Direct Connect, which allows enterprises to purchase direct connect
> from network service providers to get a private leased line interconnecting
> the enterprises gateway(s) and the AWS Direct Connect routers. In addition,
> an AWS Transit Gateway (https://aws.amazon.com/transit-gateway/
> <https://aws.amazon.com/transit-gateway/<https://aws.amazon.com/transit-gateway/%3E)>>)  can be used to interconnect
> multiple VPCs in different Availability Zones. AWS Transit Gateway acts as
> a hub that controls how traffic is routed among all the connected networks
> which act like spokes.*
>
>
>
> [CB2]  I don't think the text should reference this URL, since the URL
> might go away in the future.

[Linda2] Okay, I will remove the URL. The reference is primarily for you.


[Snipped]

>
>    - *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. Even with AWS DirectConnect, the connection only reaches the
>    AWS DirectConnect Gateway. AWS DirectConnect Gateway uses BGP to exchange
>    all routes behind the gateway, even routes which might be physically
>    located in different geographical locations. There is no visibility to how
>    the applications/workloads are interconnected within a Cloud DC or across
>    multiple Cloud DCs.*
>
>
[CB2]  If I understand correctly, the following problem is being
highlighted.  An enterprise with a hybrid cloud deployment can use an
MPLS-VPN to connect to a Cloud provider at multiple locations.  The
connection locations often correspond to different Cloud DC locations from
the Cloud provider.  The different Cloud DCs are interconnected by the
Cloud provider's own internal network.  At each connection location, the
Cloud provider uses BGP to advertise all of the prefixes in the
enterprise's VPC, regardless of which Cloud DC a given prefix is actually
in. This can result in inefficient routing for the end-to-end data path.

Is this the problem that the text in the draft is trying to describe? If
so,  I suggest using something like the text provided here to make it
clearer.

[Linda2] Thank you very much for the suggestion. I change the text to the following:


  *   Most of the cloud DCs do not expose their internal networks. An enterprise with a hybrid cloud deployment can use an MPLS-VPN to connect to a Cloud provider at multiple locations.  The connection locations often correspond to gateways of different Cloud DC locations from the Cloud provider.  The different Cloud DCs are interconnected by the Cloud provider's own internal network.  At each connection location (gateway), the Cloud provider uses BGP to advertise all of the prefixes in the enterprise's VPC, regardless of which Cloud DC a given prefix is actually in. This can result in inefficient routing for the end-to-end data path.

Linda