Hi Linda, Thanks for expeditiously addressing most of my technical comments and retaining the reference to draft-ietf-idr-sdwan-edge-discovery.
I will update my ballot on this document shortly to change my position from DISCUSS. Thanks, Ketan On Wed, May 27, 2026 at 12:11 PM Linda Dunbar <[email protected]> wrote: > Ketan, Med, > > > > I have uploaded revision (v35) that incorporated Ketan latest markup and > resolutions to Med’s comments: > https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/ > > > > Please let me know if you have more issues. > > > > Thank you very much, > > Linda > > *From:* Linda Dunbar > *Sent:* Tuesday, May 26, 2026 10:58 PM > *To:* Ketan Talaulikar <[email protected]> > *Cc:* The IESG <[email protected]>; [email protected]; BESS <[email protected]>; > [email protected]; [email protected] > *Subject:* RE: Ketan Talaulikar's Discuss on > draft-ietf-bess-bgp-sdwan-usage-32: (with DISCUSS and COMMENT) > > > > Ketan, > > > > Thanks for the markup. I accepted your suggestion of moving the other > published RFC references you identified to Normative reference. > > > > My hesitation is only with making the in-progress [SD-WAN-Discovery] draft > normative. That would put this document on hold until another draft > completes, which may take an unknown amount of time. I have seen documents > wait more than five years after IESG approval because of a normative > dependency. I have also seen cases where, by the time the dependency was > finally cleared, authors had moved on and it became difficult to complete > the final publication updates. > > > > This document has already gone through many years of WG discussion and > review. I am very concerned about putting it into a long post-approval hold > if the dependency can be avoided through clearer wording. > > > > We have revised the text so that the claims stand on their own and > [SD-WAN-Discovery] is cited only as one possible approach, not as a > prerequisite. Would you be willing to let [SD-WAN-Discovery] remain > Informative if we make that separation explicit, while moving the > applicable published RFCs to Normative? > > > > Thank you very much, > > > > Linda > > > > *From:* Ketan Talaulikar <[email protected]> > *Sent:* Tuesday, May 26, 2026 10:03 PM > *To:* Linda Dunbar <[email protected]> > *Cc:* The IESG <[email protected]>; [email protected]; BESS <[email protected]>; > [email protected]; [email protected] > *Subject:* Re: Ketan Talaulikar's Discuss on > draft-ietf-bess-bgp-sdwan-usage-32: (with DISCUSS and COMMENT) > > > > Hi Linda, > > > > Thanks for your response and for sharing the proposed update. To help us > conclude faster, I've provided the suggested changes (all of them related > to references) in the Word document that you had shared with tracked > changes. > > > > I see that you are already discussing the nuances between normative and > informative references with Med. I concur with Med's observations and (I > believe) the changes I've suggested align with them. I will let you and Med > continue that discussion. > > > > Once this version is posted, I will update my ballot. > > > > Thanks, > > Ketan > > > > > > On Wed, May 27, 2026 at 6:26 AM Linda Dunbar <[email protected]> > wrote: > > Ketan, > > > > Thank you. Please see the proposed resolution below marked by [Linda3]. > > > > Attached is the Diff file between v34 and the v33. > > > > Linda > > > > *From:* Ketan Talaulikar <[email protected]> > *Sent:* Tuesday, May 26, 2026 3:26 AM > *To:* Linda Dunbar <[email protected]> > *Cc:* The IESG <[email protected]>; [email protected]; BESS <[email protected]>; > [email protected]; [email protected] > *Subject:* Re: Ketan Talaulikar's Discuss on > draft-ietf-bess-bgp-sdwan-usage-32: (with DISCUSS and COMMENT) > > > > Hi Linda, > > > > Please check inline below for follow-up with KT2. Also, check all the way > to the end of the email so you are not missing the previous conversation > where some points were still under discussion. > > > > You can submit the update directly or share the diff if you would like to > cross-check or discuss further. > > > > On Tue, May 26, 2026 at 12:48 PM Linda Dunbar <[email protected]> > wrote: > > Ketan, > > > > Thank you for the additional comments and suggestions. Please see the > proposed resolutions below, marked with [Linda2]. > > > > Linda > > > > *From:* Ketan Talaulikar <[email protected]> > *Sent:* Friday, May 22, 2026 5:46 AM > *To:* Linda Dunbar <[email protected]> > *Cc:* The IESG <[email protected]>; [email protected]; [email protected]; > [email protected]; [email protected] > *Subject:* Re: Ketan Talaulikar's Discuss on > draft-ietf-bess-bgp-sdwan-usage-32: (with DISCUSS and COMMENT) > > > > Hi Linda, > > > > Thanks for the super fast response and for posting the update. Please > check inline below for follow-up. > > > > For the <discuss-1>, I am highlighting a few other text in the document > that I find making asserts and comparisons that do not seem to be > substantiated by details or reference. Can you please consider rephrasing > these sentences? > > > > Section 5.1 says: > > > > In small SD-WAN networks with a modest number of nodes, > traditional approaches such as the hub-and-spoke model, employing > Next Hop Resolution Protocol (NHRP)[RFC2332] or a centralized hub > managing edge nodes, including the mapping of local and public > addresses along with tunnel identifiers, has proven effective. > However, for larger SD-WAN networks, with more than 100 nodes and > encompassing diverse underlays, the conventional approach becomes > increasingly complex, error-prone, and difficult to manage. > > > > It is OK to reference NHRP as an IETF technology. Can you cite references > to SD-WAN implementations or solutions that use NHRP? This paragraph > asserts that NHRP is the conventional approach while many SD-WAN solutions > exist (that you consider traditional?) that do not suffer from any of these > challenges. If they do, please substantiate that claim with references. Why > compare? Also, "traditional approach" is unspecified - aren't there SD-WAN > solutions that do more than use the hub-and-spoke model? Why not just state > how things are done with BGP? > > > > [Linda2] NHRP is referenced because DMVPN-like IPsec/GRE overlay designs > use NHRP for tunnel endpoint resolution. Some SD-WAN products support or > coexist with DMVPN-like deployment models; for example, Cisco documentation > describes DMVPN tunnels being configured through Cisco Catalyst SD-WAN > Manager. However, we agree that it may not be appropriate for this document > to generalize such vendor-specific deployment practices or to rely on > vendor implementation references. Therefore, we can make the following > wording change: > > > > Old: > > “In small SD-WAN networks with a modest number of nodes, traditional > approaches such as the hub-and-spoke model, employing Next Hop Resolution > Protocol (NHRP)[RFC2332] or a centralized hub managing edge nodes, > including the mapping of local and public addresses along with tunnel > identifiers, has proven effective. However, for larger SD-WAN networks, > with more than 100 nodes and encompassing diverse underlays, the > conventional approach becomes increasingly complex, error-prone, and > difficult to manage.” > > > > New: > > *“In small SD-WAN networks with a modest number of nodes, a hub-and-spoke > overlay model, including designs that use Next Hop Resolution Protocol > (NHRP) [RFC2332] for tunnel endpoint resolution, can be manageable. In > larger SD-WAN networks with many edge nodes and diverse underlays, > additional mechanisms are often needed to distribute reachability, tunnel > endpoint information, and policy-related attributes in a scalable and > consistent manner. This document describes how BGP can be used for that > purpose.”* > > > > KT2> This text works. > > > > > > In summary, BGP combines scalability, robust policy enforcement, > interoperability, and centralized security, > *making it an ideal choice* for managing SD-WAN overlay networks, > particularly as they > grow in size and complexity. > > > > BGP is certainly a choice. Can you substantiate that it is an ideal choice > without supporting references that analyze the other choices? > > > > [Linda2] Good suggestion. The intent of this section is not to prove that > BGP is superior to every possible SD-WAN control-plane mechanism, but to > explain why BGP is suitable for the SD-WAN control-plane functions scoped > by this document. How about the following wording change? > > > > Old: > > “In summary, BGP combines scalability, robust policy enforcement, > interoperability, and centralized security, making it an ideal choice for > managing SD-WAN overlay networks, particularly as they grow in size and > complexity.” > > > > New: > > *“In summary, BGP is well suited to these SD-WAN overlay control-plane > functions because it provides standardized mechanisms for scalable route > distribution, policy-based route propagation, VPN membership control using > Route Targets, and extensible encoding of tunnel-related attributes, which > are especially useful as the network grows in size and complexity*.” > > > > KT2> This text also works. > > > > > > A related point appears in section 5.1 and also in other places in this > document. There is a comparison between "traditional IPsec VPN" and SD-WAN. > I do not understand the motivation for such comparisons. Are they not > comparing apples and oranges? Is this document proposing BGP for > traditional IPsec VPNs or for an SD-WAN solution that aligns more closely > with MEF/Mplify specifications? Why not just state how things are done with > BGP? > > > > [Linda2] This document is about using BGP as the SD-WAN control plane. > Here, “traditional” was intended to refer to SD-WAN deployments that use > IPsec VPN tunnels for the data plane and proprietary mechanisms for the > control plane. We agree that the term is ambiguous and will replace it with > more specific wording, such as “proprietary SD-WAN control-plane > mechanisms.” > > > > KT2> Thanks. Replacing "traditional" with the specific types of VPN/SD-WAN > would help. > > > > > > > > Please search for "traditional" in the document. You will see many similar > comparisons and assertions that I am unsure are substantiated but more > importantly, they are probably unnecessary. > > > > [Linda2] Agree. We have searched for “traditional” throughout the document. > > Here are the detailed changes: > > > > Section 3.2: > > > > Old : > > A Homogeneous Encrypted SD-WAN shares certain similarities with > > traditional IPsec VPN. However, unlike IPsec VPNs, which are > > typically deployed in a point-to-point fashion among a limited > > number of nodes, SD-WAN networks can comprise a large number of > > edge nodes, all centrally managed by a controller responsible for > > configurations and policies across the network > > New: > > *A Homogeneous Encrypted SD-WAN uses IPsec tunnels to protect traffic > between SD-WAN edges. The SD-WAN overlay may include many edge nodes, with > configuration and policy information managed by an SD-WAN controller.* > > > > Section 4.3: > > Old: > > In a BGP-controlled SD-WAN, BGP UPDATE messages could be extended > > to propagate IPsec-related attributes for each SD-WAN edge [SD- > > WAN-Discovery]. This approach allows peers to receive and apply > > compatible cryptographic parameters distributed over a secure > > channel between the SD-WAN edge and its BGP RR, thereby > > simplifying IPsec tunnel establishment and reducing reliance on > > traditional IKEv2 negotiation [RFC7296]. > > > > New: > > *In a BGP-controlled SD-WAN, BGP UPDATE messages could be extended to > propagate IPsec-related attributes for each SD-WAN edge [SD-WAN-Discovery]. > These attributes allow SD-WAN edges to receive compatible IPsec parameters > from the RR over a protected BGP session. By leveraging the authenticated > and authorized relationship between each SD-WAN edge and the RR, this > approach can simplify IPsec tunnel establishment and reduce or eliminate > the need for separate per-peer IKEv2 authentication between SD-WAN edges, > depending on the deployment model [RFC7296] (see Section 5.1 and Section > 7).* > > > > > > Section 5.1: > > Old: > > Unlike traditional IPsec VPN where IPsec tunnels between two edge nodes > are treated as independent parallel links requiring duplicated control > plane messages for load sharing, BGP in an SD-WAN context can associate > multiple service flows with shared tunnel parameters, reducing repeated > signaling. > > > > New: > > *When an IGP such as OSPF is run over IPsec tunnel interfaces, routing > adjacencies are typically established per tunnel. In a BGP-controlled > SD-WAN context, multiple service flows can be associated with shared tunnel > parameters, reducing repeated per-tunnel control-plane configuration.* > > > > > > Section 6.1.1: > > Old: > > Instead of running IGP within each IPsec tunnel, as is common in > traditional IPsec VPN, the BGP RR can propagate the client route UPDATE > messages to authorized SD-WAN edges based on configured policies. > > > > New: > > *In a BGP-controlled SD-WAN, the BGP RR can propagate the client route > UPDATE messages to authorized SD-WAN edges based on configured policies.* > > > > > > Section 8: > > Old: > > The primary operational difference between SD-WAN deployments and > traditional BGP-based VPNs is that SD-WAN edge nodes often include > Internet-facing WAN ports, > > > > New: > > *The primary operational difference between SD-WAN deployments and classic > BGP-based VPNs is that SD-WAN edge nodes often include Internet-facing WAN > ports,* > > > > > > KT2> All of these are good. For the last one, instead of "classic", > perhaps you are referring to BGP L3VPN and/or EVPN? If so, please provide > informative reference to those specific RFCs? > > > > [Linda3] Ok, removed “classic” and added the reference: > > > > New: > > *A primary operational difference between SD-WAN deployments and BGP/MPLS > IP VPNs [RFC4364][RFC4659]is that SD-WAN edge nodes often include > Internet-facing WAN ports, which introduce additional security, filtering, > and policy-enforcement requirements that are not typically present in > BGP/MPLS IP VPN environments.* > > > > > > Section 6.1.1 says > > > > Instead of running IGP within each IPsec tunnel, as is common in > traditional IPsec VPN, the BGP RR can propagate the client route > UPDATE messages to authorized SD-WAN edges based on configured > policies. The SD-WAN edges use BGP attributes-such as the Tunnel > Encapsulation Attribute and associated Color values-to associate > received client routes with the appropriate IPsec Security > Associations (SAs), thereby eliminating the need for manual > configuration of tunnel endpoints and service policies on each > edge node. > > > > SD-WAN is a rich service with several policies beyond tunnel endpoints and > their security parameters. Also, most SD-WAN solutions employ a high degree > of automation, resulting in minimal manual configuration. Is the claim of > "eliminating the need for manual configuration" substantiated? Does > everything required for traffic flow management, steering and service > configuration arrive via the BGP protocol without any manual configuration > or provisioning outside of BGP? > > > > [Linda2] Agree. Section 5.1 has been revised to explain the rationale > more narrowly: “BGP is well suited to these SD-WAN overlay control-plane > functions because it provides standardized mechanisms, ….”; Section 6.1.1 > has also removed the comparison with running IGP within each IPsec > tunnel..” . The intended point is narrower: BGP can distribute client > reachability and tunnel-association information using standardized > mechanisms,... > > > > Here is the updated paragraph: > > *In a BGP-controlled SD-WAN, the BGP RR can propagate client route UPDATE > messages to authorized SD-WAN edges based on configured policies. The > SD-WAN edges use BGP attributes, such as the Tunnel Encapsulation Attribute > and associated Color values, to associate received client routes with the > appropriate IPsec Security Associations (SAs), thereby reducing per-edge > configuration of tunnel endpoint associations. Other SD-WAN service > policies, traffic-steering rules, and device-specific parameters may still > be provisioned by the SD-WAN controller or local configuration.* > > > > > > KT2> This is good as well. Thanks. > > > > > > > > On Fri, May 22, 2026 at 12:15 AM Linda Dunbar <[email protected]> > wrote: > > Ketan, > > > > Thank you very much for the comments and the suggestions. > > Please see below of the proposed resolutions marked by [Linda] and let us > know if they are acceptable. > > > > Thank you, Linda > > > > -----Original Message----- > From: Ketan Talaulikar via Datatracker <[email protected]> > Sent: Thursday, May 21, 2026 7:00 AM > To: The IESG <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; [email protected] > Subject: Ketan Talaulikar's Discuss on draft-ietf-bess-bgp-sdwan-usage-32: > (with DISCUSS and COMMENT) > > > > Ketan Talaulikar has entered the following ballot position for > > draft-ietf-bess-bgp-sdwan-usage-32: Discuss > > > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > > > Please refer to > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-positions%2F&data=05%7C02%7Clinda.dunbar%40futurewei.com%7C35d83c8756f94413745508deb7414751%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C639149688199996146%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=oxHEUk6zLddBfUdPrZvZQIh96leymiB84hgv0wO563k%3D&reserved=0 > <https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/> > > for more information about how to handle DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-bess-bgp-sdwan-usage%2F&data=05%7C02%7Clinda.dunbar%40futurewei.com%7C35d83c8756f94413745508deb7414751%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C639149688200078779%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=BUVwWa%2F4fcBNEhwpIIEjLISM03arenARbijC5sTp5U0%3D&reserved=0 > <https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/> > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Thanks to the authors and the WG for their work on this document. > > > > I have a few high-level aspects in this document that I would like to > discuss. > > > > <discuss-1> The abstract of this document says: > > > > This document explores the complexities involved in managing large > > scale Software Defined WAN (SD-WAN) overlay networks, along with > > various SD-WAN scenarios. Its objective is to illustrate how a > > BGP-based control plane can effectively manage these overlay > > networks by distributing edge service reachability information, > > WAN port attributes, and underlay path details, thereby minimizing > > manual provisioning. > > > > To my knowledge there are SD-WAN solutions from several vendors that are > > widely deployed today. Some of them use IETF protocols for specific > > functionalities while others use proprietary mechanisms (here I am not > > referring to IPSec or TLS but routing protocols). This text (and a few > > similar in the body of the document) gives the impression of comparison > > between a BGP-based solution that is not fully specified (not even the > > framework is specified) in this document against solutions deployed out > > there. > > > > As easy way to address this would be to rephrase such text to not make > > claims or comparisons. Perhaps just plainly state how use of BGP can > > potentially replace other proprietary mechanisms used in SD-WAN solution? > > E.g., the first sentence is problematic since it can be read as existing > > solutions have complexities that are solved by BGP without any supporting > > evidence or evaluation of those other solutions. > > > > [Linda] Very good point. How about the following change for the Abstract? > > Old: > > *Its objective is to illustrate how a BGP-based control plane can > effectively manage these overlay networks...* > > > > New: > > *Its objective is to illustrate how a BGP-based control plane can be used > to manage these overlay networks...* > > > > Add the following sentence at the end of the Abstract: > > *In such deployments, BGP can provide a standards-based mechanism for > distributing information that may otherwise be exchanged using proprietary > SD-WAN control-plane mechanisms.* > > > > KT> Thanks. That helps. However the first sentence still remains. How > about the following abstract? > > > > This document illustrates how a BGP-based control plane can be > used to manage large scale Software Defined WAN (SD-WAN) overlay > networks by distributing edge service reachability information, > WAN port attributes, and underlay path details, thereby minimizing > manual provisioning. In such deployments, BGP can provide a > standards-based mechanism for distributing information that may > otherwise be exchanged using proprietary SD-WAN control-plane > mechanisms. > > [Linda3] Thanks for the suggestion. Changed. Sorry that I missed it > yesterday. > > KT> This change along with an appropriate rephrasing of the similar issues > identifed at the top of this email will address this point. > > > > > > KT2> Is this suggested abstract ok? > > [Linda3] Yes. Thank you. > > > > > > <discuss-2> Introduction section says: > > > > 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. > > > > As mentioned in the previous point, there are multiple SD-WAN solutions > > that have been developed by various vendors using IETF technologies > > like BGP (but with proprietary extensions) or entirely proprietary > > solutions. AFAIK, none of these solutions support interoperability between > > SD-WAN gateways and controllers from different vendors. Please correct > > me if I am wrong. So, I wonder where and how the standardization of SD-WAN > > at the IETF is happening to enable such interoperability that is after all > > the purpose of the IETF. The BGP extensions are but a small portion of what > > an SD-WAN solution entails. Do the claims made in that text hold? > > > > Why not just say "This document captures the SD-WAN scenarios, > control-plane > > behaviors, and forwarding considerations using BGP." or something like > that? > > > > [Linda] Thanks for the suggestion. We will take your suggestion, make the > following wording change: > > Old: > > 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. > > New: > > *This document captures SD-WAN scenarios, control-plane behaviors, and > forwarding considerations when BGP is used as the SD-WAN overlay control > plane. Publishing this material as an RFC provides a stable, citable > foundation for related protocol specifications that use BGP for SD-WAN > networks and helps establish a shared understanding of the problem space > and assumptions described in this document. This document is informational > and does not specify a complete SD-WAN solution.* > > > > KT> Thanks. Just one point and suggestion below: > > > > s/related protocol specifications that use BGP for SD-WAN networks/related > protocol specifications [draft-ietf-idr-sdwan-edge-discovery] that use BGP > for SD-WAN networks > > [Linda3] To avoid creating an unintended dependency on a specific > protocol-extension draft, we prefer to keep this sentence generic rather > than naming [SD-WAN-Discovery] here. This document is Informational and > does not specify the BGP extensions defined in [SD-WAN-Discovery]. The > purpose of this paragraph is only to state that the usage document provides > shared context. How about the following wording change: > > “*Publishing this material as an RFC establishes a shared understanding > of the SD-WAN problem space and deployment assumptions and can assist with > future protocol development for BGP-based SD-WAN networks.”* > > > > Also, for the text in section 5.3, > doesn't draft-ietf-idr-sdwan-edge-discovery become a normative reference? > > > > KT2> Have these changes been considered? > > [Linda3] This document is Informational and does not require > implementation of [SD-WAN-Discovery] to understand the SD-WAN scenarios or > the BGP usage described here. [SD-WAN-Discovery] is cited only as an > example of one possible protocol extension/encoding in Section 5.1 and > Section 5.2. To make it clearer, we can make the following wording change: > > > > Section 5.1: > > Old: > > In networks with multiple IPsec tunnels between SD-WAN edges, BGP can > simplify tunnel management by using the SD-WAN edge discovery mechanism > defined in [SD-WAN-Discovery] to advertise WAN-port properties and > IPsec-related parameters. > > > > New: > > *In networks with multiple IPsec tunnels between SD-WAN edges, BGP can > simplify tunnel management by advertising WAN-port properties and > IPsec-related parameters. One possible approach for carrying such > information is described in [SD-WAN-Discovery].* > > > > Section 5.2: > > Old: > > In a BGP-controlled Homogeneous Encrypted SD-WAN, an SD-WAN edge (i.e., > C-PE) could advertise both its attached client routes and associated IPsec > tunnel parameters using BGP UPDATE messages, potentially within in a single > message that includes the Tunnel Encapsulation Attribute [SD-WAN-Discovery]. > > > > New: > > *In a BGP-controlled Homogeneous Encrypted SD-WAN, an SD-WAN edge (i.e., > C-PE) could advertise both its attached client routes and associated IPsec > tunnel parameters using BGP UPDATE messages. One possible approach using > the Tunnel Encapsulation Attribute is described in [SD-WAN-Discovery].* > > > > Old: > > the BGP UPDATE message from C-PE2 to RR can include the client routes in > the MP-NLRI Path Attribute, and can use the Tunnel Encapsulation Attribute > [SD-WAN-Discovery] to convey the parameters needed to associate those > routes with the appropriate IPsec tunnel. > > > > New: > > *the BGP UPDATE message from C-PE2 to RR can include the client routes in > the MP-NLRI Path Attribute and can use BGP attributes to convey the > parameters needed to associate those routes with the appropriate IPsec > tunnel. One possible approach using the Tunnel Encapsulation Attribute is > described in [SD-WAN-Discovery].* > > > > <discuss-3> In continuation of the previous point. There is no SD-WAN WG > that > > is chartered today to study and undertake the work necessary for a > standards > > based open and interoperable SD-WAN solution. Without that in place, I do > not > > understand the value or benefit of publication of this document via the > IETF > > track. It could as well be via ISE? > > > > [Linda] This document is limited to BGP usage for SD-WAN overlay > control-plane scenarios; it is not intended to define a complete SD-WAN > solution. The document has been discussed in BESS for several years and has > reached BESS WG consensus. Moving it to the Independent Stream at this > stage would disregard the WG reviews and consensus already achieved. > > This document also serves an important role for the related IDR work. > During the multi-year discussion of the SD-WAN Discovery draft, the IDR WG > preferred to keep background material, scenarios, and usage context out of > the protocol-extension draft and instead reference this SD-WAN usage > document for that material. > > There is precedent for BESS publishing Informational usage/applicability > documents, such as RFC 8388 on EVPN usage and applicability and RFC 9469 on > EVPN applicability to NVO3. Those documents describe usage of BGP-based > technologies without defining an entire end-to-end solution. > > > > > > KT> This point was exactly about the fact that there is no end-to-end > solution for a BGP-based SD-WAN solution being specified or worked on in > the IETF. Without that, these documents represent efforts that cannot > achieve a truly standards-based interoperable multi-vendor SD-WAN solution. > I am ok if we can agree to disagree on this. I will not block the document > on this account given the history of how we got here and the effort put in > by the authors over the past several years. > > [Linda3] Thank you. We understand the concern. Do you think the following > added sentences at the end of the Introduction (to address your earlier > comment) makes it clear enough? > > *“This document is informational and does not specify a complete SD-WAN > solution. Its scope is limited to selected SD-WAN overlay control-plane > functions, such as distributing edge reachability, WAN-port attributes, > tunnel-related information, and policy-constrained routes.”* > > > > > > > > <discuss-4> Section 3.1.5 says > > > > An SD-WAN edge must use a secure channel, such as TLS following > > BCP195[RFC9325] or Ipsec [RFC4301], to its designated RR for > > exchanging BGP UPDATE messages. > > > > I assume that IPsec tunnels need to be setup between the edge and > > the controller and this tunnel has IP addresses on both ends that are used > > to setup a BGP Session over it - i.e., in tunnel mode per RFC4301 with both > > AH and ESP. If so, please clarify. I am unable to find a similar IETF > > specification for setting BGP over TLS tunnels. I don't think BCP195 covers > > these aspects. Can you please clarify this use of TLS with an appropriate > > reference? > > > > [Linda] The intent is that the BGP session between the SD-WAN edge and the > designated RR is carried over a protected transport. When IPsec is used, > this means an IPsec-protected path between the edge and RR, typically using > IPsec tunnel mode, with IP addresses at both ends used to establish the BGP > TCP session over that protected path. We also agree that BCP195/RFC9325 > gives general TLS/DTLS security recommendations and does not itself specify > how to run BGP over TLS. Since there is no RFC that we should rely on here > for BGP-over-TLS, we will remove the TLS example from this sentence and > keep the requirement generic, with IPsec as the concrete example. Here is > the wording change: > > > > Old: > > An SD-WAN edge must use a secure channel, such as TLS following > BCP195[RFC9325] or Ipsec [RFC4301], to its designated RR for exchanging BGP > UPDATE messages. > > > > New: Section 3.1.5 > > An SD-WAN edge must exchange BGP UPDATE messages with its designated RR > over a protected transport. For example, IPsec [RFC4301] can be used to > protect the path between the SD-WAN edge and RR, with the BGP TCP session > established over that protected path. Other mechanisms for protecting the > edge-to-RR BGP session are outside the scope of this document. > > > > > > KT> Thanks, this addresses my concern. Please run idnits on the document > and it will put out several warnings related to references that should be > addressed. e.g., BCP195 reference to be removed. > > > > KT2> And this aspect too. > > > > Thanks, > > Ketan > > > > > > > > Thanks, > > Ketan > > > > > > > > Linda > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I support the DISCUSS position of Med. > > > > > > > > > >
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
