Skip to main content

Early Review of draft-ietf-rtgwg-net2cloud-problem-statement-22
review-ietf-rtgwg-net2cloud-problem-statement-22-opsdir-early-hares-2023-04-10-00

Request Review of draft-ietf-rtgwg-net2cloud-problem-statement-19
Requested revision 19 (document currently at 42)
Type Early Review
Team Ops Directorate (opsdir)
Deadline 2023-04-09
Requested 2023-03-06
Requested by Jeff Tantsura
Authors Linda Dunbar , Andrew G. Malis , Christian Jacquenet , Mehmet Toy , Kausik Majumdar
I-D last updated 2023-04-10
Completed reviews Secdir Last Call review of -36 by Deb Cooley (diff)
Tsvart Last Call review of -32 by Magnus Westerlund (diff)
Intdir Early review of -26 by Benson Muite (diff)
Secdir Early review of -22 by Deb Cooley (diff)
Genart Early review of -21 by Paul Kyzivat (diff)
Opsdir Early review of -22 by Susan Hares (diff)
Rtgdir Early review of -22 by Ines Robles (diff)
Tsvart Early review of -22 by David L. Black (diff)
Dnsdir Early review of -22 by Florian Obser (diff)
Dnsdir Last Call review of -41 by David C Lawrence (diff)
Rtgdir Early review of -41 by Shuping Peng (diff)
Secdir Early review of -41 by Mike Ounsworth (diff)
Artart Last Call review of -41 by Rich Salz (diff)
Comments
Dear colleagues,

RTGWG chairs would like to begin an early review process for the draft.

Thanks,
Yingzhen & Jeff
Assignment Reviewer Susan Hares
State Completed
Request Early review on draft-ietf-rtgwg-net2cloud-problem-statement by Ops Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/9ash68RoltQDA6kOKZ725UgoYOM
Reviewed revision 22 (document currently at 42)
Result Has issues
Completed 2023-04-10
review-ietf-rtgwg-net2cloud-problem-statement-22-opsdir-early-hares-2023-04-10-00
I have read this document, sec-dir early review, rtg-dir, and tsv-dir early
review. I am not a Cloud or Inter-Cloud expert.  I am familiar with BGP and
MPLS technology.

I have marked this has issues just as the rtg-dir review (Ines Robles) has
marked this "has issues" due to missing references. These reviews deal with
editorial issues and not substantial technical issues.

Technical issues:
1) I think the security issues listed in section 7 should include a reference
to section 5 on the scaling. 2) Security issues in section 3 seem to be limited
to 3.5 3) operational issues are covered in the remainder of section 3.0

Editorial issues:
The textual issues that the rtg-dir (Ines Robles_ mentioned seem to be mostly
editorial issues.

My unique editorial comments [hares-comments] are included with the comments
from rtg-dir I agree withy:

[rtg-dir] Abstract: "today" --> "at the moment of writing this specification" ?
[hares] Abstract: /old text:  Here are some examples of cloud network functions:
Virtual Firewall services, Virtual Private network services, Virtual PBX
services including voice and video conferences, etc./
 /new text:  Examples of cloud network functions are: Virtual Firewall services,
Virtual Private network services, or Virtual PBX services including
voice and video conferences./

[rtg-dir] Section 1: The abstract mentions that the problems are related to
MPLS, but the introduction does not mention it. Furthermore, it would be nice
to explain why these 8 problems (Section 3) were selected in relation with
MPLS. [rtg-dir] Section 2, VPC: "... Most Cloud operators' VPCs only
support...." --> "at the moment of writing this specification, most Cloud
operators' VPCs only support...." ?

- Section 3:
[rtg-dir] * " There are many problems associated with connecting to hybrid
Cloud" --> "... connecting to Cloud DCs" ? In this way, it is aligned with the
title. - Section 3.1: [rtg-dir] * "it MUST ignore..." --> it must ignore ... ?
[rtg-dir] * "BGP session MUST NOT ..." --> BGP session must not ...? [Hares]
Old Text:/ All of these can contribute to increased BGP peering errors, such as
capability mismatch, BGP ceasing notification, unwanted route leaks, missed
Keepalives, etc. / New Text :/ All of these can contribute to increased BGP
peer errors such as capability mismatch, unwanted route leaks, missed
Keepalives, and errors causing BGP ceases./

- Section 3.2:
[rtg-dir]* "BFD" --> Bidirectional Forwarding Detection (BFD) ?
[rtg-dir]* What means a site capacity goes dark?
[hares replacement] old text/dark/ New text/dark (capacity goes to zero)/
[hares edit]
Old text/ Site failures include, but not limited to, a site capacity
   degradation or entire site going down caused by a variety of
   reasons, such as fiber cut connecting to the site or among pods
   within the site, cooling failures, insufficient backup power, cyber
   threat attacks, too many changes outside of the maintenance window,
   etc. /
New text/  Site failures can include (but are not limited to) a site capacity
   degradation or entire site going down.  The reasons for these capacity
   degradations or failures can include: a) fiber cuts for links connecting to
   the site or among pods within the site, b) cooling failures, c) insufficient
   backup power, d) cyber threat attacks, e) too many changes outside of the
   maintenance window, or other errors. /

