[bess] Re: Mohamed Boucadair's Discuss on draft-ietf-bess-bgp-sdwan-usage-31: (with DISCUSS and COMMENT)

[[e-mail]]

Hi Linda,

Thank you for the follow-up. I also checked iddiff?url1=draft-ietf-bess-bgp-sdwan-usage-31&url2=draft-ietf-bess-bgp-sdwan-usage-33, I like the changes made so far.

Please see inline.

Cheers,
Med

De : Linda Dunbar <[e-mail]>
Envoyé : jeudi 21 mai 2026 03:23
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>; The IESG <[e-mail]>
Cc : [e-mail]; [e-mail]; [e-mail]; [e-mail]
Objet : RE: Mohamed Boucadair's Discuss on draft-ietf-bess-bgp-sdwan-usage-31: (with DISCUSS and COMMENT)

Med,

Thank you very much for the detailed comments. Please see below of our resolutions marked by [Linda].

Linda

-----Original Message-----
From: Mohamed Boucadair via Datatracker <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, May 20, 2026 12:57 AM
To: The IESG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Mohamed Boucadair's Discuss on draft-ietf-bess-bgp-sdwan-usage-31: (with DISCUSS and COMMENT)

Mohamed Boucadair has entered the following ballot position for
draft-ietf-bess-bgp-sdwan-usage-31: Discuss

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi Linda, Ali, John, Basil, and Sue,

Thank you for the effort put into this document.

Thanks to Luis Miguel Contreras for the detailed OPSDIR review and to the
authors for engaging and making changes.

Given the intended Informational status of the document, I will focus on high
level comments:

# Lack of clear reference deployment model

It is not clear to me which BGP sessions we are referring to nor why an underly
PE will be involved in arrangements with an external SD-WAN provider. SD-WAN
can be offered without coordination with PEs of underlying networks.

There are maybe deployment assumptions that are not called out it here.

Absent a clear deployment context, it is really hard (at least to me) to digest
what is stated in several sections (e.g., 3.1.1).

[Linda] The reference deployment models are described in the Scenario sections, specifically Sections 3.2, 3.3, and 3.4. Would the following wording change at the end of the first paragraph of Section 3 address your concern?
[Med] These sections are too deep in the structure and require an effort to graft various pieces. Can we please have a description of the reference deployment model early in the document (preferably, right after the introduction)? Please consider clarifying in that section why/when an underly PE needs to be part of an SD-WAN arrangement.

New:
Sections 3.2, 3.3, and 3.4 describe potential SD-WAN deployment scenarios, which are further explored in subsequent sections to illustrate how the BGP control plane can be used to distribute reachability and policy information within SD-WAN overlay networks.

Old:
These scenarios serve as examples that are further explored in subsequent sections to illustrate how the BGP control plane is used to distribute reachability and policy information within SD-WAN overlay networks.

## In the same vein, it is not clear to me whether this is documenting what is
deployed as suggested by this sentence?

CURRENT:
   By documenting how
   these mechanisms are used in SD-WAN deployments, this document
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   enables consistent interpretations and supports interoperability
   without defining new protocols.

Do you confirm that [SD-WAN-Discovery] in particular is implemented and
deployed as described in this document?

[Linda] Yes. the IDR implementation report for [SD-WAN-Discovery] is documented here: https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-sdwan-edge-discovery
[Med] Thanks. My concern was that the OLD text says that these "these mechanisms are used in SD-WAN deployments". I see that you deleted that text. Thanks.

Likewise, do you confirm that these are deployed today:

[Linda] I am afraid that I cannot comment on specific deployment status, as that may be confidential. The statement is intended as a requirement for the BGP-controlled SD-WAN model described in this document.
[Med] I consider this point closed as the text was deleted.


CURRENT:
   An SD-WAN edge must use a secure channel, such as TLS following
   BCP195[RFC9325] or Ipsec [RFC4301], to its designated RR for
   exchanging BGP UPDATE messages.

[Med] I also see that you reworded this, which I think is better that the OLD.


# Disconnect between the claimed scope vs. content

## The document deviates from the goal set (BGP-based control) and includes
tangential material (e.g., onboarding, forwarding, etc.). For example, how the
ZTP discussion is relevant here? Does it inform decisions about the BGP control
part? Idem for the onboarding.

For the forwarding part, is there any difference between how forwarding is done
with proprietary control plane vs. BGP?

Unless there are specifics, I suggest the main document to be trimmed to serve
its claimed purpose.

[Linda] Similar to EVPN usage/applicability documents such as RFC8388, some provisioning, onboarding, and forwarding context is included to explain how the BGP-distributed information is applied in actual service scenarios. The ZTP/onboarding discussion explains how an SD-WAN edge obtains the controller/RR information and secure connectivity needed before BGP UPDATEs can be exchanged. The forwarding sections illustrate how BGP-distributed reachability, tunnel attributes, Route Targets, and policy information are consumed by SD-WAN edges; they do not define a new forwarding architecture.

How about we trim the wording in the following way:

  *   In Section 3.1.4, replace the detailed ZTP text with the following shorter text:
"SD-WAN Zero-Touch Provisioning (ZTP) allows an SD-WAN edge to obtain initial configuration without manual intervention. In the context of this document, the relevant ZTP function is that the edge obtains the information needed to authenticate to the SD-WAN controller/RR and establish a secure channel for exchanging BGP UPDATE messages. Detailed ZTP mechanisms are outside the scope of this document."


  *   In Section 6, replace the opening sentence:
OLD:
"This section describes how client traffic is forwarded in a BGP Controlled SD-WAN for the use cases described in Section 3."

