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

[Chris Bowers <[e-mail]>]

Thanks.  Please see inline with [CB2].

On Tue, Jul 2, 2019 at 5:24 PM Linda Dunbar <[e-mail]>
wrote:

> Chris,
>
>
>
> Here are the complete resolutions to all your comments. Thank you very
> much for the detailed comments. Please let us know if you have more.
>
>
>
> Please see below in Purple. Also attached is the document with changes
> highlighted.
>
>
>
> Linda
>
> --------------------------------------------------------------------------
>
>
>
> [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.

>
>
> See below in purple for the proposed resolutions for other comments:
>
>
>
> *From:* Chris Bowers <[e-mail]>
> *Sent:* Tuesday, June 25, 2019 4:52 PM
> *To:* Linda Dunbar <[e-mail]>
> *Cc:* RTGWG <[e-mail]>
> *Subject:* Re: comments on draft-ietf-rtgwg-net2cloud-problem-statement-01
>
>
>
> [Snipped]
>
> 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.
>
>
>
> [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.
>
>
>
> =============
>
> 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.
>
>
>
> [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”?
>
>
>
> [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.
>
>
>
> *[Linda] AWS VPC only supports private IPv4 addresses, it doesn’t support
> IPv6,. Azure supports dual stack. Do you think it is necessary to elaborate
> more on the Internet Gateway? *
>
>
>
>
>
>
>
> 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:
>
> 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.
>
>
>
> [Linda] it is referring to AWS Transit Gateway which is described in
> detail in AWS documentation: https://aws.amazon.com/transit-gateway/
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Faws.amazon.com%2Ftransit-gateway%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C7889c9cecd504a25a48408d6f9c73cbc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636971031444510847&sdata=DO4pNt3emXMzWIz9n%2BPEmRx8NyTN1HcoadjzvSSuC0s%3D&reserved=0>
>
>  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.
>
> [Linda] I added the Transit Gateway link to the document, and a brief
> summary of what AWS Transit Gateway does. The goal is only to illustrate
> that there could be multiple ways to connect to workloads in Cloud DCs. See
> below text:
>
>
>
> *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/>)  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.
>
>
>
>
>
> ============
>
> 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).
>
>
>
> [Linda] thank you very much for the suggestion. Changed accordingly.
>
>
>
> =============
>
> 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?
>
>
>
> [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:
>
>    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.
>
>
>
> [Linda] removed the reference.
>
>
>
> [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] Changed to your suggested wording.
>
>
>
>
>
> ========
>
> 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.
>
>
>
> [CB]  This hasn't provided more detail on the first two options.  It is
> has just rearranged the existing information.
>
>
>
> [Linda] How about the following additional description added?
>
>
>
>    1. *Utilize Cloud DC provided inter/intra cloud connectivity services
>    (e.g. AWS Transit Gateway) to connect workloads instantiated in multiple
>    VPCs provided with the cloud gateway to external network (e.g. AWS
>    DirectConnect Gateway). *
>    2. *Hairpin all the traffic through the customer gateway, meaning all
>    workloads are directly connected to the customer gateway, so that
>    communication among workloads within one Cloud DC have to traverse through
>    the customer gateway.*
>    3. *Establish direct tunnels among different VPCs (Virtual Private
>    Clouds) 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.*
>
>
>
>
>
> ========
>
> 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?
>
> [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:
>
>      - 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?
>
> [Linda] Both. Changed to the following:
>
> ·        High availability to access all workloads in the desired cloud
> DCs.
>
>
>
>
>
> =========
>
> 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.
>
>
>
> [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.
>
>
>
>
>
> =============
>
> 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.
>
>
>
> [Linda] added this paragraph to explain:
>
> *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.
>
>
>
> [Linda] The limitation is no visibility to how the applications/workloads
> are interconnected within a Cloud DC or across multiple Cloud DCs. Add
> the following sentence:
>
>    - *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.