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 <[email protected]>
Sent: Monday, September 8, 2025 1:51 AM
To: 'Chongfeng Xie' <[email protected]>; 'Matthew Bocci (Nokia)'
<[email protected]>; 'bess' <[email protected]>
Cc: [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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-bess-bgp-sdwan-usage%2F&data=05%7C02%7Clinda.dunbar%40futurewei.com%7C802d0474791c42bcad3708ddeeb4e1ae%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638929182873283390%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=BULGfVgTS8K9OplS21MLrHQjT1Bo8a1wkR3MgIZXvBs%3D&reserved=0>
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]
