Skip to main content

Early Review of draft-ietf-rtgwg-net2cloud-problem-statement-22

Request Review of draft-ietf-rtgwg-net2cloud-problem-statement-19
Requested revision 19 (document currently at 30)
Type Early Review
Team Transport Area Review Team (tsvart)
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-03
Completed reviews 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)
Dear colleagues,

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

Yingzhen & Jeff
Assignment Reviewer David L. Black
State Completed
Review review-ietf-rtgwg-net2cloud-problem-statement-22-tsvart-early-black-2023-04-03
Posted at
Reviewed revision 22 (document currently at 30)
Result Not ready
Completed 2023-04-03
Transport Area Review:

        Dynamic Networks to Hybrid Cloud DCs: Problem Statement and
                           Mitigation Practices

Reviewer: David L. Black (
Date: April 3, 2023
Result: Not Ready

From a Transport Area perspective, there's not a lot of relevant content in this draft.
Section 5 mentions IPsec tunnels, which raise the usual transport-related concerns in
dealing with tunnels.  Those concerns can be primarily addressed by citing appropriate
references, e.g., MTU concerns are discussed in the tunnels draft in the intarea
WG, and ECN propagation is covered by RFC 6040 plus the related update draft for
shim headers in the TSVWG working group.  I don't see any serious problems here.

OTOH, from a broader perspective, the draft is not a coherent problem statement -
it discusses a plethora of technologies ranging from MPLS to DNS, often without
making any connections among them (e.g., section 6 identifies policy management
as a requirement, but there's no discussion of policies that require management
elsewhere in the draft).

I'm not even sure what the scope of the draft is, e.g.:

a) The abstract states that the draft is "mainly for enterprises that already have
traditional MPLS services and are interested in leveraging those networks," but section
3.4 discusses 5G Edge Clouds, which are rather unlikely to use MPLS.

b) There are at least three roles for BGP in this draft that are not disambiguated -
IGP, EGP, and VPN routing protocol for MPLS-based VPNs, e.g., EVPN.  Section 4
would be a good place to clarify this by describing the Gateway interfaces in
detail, including the role of BGP.

In its current form, I don't understand the target audience or purpose of this draft,
especially the head-spinning mixture of topics in section 3, so I cannot recommend
IETF publication of the draft in its current form.

Perhaps the draft ought to be focused and organized around extending and/or using
MPLS and MPLS-based VPNs - much of the material in Sections 4 and 5 would be
applicable, and some of the worst of section 3's distractions (e.g., 5G, DNS)
could be avoided or at least scoped to the relevant VPN technologies.