Thanks Linda; Please see my comments below in red.
Best Regards; Basil From: Linda Dunbar <[email protected]> Sent: November-13-25 7:02 PM To: Najem, Basil <[email protected]>; Matthew Bocci (Nokia) <[email protected]>; Aijun Wang <[email protected]>; 'Chongfeng Xie' <[email protected]>; 'bess' <[email protected]> Cc: [email protected] Subject: [EXT]RE: [bess] Re: WG Last Call for draft-ietf-bess-bgp-sdwan-usage Najem, Thanks. Please see the resolutions below and the attached document with the change. Please let us know if all your comments are addressed. Linda From: Najem, Basil <[email protected]<mailto:[email protected]>> Sent: Thursday, November 13, 2025 1:18 PM To: Linda Dunbar <[email protected]<mailto:[email protected]>>; Matthew Bocci (Nokia) <[email protected]<mailto:[email protected]>>; Aijun Wang <[email protected]<mailto:[email protected]>>; 'Chongfeng Xie' <[email protected]<mailto:[email protected]>>; 'bess' <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: RE: [bess] Re: WG Last Call for draft-ietf-bess-bgp-sdwan-usage Thanks Linda; I reviewed revision 28; quick comments: 1. Re "SD-WAN edge": We need to stay consistent (as per your comment); I still see some occurrences of this term are either capitalized or written like "SDWAN-Edge" or "SDWAN-edge"..etc. Please make sure you update that. [Linda] thanks for pointing them out. They are all changed to "SDWAN edge" in the document attached. [Basil] Thanks for that; I still see occurrences with "Edge" capitalized (e.g. first sentence in section 3.1.5; Page 17; section 5.2; end of Page 18; Page 21; and Page 25); can you please do another "find and replace" and make the necessary change? Re "Figure 4": I have no issue with your resolution; however, I didn't see any reference in the figure or in the preceding paragraph to the figure indicating that C3, D2, A1, and B2 interfaces are forwarding the traffic to the Internet. Can you please update that? [Linda] How about changing the paragraph right before the Figure 4 to the following: "In the figure below, In the figure below, each C-PE has both Internet-facing and private-VPN interfaces (e.g., A1, B2, C3, and D2 connect to the Internet, while others connect to the private VPN). The WAN ports' addresses can be allocated by the service providers or dynamically assigned (e.g., by DHCP)." And change the Figure4 Caption to the following: "Figure4: SD-WAN with Internet facing ports (A1, B2, C3, D2)" [Basil] Thanks for that and I accepted. I don't think you need to have "in the figure below" twice; keep only one please. Best Regards; Basil From: Linda Dunbar <[email protected]<mailto:[email protected]>> Sent: November-13-25 3:21 PM To: Najem, Basil <[email protected]<mailto:[email protected]>>; Matthew Bocci (Nokia) <[email protected]<mailto:[email protected]>>; Aijun Wang <[email protected]<mailto:[email protected]>>; 'Chongfeng Xie' <[email protected]<mailto:[email protected]>>; 'bess' <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: [EXT]RE: [bess] Re: WG Last Call for draft-ietf-bess-bgp-sdwan-usage Najem, Thanks for the comments. Please see below of the resolutions. Linda From: Najem, Basil <[email protected]<mailto:[email protected]>> Sent: Tuesday, November 11, 2025 12:25 PM To: Linda Dunbar <[email protected]<mailto:[email protected]>>; Matthew Bocci (Nokia) <[email protected]<mailto:[email protected]>>; Aijun Wang <[email protected]<mailto:[email protected]>>; 'Chongfeng Xie' <[email protected]<mailto:[email protected]>>; 'bess' <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: RE: [bess] Re: WG Last Call for draft-ietf-bess-bgp-sdwan-usage Thanks Linda for updating the document; I have the following comments on the updated document: 1. We should NOT reference both MEF 70.1 & MEF 70.2 in the document; MEF 70.2 has superseded MEF 70.1 and therefore we should ONLY reference 70.2 (i.e. replace the reference to MEF 70.1 with MEF 70.2 where applicable) [Linda] got it. Removed all reference to MEF70.1, using MEF70.2 instead. 1. Page 3, Introduction Section: in the "Policy-Based Traffic Steering" sub-bullet, change the last sentence to read: "Tables 8 & 9 in [MEF 70.2] include more details on traffic classification that can be used by the SD-WAN Policies" (we need to refer to the correct tables from MEF 70.2, not MEF 70.1) [Linda] changed in -28 revision 1. Page 5, Convention used in this document Section: Multiple comments on the "SD-WAN Edge Node" term: * MEF 70.2 defines the term "SD-WAN Edge". I suggest add the following sentence (after the end of the definition) "SD-WAN Edge Node, in this document, and the SD-WAN Edge, in [MEF 70.2], are synonyms" [Linda] to make it simpler, the SD-WAN edge is used across the document. * In this document the term "SD-WAN Edge Node" is NOT always capitalized and even sometimes it's written as "SD-WAN edge" (i.e. without the word "Node"). I suggest we stay consistent and capitalize the term "SD-WAN Edge Node" in the document and DO NOT use a truncated version of this term (i.e. use "SD-WAN Edge Node' NOT "SD-WAN Edge") [Linda] Have revised the document to use the consistent term "SD-WAN edge(s)" throughout. The term is used in lowercase, following IETF convention, where functional node roles (e.g., router, edge, controller) are not capitalized. This ensures clarity and consistency across the document without implying a proper name or specific product.. 1. Page 6, Convention used in this document Section: ZTP is an acronym for a term (Zero Touch Provisioning) without any definition for the term. I suggest we use the definition in section 3.1.4 to read " Zero-Touch Provisioning is a network automation approach that enables the automatic provisioning and configuration of SD-WAN devices, such as routers and switches, at remote locations without requiring manual intervention" [Linda] Okay, updated the Section 2 definition of ZTP to the following (similar concepts and mechanisms are described in RFC 8995 (Bootstrapping Remote Secure Key Infrastructure - BRSKI), which provides an IETF reference framework for secure zero-touch onboarding and provisioning): "Zero Touch Provisioning (ZTP): a network automation approach that enables automatic provisioning and configuration of SD-WAN devices, such as routers and switches, at remote locations without manual intervention." 1. Page 13, Figure 4: if the traffic from interface C3 & interface D2 is meant to be directed to the internet (as explained before the figure), we need a dotted rectangle (between the two interfaces) to refer to the Internet. The figure (now) is misleading as it shows these two interfaces are connected to each other over "untrusted" network without any encryption (which is not the intent). Update the figure accordingly please. [Linda] The dotted line in Figure 4 is only meant to represent a logical connection, not a direct or unencrypted link between interfaces C3 and D2. It does not indicate that the two interfaces are physically connected to each other. The intent is simply to show that both interfaces have connectivity toward an untrusted network (e.g., the Internet). We believe adding an additional dotted rectangle for the Internet may not be necessary, as it could visually clutter the diagram without improving clarity. However, we can add a note to the figure caption to explicitly state that the dotted line represents connectivity to the Internet rather than a direct interface-to-interface connection.. Best Regards; Basil Najem From: Linda Dunbar <[email protected]<mailto:[email protected]>> Sent: November-07-25 1:54 PM To: Matthew Bocci (Nokia) <[email protected]<mailto:[email protected]>>; Aijun Wang <[email protected]<mailto:[email protected]>>; 'Chongfeng Xie' <[email protected]<mailto:[email protected]>>; 'bess' <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: [EXT]RE: [bess] Re: WG Last Call for draft-ietf-bess-bgp-sdwan-usage Matthew, The update that include the resolutions to Aijun's comments has been uploaded: https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/ Thank you very much for closing the WGLC. Linda From: Matthew Bocci (Nokia) <[email protected]<mailto:[email protected]>> Sent: Wednesday, October 29, 2025 4:27 AM To: Linda Dunbar <[email protected]<mailto:[email protected]>>; Aijun Wang <[email protected]<mailto:[email protected]>>; 'Chongfeng Xie' <[email protected]<mailto:[email protected]>>; 'bess' <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: Re: [bess] Re: WG Last Call for draft-ietf-bess-bgp-sdwan-usage Hi Linda I have not seen any comments resulting from the Mplify liaison. I believe the WG LC can now be closed. Are you going to post a new version of the draft when the window reopens, incorporating the changes you proposed to Aijun? Thanks Matthew From: Linda Dunbar <[email protected]<mailto:[email protected]>> Date: Tuesday, 28 October 2025 at 00:43 To: Matthew Bocci (Nokia) <[email protected]<mailto:[email protected]>>, Aijun Wang <[email protected]<mailto:[email protected]>>, 'Chongfeng Xie' <[email protected]<mailto:[email protected]>>, 'bess' <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: RE: [bess] Re: WG Last Call for draft-ietf-bess-bgp-sdwan-usage CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Matthew, We have addressed all of the comments from the WGLC. Have you got any comments from the Liaison to Mplify? Are there anything else to be done before closing the WGLC? Thanks, Linda From: Matthew Bocci (Nokia) <[email protected]<mailto:[email protected]>> Sent: Friday, September 26, 2025 4:51 AM To: Aijun Wang <[email protected]<mailto:[email protected]>>; Linda Dunbar <[email protected]<mailto:[email protected]>>; 'Chongfeng Xie' <[email protected]<mailto:[email protected]>>; 'bess' <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: Re: [bess] Re: WG Last Call for draft-ietf-bess-bgp-sdwan-usage Authors Please can you respond to these WGLC comments. Note that a liaison was recently sent to the Mplify Alliance (formerly MEF) asking for comments on a number of SDWAN drafts (see https://datatracker.ietf.org/liaison/2066/). I will therefore keep this WGLC open for a couple more weeks in case there are any further comments. Best regards Matthew From: Aijun Wang <[email protected]<mailto:[email protected]>> Date: Tuesday, 9 September 2025 at 04:11 To: 'Linda Dunbar' <[email protected]<mailto:[email protected]>>, 'Chongfeng Xie' <[email protected]<mailto:[email protected]>>, Matthew Bocci (Nokia) <[email protected]<mailto:[email protected]>>, 'bess' <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: RE: [bess] Re: WG Last Call for draft-ietf-bess-bgp-sdwan-usage CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. 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-implementation-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: 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. 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. Section 4 should be actually "Provisioning Requirements", not "Model"? it determines what contents should be delivered via the BGP protocol, right? 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]> [mailto:[email protected]] On Behalf Of Linda Dunbar Sent: Tuesday, September 9, 2025 5:40 AM To: Aijun Wang <[email protected]<mailto:[email protected]>>; 'Chongfeng Xie' <[email protected]<mailto:[email protected]>>; 'Matthew Bocci (Nokia)' <[email protected]<mailto:[email protected]>>; 'bess' <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[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: 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. 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. 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." 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 <[email protected]<mailto:[email protected]>> Sent: Monday, September 8, 2025 1:51 AM To: 'Chongfeng Xie' <[email protected]<mailto:[email protected]>>; 'Matthew Bocci (Nokia)' <[email protected]<mailto:[email protected]>>; 'bess' <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[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]] Sent: Monday, September 8, 2025 1:35 PM To: Aijun Wang <[email protected]<mailto:[email protected]>>; Matthew Bocci (Nokia) <[email protected]<mailto:[email protected]>>; bess <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[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: Aijun Wang<mailto:[email protected]> Date: 2025-09-08 12:09 To: 'Matthew Bocci \(Nokia\)'<mailto:[email protected]>; 'BESS'<mailto:[email protected]> CC: draft-ietf-bess-bgp-sdwan-usage<mailto:[email protected]> 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: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Matthew Bocci (Nokia) Sent: Wednesday, August 27, 2025 7:05 PM To: BESS <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: [bess] WG Last Call for draft-ietf-bess-bgp-sdwan-usage This email begins a working group last call for draft-ietf-bess-bgp-sdwan-usage-26 - BGP Usage for SD-WAN Overlay Networks<https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/> 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 ________________________________ External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints ________________________________ External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints ________________________________ External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
