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?
========
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
