Ketan, Thank you very much for the comments and the suggestions. Please see below of the proposed resolutions marked by [Linda] and let us know if they are acceptable.
Thank you, Linda -----Original Message----- From: Ketan Talaulikar via Datatracker <[email protected]> Sent: Thursday, May 21, 2026 7:00 AM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Ketan Talaulikar's Discuss on draft-ietf-bess-bgp-sdwan-usage-32: (with DISCUSS and COMMENT) Ketan Talaulikar has entered the following ballot position for draft-ietf-bess-bgp-sdwan-usage-32: 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%7C35d83c8756f94413745508deb7414751%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C639149688199996146%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=oxHEUk6zLddBfUdPrZvZQIh96leymiB84hgv0wO563k%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%7C35d83c8756f94413745508deb7414751%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C639149688200078779%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=BUVwWa%2F4fcBNEhwpIIEjLISM03arenARbijC5sTp5U0%3D&reserved=0 ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks to the authors and the WG for their work on this document. I have a few high-level aspects in this document that I would like to discuss. <discuss-1> The abstract of this document says: This document explores the complexities involved in managing large scale Software Defined WAN (SD-WAN) overlay networks, along with various SD-WAN scenarios. Its objective is to illustrate how a BGP-based control plane can effectively manage these overlay networks by distributing edge service reachability information, WAN port attributes, and underlay path details, thereby minimizing manual provisioning. To my knowledge there are SD-WAN solutions from several vendors that are widely deployed today. Some of them use IETF protocols for specific functionalities while others use proprietary mechanisms (here I am not referring to IPSec or TLS but routing protocols). This text (and a few similar in the body of the document) gives the impression of comparison between a BGP-based solution that is not fully specified (not even the framework is specified) in this document against solutions deployed out there. As easy way to address this would be to rephrase such text to not make claims or comparisons. Perhaps just plainly state how use of BGP can potentially replace other proprietary mechanisms used in SD-WAN solution? E.g., the first sentence is problematic since it can be read as existing solutions have complexities that are solved by BGP without any supporting evidence or evaluation of those other solutions. [Linda] Very good point. How about the following change for the Abstract? Old: Its objective is to illustrate how a BGP-based control plane can effectively manage these overlay networks... New: Its objective is to illustrate how a BGP-based control plane can be used to manage these overlay networks... Add the following sentence at the end of the Abstract: 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. <discuss-2> Introduction section says: This document captures the SD-WAN scenarios, control-plane behaviors, and forwarding considerations that motivate current and future IETF work on SD-WAN. Publishing this material as an RFC provides a stable, citable foundation for related protocol specifications and ensures a shared understanding of the problem space across the industry. As mentioned in the previous point, there are multiple SD-WAN solutions that have been developed by various vendors using IETF technologies like BGP (but with proprietary extensions) or entirely proprietary solutions. AFAIK, none of these solutions support interoperability between SD-WAN gateways and controllers from different vendors. Please correct me if I am wrong. So, I wonder where and how the standardization of SD-WAN at the IETF is happening to enable such interoperability that is after all the purpose of the IETF. The BGP extensions are but a small portion of what an SD-WAN solution entails. Do the claims made in that text hold? Why not just say "This document captures the SD-WAN scenarios, control-plane behaviors, and forwarding considerations using BGP." or something like that? [Linda] Thanks for the suggestion. We will take your suggestion, make the following wording change: Old: This document captures the SD-WAN scenarios, control-plane behaviors, and forwarding considerations that motivate current and future IETF work on SD-WAN. Publishing this material as an RFC provides a stable, citable foundation for related protocol specifications and ensures a shared understanding of the problem space across the industry. Although BGP and IPsec are mature technologies, applying them to SD-WAN introduces challenges such as scalability, segmentation, and multi-homing. By documenting how these mechanisms are used in SD-WAN deployments, this document enables consistent interpretations and supports interoperability without defining new protocols. New: This document captures SD-WAN scenarios, control-plane behaviors, and forwarding considerations when BGP is used as the SD-WAN overlay control plane. Publishing this material as an RFC provides a stable, citable foundation for related protocol specifications that use BGP for SD-WAN networks and helps establish a shared understanding of the problem space and assumptions described in this document. This document is informational and does not specify a complete SD-WAN solution. <discuss-3> In continuation of the previous point. There is no SD-WAN WG that is chartered today to study and undertake the work necessary for a standards based open and interoperable SD-WAN solution. Without that in place, I do not understand the value or benefit of publication of this document via the IETF track. It could as well be via ISE? [Linda] This document is limited to BGP usage for SD-WAN overlay control-plane scenarios; it is not intended to define a complete SD-WAN solution. The document has been discussed in BESS for several years and has reached BESS WG consensus. Moving it to the Independent Stream at this stage would disregard the WG reviews and consensus already achieved. This document also serves an important role for the related IDR work. During the multi-year discussion of the SD-WAN Discovery draft, the IDR WG preferred to keep background material, scenarios, and usage context out of the protocol-extension draft and instead reference this SD-WAN usage document for that material. There is precedent for BESS publishing Informational usage/applicability documents, such as RFC 8388 on EVPN usage and applicability and RFC 9469 on EVPN applicability to NVO3. Those documents describe usage of BGP-based technologies without defining an entire end-to-end solution. <discuss-4> Section 3.1.5 says 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. I assume that IPsec tunnels need to be setup between the edge and the controller and this tunnel has IP addresses on both ends that are used to setup a BGP Session over it - i.e., in tunnel mode per RFC4301 with both AH and ESP. If so, please clarify. I am unable to find a similar IETF specification for setting BGP over TLS tunnels. I don't think BCP195 covers these aspects. Can you please clarify this use of TLS with an appropriate reference? [Linda] The intent is that the BGP session between the SD-WAN edge and the designated RR is carried over a protected transport. When IPsec is used, this means an IPsec-protected path between the edge and RR, typically using IPsec tunnel mode, with IP addresses at both ends used to establish the BGP TCP session over that protected path. We also agree that BCP195/RFC9325 gives general TLS/DTLS security recommendations and does not itself specify how to run BGP over TLS. Since there is no RFC that we should rely on here for BGP-over-TLS, we will remove the TLS example from this sentence and keep the requirement generic, with IPsec as the concrete example. Here is the wording change: Old: 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. New: Section 3.1.5 An SD-WAN edge must exchange BGP UPDATE messages with its designated RR over a protected transport. For example, IPsec [RFC4301] can be used to protect the path between the SD-WAN edge and RR, with the BGP TCP session established over that protected path. Other mechanisms for protecting the edge-to-RR BGP session are outside the scope of this document. Linda ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support the DISCUSS position of Med.
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
