Hi, Linda:
I recommended also that this document could refer to section 6 of https://www.mplify.net/resources/mplify-119-universal-sd-wan-edge-implementa tion-agreement/ as mentioned https://mailarchive.ietf.org/arch/msg/bess/kUyUXe8myckcwJRjv2NoXFVaigQ/ in by Najem. Such contents describes more clearly the motivation of standard protocol that can be applied in SD-WAN scenarios. Regarding to your responses, I have still the following comments/suggestions: 1. Section 3.1 of the current draft is not the framework and the scenarios described in section 3.2/3.3/3.4 doesn't get the key necessaries of the standard protocol. 2. Should "Scenario #3" be clarified also into the "Scenario #2", although the scenario is different, the solution is similar. I suggest to remove the scenario #3, because it is uncommon for the PEs to utilize the SD-WAN technology. 3. Section 4 should be actually "Provisioning Requirements", not "Model"? it determines what contents should be delivered via the BGP protocol, right? 4. If you want to keep section 6 of the "SD-WAN forwarding model", it is OK. For simplicity, removing the section 6.3? is there any extra requirements for the BGP protocol, when compared it with section 6.2 for "Hybrid underlay SD-WAN"? Best Regards Aijun Wang China Telecom From: [email protected] [mailto:[email protected]] On Behalf Of Linda Dunbar Sent: Tuesday, September 9, 2025 5:40 AM To: Aijun Wang <[email protected]>; 'Chongfeng Xie' <[email protected]>; 'Matthew Bocci (Nokia)' <[email protected]>; 'bess' <[email protected]> Cc: [email protected] Subject: [bess] Re: WG Last Call for draft-ietf-bess-bgp-sdwan-usage Aijun, The BGP described in this document is the iBGP instance that controls the SD-WAN overlay, not the underlay BGP sessions. In this model, the SD-WAN controller includes the Route Reflector function, distributing overlay routes and tunnel attributes to edge sites. While sites normally connect to a single SD-WAN controller, using BGP for the overlay still provides clear benefits in scalability, policy distribution, and interoperability that proprietary solutions cannot match. Here are the responses to your other comments: 1. The document focus on the "BGP Usage for SD-WAN Overlay Networks", then, can we remove the section 6 of "SD-WAN Forwarding Model" which focuses mainly on the forwarding plane, not BGP usage? [Linda] Section 6 should remain because, while the draft focuses on BGP as the control plane, it is important to show how the attributes BGP distributes (such as tunnel parameters and colors) are actually applied in the SD-WAN forwarding plane. Many BGP RFCs include forwarding-plane context for clarity-for example, RFC 4271 (BGP-4) describes how NEXT_HOP affects forwarding, RFC 4364 (BGP/MPLS IP VPNs) explains how BGP routes map to MPLS label forwarding, and RFC 7432 (EVPN) details how BGP-distributed information drives Ethernet data-plane behavior. Removing Section 6 would make the usage description incomplete. 2. Should the document introduce first the scenario, and requirements, and then the BGP controlled SD-WAN? That is to say, put the current section 3.1 after the section 3.2/3.3/3.4? [Linda] The reason Section 3.1 introduces the BGP-controlled SD-WAN framework first is to establish the control-plane context before diving into detailed scenarios and requirements. This ordering follows the style of many BGP-related RFCs, where the control-plane architecture is introduced early and then illustrated by scenarios and requirements. That said, we can certainly revisit the section ordering if the WG feels that leading with scenarios (Sections 3.2/3.3/3.4) and then returning to the BGP framework would improve readability. 3. Should the authors review again the current "requirements" with the section 5, and evaluate again whether the section 5 meets the current "requirements"? for example, can the "Zero Touch Provisioning" is accomplished via the BGP protocol? If not, I suggest to remove such requirements. [Linda] We agree that requirements should be aligned with what BGP can realistically provide. While Zero Touch Provisioning (ZTP) is not delivered by BGP alone, our approach uses BGP to exchange the IPsec-related parameters, under the assumption that the Route Reflector already has a trusted relationship with the edge for basic configuration and route exchange. This allows the IKEv2 negotiation step to be eliminated, which in turn simplifies and accelerates the process of achieving ZTP for IPsec establishment. How about adding the following sentence at the end of Section 4.3 (IPsec Related Parameters Provisioning): "This mechanism supports the ZTP requirement outlined in Section 3.1.4 by enabling IPsec tunnels to be provisioned without IKEv2 negotiation." 4. As I known, current SD-WAN deployment is mainly implemented via the vendor's proprietary protocol, because the complex policy requirements. Can the authors explain more the benefits that depends on BGP, instead of the proprietary protocol to accomplish the similar aim? And, if we need still the controller, why don't use the proprietary protocol, instead of extending the BGP protocol? [Linda] The document already addresses this point in Section 5.1 (Rationale for Using BGP as the Control Plane for SD-WAN). While proprietary protocols have been common in early SD-WAN deployments, BGP provides significant advantages: it is a well-understood, widely deployed standard, scales through mechanisms like route reflection, and enables interoperability across multi-vendor environments. The controller remains necessary for centralized policy distribution, but extending BGP allows us to achieve this using an open protocol rather than relying on proprietary mechanisms. We can make sure Section 5.1 is more clearly cross-referenced earlier in the draft, so readers do not miss this rationale. Thank you, Linda From: Aijun Wang < <mailto:[email protected]> [email protected]> Sent: Monday, September 8, 2025 1:51 AM To: 'Chongfeng Xie' < <mailto:[email protected]> [email protected]>; 'Matthew Bocci (Nokia)' < <mailto:[email protected]> [email protected]>; 'bess' < <mailto:[email protected]> [email protected]> Cc: <mailto:[email protected]> [email protected] Subject: RE: [bess] Re: WG Last Call for draft-ietf-bess-bgp-sdwan-usage Hi, Chongfeng: The standard BGP protocol can certainly unlock the customer to one specific SD-WAN service provider. But given the scenario in this document depends on the SD-WAN controller, it is unrealistic that the different sites of one customer connect to different SD-WAN controllers. Normally, these sites of the customer will connect one SD-WAN controller, then, the advantage of BGP protocol, when compared with the prosperity protocol, is not very convinced. Best Regards Aijun Wang China Telecom From: Chongfeng Xie [ <mailto:[email protected]> mailto:[email protected]] Sent: Monday, September 8, 2025 1:35 PM To: Aijun Wang < <mailto:[email protected]> [email protected]>; Matthew Bocci (Nokia) < <mailto:[email protected]> [email protected]>; bess < <mailto:[email protected]> [email protected]> Cc: <mailto:[email protected]> [email protected] Subject: Re: [bess] Re: WG Last Call for draft-ietf-bess-bgp-sdwan-usage Hi Aijun, For point 4 you raised, I think current proprietary protocol-based implementations have limited deployment scale, in addition, for users are bound to a specific service provider, it constrains users' choices. Therefore, It is necessary to propose new alternative solutions. Best regards Chongfeng From: <mailto:[email protected]> Aijun Wang Date: 2025-09-08 12:09 To: <mailto:[email protected]> 'Matthew Bocci \(Nokia\)'; <mailto:[email protected]> 'BESS' CC: <mailto:[email protected]> draft-ietf-bess-bgp-sdwan-usage Subject: [bess] Re: WG Last Call for draft-ietf-bess-bgp-sdwan-usage Hi, All: I have reviewed roughly this document, and have the following comments before its publication: 1) The document focus on the "BGP Usage for SD-WAN Overlay Networks", then, can we remove the section 6 of "SD-WAN Forwarding Model" which focuses mainly on the forwarding plane, not BGP usage? 2) Should the document introduce first the scenario, and requirements, and then the BGP controlled SD-WAN? That is to say, put the current section 3.1 after the section 3.2/3.3/3.4? 3) Should the authors review again the current "requirements" with the section 5, and evaluate again whether the section 5 meets the current "requirements"? for example, can the "Zero Touch Provisioning" is accomplished via the BGP protocol? If not, I suggest to remove such requirements. 4) As I known, current SD-WAN deployment is mainly implemented via the vendor's proprietary protocol, because the complex policy requirements. Can the authors explain more the benefits that depends on BGP, instead of the proprietary protocol to accomplish the similar aim? And, if we need still the controller, why don't use the proprietary protocol, instead of extending the BGP protocol? Answering the above questions, and make the above adjustment, can convince the reader better and make the document's motivation more clearly. Best Regards Aijun Wang China Telecom From: <mailto:[email protected]> [email protected] [ <mailto:[email protected]> mailto:[email protected]] On Behalf Of Matthew Bocci (Nokia) Sent: Wednesday, August 27, 2025 7:05 PM To: BESS < <mailto:[email protected]> [email protected]> Cc: <mailto:[email protected]> [email protected] Subject: [bess] WG Last Call for draft-ietf-bess-bgp-sdwan-usage This email begins a working group last call for <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack er.ietf.org%2Fdoc%2Fdraft-ietf-bess-bgp-sdwan-usage%2F&data=05%7C02%7Clinda. dunbar%40futurewei.com%7C802d0474791c42bcad3708ddeeb4e1ae%7C0fee8ff2a3b24018 9c753a1d5591fedc%7C1%7C0%7C638929182873283390%7CUnknown%7CTWFpbGZsb3d8eyJFbX B0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj oyfQ%3D%3D%7C0%7C%7C%7C&sdata=BULGfVgTS8K9OplS21MLrHQjT1Bo8a1wkR3MgIZXvBs%3D &reserved=0> draft-ietf-bess-bgp-sdwan-usage-26 - BGP Usage for SD-WAN Overlay Networks Please review the draft and send any comments to the BESS WG list, including whether (or not) you support publishing this draft as an informational RFC. A bit of background: the draft was previously sent to the IESG but was returned to the working group after extensive review/discussion and due to some concerns that it was not in charter at the time. The BESS WG charter has recently been clarified. This WG last call ends on Wednesday 10th September. Matthew
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
