Joel, Thank you very much for reviewing the document and the valuable feedback.
Please see below for the detailed resolutions. If they are okay with you, we can upload the revision on Monday. Linda -----Original Message----- From: Joel Halpern via Datatracker <[email protected]> Sent: Thursday, July 17, 2025 10:46 AM To: [email protected] Cc: [email protected]; [email protected] Subject: draft-ietf-rtgwg-multisegment-sdwan-04 early Rtgdir review Document: draft-ietf-rtgwg-multisegment-sdwan Title: Multi-segment SD-WAN via Cloud DCs Reviewer: Joel Halpern Review result: Not Ready Hello I have been selected to do a routing directorate "early" review of this draft. https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-rtgwg-multisegment-sdwan%2F&data=05%7C02%7Clinda.dunbar%40futurewei.com%7Cde59685e54d84193978008ddc559be0d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638883711415554778%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0rGQhV01eJsDerr6g1jxCzUIkhF5vlwTPOohcWDo3%2Bg%3D&reserved=0 The routing directorate will, on request from the working group chair, perform an "early" review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft's lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached. This draft describes the extensions to Geneve to enable using it to interconnect multiple SD-WAN segments, with particular attention to the case when the carried payload is IPSec protected. For more information about the Routing Directorate, please see https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.ietf.org%2Fen%2Fgroup%2Frtg%2FRtgDir&data=05%7C02%7Clinda.dunbar%40futurewei.com%7Cde59685e54d84193978008ddc559be0d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638883711415582636%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=rne%2Fx6T0XCvkiaZPqAx%2F6%2BWGFFOY7%2FXs9tPq%2BmBi5G4%3D&reserved=0 Document: draft-ietf-rtgwg-multisegment-sdwan-04 Reviewer: Joel Halpern Review Date: 17-July-2025 Intended Status: Proposed Standard Summary: I have some minor concerns about this document that I think should be resolved before it is submitted to the IESG. I also have one major concern that was flagged by I-D nits. And one major concern where a procedural element does nto sem to work. Major issues: The example topologies use all sorts of IP v4 addresses. It should use exclusively example addresses. And mixing private and public IP addresses in examples is even more confusing. (Note that this problem might be slightly easier to address if all examples were IPv6 instead of IPv4.) [Linda] Changed to use example IP addresses per RFC5737 for all the client addresses attached to CPEs: 192.0.2.0/24 and 198.51.100.0/24; Do you think adding the following Note at the end of the Introduction section would be enough? "Note: All IP addresses used in this document are for illustrative purposes only. They are drawn from address blocks designated for use in documentation as specified in [RFC5737] and [RFC3849], and do not represent real or routable network addresses." Section 4.5 on including specific SD-WAN transitsegments eems an understandable goal. However, it also seems fraught with failure potential. In simple topologies, yes, it works. But suppose that the actual path to the destination is SD-WAN segments A-B-C-D-E. And suppose the include requirement says "B". When the GENEVE packet arrives at the C-D boundary, it says that its path must include B. But the path to the destination from there does not include B. How is the C-D boundary supposed to know that B has alreay been traversed? [Linda] Some SD-WAN deployments require specific transit segments to be included in the end-to-end path for regulatory, security, or service chaining purposes, rather than for path optimization. The Include-Transit Sub-TLV, an optional field, is used to signal such requirements. It allows explicitly specifying a list of Cloud Availability Regions or Zones that a packet must traverse when forwarded through the Cloud Backbone. Minor Issues: The description of SD-WAN in the second paragraph of the introduction could use some clarification. The text reads: "Multi-segment SD-WAN refers to SD-WAN deployments where different segments-such as branch offices, cloud regions, and data centers" But a branch office is a location. It is not an SD-WAN segment. Some set of branch offices might be interconnected by an SD-WAN segment, but that is not what this text says. I think a multi-segment SD-WAN is simply several SD-WAN services from several providers with a means (unclear from whom) to interconnect those SD-WAN services? The text later refers to a backbone network, which seems to imply a more specific structuring for this interconnection. If so, a description or reference would seem appropriate. [Linda] How about revising the second paragraph to the following: Multi-segment SD-WAN refers to deployments where multiple SD-WAN segments-such as those connecting branch CPE to cloud gateways-are used together to form an end-to-end service path. These segments may be independently managed by different service providers, enterprises, or cloud operators. A Cloud Backbone-typically operated by a cloud provider or network service provider-acts as the interconnect fabric that stitches these segments together. This architecture is often necessary when enterprises span multiple geographic regions, use different SD-WAN vendors, or have regulatory constraints requiring segmented traffic management. Section 3.1 reads more as a marketing section for SD-WAN. This draft, as I understand it, is for the case where the customer has already chosen to use an SD-WAN, and wants the added benefits of the GENEVE traffic directing encapsulation. So stick to that. Don't talk about hypothetical stability benefits of SD-WAN as compared with other inter-connection services. [Linda] How about the following text for Section 3.1? Enterprise branches with established SD-WAN paths to a Cloud GW for accessing cloud services can also use the Cloud GW to interconnect with one another, as shown in Figure 1. Stitching SD-WAN segments through a Cloud Gateway provides a way to extend policy enforcement and traffic control across branches, particularly when direct branch-to-branch paths over the public internet are insufficient. This approach is beneficial for several reasons: * The public internet between branches may suffer from limited bandwidth, unpredictable performance, and security risks. * Centralized enforcement of enterprise security policies is possible through cloud-hosted security services (e.g., firewalls, DDoS protection), ensuring consistent treatment of traffic across sites. * Cloud platforms often offer enhanced monitoring, proprietary threat detection tools, and analytics services that can inspect and respond to suspicious traffic crossing segments. Section 4.3 discusses the origin identification sub-TLV. Having such a sub-TLV seems reasonable. However, the text in explaining the reason says "These policies may include routing optimization based on the origin,". I have trouble understanding under what circumstance, given taht the packet is at the processing gateway, knowledge of the origin can enable any more optimal route selection than would otherwise be available. I can understand that paths may be restricted to certain sources by policy, but that is not an optimization. [Linda] How about the following wording changes? Old: These policies may include routing optimization based on the origin, security enforcement tailored to the source, or traffic engineering rules specific to the originating CPE. New: These policies may include traffic engineering rules specific to the originating CPE, security enforcement tailored to the source, or path selection constraints based on the origin. Section 4.4 on the egress gateway identifier again asserts taht allowing the source CPE to specify the egress gateway optimizes path selection. It seems difficult to construct cases where that will optimize, and easy to construct cases where it will make things worse. It may again be desirable for policy reasons. But let's not conflate policy with optimization. [Linda] How about changing the text to the following: Old: This ensures predictable routing and optimized packet delivery across the Cloud Backbone New: This ensures predictable routing behavior and enables policy-driven packet delivery across the Cloud Backbone.. I presume that the processing SD-WAN gateway logic in section 5 includes checking for the SD-WAN option class being present, as this draft does not otherwise apply? Shouldn't the text include that check? [Linda] Good catch. How about adding this sentence to Section 5: The procedures described in this section apply only to packets that carry the SD-WAN Option Class in the GENEVE header. Packets without this option are processed using default forwarding behavior. In section 5, in describing the Ingress GW processing, the text is written as if the outer IP destination address will always become the egress gateway. As I understand it, if the path goes through multiple SD-WAN, the outer IP address at each stage is that of the next gateway? Could the text be rewritten to make that clear. Also, doesn't this imply there is a "transit gateway" case as well as ingress and egress? [Linda] The GENEVE header remains during transit across the Cloud Backbone and is removed by the egress Cloud Gateway before the packet is forwarded to the destination CPE. The packet is forwarded natively on the final SD-WAN segment (egress GW to destination CPE) without GENEVE encapsulation. I do not know if this is a major concern, a minor concern, or merely a confused reviewer. There is a description in section 9 of an attack to steal data service (conceptually, an understandable problem.) However, I am unable to figure out what set of access to what set of places the attacker must have, nor how adding authentication to the CPE / GW exchange would actually help prevent this attack. In part this is because the attack appears underspecified, and in part this is because the remediation appears underspecified. [Linda] does it help to add this sentence to the introduction? In this document, "multi-segment SD-WAN" refers specifically to deployments with two SD-WAN edge segments: one from the originating CPE to the ingress Cloud Gateway, and one from the egress Cloud Gateway to the destination CPE. There may be additional SD-WAN segments or forwarding domains between the ingress and egress Cloud Gateways across the Cloud Backbone, but their internal behavior is out of scope for this specification. Section 11 on IANA consideration should note that IANA has already assigned the code point. Otherwise, specifying the value would be improper. [Linda] Changed.
_______________________________________________ rtgwg mailing list -- [email protected] To unsubscribe send an email to [email protected]
