Return-Path: X-Original-To: bess@mail2.ietf.org Delivered-To: bess@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 5424BF611916 for ; Wed, 27 May 2026 10:41:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1779903706; bh=4pgv47lpcqGXFgt9UBvFIswPbepfeC5DwUR1tHSjKqk=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=B/OfjDSVdjj1FY5t6TXZjOnI0HV/LjJJfdEwuFhZwzf+0mBD/z8gVDeohA0C0DGfv Gio/3AjlypJwMFJZCtV8ixomp1AnhJXszYAmwtqI3DL2jTbcdNXSwAWfSK/dzGl5wN UOP9UNxQaKvPnQKtVyr56P4a1SxcsOaLI0dZb1sE= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p82YKmONR-bD for ; Wed, 27 May 2026 10:41:44 -0700 (PDT) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 056A8F61108B for ; Wed, 27 May 2026 10:41:12 -0700 (PDT) Received: by mail-pl1-x62e.google.com with SMTP id d9443c01a7336-2befd7eeb46so2761595ad.3 for ; Wed, 27 May 2026 10:41:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779903671; cv=none; d=google.com; s=arc-20240605; b=jiySvXlirB7OaOGvsSe2Vx1S7NiYCe1fCwqGxs0jCmC3g0lCy/iyd96d6+3Gkut9sD uXv6jNNIsBoUGLpI9NgLYcbRs59o2BWwD2fexGj//Cn2iA2Hm6gwMx5XfAim3EfWMDBq BFbhIQkml7DVLm0gTFB3LtaFYJcGWJIP9GX8cpwtV4d0Wk/HMNSYRqtH2vLitO8B7o0b RoYdjA/yOguaX57oF87Co11qIQoZ9tRuHQsvxDQBfQmKi09Ymx6ioPxOecr6wh9lxN+A IIgx9c3ZpHlsyf9Vdka/0nfzgGTG4W6S9GyD9YxUJTZMOmVYns234wVXDuIV971Hl3qw sJvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=AudhDFH9k7mnDuypMzNkz53dUqqTLciCck5CJ9b2E/Q=; fh=WYC10xlDlFdODv/q8CZuE1VUPEytZX/N6pb+CL96vlk=; b=PAyj+K1jJinA6fD67/7eRmzaCh4bW+1/sxNcLxOWomWkdg/KCkBDdSeKX4fML0Wo3K ubseyvsOM+55e6urUtjZJ1fRSK19tuxVFPdxYG5bW7QB6vuTFVsGeS2i94tQMPyH74be /703N4sJ4PWt/8nSCoDplevTe/E9y75RWLyI0lQoI2dPDvqjwR6HSXDVxG2gZXCRgkEn skIeu12wQjmOhx/CWEJKcr/jI6IselESyy3UHwoROt2DQgVUkOwe4klriSDx/nz6I49w rWmoG0ltZXuc1anULGLCEegEIHk9mnMEGu5lpbxBXuG2nmfUQhJNc7NnRhpbWZOQkXgn U9fg==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779903671; x=1780508471; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=AudhDFH9k7mnDuypMzNkz53dUqqTLciCck5CJ9b2E/Q=; b=eHs1iCA7uot0W/NkGKOY9HV7RzvsJqyAUJyZN8TNCg4yr197Fq9MFby+aP5NyKLeGk gBMkAxewiC3xrorH0Ys+SJh7uw1sUprj0T3m12Vjg6RYj3B5uPrSfyeJQGG8PkXcZycS 1mUmyFacPsmmEpjtVu0jX2kBkBKZ8mq9lPxSrpLlS+gKjVujd16F6u//dRfvvLMYP5Ah 0HxOM1ByWWwXuJonwNF58upAriRNYdQ5VfFjjlK/vMZwBZIjF5QZhh/tx3a2flMfLp1u mFf4snG2sq/mqbWoyzx9QAwmlfZptTrGm6oh/MQVrpBS4WHlqNUCLirwJC8ICyYruU5a f2GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779903671; x=1780508471; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=AudhDFH9k7mnDuypMzNkz53dUqqTLciCck5CJ9b2E/Q=; b=giEjek9eXU60h+NfgFFAN/Ft43Xap2Sovl+fJ9T3RF04iUYnkI7KdyDBLGSlk8LmUp PTnzr5iahSnNdo3/XsLuMiZ3vH1qNQvrRrolqUExRl0B2YFFVZLvBS16mG80LvIljGHJ AYUHX28/f8IQ6vmbylpC51/mxX09TRdia2fj8/rDCU3piQ6moe39AUlle9Em+h26Sg4P doxnZ5locvrTss70vu3ZtNg5uMUqO7UY19KFelZU023wTCCyqT8eZ96WwRZnORzRtKq2 Gbk1WHMHsREKVjg/tqkZem+s5DQ4RTH5hDnqjgmK5FJZBXj2uNv97qXkMT7x5k0vQINA gWmw== X-Forwarded-Encrypted: i=1; AFNElJ8WXfrlv/ZWaA9ft+zTMCKWSMufvKkJSMLfwyEtcSnWCDVdyy2MhmDEgxqh0+8+HLTAIKBY@ietf.org X-Gm-Message-State: AOJu0YwkkRveZhIcSs+bo8Zdfs9rdE+pcsxj1xEaK8UjIdi7ad30TEqZ /ecWIm+cbYuUhHKHA96y063KvJfprWWmEJbHmvC1wQK38RSwvZOtarXn1VThfq4LamK1NjUfKEb 4FOyzHNIP6HEyeMu5quSkFyd5fALvPko= X-Gm-Gg: Acq92OFVOIEfnitN+1Jzk6oTP5lsVcz5KXZlKDasAZ1LaJZMYvvQ3itLm9gg7MyyH8H GaJtLl5ICU+wX53xGUUVwDi4Dg5bz42Z9mSW5tZHnP8TxwJ+2BF7oDpQWuDROCAwAeH99lbD0IE 3BNg630ioSrSyXWxJFkJUbK9QtQ+YiKxMZN1RIUgZKHyMdvaA8cOy8JFRBgKTS6eoIBEzHs2y79 Xsc9NFej5qXnTf7uBi0sAVu96fix5iTdROkM3wDbu1NcX8VjFk9hLhgKrKRECKc0GYWyCVz3LCo cDg6blPgUZHr44et9xVRxOp4a8dtxdBqWzSgPacGZX0MHflFFs4= X-Received: by 2002:a17:903:1ac5:b0:2b2:4fe3:7b89 with SMTP id d9443c01a7336-2beb070c102mr265057215ad.38.1779903670917; Wed, 27 May 2026 10:41:10 -0700 (PDT) MIME-Version: 1.0 References: <177937197001.149314.17727989683225339964@dt-datatracker-6995bf6b4c-lv9zr> In-Reply-To: From: Ketan Talaulikar Date: Wed, 27 May 2026 23:10:59 +0530 X-Gm-Features: AVHnY4JDZbqe3WXBr1Q-z1QqzubBoJK2hpNSRh2RlfsIKXjXcbZsOYZbG0mlJak Message-ID: To: Linda Dunbar Content-Type: multipart/alternative; boundary="0000000000000a1e0e0652d01ebb" Message-ID-Hash: FJRGEA6JLPBH4STCIGJG5OPCOSPQWUD7 X-Message-ID-Hash: FJRGEA6JLPBH4STCIGJG5OPCOSPQWUD7 X-MailFrom: ketant.ietf@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-bess.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: The IESG , "bess-chairs@ietf.org" , BESS , "draft-ietf-bess-bgp-sdwan-usage.all@ietf.org" , "matthew.bocci@nokia.com" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bbess=5D_Re=3A_Ketan_Talaulikar=27s_Discuss_on_draft-ietf-bess-b?= =?utf-8?q?gp-sdwan-usage-32=3A_=28with_DISCUSS_and_COMMENT=29?= List-Id: BGP-Enabled ServiceS working group discussion list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000000a1e0e0652d01ebb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM Linda Dunbar wrote: > Ketan, Med, > > > > I have uploaded revision (v35) that incorporated Ketan latest markup and > resolutions to Med=E2=80=99s 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 > *Cc:* The IESG ; bess-chairs@ietf.org; BESS ; > draft-ietf-bess-bgp-sdwan-usage.all@ietf.org; matthew.bocci@nokia.com > *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] draf= t > normative. That would put this document on hold until another draft > completes, which may take an unknown amount of time. I have seen document= s > 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 ho= ld > 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 > *Sent:* Tuesday, May 26, 2026 10:03 PM > *To:* Linda Dunbar > *Cc:* The IESG ; bess-chairs@ietf.org; BESS ; > draft-ietf-bess-bgp-sdwan-usage.all@ietf.org; matthew.bocci@nokia.com > *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 M= ed > continue that discussion. > > > > Once this version is posted, I will update my ballot. > > > > Thanks, > > Ketan > > > > > > On Wed, May 27, 2026 at 6:26=E2=80=AFAM Linda Dunbar > 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 > *Sent:* Tuesday, May 26, 2026 3:26 AM > *To:* Linda Dunbar > *Cc:* The IESG ; bess-chairs@ietf.org; BESS ; > draft-ietf-bess-bgp-sdwan-usage.all@ietf.org; matthew.bocci@nokia.com > *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=E2=80=AFPM Linda Dunbar > wrote: > > Ketan, > > > > Thank you for the additional comments and suggestions. Please see the > proposed resolutions below, marked with [Linda2]. > > > > Linda > > > > *From:* Ketan Talaulikar > *Sent:* Friday, May 22, 2026 5:46 AM > *To:* Linda Dunbar > *Cc:* The IESG ; bess-chairs@ietf.org; bess@ietf.org; > draft-ietf-bess-bgp-sdwan-usage@ietf.org; matthew.bocci@nokia.com > *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 , 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 solution= s > exist (that you consider traditional?) that do not suffer from any of the= se > challenges. If they do, please substantiate that claim with references. W= hy > compare? Also, "traditional approach" is unspecified - aren't there SD-WA= N > solutions that do more than use the hub-and-spoke model? Why not just sta= te > 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 documentati= on > describes DMVPN tunnels being configured through Cisco Catalyst SD-WAN > Manager. However, we agree that it may not be appropriate for this docume= nt > to generalize such vendor-specific deployment practices or to rely on > vendor implementation references. Therefore, we can make the following > wording change: > > > > Old: > > =E2=80=9CIn small SD-WAN networks with a modest number of nodes, traditio= nal > 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.=E2=80=9D > > > > New: > > *=E2=80=9CIn small SD-WAN networks with a modest number of nodes, a hub-a= nd-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.=E2=80=9D* > > > > 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 choic= e > 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: > > =E2=80=9CIn 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.=E2=80=9D > > > > New: > > *=E2=80=9CIn 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 usin= g > Route Targets, and extensible encoding of tunnel-related attributes, whic= h > are especially useful as the network grows in size and complexity*.=E2=80= =9D > > > > 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-WA= N. > 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 wi= th > BGP? > > > > [Linda2] This document is about using BGP as the SD-WAN control plane. > Here, =E2=80=9Ctraditional=E2=80=9D was intended to refer to SD-WAN deplo= yments 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 wi= th > more specific wording, such as =E2=80=9Cproprietary SD-WAN control-plane > mechanisms.=E2=80=9D > > > > KT2> Thanks. Replacing "traditional" with the specific types of VPN/SD-WA= N > would help. > > > > > > > > Please search for "traditional" in the document. You will see many simila= r > comparisons and assertions that I am unsure are substantiated but more > importantly, they are probably unnecessary. > > > > [Linda2] Agree. We have searched for =E2=80=9Ctraditional=E2=80=9D throug= hout 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, wit= h > 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 parameter= s > 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 tunn= el > 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 classi= c > BGP-based VPNs is that SD-WAN edge nodes often include Internet-facing WA= N > 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 =E2=80=9Cclassic=E2=80=9D 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 an= d > their security parameters. Also, most SD-WAN solutions employ a high degr= ee > 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 configuratio= n > or provisioning outside of BGP? > > > > [Linda2] Agree. Section 5.1 has been revised to explain the rationale > more narrowly: =E2=80=9CBGP is well suited to these SD-WAN overlay contro= l-plane > functions because it provides standardized mechanisms, =E2=80=A6.=E2=80= =9D; Section 6.1.1 > has also removed the comparison with running IGP within each IPsec > tunnel..=E2=80=9D . The intended point is narrower: BGP can distribute c= lient > 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 Attribu= te > 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 stil= l > 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=E2=80=AFAM Linda Dunbar > 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 > Sent: Thursday, May 21, 2026 7:00 AM > To: The IESG > Cc: bess-chairs@ietf.org; bess@ietf.org; > draft-ietf-bess-bgp-sdwan-usage@ietf.org; matthew.bocci@nokia.com > 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=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-positions%2F= &data=3D05%7C02%7Clinda.dunbar%40futurewei.com%7C35d83c8756f94413745508deb7= 414751%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C639149688199996146%7CUn= known%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4= zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3DoxHEUk6zLddBfUdP= rZvZQIh96leymiB84hgv0wO563k%3D&reserved=3D0 > > > 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=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fdraft-ietf-bess-bgp-sdwan-usage%2F&data=3D05%7C02%7= Clinda.dunbar%40futurewei.com%7C35d83c8756f94413745508deb7414751%7C0fee8ff2= a3b240189c753a1d5591fedc%7C1%7C0%7C639149688200078779%7CUnknown%7CTWFpbGZsb= 3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp= bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3DBUVwWa%2F4fcBNEhwpIIEjLISM03arenA= RbijC5sTp5U0%3D&reserved=3D0 > > > > > > > > > ---------------------------------------------------------------------- > > 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. > > > > 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 proprietar= y > 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 issue= s > identifed at the top of this email will address this point. > > > > > > KT2> Is this suggested abstract ok? > > [Linda3] Yes. Thank you. > > > > > > 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 betwee= n > > 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-WA= N > > at the IETF is happening to enable such interoperability that is after al= l > > the purpose of the IETF. The BGP extensions are but a small portion of wh= at > > 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 informationa= l > 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/relate= d > protocol specifications [draft-ietf-idr-sdwan-edge-discovery] that use BG= P > 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 provid= es > shared context. How about the following wording change: > > =E2=80=9C*Publishing this material as an RFC establishes a shared underst= anding > of the SD-WAN problem space and deployment assumptions and can assist wit= h > future protocol development for BGP-based SD-WAN networks.=E2=80=9D* > > > > 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 o= r > 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 IPse= c > tunnel parameters using BGP UPDATE messages, potentially within in a sing= le > message that includes the Tunnel Encapsulation Attribute [SD-WAN-Discover= y]. > > > > 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 IPse= c > 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 Attribut= e > [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].* > > > > 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 h= as > 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 W= G > preferred to keep background material, scenarios, and usage context out o= f > 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 solutio= n. > I am ok if we can agree to disagree on this. I will not block the documen= t > on this account given the history of how we got here and the effort put i= n > 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? > > *=E2=80=9CThis 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.=E2=80=9D* > > > > > > > > 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 use= d > > to setup a BGP Session over it - i.e., in tunnel mode per RFC4301 with bo= th > > 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 cove= rs > > 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 th= e > designated RR is carried over a protected transport. When IPsec is used, > this means an IPsec-protected path between the edge and RR, typically usi= ng > IPsec tunnel mode, with IP addresses at both ends used to establish the B= GP > TCP session over that protected path. We also agree that BCP195/RFC9325 > gives general TLS/DTLS security recommendations and does not itself speci= fy > how to run BGP over TLS. Since there is no RFC that we should rely on her= e > 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 B= GP > 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. > > > > > > > > > > --0000000000000a1e0e0652d01ebb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Linda,

