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)
2. 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)
3. 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"
* 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")
4. 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"
5. 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.
Best Regards;
Basil Najem
From: Linda Dunbar <[email protected]>
Sent: November-07-25 1:54 PM
To: 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
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
_______________________________________________
BESS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
