Transport Area Review:

        Dynamic Networks to Hybrid Cloud DCs: Problem Statement and
                           Mitigation Practices
              draft-ietf-rtgwg-net2cloud-problem-statement-22

Reviewer: David L. Black (david.black@dell.com)
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.