Thanks for expeditiously addr= essing most of my technical comments and retaining the reference to=C2=A0dr= aft-ietf-idr-sdwan-edge-discovery.

I will update m= y ballot on this document shortly to change my position from DISCUSS.
=

Thanks,
Ketan


<= div class=3D"gmail_quote gmail_quote_container">
On Wed, May 27, 2026 at 12:11=E2=80=AFPM Linda Dunbar <linda.dunbar@futurewei.com> = wrote:

Ketan, Med,

=C2=A0

I have uploaded revision (v35) that incorporated Ket= an latest markup and resolutions to Med=E2=80=99s comments: =C2=A0https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-us= age/

=C2=A0

Please let me know if you have more issues. <= u>

=C2=A0

Thank you very much,

Linda

From: Linda Dunbar
Sent: Tuesday, May 26, 2026 10:58 PM
To: Ketan Talaulikar <ketant.ietf@gmail.com>
Cc: The IESG <= iesg@ietf.org>; bess-chairs@ietf.org; BESS <bess@ietf.org>; draft-ietf-bess-bgp-sdwan-us= age.all@ietf.org; matthew.bocci@nokia.com
Subject: RE: Ketan Talaulikar's Discuss on draft-ietf-bess-bgp-s= dwan-usage-32: (with DISCUSS and COMMENT)

