Ketan, and Med, Your latest suggestions have been incorporated into the v36: https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/
Hope we have resolved all the issues. Thank you very much. Linda -----Original Message----- From: Linda Dunbar <[email protected]> Sent: Wednesday, May 27, 2026 10:29 AM To: [email protected]; The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: RE: Mohamed Boucadair's Discuss on draft-ietf-bess-bgp-sdwan-usage-31: (with DISCUSS and COMMENT) Med, Thank you for the additional suggestions. Please see the proposed resolutions below marked by [Linda3]. Linda From: [email protected] <[email protected]> Sent: Tuesday, May 26, 2026 11:46 PM To: Linda Dunbar <[email protected]>; The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: RE: Mohamed Boucadair's Discuss on draft-ietf-bess-bgp-sdwan-usage-31: (with DISCUSS and COMMENT) Hi Linda, Thanks for the changes made in -34. Please see inline. Cheers, Med De : Linda Dunbar <[email protected]<mailto:[email protected]>> Envoyé : mercredi 27 mai 2026 07:22 À : BOUCADAIR Mohamed INNOV/NET <[email protected]<mailto:[email protected]>>; The IESG <[email protected]<mailto:[email protected]>> Cc : [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Objet : [iesg] Re: Mohamed Boucadair's Discuss on draft-ietf-bess-bgp-sdwan-usage-31: (with DISCUSS and COMMENT) Med, Thank you for the additional comments and the suggestions. Please see the proposed resolutions below marked by [Linda2] p.s. I've made some changes to address additional comments from Ketan. Linda From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Sent: Tuesday, May 26, 2026 1:32 AM To: Linda Dunbar <[email protected]<mailto:[email protected]>>; The IESG <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: RE: Mohamed Boucadair's Discuss on draft-ietf-bess-bgp-sdwan-usage-31: (with DISCUSS and COMMENT) Hi Linda, Thank you for the follow-up. I also checked iddiff?url1=draft-ietf-bess-bgp-sdwan-usage-31&url2=draft-ietf-bess-bgp-sdwan-usage-33, I like the changes made so far. Please see inline. Cheers, Med De : Linda Dunbar <[email protected]<mailto:[email protected]>> Envoyé : jeudi 21 mai 2026 03:23 À : BOUCADAIR Mohamed INNOV/NET <[email protected]<mailto:[email protected]>>; The IESG <[email protected]<mailto:[email protected]>> Cc : [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Objet : RE: Mohamed Boucadair's Discuss on draft-ietf-bess-bgp-sdwan-usage-31: (with DISCUSS and COMMENT) Med, Thank you very much for the detailed comments. Please see below of our resolutions marked by [Linda]. Linda -----Original Message----- From: Mohamed Boucadair via Datatracker <[email protected]<mailto:[email protected]>> Sent: Wednesday, May 20, 2026 12:57 AM To: The IESG <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Mohamed Boucadair's Discuss on draft-ietf-bess-bgp-sdwan-usage-31: (with DISCUSS and COMMENT) Mohamed Boucadair has entered the following ballot position for draft-ietf-bess-bgp-sdwan-usage-31: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi Linda, Ali, John, Basil, and Sue, Thank you for the effort put into this document. Thanks to Luis Miguel Contreras for the detailed OPSDIR review and to the authors for engaging and making changes. Given the intended Informational status of the document, I will focus on high level comments: # Lack of clear reference deployment model It is not clear to me which BGP sessions we are referring to nor why an underly PE will be involved in arrangements with an external SD-WAN provider. SD-WAN can be offered without coordination with PEs of underlying networks. There are maybe deployment assumptions that are not called out it here. Absent a clear deployment context, it is really hard (at least to me) to digest what is stated in several sections (e.g., 3.1.1). [Linda] The reference deployment models are described in the Scenario sections, specifically Sections 3.2, 3.3, and 3.4. Would the following wording change at the end of the first paragraph of Section 3 address your concern? [Med] These sections are too deep in the structure and require an effort to graft various pieces. Can we please have a description of the reference deployment model early in the document (preferably, right after the introduction)? Please consider clarifying in that section why/when an underly PE needs to be part of an SD-WAN arrangement. [Linda2] To make the reference deployment models easier to find and clarify the PE's role in VPN PE based SD-WAN, we propose the following wording changes? Introduction: last paragraph (after changes to Ketan's comments): Old: This document captures the SD-WAN scenarios, control-plane behaviors, and forwarding considerations when BGP is used as the SD-WAN overlay control plane. New: This document captures the SD-WAN scenarios described in Sections 3.2, 3.3, and 3.4, along with the control-plane behaviors and forwarding considerations when BGP is used as the SD-WAN overlay control plane. Section 3.4, first paragraph: Old: Private VPN PE-Based SD-WAN refers to extending an existing VPN (e.g., EVPN [RFC7432] or IPVPN) by adding additional ports that face the public Internet to address increased bandwidth requirements between Provider Edge (PE) devices. This approach allows VPN service providers to augment their networks without immediately committing to building or leasing new infrastructure. New: Private VPN PE-Based SD-WAN refers to extending an existing VPN (e.g., EVPN [RFC7432] or IPVPN) by adding additional ports that face the public Internet to Provider Edge (PE) devices. In this scenario, the PE is part of the SD-WAN edge function, enabling selected traffic to be offloaded over the public Internet to address increased bandwidth requirements between PE devices. This approach allows VPN service providers to augment their networks without immediately committing to building or leasing new infrastructure. [Med] ACK. New: Sections 3.2, 3.3, and 3.4 describe potential SD-WAN deployment scenarios, which are further explored in subsequent sections to illustrate how the BGP control plane can be used to distribute reachability and policy information within SD-WAN overlay networks. Old: These scenarios serve as examples that are further explored in subsequent sections to illustrate how the BGP control plane is used to distribute reachability and policy information within SD-WAN overlay networks. ## In the same vein, it is not clear to me whether this is documenting what is deployed as suggested by this sentence? CURRENT: By documenting how these mechanisms are used in SD-WAN deployments, this document ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ enables consistent interpretations and supports interoperability without defining new protocols. Do you confirm that [SD-WAN-Discovery] in particular is implemented and deployed as described in this document? [Linda] Yes. the IDR implementation report for [SD-WAN-Discovery] is documented here: https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-sdwan-edge-discovery [Med] Thanks. My concern was that the OLD text says that these "these mechanisms are used in SD-WAN deployments". I see that you deleted that text. Thanks. Likewise, do you confirm that these are deployed today: [Linda] I am afraid that I cannot comment on specific deployment status, as that may be confidential. The statement is intended as a requirement for the BGP-controlled SD-WAN model described in this document. [Med] I consider this point closed as the text was deleted. CURRENT: An SD-WAN edge must use a secure channel, such as TLS following BCP195[RFC9325] or Ipsec [RFC4301], to its designated RR for exchanging BGP UPDATE messages. [Med] I also see that you reworded this, which I think is better that the OLD. # Disconnect between the claimed scope vs. content ## The document deviates from the goal set (BGP-based control) and includes tangential material (e.g., onboarding, forwarding, etc.). For example, how the ZTP discussion is relevant here? Does it inform decisions about the BGP control part? Idem for the onboarding. For the forwarding part, is there any difference between how forwarding is done with proprietary control plane vs. BGP? Unless there are specifics, I suggest the main document to be trimmed to serve its claimed purpose. [Linda] Similar to EVPN usage/applicability documents such as RFC8388, some provisioning, onboarding, and forwarding context is included to explain how the BGP-distributed information is applied in actual service scenarios. The ZTP/onboarding discussion explains how an SD-WAN edge obtains the controller/RR information and secure connectivity needed before BGP UPDATEs can be exchanged. The forwarding sections illustrate how BGP-distributed reachability, tunnel attributes, Route Targets, and policy information are consumed by SD-WAN edges; they do not define a new forwarding architecture. How about we trim the wording in the following way: * In Section 3.1.4, replace the detailed ZTP text with the following shorter text: "SD-WAN Zero-Touch Provisioning (ZTP) allows an SD-WAN edge to obtain initial configuration without manual intervention. In the context of this document, the relevant ZTP function is that the edge obtains the information needed to authenticate to the SD-WAN controller/RR and establish a secure channel for exchanging BGP UPDATE messages. Detailed ZTP mechanisms are outside the scope of this document." * In Section 6, replace the opening sentence: OLD: "This section describes how client traffic is forwarded in a BGP Controlled SD-WAN for the use cases described in Section 3." NEW: "This section briefly illustrates how BGP-distributed reachability, tunnel attributes, Route Targets, and policy information are used by SD-WAN edges when forwarding client traffic in the scenarios described in Section" [Med] Thanks. I see that you shortened the ZTP text, which is great. However, it is not clear to me whether there are aspects that are specific to BGP or these are generic matters. If there are no specifics, can we please have a statement that says so? (my preference would be to move such material to an appendix), but I would be fine also if we provide readers with clear cautions. [Linda2] agree. How about the following wording changes? For Section 3.1.4, we propose the following changes: Old: SD-WAN Zero-Touch Provisioning (ZTP) allows an SD-WAN edge to obtain initial configuration without manual intervention. In the context of this document, the relevant ZTP function is that the edge obtains the information needed to authenticate to the SD-WAN controller/RR and establish a secure channel for exchanging BGP UPDATE messages. Detailed ZTP mechanisms are outside the scope of this document. New: SD-WAN Zero-Touch Provisioning (ZTP) allows an SD-WAN edge to obtain initial configuration without manual intervention. ZTP and onboarding procedures are not specific to BGP and are outside the scope of this document. In the context of this document, the only ZTP-related aspect is that the SD-WAN edge obtains the information needed to authenticate to the SD-WAN controller/RR and establish a secure channel for exchanging BGP UPDATE messages.. [Med] Thanks. What about the other part of my comment: "forwarding behavior" (Section 6)? Is there anything in that section that is specific to BGP and can't be applicable when proprietary control planes are used? If nothing specific, then please add a statement such as "The forwarding behavior described in this section is not specific to BGP-based control; it is provided here for completeness" or similar. [Linda3] Sorry for missing this one. How about adding the following wording to the end of the first paragraph of Section 6? The forwarding behavior described in this section is not specific to BGP-based control and is provided here only to show how the BGP-distributed information is consumed by SD-WAN edges." ## Operational Challenges CURRENT: Although BGP and IPsec are mature technologies, applying them to SD-WAN introduces challenges such as scalability, segmentation, and multi-homing. Putting aside that it is not easy to find a single place which each of these are discussed, the document includes inconsistent statements. For example, the document concludes with the following after discussing BGP/IPsec: This model emphasizes simplicity and efficiency, leveraging centralized governance to mitigate risks while ensuring scalability and interoperability of the SD-WAN. but the main body states: This approach may have scalability implications due to per-destination packet replication; optimization mechanisms are outside the scope of this document. [Linda] The two uses of "scalability" refer to different aspects: the last sentence of the Security Consideration (i.e. "This model emphasizes simplicity and efficiency, ..") is intended to refer to the scalability of the BGP/RR-based control-plane distribution, while the multicast text refers to data-plane scalability implications caused by per-destination packet replication. To make this distinction clearer, how about the following changes to the last sentence of the Security Considerations section: OLD: "This model emphasizes simplicity and efficiency, leveraging centralized governance to mitigate risks while ensuring scalability and interoperability of the SD-WAN." NEW: "This model emphasizes simplicity and efficiency, leveraging centralized governance to mitigate risks while supporting scalable control-plane distribution and interoperability of the SD-WAN." [Med] This is clearer. Thanks ## Also, it is not clear if the assessment is about BGP with [SD-WAN-Discovery] or BGP without [SD-WAN-Discovery]. [Linda] The document is about using BGP for SD-WAN together with the SD-WAN-specific extensions described in [SD-WAN-Discovery]. [Med] Thanks for confirming. This makes SD-WAN-Discovery normative. That is why the document references [SD-WAN-Discovery] in multiple places. This draft describes the deployment scenarios and BGP usage, while [SD-WAN-Discovery] specifies the detailed BGP protocol extensions. # Is really DPI required? [Linda] No, the document does not require DPI, nor does it use the term DPI. The intent is to describe policy-based traffic classification and forwarding in SD-WAN deployments, which can be based on configured policies and packet/header information. CURRENT: SD-WAN: An overlay connectivity service that optimizes the transport of IP packets over one or more Underlay connectivity services by recognizing applications and ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ determining forwarding behavior by applying policies to them [MEF-70.2]. I would avoid this wording as this smells like DPI function is mandatory, while this can be basically about supplying classification rules (without having to inspect user traffic payload). [Linda] We were asked to include an official reference for SD-WAN, and the WG considered [MEF-70.2] to be the appropriate reference. The quoted wording comes from [MEF-70.2]. To avoid "smells like DPI", how about shortening the definition while keeping the reference to MEF-70.2: "SD-WAN: An overlay connectivity service that optimizes the transport of IP packets over one or more underlay connectivity services by forwarding them based on policies [MEF-70.2]." [Med] This is better. Note that I disagree with "optimizes" as that is not something that is guaranteed by design, but depends on the enforced policies. [Linda2] Agree. We can remove the word "optimize", like the below: "SD-WAN: An overlay connectivity service that transports IP packets over one or more underlay connectivity services and forwards them based on policies. [MEF70.2]" _______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
