Thanks, Ajeet. We will review your thoughts and questions and get back to you accordingly.
Added RTG WG mailer for archiving purposes. Thanks, Kausik From: Ajeet Gill <[email protected]> Sent: Monday, November 3, 2025 6:13 PM To: [email protected] Subject: [External] : 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. 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. 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? 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? Q5. Also case of multi-egress GWs , are there going to be plurality of paths to choose from for the ingress GW? Thanks and Best Regards, Ajeet Confidential - Oracle Internal
_______________________________________________ rtgwg mailing list -- [email protected] To unsubscribe send an email to [email protected]