=C2=A0

Ketan,

=C2=A0

Thanks for the markup. I accepted your suggestion of= moving the other published RFC references you identified to Normative refe= rence.

=C2=A0

My hesitation is only with making the in-progress [S= D-WAN-Discovery] draft normative. That would put this document on hold unti= l 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 s= een cases where, by the time the dependency was finally cleared, authors ha= d moved on and it became difficult to complete the final publication update= s.

=C2=A0

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 wordin= g.

=C2=A0

We have revised the text so that the claims stand on= their own and [SD-WAN-Discovery] is cited only as one possible approach, n= ot 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?<= u>

=C2=A0

Thank you very much,

=C2=A0

Linda

=C2=A0

From: Ketan Talaulikar <ketant.ietf@gmail.com>
Sent: Tuesday, May 26, 2026 10:03 PM
To: Linda Dunbar <linda.dunbar@futurewei.com>
Cc: The IESG <= iesg@ietf.org>; bess-chairs@ietf.org; BESS <bess@ietf.org>; draft-ietf-bess-bgp-sdwan-usage.all@ietf.org; matthew.bocci@= nokia.com
Subject: Re: Ketan Talaulikar's Discuss on draft-ietf-bess-bgp-s= dwan-usage-32: (with DISCUSS and COMMENT)

