Hi Linda, Thanks for the changes made in -35 and -36. We are almost there :-)
For convenience, I'm extracting the pending items below: (1) "[Linda2] Agree with the principle in the IESG statement: if the text requires [SD-WAN-Discovery] to be read in order to understand or assess the claims, then the wording should be changed or the reference would become normative. To avoid creating an unnecessary normative dependency on another in-progress draft, we revised the text so that the claims in this document stand on their own. The remaining references to [SD-WAN-Discovery] only point to one possible approach for carrying the relevant SD-WAN edge discovery and tunnel-related information. [Med] :-) Let's then make it explicit and indicate that extensions are needed. You may consider: OLD: In such deployments, BGP can provide a standards-based mechanism for distributing information that may otherwise be exchanged using proprietary SD-WAN control-plane mechanisms. NEW In such deployments, BGP can provide a standards-based mechanism for distributing information that may otherwise be exchanged using proprietary SD-WAN control-plane mechanisms. However, extensions to BGP are needed to achieve that goal." As you want to avoid the normative dependency on SD-WAN-Discovery, we need avoid misinterpreting the promise of the document that using BGP features available out there would be sufficient to meet the needs you set in this draft. (2) "[Med] I see that you made some changes, but I think that some fixes are still needed here. At least, RFC4271 has to be normative. [Linda3] v35 has moved RFC4301, 4360, 4364, 4456, 4659, 9012, MPLIFY-119 and MEF70.2 to the normative reference. " RFC4271 is missing and should be added to normative. Please fix that one. Thanks. Cheers, Med De : Linda Dunbar <[email protected]> Envoyé : mercredi 27 mai 2026 19:29 À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; The IESG <[email protected]> Cc : [email protected]; [email protected]; [email protected]; [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 suggestions. Please see the proposed resolutions below marked by [Linda3]. Linda From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Sent: Tuesday, May 26, 2026 11:46 PM 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, 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]" . [Med] Thanks. Please note that you may want fix this part as well for consistency: Software Defined Wide Area Network (SD-WAN), as described in [MEF70.2], provides overlay connectivity services that optimize ^^^^^^^^ the transport of IP packets across one or more underlay networks [Linda3] Thanks. It is changed to "provides overlay connectivity services that transport IP packets across one or more underlay networks." # 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. [Med] Please check https://datatracker.ietf.org/doc/statement-iesg-iesg-statement-normative-and-informative-references-20060419/ as the classification applies also for Info docs/ It describes SD-WAN deployment scenarios and BGP usage, but does not define new BGP, IPsec, MEF, or IEEE protocol behavior. [Med] Yes, but it includes statements that require reading of these references to understand/assess the claims. See the excerpt I provided below. Please refer to "Normative references specify documents that must be read to understand.." of the IESG statement. [Linda2] Agree with the principle in the IESG statement: if the text requires [SD-WAN-Discovery] to be read in order to understand or assess the claims, then the wording should be changed or the reference would become normative. To avoid creating an unnecessary normative dependency on another in-progress draft, we revised the text so that the claims in this document stand on their own. The remaining references to [SD-WAN-Discovery] only point to one possible approach for carrying the relevant SD-WAN edge discovery and tunnel-related information. [Med] :-) Let's then make it explicit and indicate that extensions are needed. You may consider: OLD: In such deployments, BGP can provide a standards-based mechanism for distributing information that may otherwise be exchanged using proprietary SD-WAN control-plane mechanisms. NEW In such deployments, BGP can provide a standards-based mechanism for distributing information that may otherwise be exchanged using proprietary SD-WAN control-plane mechanisms. However, extensions to BGP are needed to achieve that goal. The cited documents are used as references for existing technologies and related specifications; therefore, we believe keeping them as Informative references is appropriate. [Med] I see that you made some changes, but I think that some fixes are still needed here. At least, RFC4271 has to be normative. [Linda3] v35 has moved RFC4301, 4360, 4364, 4456, 4659, 9012, MPLIFY-119 and MEF70.2 to the normative reference. 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. [Linda3] those have been Fixed in V35. ---------------------------------------------------------------------- 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." [Med] ACK # 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. [Med] Thanks. Cheers, Med ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
