Med, The revision that addressed your comments and suggestions have been uploaded: https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/
Again, Thank you very much. Linda _____________________________________________ From: Linda Dunbar Sent: Wednesday, May 20, 2026 6:23 PM To: 'Mohamed Boucadair' <[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 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.) Please refer to https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-positions%2F&data=05%7C02%7Clinda.dunbar%40futurewei.com%7Cdc1da763088e42eb3e1d08deb6457e90%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C639148606773720781%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=V0vzxw%2BOjXg%2FsHHAmlUWv%2FwsVEQ9yZX2Df7swcdu%2FAo%3D&reserved=0 for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-bess-bgp-sdwan-usage%2F&data=05%7C02%7Clinda.dunbar%40futurewei.com%7Cdc1da763088e42eb3e1d08deb6457e90%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C639148606773772088%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=yeWSOTAkezZlSU3dzOPaG9WGHD9gUJH0AhP5Xc9sUXI%3D&reserved=0 ---------------------------------------------------------------------- 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? 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 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. 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. # 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" ## 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." ## 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]. 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]." # MEF, BGP, IPsec, and more are normative [Linda] This document is an Informational usage document, following the model of usage/applicability documents such as RFC8388 for EVPN. It describes SD-WAN deployment scenarios and BGP usage, but does not define new BGP, IPsec, MEF, or IEEE protocol behavior. The cited documents are used as references for existing technologies and related specifications; therefore, we believe keeping them as Informative references is appropriate. RFC4271 .. Software Defined Wide Area Network (SD-WAN), as described in [MEF70.2], ... The detailed BGP extensions used for SD-WAN edge discovery and attribute distribution are specified in [SD-WAN-Discovery]. ... The SD-WAN client interface should support IPv4 and IPv6 addresses as well as Ethernet in accordance with the [IEEE802.3] standard. ... The client service at the SD-WAN edge must support the SD-WAN UNI service attributes outlined in Section 4 of [MEF 70.2]. ... 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. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # I don't parse how IP prefix is a service. CURRENT: Client service: A service (e.g., IP prefix or VLAN) attached to [Linda] How about changing the wording to: "Client service: A service attached to the client-facing interface of an SD-WAN edge, identified by associated reachability or attachment information, such as an IP prefix or VLAN." # A device is physical OLD: SD-WAN edge: A device, either physical or virtual, that participates in the SD-WAN overlay network. These nodes advertise client routes to the SD-WAN Controller (e.g., BGP RR). NEW: SD-WAN edge: A functional entity, either physical or virtual, that participates in the SD-WAN overlay network. These nodes advertise client routes to the SD-WAN Controller (e.g., BGP RR). [Linda] Thank you for the suggestion. Changed. Cheers, Med
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
