[Int-dir] Intdir early review of draft-ietf-rtgwg-net2cloud-problem-statement-26
Benson Muite via Datatracker <noreply@ietf.org> Sat, 06 May 2023 16:42 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: int-dir@ietf.org
Delivered-To: int-dir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 003D1C151B08; Sat, 6 May 2023 09:42:21 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benson Muite via Datatracker <noreply@ietf.org>
To: int-dir@ietf.org
Cc: draft-ietf-rtgwg-net2cloud-problem-statement.all@ietf.org, rtgwg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 10.2.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <168339134098.50646.426487576555315086@ietfa.amsl.com>
Reply-To: Benson Muite <benson_muite@emailplus.org>
Date: Sat, 06 May 2023 09:42:20 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-dir/o36xK5_sh8qTZ3s9BFlKvZAXnlA>
Subject: [Int-dir] Intdir early review of draft-ietf-rtgwg-net2cloud-problem-statement-26
X-BeenThere: int-dir@ietf.org
X-Mailman-Version: 2.1.39
List-Id: "This list is for discussion between the members of the Internet Area directorate." <int-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-dir>, <mailto:int-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-dir/>
List-Post: <mailto:int-dir@ietf.org>
List-Help: <mailto:int-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-dir>, <mailto:int-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 May 2023 16:42:21 -0000
Reviewer: Benson Muite Review result: Ready with Nits A useful problem statement. Most suggestions below aim 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) May want to examine for draft-ietf-cdni-additional-footprint-types adding location information, though in this case geographic coordinates may be better. 4) 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. 5) Cloud probably does not need to be capitalized in every use when not part of a proper name. 6) Some enterprises/institutions who are not cloud providers may have multiple on premises DC at different sites. They may also have similar problems. 7) 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. 8) May want to explain "Availability Zone" since different cloud providers may use this term in slightly different manners. 9) It may be helpful to add examples from cloud providers headquartered outside the USA. 10) The abbreviation TN in Figure 1 is not defined. 11) Perhaps 'Multi-point-to-Point' to 'multi-point-to-point' 12) MPLS (Multiprotocol Label Switching) is not defined in the document. 13) The abbreviation CPE (Customer Premises Equipment?) in section 4.3 is not defined. 14) May want to use "software application" instead of App 15) As a document not aimed at experts, may wish to reference rfc8926 16) 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. 17) 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. 18) 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.
- [Int-dir] Intdir early review of draft-ietf-rtgwg… Benson Muite via Datatracker