- Section 3.4:
[rtg-dir] * It would be nice to add a reference to 5G, specially when mentions
the 5G core functions [rtg-dir] * Does the mentioned problems and mitigations
applies for 5G Standalone and Non-Standalone deployments options? [hares]old
text/The 5G Core functions include Radio
   Control Functions, Session Management Functions (SMF), Access
   Mobility Functions (AMF), User Plane Functions (UPF), etc./
New text/The 5G Core functions include Radio
   Control Functions, Session Management Functions (SMF), Access
   Mobility Functions (AMF), User Plane Functions (UPF), and others./

- Section 3.5:
 [hares] Old text/ cloud edge resources. [tab]To mitigate such
 security risk, it is necessary for the ports facing the internet
to enable Anti-DDos features. /
 New text/ cloud edge resources. To mitigate such
 security risk, it is necessary for the ports facing the internet
to enable Anti-DDos features. /
[rtg-dir][hares]
Old text/More diligent security procedures need to be considered to mitigate
   all those security issues/
New text/Additional Internet security procedures need to be designed
that are able to to mitigate all these issues./

- Section 3.7:
[rtg-dir][hares] suggestion to add the URL as a reference rather
than a inline comment:
(https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-
   nat-gateway.html#nat-gateway-other-services)

[hares] It might also be good to provide references to Google's Cloud NAT,
Goggle /cold virtual machine (VM), and Google Kubernetes Engine (GKE).

- Section 4.1
[hares] it might be useful to provide references to the
services referenced for Amazon, Microsoft, and Google.

Positive: The diagram helps this text.

section 4.2
page 13, please check the spacing after a), b), and c).
It appears in my printout that there are extra spaces.

section 4.3
[hares] in this text, the last phrase is confusing:
 text/ As MPLS VPNs provide
   more secure and higher quality services, it is desirable to locate
   the PEs with the least cost (including routing distance and capacity
   cost) for the dynamic IPsec tunnels to the Cloud DC GW./

   Do you mean that these dynamic IPsec tunnels should be on the Cloud DC GW?

 Section 5.1
[hares]
old text/
   To scale the IPsec key management, a solution like group encryption
   where a single IPsec SA is necessary at the GW can be considered.
   But the drawback is key distribution and maintenance of a key
   server, etc./
New text/
   To scale the IPsec key management, a solution like group encryption
   where a single IPsec SA is necessary at the GW can be considered.
   The drawback of group encryption solutions is the key distribution for
   group encryption which requires protocols and a maintenance of a key server.
   Other mechanisms, might be operationally better this situation/

Section 5.2
Old Text/
   When large number of IPSec encap & decap are needed, the performance
   is degraded. /
 New text/
   When large numbers of IPSec encapsulation and decapsulation sequences
   are needed, the performance is degraded./