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

[Ketan Talaulikar <[e-mail]>]

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 <[e-mail]>
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 <[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]>
> *Sent:* Tuesday, May 26, 2026 10:03 PM
> *To:* Linda Dunbar <[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)
>
>
>
> 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]>
> 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]>
> *Sent:* Tuesday, May 26, 2026 3:26 AM
> *To:* Linda Dunbar <[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)
>
>
>
> 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]>
> 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]>
> *Sent:* Friday, May 22, 2026 5:46 AM
> *To:* Linda Dunbar <[e-mail]>
> *Cc:* The IESG <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]; [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]>
> 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]>
> Sent: Thursday, May 21, 2026 7:00 AM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [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://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.
>
>
>
>
>
>
>
>
>
>