Luis, Thank you very much for the review and the comments. Please let us know if the resolutions below have addressed your concerns.
Linda -----Original Message----- From: Luis Contreras via Datatracker <[email protected]> Sent: Monday, April 27, 2026 9:17 AM To: [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: draft-ietf-bess-bgp-sdwan-usage-30 ietf last call Opsdir review Document: draft-ietf-bess-bgp-sdwan-usage Title: BGP Usage for SD-WAN Overlay Networks Reviewer: Luis Contreras Review result: Has Issues Hi, I have been selected as the Operational Directorate (opsdir) reviewer for this Internet-Draft. The Operational Directorate reviews all operational and management-related Internet-Drafts to ensure alignment with operational best practices and that adequate operational considerations are covered. A complete set of _"Guidelines for Considering Operations and Management in IETF Specifications"_ can be found at https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-rfc5706bis%2F&data=05%7C02%7Clinda.dunbar%40futurewei.com%7C0a605066a4c146dd736d08dea47860c9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C639129034108700547%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=G52LRRgGV%2Fy5bSrbuIveD4MmQS%2BIMEEb4Ns2O0E726k%3D&reserved=0. While these comments are primarily for the Operations and Management Area Directors (Ops ADs), the authors should consider them alongside other feedback received. - Document: BGP Usage for SD-WAN Overlay Networks, draft-ietf-bess-bgp-sdwan-usage-30 - Reviewer: Luis Contreras - Review Date: 27/04/2026 - Intended Status: Informational --- ## Summary Choose one: - Has Issues: I have some minor concerns about this document that I think should be resolved before publication. ## General Operational Comments Alignment with RFC 5706bis - As a general comment, the draft presents in some parts assessments which are confusing. For example, in section 4.3, 3rd paragraph, it is mentioned “In a BGP-controlled SD-WAN, BGP UPDATE messages can be extended to propagate IPsec-related attributes for each SD-WAN edge”. Is this already possible, and if so, where is it specified? Is it only a potential way to follow but requiring specification work? Is it just a possibility? This kind of assessments make the text not clear. So, it is not clear if we are discussing applicability or feasibility approaches. In my opinion, when using “can” this implies that it is already possible, then it should be accompanied with a reference to any document where such capability is specified. Otherwise, maybe using terms such as “could” or “potentially can”, etc, have to be used for not confusing the reader. (Same happens in other parts of the text such as in the 1st paragraph of section 5.2, etc). [Linda] Thanks for the suggestion. The extension is specified in [SD-WAN-Discovery], not in this Informational document. We can change “can” to “could” and add that reference. Does this address your concern? Section 4.3: Old: In a BGP-controlled SD-WAN, BGP UPDATE messages can be extended to propagate IPsec-related attributes for each SD-WAN edge. New: In a BGP-controlled SD-WAN, BGP UPDATE messages could be extended to propagate IPsec-related attributes for each SD-WAN edge, as specified in [SD-WAN-Discovery] Section 5.2 first sentence, added the reference [SD-WAN-Discovery]. - Linked with the previous comment, it is not clear if the focus of the document is a problem statement for identifying potential info to be included in the BGP UPDATE messages, or if it is an applicability document. In the latter case, it would be necessary to add the references to the specifications that describe the information needed in the BGP UPDATE messages. [Linda] This document is intended as an Informational applicability document, describing how existing BGP mechanisms (with minimal extensions) can be used for SD-WAN deployments, rather than defining new protocol behavior. The draft already has wording that supports “applicability/usage”: Abstract: “This document explores the complexities involved in managing large scale SD-WAN overlay networks… Its objective is to illustrate how a BGP-based control plane can effectively manage these overlay networks…” Introduction: “By documenting how these mechanisms are used in SD-WAN deployments, this document enables consistent interpretations and supports interoperability without defining new protocols.” This is similar in spirit to RFC 8365, which describes how EVPN is used in overlay networks.. The document already references the relevant specifications (e.g., [RFC9012] and [SD-WAN-Discovery]) where BGP UPDATE contents are discussed. ## Major Issues - The draft considers the transport across one or more underlay networks. It is not clear in the draft if such underlay networks pertain to the same administrative domain or to many. Operational implications of that can differ. Please, specify (1) if the multiple administrative setting is considered, and (2) if distinct operational implications apply to single- vs Multiple administrative domain scenarios. [Linda] The document assumes a single administrative domain for the SD-WAN overlay, consistent with the MEF SD-WAN service model. The underlay connectivity may be provided by one or more networks or NSPs, but the SD-WAN overlay control plane described in this document is under a single administrative control. This is already reflected in the Introduction, which states that “the SD-WAN control plane is logically centralized … with the RR remaining the logical control point for SD-WAN route distribution and policy enforcement.” - Just below Figure 2 it is stated: “Tenant separation is achieved by the SD-WAN VPN identifiers represented in the control plane and data plane, respectively”. Several questions here: How are the data plane points identified? Is it expected the overlays to be any-to-any? How does this scale? [Linda] The text below Figure 2 is intended to describe tenant separation at a conceptual level, not to define new data-plane mechanisms. The identification of data-plane packets follows existing encapsulations and mechanisms already described earlier in the document (e.g., Section 3.1.1). The overlay connectivity model is policy-driven and not necessarily any-to-any; communication among SD-WAN edges is constrained by policies enforced by the controller/RR, as described in Section 3.1.6. Scalability is achieved by leveraging existing BGP mechanisms such as Route Targets and RR-based policy enforcement to limit propagation to authorized peers [Section 3.1.5, Section 5.1], rather than requiring full-mesh connectivity. - Just below Figure 4. It is stated: “Services may not be congruent, i.e., the packets from A-> B may traverse one underlay network, and the packets from B -> A may go over a different underlay.”. It is necessary to develop this further and describe the implications. Is this possible for both the private and the public parts? What are the impacts of this in IPSec? [Linda] The statement is intended to reflect that SD-WAN policies are applied per direction, so paths selected for A→B and B→A traffic may differ. This behavior applies to both private and public underlay segments, depending on policy and available paths. From an IPsec perspective, this does not introduce new requirements, since IPsec SAs are inherently unidirectional and are independently established for each direction, as described in Section 6.1.1. - Section 5.1 makes refers to the hub-and-spoke model. However it is not clear how this can be implemented with the previous description of the solution. Please, provide details on how hub-and-spoke model can be built. [Linda] The reference to the hub-and-spoke model in Section 5.1 is meant as a comparison to traditional approaches used in smaller deployments. In the context of this document, hub-and-spoke behavior can be realized through policy control by the SD-WAN controller/RR, for example by constraining route propagation (e.g., via Route Targets or policy) so that branch-to-branch communication is not permitted and all traffic is directed via designated hub nodes. This policy-driven topology control is already described in Sections 3.1.5 and 4.1. Therefore, we believe the current description is sufficient for this Informational document. - Section 5.3. “BGP receivers associate the two UPDATE messages using the common loopback address of the SD-WAN edge (e.g., C-PE2).” Does this apply to both customer-managed and provider-managed SD-WAN? [Linda] The association by loopback address is independent of who manages the SD-WAN edge. It is a BGP control-plane correlation mechanism, not an operational ownership distinction. The document already defines C-PE broadly as an SD-WAN edge that can be either Customer Premises Equipment for customer-managed SD-WAN or Provider Edge for provider-managed SD-WAN services. - Generally specking, add as operational consideration some reference / analysis to the scalability of the proposed solution (for instance in terms of CPU usage of the routers, etc). [Linda] This document is an Informational applicability document and does not introduce new protocol mechanisms; it relies on existing BGP constructs such as Route Reflectors and policy-based route distribution, whose scalability characteristics are well understood from existing deployments. As such, detailed analysis of implementation aspects (e.g., CPU or memory usage on routers) is outside the scope of this document. However, the document already highlights the use of RR-based policy control and constrained propagation to improve scalability. - Again on scalability. Paragraph just before section 6.3 heading. “If IPsec tunnels are used for multicast traffic, the packet must be encapsulated and encrypted separately for each destination, creating multiple unicast IPsec tunnels to deliver the multicast packet to all intended recipients.” Can be this become a scalability issue? [Linda] Yes, this approach can have scalability implications, as noted by the need to replicate packets per destination when using unicast IPsec tunnels for multicast traffic. This is a known characteristic of such deployments. As stated in the document, more optimized multicast forwarding approaches are outside the scope of this Informational document. - Section 6.3.2. The paragraphs towards the end starting as “When the PE’s …” and “When a packet …” imply different encapsulations. This can be a problem from the perspective of the MTU to be used. Good to add to operational considerations. [Linda] We agree that different encapsulation modes can introduce different overhead and therefore affect MTU handling. However, the encapsulations referenced here, such as MPLS-in-IP, GRE, IPsec, and the Tunnel Encapsulation Attribute, are defined in their respective specifications, including [RFC9012]. Since this document is Informational and focuses on SD-WAN applicability, repeating detailed MTU considerations already covered by the underlying encapsulation specifications would be unnecessarily duplicative. - The document refers to Route Reflector functionality to something that in my view is more than that. Would it not be better to rename it to differentiate from the simple reflection of routes? [Linda] We agree that the RR in this document performs more than simple route reflection, as it is integrated with the SD-WAN controller and enforces policy-based distribution. However, the use of the term “Route Reflector (RR)” is intentional, as the functionality described is still based on the standard BGP RR behavior defined in [RFC4456], with additional policy control applied. The document already clarifies that the RR function may be integrated with the SD-WAN controller and represents the logical control point for route distribution and policy enforcement. Introducing a new term could create confusion with existing BGP terminology. Therefore, we prefer to keep the current terminology and rely on the existing clarifications in the text. --- ## Minor Issues - Section 1, Introduction, first bullet: “… and public networks (requiring encryption).”. Is it actually a requirement? If so, where such requirements is defined? [Linda] This bullet is not intended to state a strict requirement, but rather to describe a common characteristic of SD-WAN as defined in industry frameworks such as MEF 70.2. - SD-WAN IPsec SA. Why the distinction between “two WAN ports of the SD-WAN edges” and “two SD-WAN edges”. Is not the second statement comprise din the first one? [Linda] The distinction is intentional. An SD-WAN edge can have multiple WAN ports, and the IPsec SA (i.e., the overlay path) can be defined either between specific WAN ports or between the edge nodes themselves. When the IPsec SA is established between two WAN ports, the overlay path is tied to those specific ports, and traffic must be transmitted through those ports. In contrast, when the IPsec SA is defined between two SD-WAN edges (e.g., using loopback addresses), the overlay path terminates at the edge nodes, allowing traffic to be forwarded over any available WAN port based on local policy and path selection. Therefore, the second case is not fully subsumed by the first, as it represents a more abstracted model where the underlay path selection is decoupled from specific WAN ports. - Figure 5 is confusing, since it mixes control plane and data plane functions and interactions on the same figure without clear distinction. Please, improve it. [Linda] The intent of Figure 5 is to illustrate the use case described in Section 3.4: extending an existing VPN by adding Internet-facing ports to address temporary bandwidth needs between PEs. The text already states that Private VPN PE-Based SD-WAN “refers to extending an existing VPN … by adding additional ports that face the public Internet” and that the main use case is “Temporary Bandwidth Expansion.” It also clarifies that the BGP RR remains connected to the PEs via the same trusted network as the original VPN. Therefore, Figure 5 is intended as a high-level illustration of the original VPN/RR connectivity plus an added Internet offload path for low-priority traffic, not as a detailed control-plane/data-plane protocol diagram.. - The paragraph just before 5.2 heading seems to be a “marketing statement”. I tend to feel it not necessary in a technical document like this. [Linda] The paragraph is intended to provide a brief summary of the motivation and context for using BGP in SD-WAN, rather than as a marketing statement. Since this is an Informational document, we believe such context is helpful to frame the subsequent technical discussion. - Section 5.3. Maybe convenient to add a workflow to illustrate the process based on the scenario in Figure 6. [Linda] Section 5.3 is intended to describe the association process at a conceptual level, and Figure 6 already provides the context for that description. Since this document is Informational and focuses on applicability rather than detailed procedures, we prefer to keep the current level of detail and avoid adding step-by-step workflows - It would be nice to clarify from the SD-WAN forwarding models the ones applicable for customer-managed and provider-managed services. [Linda] The forwarding models described in this document are intended to be generally applicable to SD-WAN deployments, independent of whether they are customer-managed or provider-managed. As noted in the document, an SD-WAN edge (C-PE) can represent either case, and the forwarding behavior is determined by the control-plane policies rather than the management model. Given that this document is Informational and focuses on applicability, we believe the current description is sufficient without further differentiation. - Section 6.3.2. Scenario #2. What is that? [Linda] The reference to “Scenario #2” corresponds to the scenarios defined earlier in the document. Sections 3.2, 3.3, and 3.4 explicitly define Scenario #1, #2, and #3, respectively, and the section titles already reflect this. For clarity, we can add an explicit reference to Section 3.3 in Section 6.3.2.. - The document contains in section 7 a “Manageability Considerations” section. But this is not the same as Operational Considerations. Please, check if merging both makes sense, with the recommendation of adding a new section containing operational considerations (some of them being suggested in the forthcoming comments). [Linda] This document follows the convention of including a “Manageability Considerations” section, which already covers operational aspects relevant to the described deployment model. Since this is an Informational document focused on applicability rather than detailed operational procedures, we prefer to keep a single section and avoid introducing a separate “Operational Considerations” section. --- ## Nits - The penultimate paragraph before 3.1.2 mentions a number of technologies. For MPLS L2VPN a number of references are introduced, but that is not the case for VPN ID, VN-ID, VLAN. Would it be necessary to add references for all of them? [Linda] The terms VPN ID, VN-ID, and VLAN are widely used and well understood in the industry, and are referenced here only for illustrative purposes rather than to define new mechanisms. Given their common usage and the Informational nature of this document, we believe adding explicit references for each of these terms would not significantly improve clarity and may unnecessarily increase the number of references. - Second paragraph in 3.1.2. S/&/and [Linda] Thanks, changed in next revision. - Section 5.2, second paragraph. It refers to “figure below”. Better to add the Figure number. [Linda]Okay, added. - Section 5.3, last paragraph. UPDATE 1. Please, be consistent on the use of capital letters (update is use as Update 1 before). [Linda] all changed to UPDATE 1 - Paragraph just above Figure 7. s/pretections/protections [Linda] Changed. - Title of Figure 7 seems to be incomplete [Linda] Changed to “Forwarding over Hybrid SD-WAN” - Section 8, second paragraph. “… control-plane information received from internet-facing ports …”. Would it not be “for” instead of “from”? [Linda] The intended meaning is information received from Internet-facing ports, i.e., control-plane information entering the system via those interfaces. Therefore, “from” is correct in this context, and we prefer to keep the current wording. - Acknowledgements. “Victo Sheng”. I guess it should be Victor instead of Victo. [Linda] Thanks, changed. ---
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