=C2=A0

Hi Linda,

=C2=A0

Thanks for your response and for sharing the propose= d update. To help us conclude faster, I've provided the suggested chang= es (all of them related to references) in the Word document that you had sh= ared with tracked changes.

=C2=A0

I see that you are already discussing the nuances be= tween normative and informative references with Med. I concur with Med'= s observations and (I believe) the changes I've suggested align with th= em.=C2=A0I will let you and Med continue that discussion.

=C2=A0

Once this version is posted, I will update my ballot= .

=C2=A0

Thanks,

Ketan

=C2=A0

=C2=A0

On Wed, May 27, 2026 at 6:26=E2=80=AFAM Linda Dunbar <linda.dunbar@futurewei.com> wrote:

Ketan,

=C2=A0

Thank you. Please see the proposed resolution below = marked by [Linda3].

=C2=A0

Attached is the Diff file between v34 and the v33.

=C2=A0

Linda

=C2=A0

From: Ketan Talaulikar <ketant.ietf@gmail.com>
Sent: Tuesday, May 26, 2026 3:26 AM
To: Linda Dunbar <linda.dunbar@futurewei.com>
Cc: The IESG <= iesg@ietf.org>; bess-chairs@ietf.= org; BESS <bess@i= etf.org>; draft-ietf-bess-bgp-sdwan-usage.all@ietf.org; matthew.bocci@= nokia.com
Subject: Re: Ketan Talaulikar's Discuss on draft-ietf-bess-bgp-s= dwan-usage-32: (with DISCUSS and COMMENT)

=C2=A0

Hi Linda,

=C2=A0

Please check inline below for follow-up with KT2. Al= so, check all the way to the end of the email so you are not missing the pr= evious conversation where some points were still under discussion.

=C2=A0

You can submit the update directly or share the diff= if you would like to cross-check or discuss further.

=C2=A0

On Tue, May 26, 2026 at 12:48=E2=80=AFPM Linda Dunbar <linda.dunbar@futurewei.com> wrote:

Ketan,

=C2=A0

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

=C2=A0

Linda

=C2=A0

From: Ketan Talaulikar <ketant.ietf@gmail.com>
Sent: Friday, May 22, 2026 5:46 AM
To: Linda Dunbar <linda.dunbar@futurewei.com>
Cc: The IESG <= iesg@ietf.org>; bess-chairs@ietf.= org; bess@ietf.org; draft-ietf-bess-bgp-sdwan-usage@ietf.org; matthew.bocci@nokia.com
Subject: Re: Ketan Talaulikar's Discuss on draft-ietf-bess-bgp-s= dwan-usage-32: (with DISCUSS and COMMENT)

=C2=A0

Hi Linda,

=C2=A0

Thanks for the super fast response and for posting t= he update. Please check inline below for follow-up.

=C2=A0

For the <discuss-1>, I am highlighting a few o= ther text in the document that I find making asserts and comparisons that d= o not seem to be substantiated by details or reference. Can you please consider rephrasing these sentences?

=C2=A0

Section 5.1 says:

=C2=A0

=C2=A0 =C2=A0In small SD-WAN networks with a modest = number of nodes,
=C2=A0 =C2=A0traditional approaches such as the hub-and-spoke model, employ= ing
=C2=A0 =C2=A0Next Hop Resolution Protocol (NHRP)[RFC2332] or a centralized = hub
=C2=A0 =C2=A0managing edge nodes, including the mapping of local and public=
=C2=A0 =C2=A0addresses along with tunnel identifiers, has proven effective.=
=C2=A0 =C2=A0However, for larger SD-WAN networks, with more than 100 nodes = and
=C2=A0 =C2=A0encompassing diverse underlays, the conventional approach beco= mes
=C2=A0 =C2=A0increasingly complex, error-prone, and difficult to manage.=

