David, We really appreciate your review and comments. Please see below for the resolutions. Sorry for the delayed response. I missed yours when I was going through the comments from other reviewers.
The revision -23 https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/ has addressed the comments from OpsDIR, RTGDIR, DNSDIR and GENART. Changes to your comments will be reflected in the -24 revision. Linda -----Original Message----- From: David Black via Datatracker <[email protected]> Sent: Monday, April 3, 2023 4:13 PM To: [email protected] Cc: [email protected]; [email protected] Subject: Tsvart early review of draft-ietf-rtgwg-net2cloud-problem-statement-22 Reviewer: David Black Review result: Not Ready 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 ([email protected]<mailto:[email protected]>) 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. [Linda] For the MTU introduced by IPsec tunnels, how about adding the following sentences? As described in [Int-tunnels], IPsec tunnels can introduce MTU problems. This document assumes that endpoints manage the appropriate MTU sizes, therefore, not requiring VPN PEs to perform the fragmentation when encapsulating user payloads in the IPsec packets IPsec tunnels are over public internet, which doesn’t support ECN. Why need to mention RFC6040? 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). [Linda] This document describes the network-related problems enterprises face when interconnecting their branch offices with dynamic workloads in third-party data centers (a.k.a. Cloud DCs) and some mitigation practices. It is a list of technologies ranging from VPN to DNS. 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. [Linda] The document is mainly for enterprises that already have traditional VPN services and are interested in leveraging those networks (instead of altogether abandoning them). MPLS (which is now replaced by VPN) is just one example. 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. [Linda] Connecting to Cloud needs BGP, but doesn’t run IGP, EVPN. The intend of the draft is to identify future work in 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. [Linda] The intent of the document is to lay out current mitigation methods and additional work on extension to BGPs, such as https://datatracker.ietf.org/doc/draft-ietf-idr-sdwan-edge-discovery/ 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. [Linda] DNS issues introduced by connecting to Cloud DCs were strongly requested by DNSOps and OpsDIRs. Thank you very much Linda
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