NEW:
"This section briefly illustrates how BGP-distributed reachability, tunnel attributes, Route Targets, and policy information are used by SD-WAN edges when forwarding client traffic in the scenarios described in Section"
[Med] Thanks. I see that you shortened the ZTP text, which is great. However, it is not clear to me whether there are aspects that are specific to BGP or these are generic matters. If there are no specifics, can we please have a statement that says so? (my preference would be to move such material to an appendix), but I would be fine also if we provide readers with clear cautions.

## Operational Challenges

CURRENT:
   Although BGP and IPsec are mature
   technologies, applying them to SD-WAN introduces challenges such
   as scalability, segmentation, and multi-homing.

Putting aside that it is not easy to find a single place which each of these
are discussed, the document includes inconsistent statements. For example, the
document concludes with the following after discussing BGP/IPsec:

   This model emphasizes simplicity and efficiency, leveraging
   centralized governance to mitigate risks while ensuring
   scalability and interoperability of the SD-WAN.

but the main body states:

     This approach may have
     scalability implications due to per-destination packet
     replication; optimization mechanisms are outside the scope of
     this document.

[Linda] The two uses of "scalability" refer to different aspects: the last sentence of the Security Consideration (i.e. "This model emphasizes simplicity and efficiency, ..") is intended to refer to the scalability of the BGP/RR-based control-plane distribution, while the multicast text refers to data-plane scalability implications caused by per-destination packet replication.

To make this distinction clearer, how about the following changes to the last sentence of the Security Considerations section:

OLD:
"This model emphasizes simplicity and efficiency, leveraging centralized governance to mitigate risks while ensuring scalability and interoperability of the SD-WAN."

NEW:
"This model emphasizes simplicity and efficiency, leveraging centralized governance to mitigate risks while supporting scalable control-plane distribution and interoperability of the SD-WAN."

[Med] This is clearer. Thanks

## Also, it is not clear if the assessment is about BGP with [SD-WAN-Discovery]
or BGP without [SD-WAN-Discovery].

[Linda] The document is about using BGP for SD-WAN together with the SD-WAN-specific extensions described in [SD-WAN-Discovery].
[Med] Thanks for confirming. This makes SD-WAN-Discovery normative.

That is why the document references [SD-WAN-Discovery] in multiple places. This draft describes the deployment scenarios and BGP usage, while [SD-WAN-Discovery] specifies the detailed BGP protocol extensions.

# Is really DPI required?
[Linda] No, the document does not require DPI, nor does it use the term DPI. The intent is to describe policy-based traffic classification and forwarding in SD-WAN deployments, which can be based on configured policies and packet/header information.

CURRENT:
   SD-WAN:     An overlay connectivity service that optimizes the
               transport of IP packets over one or more Underlay
               connectivity services by recognizing applications and
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
               determining forwarding behavior by applying policies
               to them [MEF-70.2].

I would avoid this wording as this smells like DPI function is mandatory, while
this can be basically about supplying classification rules (without having to
inspect user traffic payload).

[Linda] We were asked to include an official reference for SD-WAN, and the WG considered [MEF-70.2] to be the appropriate reference. The quoted wording comes from [MEF-70.2]. To avoid "smells like DPI", how about shortening the definition while keeping the reference to MEF-70.2:
"SD-WAN: An overlay connectivity service that optimizes the transport of IP packets over one or more underlay connectivity services by forwarding them based on policies [MEF-70.2]."
[Med] This is better. Note that I disagree with "optimizes" as that is not something that is guaranteed by design, but depends on the enforced policies.

# MEF, BGP, IPsec, and more are normative

[Linda] This document is an Informational usage document, following the model of usage/applicability documents such as RFC8388 for EVPN.
[Med] Please check https://datatracker.ietf.org/doc/statement-iesg-iesg-statement-normative-and-informative-references-20060419/ as the classification applies also for Info docs/

It describes SD-WAN deployment scenarios and BGP usage, but does not define new BGP, IPsec, MEF, or IEEE protocol behavior.
[Med] Yes, but it includes statements that require reading of these references to understand/assess the claims. See the excerpt I provided below. Please refer to "Normative references specify documents that must be read to understand.." of the IESG statement.

The cited documents are used as references for existing technologies and related specifications; therefore, we believe keeping them as Informative references is appropriate.


   RFC4271
   ..
   Software Defined Wide Area Network (SD-WAN), as described in
   [MEF70.2],
   ...
   The detailed BGP extensions used for
   SD-WAN edge discovery and attribute distribution are specified in
   [SD-WAN-Discovery].
   ...
   The SD-WAN client interface should support IPv4 and IPv6 addresses
   as well as Ethernet in accordance with the [IEEE802.3] standard.
   ...
   The client service at the SD-WAN edge must support the SD-WAN UNI
   service attributes outlined in Section 4 of [MEF 70.2].
   ...
   An SD-WAN edge must use a secure channel, such as TLS following
   BCP195[RFC9325] or Ipsec [RFC4301], to its designated RR for
   exchanging BGP UPDATE messages.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# I don't parse how IP prefix is a service.

CURRENT:
  Client service: A service (e.g., IP prefix or VLAN) attached to

[Linda] How about changing the wording to:
"Client service: A service attached to the client-facing interface of an SD-WAN edge, identified by associated reachability or attachment information, such as an IP prefix or VLAN."
[Med] ACK

# A device is physical

OLD:
   SD-WAN edge:   A device, either physical or virtual, that
               participates in the SD-WAN overlay network. These
               nodes advertise client routes to the SD-WAN Controller
               (e.g., BGP RR).

NEW:
   SD-WAN edge:   A functional entity, either physical or virtual, that
               participates in the SD-WAN overlay network. These
               nodes advertise client routes to the SD-WAN Controller
               (e.g., BGP RR).

[Linda] Thank you for the suggestion. Changed.
[Med] Thanks.

Cheers,
Med




____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.