=C2=A0

It is OK to reference NHRP as an IETF technology. Ca= n 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 subst= antiate that claim with references. Why compare? Also, "traditional ap= proach" is unspecified - aren't there SD-WAN solutions that do more than use the hub-and-spoke model? Why not ju= st state how things are done with BGP?

=C2=A0

[Linda2] NHRP i= s referenced because DMVPN-like IPsec/GRE overlay designs use NHRP for tunn= el endpoint resolution. Some SD-WAN products support or coexist with DMVPN-like deployment models; for example, Cisco documentation descri= bes DMVPN tunnels being configured through Cisco Catalyst SD-WAN Manager. H= owever, we agree that it may not be appropriate for this document to genera= lize such vendor-specific deployment practices or to rely on vendor implementation references. Therefore, we ca= n make the following wording change:

=C2=A0

Old:

=E2=80=9CIn 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 central= ized hub managing edge nodes, including the mapping of local and public addresses along with tunnel identifiers, has proven ef= fective. However, for larger SD-WAN networks, with more than 100 nodes and = encompassing diverse underlays, the conventional approach becomes increasin= gly complex, error-prone, and difficult to manage.=E2=80=9D

=C2=A0

New:<= /u>

=E2=80=9CIn small SD-WAN networks w= ith a modest number of nodes, a hub-and-spoke overlay model, including desi= gns that use Next Hop Resolution Protocol (NHRP) [RFC2332] for tunnel endpo= int 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 doc= ument describes how BGP can be used for that purpose.=E2=80=9D

=C2=A0

KT2> This text works.

=C2=A0

=C2=A0

=C2=A0 =C2=A0In summary, BGP combines scalability, r= obust policy enforcement,
=C2=A0 =C2=A0interoperability, and centralized security, making it an id= eal
=C2=A0 =C2=A0choice for managing SD-WAN overlay networks, particularly = as they
=C2=A0 =C2=A0grow in size and complexity.

=C2=A0

BGP is certainly a choice. Can you substantiate that= it is an ideal choice without supporting references that analyze the other= choices?

=C2=A0

[Linda2] Good s= uggestion. 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?

=C2=A0

Old:

=E2=80=9CIn summary, BGP combines scal= ability, robust policy enforcement, interoperability, and centralized secur= ity, making it an ideal choice for managing SD-WAN overlay networks, partic= ularly as they grow in size and complexity.=E2=80=9D

=C2=A0

New:

=E2=80=9CIn summary, BGP is well su= ited to these SD-WAN overlay control-plane functions because it provides st= andardized mechanisms for scalable route distribution, policy-based route p= ropagation, 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.=E2=80=9D

=C2=A0

KT2> This text also works.

=C2=A0

=C2=A0

A related point appears in section 5.1 and also in o= ther places in this document. There is a comparison between "tradition= al IPsec VPN" and SD-WAN. I do not understand the motivation for such comparisons. Are they not comparing apples and oranges? Is this d= ocument 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?

=C2=A0

[Linda2] This d= ocument is about using BGP as the SD-WAN control plane. Here, =E2=80=9Ctrad= itional=E2=80=9D 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 sp= ecific wording, such as =E2=80=9Cproprietary SD-WAN control-plane mechanism= s.=E2=80=9D

=C2=A0

KT2> Thanks. Replacing "traditional" wi= th the specific types of VPN/SD-WAN would help.

=C2=A0

=C2=A0

=C2=A0

Please search for "traditional" in the doc= ument. You will see many similar comparisons and assertions that I am unsur= e are substantiated but more importantly, they are probably unnecessary.

=C2=A0

[Linda2] Agree.= We have searched for =E2=80=9Ctraditional=E2=80=9D throughout the document= .

Here are the de= tailed changes:

=C2=A0

Section 3.2:

=C2=A0

Old :

A Homogeneous Encrypted SD-WAN shares = certain similarities with

=C2=A0=C2=A0 traditional IPsec VPN. Ho= wever, unlike IPsec VPNs, which are

=C2=A0=C2=A0 typically deployed in a p= oint-to-point fashion among a limited

=C2=A0=C2=A0 number of nodes, SD-WAN n= etworks can comprise a large number of

=C2=A0=C2=A0 edge nodes, all centrally= managed by a controller responsible for

=C2=A0=C2=A0 configurations and polici= es 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 mana= ged by an SD-WAN controller.

=C2=A0

Section 4.3:

Old:

In a BGP-controlled SD-WAN, BGP UPDATE= messages could be extended

=C2=A0=C2=A0 to propagate IPsec-relate= d attributes for each SD-WAN edge [SD-

=C2=A0=C2=A0 WAN-Discovery]. This appr= oach allows peers to receive and apply

=C2=A0=C2=A0 compatible cryptographic = parameters distributed over a secure

=C2=A0=C2=A0 channel between the SD-WA= N edge and its BGP RR, thereby

=C2=A0=C2=A0 simplifying IPsec tunnel = establishment and reducing reliance on

=C2=A0=C2=A0 traditional IKEv2 negotiation [RFC7296].

=C2=A0

New:

