Early Review of draft-ietf-rtgwg-net2cloud-problem-statement-26
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.