Early Review of draft-ietf-rtgwg-net2cloud-problem-statement-22
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 (firstname.lastname@example.org) 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.