IETF Last Call Review of draft-ietf-bess-bgp-sdwan-usage-30
review-ietf-bess-bgp-sdwan-usage-30-opsdir-lc-contreras-2026-04-27-00

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.

---