[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.