On December 4, 2025 at 11:13:08 PM, Linda Dunbar wrote:
Linda:
Hi!
I am commenting only on the places we still need some discussion, or to
answer some questions.
Thanks!
Alvaro.
...
> > (1) Expectation about the use and placement of the RR/Controller and
the
> > BGP sessions.
> >
> > In general, the document assumes that the RR and the SD-WAN Controller
are
> > the same. However, this assumption doesn't account for multiple RRs or
> > different planes. The assumption should be clearly and explicitly
> > articulated.
> >
> > §3.1.5 also seems to mention the possibility of having BGP sessions
between
> > the SD-WAN Edges.
>
> [Linda] Section 3.1.5 (Constrained Propagation of SD-WAN Edge Properties)
> explicitly states that SD-WAN edges exchange BGP UPDATEs only with the
> central RR over a secure channel. The RR is responsible for distributing
> those properties to authorized peers.
§3.1.5 doesn't mention "the central RR". This is what it says:
BGP is well suited for this purpose. A Route-Reflector (RR)
[RFC4456], integrated into the SD-WAN controller, enforces
policies governing the communication among SD-WAN edges. The RR
ensures that BGP UPDATE messages from an SD-WAN edge are
propagated only to other edges within the same SD-WAN VPN.
I'm not arguing with your statement.
My question is as follows. Many deployments have multiple RRs for
redundancy or to separate route distribution; many deployments also have
hierarchical RRs. The text above (and in general throughout the document)
talks about a specific/single RR (using "A RR", or "The RR"), one that is
also the SD-WAN controller. In a typical deployment (with multiple or
hierarchical RRs), which route reflector is that? Is the deployment of
SD-WAN expected to have only one RR? What about redundancy? Hierarchy?
Is the assumption that the SD-WAN controller function can be distributed
across multiple RRs?
The point is that operational guidance is missing on how to implement the
concept of "the RR is the controller".
Later, when replying to comment in §2 you wrote:
> [Linda] The document does not require that there be only a single RR, nor
> does it mandate that every RR in an iBGP topology act as the SD-WAN
> controller. The text describes the common deployment model in which the
> SD-WAN controller function is integrated with (or co-located with) the RR
> that distributes SD-WAN edge properties. In networks with multiple RRs,
only
> those RRs configured to perform the SD-WAN control-plane role act as
> controllers; additional RRs may still exist for other routing purposes.
...
> [Linda] We can add this sentence to the Introduction (second to last
> paragraph):
>
> “In this document, references to “the RR” denote the RR instance(s)
> designated by the SD-WAN controller to distribute SD-WAN routing
> information. Deployments may integrate the controller and RR or keep them
> separate; the architecture does not require a single RR nor mandate
> integration.”
To be honest, this text doesn't help me because the whole purpose of the
document is to show how BGP is well-suited for the SD-WAN function, and
specifically how the RR is the control point for policy, etc. If the
functions are decoupled then most of the document doesn't make sense.
I believe we're getting to the point where we should talk about this live.
You know how to get a hold of me. :-)
...
> > (2) IPSec Tunnel Encapsulation
> >
> > The draft repeatedly references rfc9012, but no IPSec Tunnel
Encapsulation
> > is specified there. The correct reference should be
> > draft-ietf-idr-sdwan-edge-discovery.
>
> [Linda] The purpose of this draft is to serve as the usage and
applicability
> document for SD-WAN, which is then referenced by
> draft-ietf-idr-sdwan-edge-discovery. To avoid creating a recursive
reference
> between the two working group documents, this draft does not point to the
> SD-WAN Edge Discovery draft for the actual IPsec encap formats. Instead,
this
> draft describes how those attributes are used operationally.
The reference in this document would be Informative, so there are no
recursion or dependency issues.
Also, talking about rfc9012 in the context of IPSec is just wrong.
We don't need to discuss this point anymore.
> > (3) Focus of the Manageability and Security Considerations sections
> >
> > Both sections cover only a small part of what the draft covers.
> > Explicitly, none of the building technologies are mentioned (even by
> > reference).
> >
> > The Security Considerations section should not just cover expectations,
> > but also the risks if those expectations are not followed. For example,
> > BGP doesn't have a mandatory "secure communication channel"; what are
> > the risks if the expectations are not met in a deployment?
>
> [Linda] How about adding the following wordings to Section 7:
>
> “Operators should ensure that RR propagation policies, SD-WAN VPN
membership
> rules, and tunnel-attribute distribution are consistently configured, as
> misconfiguration could expose edge properties or cause incorrect binding
of
> client routes to underlay tunnels. While centralizing control in the RR
> simplifies management, it also means that errors in RR policy or
provisioning
> may have network-wide effects; therefore, careful monitoring, auditing,
and
> validation of RR configuration are essential.”
Sure, that's a start.
> And adding the following paragraph to Section 8 (Security Consideration)
> after the paragraph?
>
> “SD-WAN further depends on standard BGP security mechanisms, including
the use
> of secure transport (e.g., TLS or IPsec) for BGP sessions and strict RR
policy
> enforcement. Deployments that bypass protected channels risk exposing
SD-WAN
> edge properties or allowing unauthorized nodes to inject or receive
routes.
> Likewise, incorrect RR policies can result in unintended distribution of
> client routes or tunnel attributes. These risks arise from deployment
choices
> rather than the mechanisms described in this document, and operators must
> ensure that secure transport and proper RR configuration are consistently
> applied.”
I see you have more suggestions later on in §8. In general, including this
text and what you propose in later, you should point at the existing
security considerations of the protocols you're using. Many of the risks
that exist are, as you mention, not specific to this document, but ones
that exist in BGP already -- again, support that claim by referencing the
existing security considerations in published RFCs.
One big nit about the text above: "SD-WAN further depends on standard BGP
security mechanisms, including the use of secure transport (e.g., TLS or
IPsec) for BGP sessions..." The only standard session-level mechanism is
TCP-AO, which is not used in this case, so that statement opens the door to
questions about the existing mechanisms...
...
> > 140 The need for an RFC documenting SD-WAN use cases lies in ensuring
> > 141 standardization and interoperability. While BGP and IPsec are
> > 142 well-established technologies, their application to SD-WAN
> > 143 introduces challenges such as scalability, traffic segmentation,
> > 144 and multi-homing. This document consolidates best practices and
> > 145 defines guidelines to enable consistent implementations across
> > 146 diverse networks, optimizing existing protocols for SD-WAN
> > 147 scenarios rather than proposing new ones.
...
> > [major] "standardization and interoperability...consolidates best
> > practices and defines guidelines to enable consistent
implementations..."
> >
> > This document is tagged as Informational (which seems the right
intended
> > status to me), but the statements in this paragraph point at it being
much
> > more.
> >
> > IMO, this justification paragraph is not necessary. If justification is
> > needed for publication, the Shepherd write-up is a better place to put
it.
>
> [Linda] How about changing the text to the following (to answer why RFC is
> needed)?
>
> “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.”
As I mentioned, I don't think this justification is necessary in the
document. Also, the text above mixes "understanding of the problem space",
and "how these mechanisms are used", which waffles between problem
statement and description of the use/operation.
I will let the Chairs/Shepherd figure out whether they want a statement
justifying the document.
...
> > [minor] s/client-facing service/client service/g
> > Be consistent.
>
> [Linda] in this document “client-facing services” is used intentionally to
> refer to the services reachable behind SD-WAN edges, which is more
specific
> than “client services,” so we prefer to retain the existing phrasing.
Either term is fine with me. I suggested "client service" because §2
includes a definition for that:
Client service: A service (e.g., IP prefix or VLAN) attached to
the client-facing interface of an SD-WAN edge.
...
> > [nit] s/L2VPN[RFC4761] [RFC4762]/L3VPN[RFC4364]/L2VPN [RFC4761]
[RFC4762]/L3VPN [RFC4364]
>
> [Linda] are you suggest any changes? I can’t tell.
Spacing
...
> > [nit] s/MPLS based VPNs [RFC4364][RFC4659]/MPLS based VPNs [RFC4364]
[RFC4659]
>
> [Linda] is there difference between the suggested words?
Spacing again...
_______________________________________________
BESS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
