[rtgwg] Re: Mail regarding draft-ietf-rtgwg-multisegment-sdwan

[Ajeet Gill <[e-mail]>]

Hi Linda,

Appreciate the detailed answers and thoughtful clarifications you've provided throughout our exchange. Your insights have helped clarify several aspects of the draft, especially around the roles of Cloud Gateways and the scope of SD-WAN path selection mechanisms.
I have a few further thoughts  marked as [Ajeet2].

Thanks,
Ajeet


________________________________
From: Linda Dunbar <[e-mail]>
Sent: Wednesday, November 12, 2025 12:44 PM
To: Ajeet Gill <[e-mail]>; [e-mail] <[e-mail]>
Cc: RTGWG <[e-mail]>
Subject: [EXTERNAL] RE: Mail regarding draft-ietf-rtgwg-multisegment-sdwan

You don't often get email from [e-mail]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>

Ajeet Gill,



Please see below the answers to your questions marked by [Linda2].



Linda



From: Ajeet Gill <[e-mail]>
Sent: Tuesday, November 11, 2025 10:26 PM
To: Linda Dunbar <[e-mail]>; [e-mail]
Cc: RTGWG <[e-mail]>
Subject: Re: Mail regarding draft-ietf-rtgwg-multisegment-sdwan





Hi Linda,

 Thanks for clarification and your responses. I agree to your proposed update on the first point.

I have further thoughts for the remaining points as well. Please see inline.



Thanks

Ajeet





________________________________

From: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Sent: Friday, November 7, 2025 4:26 PM
To: Ajeet Gill <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: RTGWG <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] RE: Mail regarding draft-ietf-rtgwg-multisegment-sdwan



You don't often get email from [e-mail]<mailto:[e-mail]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>

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 <[e-mail]<mailto:[e-mail]>>
Sent: Monday, November 3, 2025 6:13 PM
To: [e-mail]<mailto:[e-mail]>
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”



 [Ajeet] - This looks good to me Linda.  Thanks for clarification.



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.



[Ajeet] Thanks for clarification Linda.  I understand that this in the scope of https://datatracker.ietf.org/doc/draft-sheng-idr-gw-exchange-in-sd-wan/

 Which talks about how to convey the cloud gw information , but that draft is silent on discovery of cloud GWs. But point taken, will review that draft separately for further clarification.



[Linda2] How CPE discover its closest Cloud GW is out of the scope of draft-ietf-rtgwg-multisegment-sdwan. It can be by configuration or protocol for the CPEs to discover its closest Cloud GW.





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.



[Ajeet] - I see. I was under the impression that source CPE can indicate the path to cloud GW ( in terms of regions to be traversed). In such case, Cloud GW should follow the guideline and the setup the path accordingly.

It may also be worth mentioning cloud gw will provide an SLA'ed path between ingress and egress GW. For example in the Azure world it would probably mean setting up overlay tunnel between ingress/egress Cloud Gws such that packet can carry the metadata(Geneve options) for egress to process.



[Linda2] That’s a good point. However, the SLA-based path setup between ingress and egress Cloud GWs is entirely under the cloud provider’s internal control. Each provider implements its own mechanisms for traffic engineering, tunnel setup, and SLA enforcement within its backbone, and these behaviors are not standardized or visible outside the provider domain. Therefore, it’s neither practical nor meaningful for the IETF to standardize such internal behaviors. From the enterprise side, a CPE can explicitly list excluded regions or specify preferred regions through sub-TLVs when selecting its associated Cloud GWs. Beyond that, how the cloud provider establishes and manages the path within its backbone remains proprietary and outside the scope of this document.



[Ajeet2] I agree that the cloud provider would handle its own traffic engineering within the constraints provided by the CPEs. These constraints are typically specified in terms of regions. Could you also clarify if other SLA parameters, such as bandwidth, latency, and jitter, would be managed out-of-band? Additionally, I believe Cloud GWs be responsible for performing traffic policing/metering as well? These parameters are usually exchanged using RR in SDWAN implementations.


 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.



[Ajeet] - The following statement confuses me -

"Additionally, IPsec SAs parameters between   CPEs and Cloud GWs can be exchanged through the iBGP control   plane using a RR to simplify security policy management.

"

I understood that CPE <-> Cloud GW IPSec is established using out-of-band mechanism or IKEv2.

Let me know if I understood it wrong. I believe the correct statement could be :

"Additionally, IPsec SAs parameters between  participating CPEs  can be exchanged through the iBGP control   plane using a RR to simplify security policy management."



[Linda2] You understood correctly. The IPsec SAs between a CPE and its Cloud GW are established using out-of-band mechanisms or IKEv2, not via iBGP. The intent of that sentence was to describe that iBGP may help distribute reachability or policy information among CPEs, not the SA parameters themselves. How about we revise the second paragraph of Section 7.2  to the following:



“When the connection between a CPE and a Cloud GW traverses a public or otherwise untrusted network, an IPsec tunnel may also be established to secure that traffic. In such cases, the IPsec Security Association (SA) parameters between the CPE and its corresponding Cloud GW are established out-of-band (e.g., via management or automation systems) or negotiated dynamically using IKEv2”

 [Ajeet2] Thanks. I agree to your proposed revision to section 7.2 to bring clarity.  This should help.  However I think last paragraph in section 7.1 may also be clarified further.


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.



[Ajeet]  I see. Thanks for clarification.  So for SDWAN path selection(end-to-end) cloud GW also needs to play its part.  Should not this be mentioned as well. Cloud Gw needs to do some sort of SDWAN path management logic to select path.  And it should course adjust itself for end-to-end SLA.



[Linda2] A Cloud GW that supports SD-WAN services is indeed expected to perform its own path optimization or selection across available underlays to meet SLA objectives—this may include traffic steering, performance monitoring, or dynamic adjustment within the provider domain. That said, the mechanisms by which a Cloud GW chooses or adjusts its internal path are proprietary and outside the scope of IETF standardization.





Thanks and Best Regards,

Ajeet