Ajeet, Thank you very much for the detailed comments. Please see below of the resolutions to your comments and answers to your questions.
Linda From: Ajeet Gill <[email protected]> Sent: Monday, November 3, 2025 6:13 PM To: [email protected] Subject: Mail regarding draft-ietf-rtgwg-multisegment-sdwan Hello Authors, I have reviewed the document and found it to be well-written. However, I have a few comments and questions for further clarification. There may be some gaps in my understanding, so I appreciate your assistance in helping me comprehend them better. Section 1 "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." Q1. Could you clarify how the firewall policy would function in this scenario? Given that the internal traffic is encrypted, it seems that DDoS protection is the primary feasible measure based on the external headers, along with potential malware detection via signature analysis. I understand this should apply to locally destined traffic, meaning traffic that terminates in the cloud rather than being forwarded to another branch. It might be helpful to elaborate on this point. [Linda] Even when traffic remains encrypted, the cloud gateway can still perform several useful security and operational functions based on outer-header information and flow context (e.g., DDoS mitigation, rate limiting, anomaly detection, geolocation controls, traffic steering, SLA/usage analytics). In addition, some CPE-originated traffic may be destined for cloud-resident services, where full decryption and firewall/malware inspection are possible. We can revise the wording to clarify these points: "- Centralized enforcement of enterprise security policies can be enabled through cloud-hosted services. Traffic destined to cloud-resident applications can be decrypted for full inspection (e.g., firewall, threat detection), while CPE-to-CPE traffic that remains IPsec-encrypted can still benefit from header- or flow-based functions-such as DDoS mitigation, rate limiting, anomaly detection, and SLA/usage analytics-especially when the same CPE also sends traffic terminating in the cloud" Q2. Could you clarify how the cloud Gateway (Gw) provides reachability information about the destination Customer Premises Equipment (CPEs) to the branch CPEs? While it is mentioned that this is out of scope for the document, there could be scenarios where some CPEs are connected to the cloud and others are not(network failure conditions), potentially reflecting a dynamic network view. Should this information be managed solely by the Route Reflectors (RRs) within the enterprise domain, or are there additional requirements that must be met by the cloud provider? This situation could lead to error cases. [Linda] Each Cloud GW exchanges routing information only with its directly connected CPEs. End-to-end (CPE-to-CPE) reachability is handled by the enterprise's own iBGP system (e.g., via RRs), not by the Cloud GWs. How a CPE discovers or learns its directly connected Cloud GWs is outside the scope of this document. A separate draft describes a mechanism for CPEs to exchange the identity of their connected Cloud GWs (https://datatracker.ietf.org/doc/draft-sheng-idr-gw-exchange-in-sd-wan/ ); however, that mechanism is not required here and is intentionally not covered in this document. Q3.I understand the requirements for GENEve processing on ingress and egress Gateways (GWs). However, are there any specific requirements for transit gateways in the cloud, or do they function solely as pure forwarders? I am trying to comprehend the setup of the path within the cloud backbone. The goal seems to be - establish an internal path in the cloud backbone based on the hints in the original packet. This would necessitate a path setup in the cloud backbone ( possible by the ingress GW), with the data path actually following that route. It might be beneficial to clarify this point. Should each transit router in the hop change the destination IP in the outer header? [Linda] Only the ingress Cloud Gateway performs GENEVE processing. How the cloud service provider forwards packets across its internal backbone-e.g., path selection, encapsulation changes, and traffic-engineering behaviors-is entirely under the provider's control and outside the scope of this document. This document assumes only that packets will be delivered to the desired egress GW (explicitly listed in the sub-TLV) or to the Cloud GW that is closest to the destination CPE. Q4. "Section 7.1" How would the IPsec SAs parameters between CPEs and Cloud GWs be exchanged through iBGP ? Did you mean to say between CPEs? [Linda] The IPsec SA parameters between a CPE and its Cloud GW are established out-of-band (e.g., via management/automation systems) or via IKEv2. There may be an eBGP session between the CPE and its Cloud GW, but iBGP is used only to exchange reachability among CPEs; it is not used for SA negotiation. Q5. Also case of multi-egress GWs , are there going to be plurality of paths to choose from for the ingress GW? [Linda] Yes. The whole point of SD-WAN is to aggregate multiple underlay paths and make them available for optimized forwarding. When multiple egress GWs are reachable, the ingress GW may have multiple viable paths to choose from. The selection among them (e.g., based on policy, performance, or metadata) is part of the SD-WAN decision process. The document does not mandate a specific algorithm; it only enables the signaling needed to support such choices. Thanks and Best Regards, Ajeet
_______________________________________________ rtgwg mailing list -- [email protected] To unsubscribe send an email to [email protected]