In a BGP-controlled SD-WAN, BGP UPD= ATE messages could be extended to propagate IPsec-related attributes for ea= ch SD-WAN edge [SD-WAN-Discovery]. These attributes allow SD-WAN edges to r= eceive compatible IPsec parameters from the RR over a protected BGP session. By leveraging the authenticated and autho= rized relationship between each SD-WAN edge and the RR, this approach can s= implify IPsec tunnel establishment and reduce or eliminate the need for sep= arate per-peer IKEv2 authentication between SD-WAN edges, depending on the deployment model [RFC7296] (see Sec= tion 5.1 and Section 7).

=C2=A0

=C2=A0

Section 5.1:

Old:

Unlike traditional IPsec VPN where IPsec tunnels between two edge nodes = are treated as independent parallel links requiring duplicated control plan= e messages for load sharing, BGP in an SD-WAN context can associate multiple service flows with shared tunnel parameters= , reducing repeated signaling.

=C2=A0

New:

When an IGP such as OSPF is run ove= r IPsec tunnel interfaces, routing adjacencies are typically established pe= r 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.

=C2=A0

=C2=A0

Section 6.1.1:<= /span>

Old:<= /u>

Instead of running IGP within each IPs= ec tunnel, as is common in traditional IPsec VPN, the BGP RR = can propagate the client route UPDATE messages to authorized SD-WAN edges b= ased on configured policies.

=C2=A0

New:

In a BGP-controlled SD-WAN, the BGP= RR can propagate the client route UPDATE messages to authorized SD-WAN edg= es based on configured policies.

=C2=A0

=C2=A0

Section 8:

Old:

The primary operational difference bet= ween SD-WAN deployments and traditional BGP-based VPNs is that= SD-WAN edge nodes often include Internet-facing WAN ports,

=C2=A0

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,

=C2=A0

=C2=A0

KT2> All of these are good. For the last one, ins= tead of "classic", perhaps you are referring to BGP L3VPN and/or = EVPN? If so, please provide informative reference to those specific RFCs?

=C2=A0

[Linda3] Ok, r= emoved =E2=80=9Cclassic=E2=80=9D and added the reference:<= /u>

=C2=A0<= u>

New:

A primary operational difference b= etween SD-WAN deployments and BGP/MPLS IP VPNs [RFC4364][RFC4659]is that SD= -WAN edge nodes often include Internet-facing WAN ports, which introduce ad= ditional security, filtering, and policy-enforcement requirements that are not typically present in BGP/MPLS IP VPN environment= s.

=C2=A0

=C2=A0

Section 6.1.1 says

=C2=A0

=C2=A0 =C2=A0Instead of running IGP within each IPse= c tunnel, as is common in
=C2=A0 =C2=A0traditional IPsec VPN, the BGP RR can propagate the client rou= te
=C2=A0 =C2=A0UPDATE messages to authorized SD-WAN edges based on configured=
=C2=A0 =C2=A0policies. The SD-WAN edges use BGP attributes-such as the Tunn= el
=C2=A0 =C2=A0Encapsulation Attribute and associated Color values-to associa= te
=C2=A0 =C2=A0received client routes with the appropriate IPsec Security
=C2=A0 =C2=A0Associations (SAs), thereby eliminating the need for manual =C2=A0 =C2=A0configuration of tunnel endpoints and service policies on each=
=C2=A0 =C2=A0edge node.

=C2=A0

SD-WAN is a rich service with several policies beyon= d tunnel endpoints and their security parameters.=C2=A0Also, most SD-WAN so= lutions employ a high degree of automation, resulting in minimal manual configuration. Is the claim of "eliminating the need f= or manual configuration" substantiated? Does everything required for t= raffic flow management, steering and service configuration arrive via the B= GP protocol without any manual configuration or provisioning outside of BGP?

=C2=A0

[Linda2] Agree.= =C2=A0 Section 5.1 has been revised to explain the rationale more narrowly:= =E2=80=9CBGP is well suited to these SD-WAN overlay control-plane function= s because it provides standardized mechanisms, =E2=80=A6.=E2=80=9D; Section = 6.1.1 has also removed the comparison with running IGP within each IPsec tu= nnel..=E2=80=9D .=C2=A0 The intended point is narrower: BGP can distribute = client reachability and tunnel-association information using standardized mechanisms,...

=C2=A0

Here is the upd= ated paragraph:

In a BGP-controlled SD-WAN, the BGP= RR can propagate client route UPDATE messages to authorized SD-WAN edges b= ased on configured policies. The SD-WAN edges use BGP attributes, such as t= he Tunnel Encapsulation Attribute and associated Color values, to associate received client routes with the appropriate IPs= ec Security Associations (SAs), thereby reducing per-edge configuration of = tunnel endpoint associations. Other SD-WAN service policies, traffic-steeri= ng rules, and device-specific parameters may still be provisioned by the SD-WAN controller or local configuration.<= /span>

=C2=A0

=C2=A0

KT2> This is good as well. Thanks.<= /p>

=C2=A0

=C2=A0

=C2=A0

On Fri, May 22, 2026 at 12:15=E2=80=AFAM Linda Dunbar <linda.dunbar@futurewei.com> wrote:

Ketan,

=C2=A0

Thank you very much for the comments and the suggestions.

Please see below of the proposed resolutions marked by [Linda] an= d let us know if they are acceptable.

=C2=A0

Thank you, Linda

=C2=A0

-----Original Message-----
From: Ketan Talaulikar via Datatracker <noreply@ietf.org>
Sent: Thursday, May 21, 2026 7:00 AM
To: The IESG <iesg@ie= tf.org>
Cc: bess-chairs@i= etf.org; bess@ietf.org; draft-ietf-bess-bgp-sdwan-usage@ietf.org; matthew.bocci@nokia.com
Subject: Ketan Talaulikar's Discuss on draft-ietf-bess-bgp-sdwan-usage-= 32: (with DISCUSS and COMMENT)

