[bess] Re: Ketan Talaulikar's Discuss on draft-ietf-bess-bgp-sdwan-usage-32: (with DISCUSS and COMMENT)

[Susan Hares <[e-mail]>]

Linda:

I suggest you make the SD-WAN-Discovery draft normative.   Keyur has promised me that it is “almost ready” to go the IESG.

Cheers, Sue

From: Linda Dunbar <[e-mail]>
Sent: Wednesday, May 27, 2026 1:58 AM
To: Ketan Talaulikar <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; BESS <[e-mail]>; [e-mail]; [e-mail]
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 <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, May 26, 2026 10:03 PM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Cc: The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; BESS <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, May 26, 2026 3:26 AM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Cc: The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; BESS <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> wrote:
Ketan,

Thank you for the additional comments and suggestions. Please see the proposed resolutions below, marked with [Linda2].

Linda

From: Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Sent: Friday, May 22, 2026 5:46 AM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Cc: The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, May 21, 2026 7:00 AM
To: The IESG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_about_groups_iesg_statements_handling-2Dballot-2Dpositions_&d=DwMGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=3QxUPy-fV0G16Z4tIRByiA&m=Xdr8YOqcVwdmpRRzpyD4vEyvXahhpeuLPqUkjtqpvmfGfqWoe20ybtsanysr8FQz&s=fk4zqP-txBh3Ovnq0MxVbkvaZwnlRG5KMitS1KxSo3o&e=>
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://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbess-2Dbgp-2Dsdwan-2Dusage_&d=DwMGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=3QxUPy-fV0G16Z4tIRByiA&m=Xdr8YOqcVwdmpRRzpyD4vEyvXahhpeuLPqUkjtqpvmfGfqWoe20ybtsanysr8FQz&s=D1-RK4jkV3mueyrKHaC3rFZGRFEJknn_QnWjfjLtW_k&e=>



----------------------------------------------------------------------
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.