Luis, The revision that addressed your comments has been uploaded: https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/
Please let us know if there are more issues. Thank you very much, Linda From: Linda Dunbar Sent: Tuesday, May 19, 2026 4:27 PM To: 'LUIS MIGUEL CONTRERAS MURILLO' <[email protected]>; [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: RE: draft-ietf-bess-bgp-sdwan-usage-30 ietf last call Opsdir review Luis. Thank you for the feedback to my proposed resolutions. Please see below my responses to your additional comments marked with [Linda2]. Linda From: LUIS MIGUEL CONTRERAS MURILLO <[email protected]<mailto:[email protected]>> Sent: Sunday, May 17, 2026 3:37 AM To: Linda Dunbar <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: RE: draft-ietf-bess-bgp-sdwan-usage-30 ietf last call Opsdir review Hi Linda, Apologies for the time taken to respond. Please, see in-line marked with [lmcm>>]. Thanks Luis De: Linda Dunbar <[email protected]<mailto:[email protected]>> Enviado el: martes, 28 de abril de 2026 0:19 Para: LUIS MIGUEL CONTRERAS MURILLO <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> CC: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Asunto: RE: draft-ietf-bess-bgp-sdwan-usage-30 ietf last call Opsdir review AVISO/WARNING: Este correo electrónico se originó desde fuera de la organización. No haga clic en enlaces ni abra archivos adjuntos a menos que reconozca al remitente y sepa que el contenido es seguro / This email has been originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 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]<mailto:[email protected]>> Sent: Monday, April 27, 2026 9:17 AM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[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<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). [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]. [lmcm>>] ok, thanks. - 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. [lmcm>>] ok. ## 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.” [lmcm>>] I would suggest to be more explicit precisely adding something as what you include in this answer: “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.” Something like that makes the text totally clear for any reader. [Linda2] Good suggestion. Add your suggested wording in the Introduction section (before the last paragraph), to be reflected in v-32. - 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. [lmcm>>] ok - 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. [lmcm>>] maybe slightly modifying like this? -> “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 due to the fact that SD-WAN policies are applied per direction.” [Linda2] thanks for the suggested wording. Added. Will be reflected in v-32. - 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. [lmcm>>] ok - 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. [lmcm>>] ok - 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. [lmcm>>] ok - 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. [lmcm>>] Maybe add something like “this approach can have scalability implications, as noted by the need to replicate packets per destination when using unicast IPsec tunnels for multicast traffic.”? Just to signal the reader about this fact, to be taken into account at the time of exploring this or newer solutions. [Linda2] thanks for the suggestion. Does adding the following sentence addresses your concern? “ This approach may have scalability implications due to per-destination packet replication; optimization mechanisms are outside the scope of this 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. [lmcm>>] Agree on not repeating, but maybe just mentioning that MTU aspects should be taken into account. Being the document informational I think is good to highlight aspects that could require elaboration on the solutions. But agree on not detailing nor repeating what is described anywhere else. [Linda2] How about adding the following short sentence at the end of the last paragraph of Section 6.3.2? “Operators should take encapsulation overhead and MTU considerations into account when deploying combinations of MPLS-in-IP, GRE, and IPsec encapsulations.” - 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. [lmcm>>] I’m not sure what is more confusing, if keeping the same name with enhanced functionality or creating a new name. Maybe as intermediate solution I would suggest to add in section 2 “Conventions used in this document” an entry for the usage of Route Reflector in the document, then making clear to the reader what is the RR role and functionality in this context. [Linda2] The RR behavior described in this document remains consistent with the standard Route Reflector procedures defined in [RFC4456]. The SD-WAN-specific BGP extensions used for edge discovery and attribute distribution are specified separately in [SD-WAN-Discovery]. To make this clearer, we can add the following sentence in the Introduction section: “In this document, references to “the Route Reflector (RR)” denote the RR instance(s) designated by the SD-WAN controller to distribute SD-WAN routing information. The detailed BGP extensions used for SD-WAN edge discovery and attribute distribution are specified in [SD-WAN-Discovery] --- ## 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. [lmcm>>] maybe adding “… (commonly requiring encryption).” [Linda2] Ok. Added - 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. [lmcm>>] ok - 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.. [lmcm>>] ok - 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. [lmcm>>] ok - 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 [lmcm>>] ok - 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. [lmcm>>] ok - 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.. [lmcm>>] yes, please. That would improve readability. Thanks. [Linda2] added. Reflected in Version -32 - 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. [lmcm>>] ok --- ## 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. [lmcm>>] ok - 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. [lmcm>>] ok - Acknowledgements. “Victo Sheng”. I guess it should be Victor instead of Victo. [Linda] Thanks, changed. --- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