=C2=A0

Ketan Talaulikar has entered the following ballot position for

draft-ietf-bess-bgp-sdwan-usage-32: Discuss<= /p>

=C2=A0

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.)<= /u>

=C2=A0

=C2=A0

for more information about how to handle DISCUSS and COMMENT posi= tions.

=C2=A0

=C2=A0

The document, along with other ballot positions, can be found her= e:

=C2=A0

=C2=A0

=C2=A0

-----------------------------------------------------------------= -----

DISCUSS:

-----------------------------------------------------------------= -----

=C2=A0

Thanks to the authors and the WG for their work on this document.=

=C2=A0

I have a few high-level aspects in this document that I would lik= e to discuss.

=C2=A0

<discuss-1> The abstract of this document says:

=C2=A0

=C2=A0=C2=A0 This document explores the complexities involved in = managing large

=C2=A0=C2=A0 scale Software Defined WAN (SD-WAN) overlay networks= , along with

=C2=A0=C2=A0 various SD-WAN scenarios. Its objective is to illust= rate how a

=C2=A0=C2=A0 BGP-based control plane can effectively manage these= overlay

=C2=A0=C2=A0 networks by distributing edge service reachability i= nformation,

=C2=A0=C2=A0 WAN port attributes, and underlay path details, ther= eby minimizing

=C2=A0=C2=A0 manual provisioning.

=C2=A0

To my knowledge there are SD-WAN solutions from several vendors t= hat are

widely deployed today. Some of them use IETF protocols for specif= ic

functionalities while others use proprietary mechanisms (here I a= m 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 comp= arison

between a BGP-based solution that is not fully specified (not eve= n the

framework is specified) in this document against solutions deploy= ed out

there.

=C2=A0

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 s= olution?

E.g., the first sentence is problematic since it can be read as e= xisting

solutions have complexities that are solved by BGP without any su= pporting

evidence or evaluation of those other solutions.=

=C2=A0

[Linda] Very good point. How about the follo= wing change for the Abstract?

Old:

Its objective is to illustrate how a BGP-= based control plane can effectively manage these overlay networks...

=C2=A0

New:

Its objective is to illustrate how a BGP-= based control plane can be used to manage these overlay networks...

=C2=A0

Add the following sentence at the end of the= Abstract:

In such deployments, BGP can provide a st= andards-based mechanism for distributing information that may otherwise be exchanged using proprietary SD-WAN control-plane mechanis= ms.

=C2=A0

KT> Thanks. That helps. However the first sentenc= e still remains. How about the following abstract?

=C2=A0

= =C2=A0 =C2=A0This document illustrates how a BGP-based control plane can be
=C2=A0 =C2=A0used to manage large scale Software Defined WAN (SD-WAN) overl= ay
=C2=A0 =C2=A0networks by distributing edge service reachability information= ,
=C2=A0 =C2=A0WAN port attributes, and underlay path details, thereby minimi= zing
=C2=A0 =C2=A0manual provisioning. In such deployments, BGP can provide a =C2=A0 =C2=A0standards-based mechanism for distributing information that ma= y
=C2=A0 =C2=A0otherwise be exchanged using proprietary SD-WAN control-plane<= br> =C2=A0 =C2=A0mechanisms.

[Linda3] Thank= s for the suggestion. Changed. Sorry that I missed it yesterday. =C2=A0

KT> This change along with an appropriate rephras= ing of the similar issues identifed at the top of this email will address t= his point.

=C2=A0

=C2=A0

KT2> Is this suggested abstract ok?=

[Linda3] Yes. = Thank you. =C2=A0

=C2=A0

=C2=A0

<discuss-2> Introduction section says:=

=C2=A0

=C2=A0=C2=A0 This document captures the SD-WAN scenarios, control= -plane

=C2=A0=C2=A0 behaviors, and forwarding considerations that motiva= te current and

=C2=A0=C2=A0 future IETF work on SD-WAN. Publishing this material= as an RFC

=C2=A0=C2=A0 provides a stable, citable foundation for related pr= otocol

=C2=A0=C2=A0 specifications and ensures a shared understanding of= the problem

=C2=A0=C2=A0 space across the industry.

=C2=A0

As mentioned in the previous point, there are multiple SD-WAN sol= utions

that have been developed by various vendors using IETF technologi= es

like BGP (but with proprietary extensions) or entirely proprietar= y

solutions. AFAIK, none of these solutions support interoperabilit= y between

SD-WAN gateways and controllers from different vendors. Please co= rrect

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 porti= on of what

an SD-WAN solution entails. Do the claims made in that text hold?=

=C2=A0

Why not just say "This document captures the SD-WAN scenario= s, control-plane

behaviors, and forwarding considerations using BGP." or some= thing like that?

=C2=A0

[Linda] Thanks for the suggestion. We will t= ake 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 mate= rial as an RFC provides a stable, citable foundation for related protocol s= pecifications and ensures a shared understanding of the problem space acros= s the industry. Although BGP and IPsec are mature technologies, applying them to SD-WAN introduces challeng= es such as scalability, segmentation, and multi-homing. By documenting how = these mechanisms are used in SD-WAN deployments, this document enables cons= istent 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 mate= rial as an RFC provides a stable, citable foundation for related protocol s= pecifications 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.<= /p>

=C2=A0

KT> Thanks. Just one point and suggestion below:<= u>

=C2=A0

= 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 av= oid creating an unintended dependency on a specific protocol-extension draf= t, we prefer to keep this sentence generic rather than naming [SD-WAN-Discovery] here. This document is Informational and does not speci= fy the BGP extensions defined in [SD-WAN-Discovery]. The purpose of this pa= ragraph is only to state that the usage document provides shared context. H= ow about the following wording change:

=E2=80=9CPublishing this material = as an RFC establishes a shared understanding of the SD-WAN problem space an= d deployment assumptions and can assist with future protocol development fo= r BGP-based SD-WAN networks.=E2=80=9D

=C2=A0

Also, for the text in section 5.3, doesn't=C2=A0= draft-ietf-idr-sdwan-edge-discovery become a normative reference?=

=C2=A0

KT2> Have these changes been considered?

[Linda3] This = document is Informational and does not require implementation of [SD-WAN-Di= scovery] to understand the SD-WAN scenarios or the BGP usage described here. [SD-WAN-Discovery] is cited only as an example of one poss= ible protocol extension/encoding in Section 5.1 and Section 5.2. To make it= clearer, we can make the following wording change:

=C2=A0<= u>

Section 5.1:

Old:

In networks with multiple IPsec tunne= ls between SD-WAN edges, BGP can simplify tunnel management by using the SD= -WAN edge discovery mechanism defined in [SD-WAN-Discovery] to advertise WA= N-port properties and IPsec-related parameters.

=C2=A0

New:

In networks with multiple IPsec tu= nnels between SD-WAN edges, BGP can simplify tunnel management by advertisi= ng WAN-port properties and IPsec-related parameters. One possible approach = for carrying such information is described in [SD-WAN-Discovery].

=C2=A0

Section 5.2:

=C2=A0Old:

In a BGP-controlled Homogeneous Encry= pted 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 messa= ges, potentially within in a single message that includes the Tunnel Encapsulation Attribute [SD-WAN-Discovery].

=C2=A0

New:

In a BGP-controlled Homogeneous En= crypted SD-WAN, an SD-WAN edge (i.e., C-PE) could advertise both its attach= ed client routes and associated IPsec tunnel parameters using BGP UPDATE me= ssages. One possible approach using the Tunnel Encapsulation Attribute is described in [SD-WAN-Discovery].<= /u>

=C2=A0

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 parame= ters needed to associate those routes with the appropriate IPsec tunnel.

=C2=A0

New:

the BGP UPDATE message from C-PE2 = to RR can include the client routes in the MP-NLRI Path Attribute and can u= se 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].

