David, Thank you thank you very much.
Do you think it is better to say: "when the Explicit Congestion Notification - ECN [RFC6040] is used by the network traffic through the private VPN,.."? Really appreciate your help. Linda From: Black, David <[email protected]> Sent: Wednesday, April 19, 2023 8:19 PM To: Linda Dunbar <[email protected]>; [email protected] Cc: [email protected]; [email protected]; Black, David <[email protected]> Subject: RE: ECN [RFC6040] reference for IPsec tunneling to Cloud GW (RE: Tsvart early review of draft-ietf-rtgwg-net2cloud-problem-statement-22 Hi Linda, I think that's close enough - I might edit it to: If Explicit Congestion Notification - ECN [RFC6040] is used by network traffic on the private VPN, then the PEs that establish the IPsec tunnels with the Cloud GW need to follow the behavior specified by RFC6040 [RFC6040]. That initial "If ... private VPN" language may engender additional comments later on, but at least ECN is now discussed, so that'll be ok for now. Thanks, --David From: Linda Dunbar <[email protected]<mailto:[email protected]>> Sent: Wednesday, April 19, 2023 5:36 PM To: Black, David; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: ECN [RFC6040] reference for IPsec tunneling to Cloud GW (RE: Tsvart early review of draft-ietf-rtgwg-net2cloud-problem-statement-22 [EXTERNAL EMAIL] David, How about adding the following description when a Private VPN PE needs to establish IPsec tunnels to Cloud WG? If the Explicit Congestion Notification - ECN [RFC6040] is enabled by the private VPN, the PEs that establish the IPsec tunnels with the Cloud GW needs to follow the behavior specified by the RFC6040. Please see the revision -25 with the update that addresses your previous comments. https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/ [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/__;!!LpKI!nX-ripPjJ_jhagFEzUcU0otxoUIBDP7nlwOrfP9JmNK9LLkrxIRDZVqISC5pKwCCf1JRUMoDVKMeMONwfktWamBxaA$> Thank you very much, Linda From: Black, David <[email protected]<mailto:[email protected]>> Sent: Monday, April 17, 2023 9:33 AM To: Linda Dunbar <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Black, David <[email protected]<mailto:[email protected]>> Subject: RE: Tsvart early review of draft-ietf-rtgwg-net2cloud-problem-statement-22 Two remaining concerns from this discussion: >>> IPsec tunnels are over public internet, which doesn't support ECN. Why need >>> to mention RFC6040? >> David> Disagree - L4S (on which a lot of recent work has been expended in >> TSVWG) is absolutely intended for deployment over the public Internet and >> uses ECN. > [Linda] None of Cloud DCs have implemented ECN. I am afraid ECN is not > relevant to connecting on-prem workloads with Cloud DCs. Firmly disagree - L4S (see RFCs 9330, 9331 and 9332) is likely to be implemented for traffic to/from Cloud DCs. A "not relevant" statement for ECN (which implies never will be relevant) is not acceptable. >> David> The MPLS -> VPN change should help in the revised draft. Are only >> BGP-based VPNs in scope here, or is the intended scope broader? > [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. I still don't understand the purpose of publishing this document (e.g., intended audience, what they and/or the IETF are intended to do as a result of reading this document), and the rationale for IETF publishing it, but that's not a Transport-specific concern. Thanks, --David From: Linda Dunbar <[email protected]<mailto:[email protected]>> Sent: Friday, April 14, 2023 4:08 PM To: Black, David; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: RE: Tsvart early review of draft-ietf-rtgwg-net2cloud-problem-statement-22 [EXTERNAL EMAIL] David, Thank you very much for the continued comments. Please see resolutions below. Linda From: Black, David <[email protected]<mailto:[email protected]>> Sent: Friday, April 14, 2023 2:38 PM To: Linda Dunbar <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Black, David <[email protected]<mailto:[email protected]>> Subject: RE: Tsvart early review of draft-ietf-rtgwg-net2cloud-problem-statement-22 Hi Linda, Thanks for taking a look at this. David> More comments inline ... Thanks, --David From: Linda Dunbar <[email protected]<mailto:[email protected]>> Sent: Friday, April 14, 2023 1:24 PM To: Black, David; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: RE: Tsvart early review of draft-ietf-rtgwg-net2cloud-problem-statement-22 [EXTERNAL EMAIL] 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/ [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/__;!!LpKI!lq0Czbr76Sn1cIp3jl8U_jOm2JnKm5AFw-ISnZwQmk-h00yPL6jrwXDZiPqHSuzr4yjtgi6t1pt0gjkoHcuKO7TqGA$> 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]<mailto:[email protected]>> Sent: Monday, April 3, 2023 4:13 PM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[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 David> Ok, it might be a slight improvement to change "assumes" -> "recommends". [Linda] Good suggestion. Change for Revision-25. IPsec tunnels are over public internet, which doesn't support ECN. Why need to mention RFC6040? David> Disagree - L4S (on which a lot of recent work has been expended in TSVWG) is absolutely intended for deployment over the public Internet and uses ECN. [Linda] None of Cloud DCs have implemented ECN. I am afraid ECN is not relevant to connecting on-prem workloads with Cloud DCs. 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. David> I don't understand how to reconcile that statement with the statement below that "The intend of the draft is to identify future work in BGP." [Linda] I am sorry for the confusion. The section 3.1 identifies the issues of increased BGP peering errors such as capability mismatch, unwanted route leaks, missing Keepalives, and errors causing BGP ceases. All those errors can cause BGP sessions to be terminated. Hopefully in the future, BGP can send some in-band notifications so that the peers are notified before the sessions are terminated. 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. David> The MPLS -> VPN change should help in the revised draft. Are only BGP-based VPNs in scope here, or is the intended scope broader? [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. When connecting to Cloud DCs, IGP is not used. 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. David> Latter sentence on "future work in BGP" would be good to add to the draft, and it would be good to state the EGP role/usage of BGP, excluding the other roles. [Linda] Please see comments above. 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/ [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-idr-sdwan-edge-discovery/__;!!LpKI!lq0Czbr76Sn1cIp3jl8U_jOm2JnKm5AFw-ISnZwQmk-h00yPL6jrwXDZiPqHSuzr4yjtgi6t1pt0gjkoHcun5DTeGg$> David> See previous comment. 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. David> But how do they relate to "future work on BGP"? [Linda] I typed in a rush. The document is not limited to BGP. Thank you very much Linda
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
