I am an assigned INT directorate reviewer for
<draft-ietf-rtgwg-net2cloud-problem-statement-19>. These comments were written
primarily for the benefit of the Internet Area Directors. Document editors
and shepherd(s) should treat these comments just like they would treat
comments from any other IETF contributors and resolve them along with any
other Last Call comments that have been received. For more details on the
INT Directorate, see https://datatracker.ietf.org/group/intdir/about/.

Have reviewed version 26 rather than version 19. Sorry for the late response.
This is primarily a formatting update to follow convention. Have not
examined the technical aspects of BGP routing as am new to this.  Work
resulting in addressing the problems raised would require careful use of
extension headers and tunnels.  Balancing verified access to resources
in particular locations and also allowing for the option of end user
privacy will require some care in any resulting technical work. 

Based on my review, if I was on the IESG I would ballot this document as
YES.

A useful problem statement. Main suggestions:


1) It may be helpful to add examples from cloud providers headquartered
outside the USA.

2) As a document not aimed at experts, may wish to reference rfc8926

3) May want to examine for draft-ietf-cdni-additional-footprint-types adding location
information, though in this case geographic coordinates may be better.

4) Geographic location may not be the only consideration for routing traffic
the nearest link may have very poor performance compared to an alternate
more geographically distant link.

Suggestions to improve clarity:

1) Acronym Cloud Datacenter (DC) used in introduction should appear in first use
and should be used consistently, DC is also used for on prem data center.

2) May want to define GW - gateway?

3) Perhaps rephrase:
If an organization uses an internal name
   like .internal and then want your services to be available via or
   within some other cloud provider which also uses .internal, then
   collisions might occur.

to

If an organization uses an internal name
   like .internal and then wants your services to be available via or
   within some other cloud provider which also uses .internal, then
   collisions might occur.


4) Cloud probably does not need to be capitalized in every use when not part of a proper name.

5) Some enterprises/institutions who are not cloud providers may have multiple on premises DC
at different sites.  They may also have similar problems.

6) Maybe introduction of section 4 should be changed from:

 For many enterprises with established provide VPNs (e.g., private
   circuits, MPLS-based L2VPN/L3VPN) interconnecting branch offices &
   on-premises data centers, connecting to Cloud services will be a mix
   of different types of networks.

to

 For many enterprises which provide VPNs (e.g., private
   circuits, MPLS-based L2VPN/L3VPN) that interconnect branch offices &
   on-premises data centers, connecting to Cloud services will be a mix
   of different types of networks.

7) May want to explain "Availability Zone" since different cloud providers
may use this term in slightly different manners.


8) The abbreviation TN in Figure 1 is not defined.

9) Perhaps 'Multi-point-to-Point' to  'multi-point-to-point'

10) MPLS (Multiprotocol Label Switching) is not defined in the document.

11) The abbreviation CPE (Customer Premises Equipment?) in section 4.3 is not defined.

12) May want to use "software application" instead of App

13) Perhaps update

When
   applications in Cloud communicate with on-premises applications, it
   may not be clear where the Cloud applications are located or to
   which VPCs they belong.

to

When
   applications in the cloud communicate with on-premises applications, it
   may not be clear where the cloud applications are located or to
   which VPCs they belong.

14) Perhaps update

   Approach b) creates additional transmission delay plus incurring
   cost when exiting Cloud DCs.

to

   Approach b) creates additional transmission delays and can incur a
   cost when exiting cloud DCs.