=C2=A0

<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 pla= ce, I do not

understand the value or benefit of publication of this document v= ia the IETF

track. It could as well be via ISE?

=C2=A0

[Linda] This document is limited to BGP usag= e for SD-WAN overlay control-plane scenarios; it is not intended to define a complete SD-WAN solution. The document has been discu= ssed 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 mat= erial, scenarios, and usage context out of the protocol-extension draft and= instead reference this SD-WAN usage document for that material.<= /u>

There is precedent for BESS publishing Infor= mational 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.

=C2=A0

=C2=A0

KT> This point was exactly about the fact that th= ere is no end-to-end solution for a BGP-based SD-WAN solution being specifi= ed or worked on in the IETF. Without that, these documents represent efforts that cannot achieve a truly standards-based interoperabl= e 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?

=E2=80=9CThis document is informat= ional and does not specify a complete SD-WAN solution. Its scope is limited= to selected SD-WAN overlay control-plane functions, such as distributing e= dge reachability, WAN-port attributes, tunnel-related information, and policy-constrained routes.=E2=80=9D<= /u>

=C2=A0

=C2=A0

=C2=A0

<discuss-4> Section 3.1.5 says

=C2=A0

=C2=A0=C2=A0 An SD-WAN edge must use a secure channel, such as TL= S following

=C2=A0=C2=A0 BCP195[RFC9325] or Ipsec [RFC4301], to its designate= d RR for

=C2=A0=C2=A0 exchanging BGP UPDATE messages.=

=C2=A0

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 app= ropriate

reference?

=C2=A0

[Linda] The intent is that the BGP session b= etween the SD-WAN edge and the designated RR is carried over a protected transport. When IPsec is used, this means an IPsec-protec= ted path between the edge and RR, typically using IPsec tunnel mode, with I= P addresses at both ends used to establish the BGP TCP session over that pr= otected path. We also agree that BCP195/RFC9325 gives general TLS/DTLS security recommendations and does no= t itself specify how to run BGP over TLS. Since there is no RFC that we sho= uld 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:

=C2=A0

Old:

An SD-WAN edge must use a secure channel, su= ch as TLS following BCP195[RFC9325] or Ipsec [RFC4301], to its designated RR for exchanging BGP UPDATE messages.<= /u>

=C2=A0

New: Section 3.1.5

An SD-WAN edge must exchange BGP UPDATE mess= ages with its designated RR over a protected transport. For example, IPsec [RFC4301] can be used to protect the path between the S= D-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 outsi= de the scope of this document.

=C2=A0

=C2=A0

KT> Thanks, this addresses my concern. Please run= idnits on the document and it will put out several warnings related to ref= erences that should be addressed. e.g., BCP195 reference to be removed.

=C2=A0

KT2> And this aspect too.

=C2=A0

Thanks,

Ketan

=C2=A0

=C2=A0

=C2=A0

Thanks,

Ketan

=C2=A0

=C2=A0

=C2=A0

Linda

-----------------------------------------------------------------= -----

COMMENT:

-----------------------------------------------------------------= -----

=C2=A0

I support the DISCUSS position of Med.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

--0000000000000a1e0e0652d01ebb--