[bess] Re: WG Last Call for draft-ietf-bess-bgp-sdwan-usage

["Najem, Basil" <[e-mail]>]

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

Best Regards;

Basil
From: Linda Dunbar <[e-mail]>
Sent: November-13-25 3:21 PM
To: Najem, Basil <[e-mail]>; Matthew Bocci (Nokia) <[e-mail]>; Aijun Wang <[e-mail]>; 'Chongfeng Xie' <[e-mail]>; 'bess' <[e-mail]>
Cc: [e-mail]
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 <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, November 11, 2025 12:25 PM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>; Matthew Bocci (Nokia) <[e-mail]<mailto:[e-mail]>>; Aijun Wang <[e-mail]<mailto:[e-mail]>>; 'Chongfeng Xie' <[e-mail]<mailto:[e-mail]>>; 'bess' <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>>
Sent: November-07-25 1:54 PM
To: Matthew Bocci (Nokia) <[e-mail]<mailto:[e-mail]>>; Aijun Wang <[e-mail]<mailto:[e-mail]>>; 'Chongfeng Xie' <[e-mail]<mailto:[e-mail]>>; 'bess' <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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) <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, October 29, 2025 4:27 AM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>; Aijun Wang <[e-mail]<mailto:[e-mail]>>; 'Chongfeng Xie' <[e-mail]<mailto:[e-mail]>>; 'bess' <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 28 October 2025 at 00:43
To: Matthew Bocci (Nokia) <[e-mail]<mailto:[e-mail]>>, Aijun Wang <[e-mail]<mailto:[e-mail]>>, 'Chongfeng Xie' <[e-mail]<mailto:[e-mail]>>, 'bess' <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
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) <[e-mail]<mailto:[e-mail]>>
Sent: Friday, September 26, 2025 4:51 AM
To: Aijun Wang <[e-mail]<mailto:[e-mail]>>; Linda Dunbar <[e-mail]<mailto:[e-mail]>>; 'Chongfeng Xie' <[e-mail]<mailto:[e-mail]>>; 'bess' <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 9 September 2025 at 04:11
To: 'Linda Dunbar' <[e-mail]<mailto:[e-mail]>>, 'Chongfeng Xie' <[e-mail]<mailto:[e-mail]>>, Matthew Bocci (Nokia) <[e-mail]<mailto:[e-mail]>>, 'bess' <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Linda Dunbar
Sent: Tuesday, September 9, 2025 5:40 AM
To: Aijun Wang <[e-mail]<mailto:[e-mail]>>; 'Chongfeng Xie' <[e-mail]<mailto:[e-mail]>>; 'Matthew Bocci (Nokia)' <matthew.bocci=[e-mail]<mailto:matthew.bocci=[e-mail]>>; 'bess' <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>>
Sent: Monday, September 8, 2025 1:51 AM
To: 'Chongfeng Xie' <[e-mail]<mailto:[e-mail]>>; 'Matthew Bocci (Nokia)' <matthew.bocci=[e-mail]<mailto:matthew.bocci=[e-mail]>>; 'bess' <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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:[e-mail]]
Sent: Monday, September 8, 2025 1:35 PM
To: Aijun Wang <[e-mail]<mailto:[e-mail]>>; Matthew Bocci (Nokia) <matthew.bocci=[e-mail]<mailto:matthew.bocci=[e-mail]>>; bess <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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:[e-mail]>
Date: 2025-09-08 12:09
To: 'Matthew Bocci \(Nokia\)'<mailto:matthew.bocci=[e-mail]>; 'BESS'<mailto:[e-mail]>
CC: draft-ietf-bess-bgp-sdwan-usage<mailto:[e-mail]>
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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Matthew Bocci (Nokia)
Sent: Wednesday, August 27, 2025 7:05 PM
To: BESS <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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