RTGwg, We would appreciate your help in evaluating whether the following resolutions to Eric Vyncke's comments are acceptable for another round of RTGWG WGLC.
P.S. The IESG has returned draft-ietf-rtgwg-net2cloud-problem-statement-41 to RTGWG. We need another WGLC to ensure that the IESG's comments have been properly addressed. Thank you for your time and input. Linda -----Original Message----- From: Éric Vyncke via Datatracker <nore...@ietf.org> Sent: Thursday, September 19, 2024 5:24 AM To: The IESG <i...@ietf.org> Cc: draft-ietf-rtgwg-net2cloud-problem-statem...@ietf.org; rtgwg-cha...@ietf.org; rtgwg@ietf.org; j...@joelhalpern.com; j...@joelhalpern.com Subject: Éric Vyncke's Discuss on draft-ietf-rtgwg-net2cloud-problem-statement-41: (with DISCUSS and COMMENT) Éric Vyncke has entered the following ballot position for draft-ietf-rtgwg-net2cloud-problem-statement-41: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-positions%2F&data=05%7C02%7Clinda.dunbar%40futurewei.com%7C068ef2dfd2d24888362008dcd8a5fc00%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638623454637412825%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=43bFSToo2Qsj%2B4Q8PpSalNUvcAs%2FcLdsJLfvq9UF1%2Bk%3D&reserved=0 for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-rtgwg-net2cloud-problem-statement%2F&data=05%7C02%7Clinda.dunbar%40futurewei.com%7C068ef2dfd2d24888362008dcd8a5fc00%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638623454637433458%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=gzro4fK03cdMPe5tKlzHpYulLZKMjwPyF7nZc53mE%2Bc%3D&reserved=0 ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-rtgwg-net2cloud-problem-statement-41 Thank you for the work put into this document, I can imagine the amount of work with 41 versions :-) but after balloting several DISCUSS points, I stopped reviewing it after section 3.7. I am also supportive of John's DISCUSS position. Please find below several DISCUSS points, some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Joel M. Halpern for the shepherd's detailed write-up including the WG consensus (`While there was not widespread support`) and the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric # DISCUSS (blocking) As noted in https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fblog%2Fhandling-iesg-ballot-positions%2F&data=05%7C02%7Clinda.dunbar%40futurewei.com%7C068ef2dfd2d24888362008dcd8a5fc00%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638623454637445320%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=K4hZyJZqo1JUb1GEcQoQu83%2BoPp66qkrUE1oG2pj1PA%3D&reserved=0, a DISCUSS ballot is a request to have a discussion on the following topics: ## Copyright Wrong template is used as `Simplified BSD License` should be "Revised BSD License". [Linda] Fixed. ## Section 3.5 AFAIK, the ".internal" is not a special-use domain name listed by IANA (and AFAIK not yet approved by ICANN), so, please be clear about this status (i.e., squatting a domain) in the document. [Linda] You are correct that ".internal" is not an officially recognized special-use domain name by IANA nor an ICANN-approved TLD. This example is to emphasize why enterprises should consider using a globally unique registered domain name even for internal resolution purposes. Do you think the following wording changes can make the intent clearer? Old: “If an organization uses internal names like those under a .internal top level domain name, and wants its services to be available via or within some other Cloud provider that also uses .internal, collisions might occur.” New: "Some organizations use internal names like those under a .internal top-level domain. However, .internal is not an officially designated special-use domain name by IANA nor an ICANN-approved TLD. To avoid potential conflicts, enterprises should consider using a globally unique, registered domain name, even for internal resolution purposes." ## Section 3.6 In 2024, such an I-D must care about IPv6 and not too much about IPv4 NAT. If this document insists to use some commercial cloud references, then please use also non-US-based cloud offerings. [Linda] While IPv6 adoption is increasing, most cloud providers still rely on private IP addressing and NAT for managing outbound traffic, even in IPv6-enabled environments. NAT remains a fundamental mechanism for cloud networking, including scenarios where IPv6 is supported alongside IPv4. The current text does not exclude IPv6 considerations but focuses on widely used cloud networking practices. Therefore, no changes are needed to address this point. Regarding the inclusion of non-US-based cloud offerings, the examples given are illustrative rather than exhaustive. However, we acknowledge the diversity of cloud providers and will consider adding broader references in future revisions if necessary ## Section 3.7 What is `IPv6 optional header` ? [Linda] Good catch. It is meant to be “IPv6 Extension Header” ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # COMMENTS (non-blocking) ## Abstract Like already noticed by other ADs, the date 2023 in the abstract is seriously outdated, the document should be refreshed for content and the date moved to 2024. But, better having a date than no date at all... [Linda] the purpose of this document is to identify the network-related problems enterprises face, the existing mitigation approaches available within the IETF, and the new solution drafts being proposed to address unresolved issues. Regarding the date in the abstract, rather than specifying a particular year, we have revised the text to make it timeless, ensuring the document remains relevant without requiring frequent updates to the date. Here is the updated Abstract: “This document describes a set of network-related problems enterprises face when interconnecting their branch offices with dynamic workloads in third-party data centers (DCs) (a.k.a. Cloud DCs). These challenges are particularly relevant to enterprises with conventional VPN services that want to leverage those networks (instead of altogether abandoning them). The document also outlines various mitigation approaches, including those already developed within the IETF. For challenges that do not yet have established solutions, it identifies new IETF drafts that have been proposed to address these issues.” ## Section 2 `Third party Data Centers` I am not sure whether "3rd party" applies when the cloud DC is used only by the employees. [Linda] "Third-party Data Centers" (or "Cloud DCs") is a widely used term in the industry to refer to data centers operated by external providers, regardless of whether access is limited to a single organization’s employees or shared among multiple tenants. `private clouds` should probably be defined to avoid any ambiguity. [Linda] According to NIST Special Publication 800-145, a Private Cloud is defined as: “The cloud infrastructure is provisioned for exclusive use by a single organization comprising multiple consumers (e.g., business units). It may be owned, managed, and operated by the organization, a third party, or some combination of them, and it may exist on or off premises.” Added this definition to Section 2. Should "SD-WAN" be expanded ? [Linda] “SD-WAN” is defined in Section 2. ## Section 3 `This section identifies some high-level problems that the IETF could address` sounds like the IETF has failed, please rephrase (e.g., using "IETF Technologies"). [Linda] The intent of this statement is not to imply that the IETF has failed, but rather to highlight areas where IETF technologies can be applied or further extended to address emerging challenges. How about the following wording changes: “This section identifies some high-level problems that can be addressed using IETF technologies and ongoing standardization efforts within the Routing area” ## Section 3.1 Should `Public Cloud DCs` be explicitly defined ? [Linda] It is specified in Section 2. `to form an IP adjacency` unsure what IP adjacency means, the adjacency term is often using for a layer-2 link between layer-3 nodes (e.g., OSPF), suggest using iBGP. [Linda] meant to say: “ to form an IP neighbor relationship". More generally, the (valid) recommendations seem to apply to any peering and not really related to cloud DC. [Linda] yes, tunnels are used for GW to be “IP neighbor” to the Cloud GW. ## Section 3.2 Please defined "pod". [Linda] The term "Pod" is commonly used in cloud and data center architectures. However, to ensure clarity, we will add a brief definition: "A pod is a unit of infrastructure within a data center, typically consisting of a group of servers, network devices, and storage that operate as a single managed entity." I will welcome explanations about the 2nd paragraph. [Linda] paragraph 2 is to emphasize that internal error within a Cloud Dc is not visible to external CPEs. I fail to see about EVPN is related to Cloud DC. [Linda] EVPN is mentioned specifically for its mass withdrawal capability, which enables rapid withdrawal of a large number of impacted EVPN routes when a Cloud DC failure occurs. ## Section 3.3 s/with an IP address/with IP addresses/ ? [Linda] IP addresses would work if one instance has multiple addresses. Should the multiple interfaces (3GPP & Wi-Fi) issues be cited ? [Linda] 3GPP reference is used for the edge data centers deployed near cell towers. Not for Wi-fi. ## Section 3.4 Suggest to introduce the acronyms in section 2. [Linda] All the acronyms that appear only once is expanded in the text, while those used multiple time are listed in Section 2. ## Section 3.5 Please note that draft-ietf-add-split-horizon-authority is not about split horizon DNS (even if it is related), please use another reference. [Linda] https://datatracker.ietf.org/doc/draft-ietf-add-split-horizon-authority/14/ Establishing Local DNS Authority in Validated Split-Horizon Environments ## Section 3.6 What is "AWS Direct Connect" ? or even what is "AWS" ? (to be honest, I know but do not expect any IETF reader to know those commercial terms). [Linda] AWS (Amazon Web Services) and AWS Direct Connect are widely recognized terms in cloud networking and are commonly referenced in discussions related to enterprise cloud connectivity. While these terms are used for illustrative purposes, their inclusion helps provide concrete examples of real-world implementations. Thank you very much, Linda
_______________________________________________ rtgwg mailing list -- rtgwg@ietf.org To unsubscribe send an email to rtgwg-le...@ietf.org
