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://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/. 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). - 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. ## 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. - 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? - 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? - 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. - 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? - 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). - 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? - 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. - 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? --- ## Minor Issues - Section 1, Introduction, first bullet: “… and public networks (requiring encryption).”. Is it actually a requirement? If so, where such requirements is defined? - 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? - 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. - 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. - Section 5.3. Maybe convenient to add a workflow to illustrate the process based on the scenario in Figure 6. - It would be nice to clarify from the SD-WAN forwarding models the ones applicable for customer-managed and provider-managed services. - Section 6.3.2. Scenario #2. What is that? - 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). --- ## 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? - Second paragraph in 3.1.2. S/&/and - Section 5.2, second paragraph. It refers to “figure below”. Better to add the Figure number. - Section 5.3, last paragraph. UPDATE 1. Please, be consistent on the use of capital letters (update is use as Update 1 before). - Paragraph just above Figure 7. s/pretections/protections - Title of Figure 7 seems to be incomplete - Section 8, second paragraph. “… control-plane information received from internet-facing ports …”. Would it not be “for” instead of “from”? - Acknowledgements. “Victo Sheng”. I guess it should be Victor instead of Victo. ---