Alvaro, Thank you very much for accepting most of the resolutions.
See below [Linda2] for the resolutions to the remaining issues. Linda From: Alvaro Retana <[email protected]> Sent: Friday, December 5, 2025 2:40 PM To: [email protected]; [email protected]; Linda Dunbar <[email protected]> Cc: [email protected]; [email protected] Subject: RE: RtgDir Early review of draft-ietf-bess-bgp-sdwan-usage-28 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". [Linda2] In the last email, resolution to one of your comments is adding the following sentence to the Section 1: “Deployments may integrate the controller and RR or keep them separate; the architecture does not require a single RR nor mandate integration.” 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. :-) [Linda2] Sure, I will give you a call tomorrow. The document does not assume a single physical RR. In production SD-WAN systems, the control plane is typically logically centralized but physically distributed for resiliency, scalability, and geographic redundancy. Do you think changing the added sentence to the following is more clear? “Deployments may integrate the controller and RR or keep them as separate components; the SD-WAN control plane is logically centralized but may be physically realized by a set of distributed controller/RR instances operating as a coordinated system for scalability, resiliency, and geographic redundancy, with the RR remaining the logical control point for SD-WAN route distribution and policy enforcement as described in this document; the mechanisms for coordination and state synchronization among multiple RR instances are out of the scope of this document.” ... > > (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. [Linda2] Okay, will change. Also, talking about rfc9012 in the context of IPSec is just wrong. [Linda2] will remove the reference to rfc9012 in next revision in the context of IPsec. 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... [Linda2] How about changing the paragraph to the following? “SD-WAN operation relies on the existing security mechanisms defined for BGP and IPsec. In particular, protection of BGP sessions may use the TCP Authentication Option (TCP-AO) as specified in RFC 5925, and the security considerations of BGP, TCP-AO, and IPsec apply directly. Many of the risks described here—including route injection, session disruption, or unintended route distribution—are therefore inherent to those protocols rather than specific to this SD-WAN usage. Operators must follow the existing security guidance in the referenced RFCs and ensure correct RR policy configuration and session protection” ... > > 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. [Linda2] The reason this paragraph was added is based directly on feedback from the previous IESG review, where multiple reviewers explicitly questioned the necessity of publishing this document as an RFC. This text is intended to proactively address that question by clearly stating the document’s scope, value, and role in providing a stable, citable reference for the SD-WAN problem space and for related protocol work. ... > > [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. [Linda2] Good point. Changed. ... > > [nit] s/L2VPN[RFC4761] [RFC4762]/L3VPN[RFC4364]/L2VPN [RFC4761] > > [RFC4762]/L3VPN [RFC4364] > > [Linda] are you suggest any changes? I can’t tell. Spacing [Linda2] thanks. ... > > [nit] s/MPLS based VPNs [RFC4364][RFC4659]/MPLS based VPNs [RFC4364] > > [RFC4659] > > [Linda] is there difference between the suggested words? Spacing again... [Linda2] Thanks.
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
