BGP Usage for SD-WAN Overlay Networks
draft-ietf-bess-bgp-sdwan-usage-37

[Ballot comment]
Hi Linda, Ali, John, Basil, and Sue,

Thank you for the discussion.

The changes made from 31 to 37 [1] address the points raised in my initial ballot [2].

Thank you.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-bess-bgp-sdwan-usage-31&url2=draft-ietf-bess-bgp-sdwan-usage-37&difftype=--html

[2] Ballot: https://mailarchive.ietf.org/arch/msg/bess/MVpLhFeKvp255BPnaxVTrl6pDGs/

[Ballot comment]
Thanks to the authors and the WG for their work on this document.

I appreciate the responsiveness from the authors (specifically Linda) in addressing most of the technical comments in my original ballot with DISCUSS position.

There are multiple SD-WAN solutions that have been developed by various vendors using IETF technologies like BGP (but with proprietary extensions) or entirely proprietary solutions. I welcome the use of IETF protocols. However, AFAIK, none of these solutions support interoperability between
SD-WAN gateways and controllers from different vendors. So, I wonder where and how the standardization of SD-WAN at the IETF is happening to enable such interoperability. After all the goal of IETF standardization is interoperability. Also, the BGP extensions are but a small portion of what
an SD-WAN solution entails (some of this is now clarified in the document). There is no SD-WAN WG that is chartered today to study and undertake the work necessary for a standards based open and interoperable SD-WAN solution. Without that in place, I do not understand the value or benefit of publication of this document via the IETF stream. It could as well be via ISE?

That said, I am moving my position to Abstain since I do not wish to stand in the way of publication of this document that has taken years through the BESS WG and IETF consensus process.

[Ballot discuss]
Thanks to the authors and the WG for their work on this document.

I have a few high-level aspects in this document that I would like to discuss.

The abstract of this document says:

  This document explores the complexities involved in managing large
  scale Software Defined WAN (SD-WAN) overlay networks, along with
  various SD-WAN scenarios. Its objective is to illustrate how a
  BGP-based control plane can effectively manage these overlay
  networks by distributing edge service reachability information,
  WAN port attributes, and underlay path details, thereby minimizing
  manual provisioning.

To my knowledge there are SD-WAN solutions from several vendors that are
widely deployed today. Some of them use IETF protocols for specific
functionalities while others use proprietary mechanisms (here I am not
referring to IPSec or TLS but routing protocols). This text (and a few
similar in the body of the document) gives the impression of comparison
between a BGP-based solution that is not fully specified (not even the
framework is specified) in this document against solutions deployed out
there.

As easy way to address this would be to rephrase such text to not make
claims or comparisons. Perhaps just plainly state how use of BGP can
potentially replace other proprietary mechanisms used in SD-WAN solution?
E.g., the first sentence is problematic since it can be read as existing
solutions have complexities that are solved by BGP without any supporting
evidence or evaluation of those other solutions.

Introduction section says:

  This document captures the SD-WAN scenarios, control-plane
  behaviors, and forwarding considerations that motivate current and
  future IETF work on SD-WAN. Publishing this material as an RFC
  provides a stable, citable foundation for related protocol
  specifications and ensures a shared understanding of the problem
  space across the industry.

As mentioned in the previous point, there are multiple SD-WAN solutions
that have been developed by various vendors using IETF technologies
like BGP (but with proprietary extensions) or entirely proprietary
solutions. AFAIK, none of these solutions support interoperability between
SD-WAN gateways and controllers from different vendors. Please correct
me if I am wrong. So, I wonder where and how the standardization of SD-WAN
at the IETF is happening to enable such interoperability that is after all
the purpose of the IETF. The BGP extensions are but a small portion of what
an SD-WAN solution entails. Do the claims made in that text hold?

Why not just say "This document captures the SD-WAN scenarios, control-plane
behaviors, and forwarding considerations using BGP." or something like that?

In continuation of the previous point. There is no SD-WAN WG that
is chartered today to study and undertake the work necessary for a standards
based open and interoperable SD-WAN solution. Without that in place, I do not
understand the value or benefit of publication of this document via the IETF
track. It could as well be via ISE?

Section 3.1.5 says

  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.

I assume that IPsec tunnels need to be setup between the edge and
the controller and this tunnel has IP addresses on both ends that are used
to setup a BGP Session over it - i.e., in tunnel mode per RFC4301 with both
AH and ESP. If so, please clarify. I am unable to find a similar IETF
specification for setting BGP over TLS tunnels. I don't think BCP195 covers
these aspects. Can you please clarify this use of TLS with an appropriate
reference?

[Ballot comment]

# Éric Vyncke INT AD comments for draft-ietf-bess-bgp-sdwan-usage-31
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

## COMMENTS (non-blocking)

### Wrong copyright

s/Simplified/Revised/

### Deviation from the goal

I second Med Boucadair's `The document deviates from the goal set ` but not at the DISCUSS level.

### PCE not mentioned

I am surprised to see mention of the PCE WG published RFC in the document, e.g., in section 4.

### Section 1

Shouldn't the MEF reference for SD-WAN be normative ?

Please expand NSP at first use.

```
  Publishing this material as an RFC
  provides a stable, citable foundation for related protocol
  specifications and ensures a shared understanding of the problem
  space across the industry.
```
has probably little benefit in the published RFC.

### Section 3.1.1

While VxLAN is the de facto standard, it is informational, why not adding GENEVE in the text ?

### Section 3.1.4

I would not qualify ZTP the requirement to insert a USB stick ;-)

### Section 3.2

Please add reference for NVo3 on figure 3.

### Section 3.3

s/Since IPsec encryption requires significant processing power/Since IPsec encryption requires significant processing power *or dedicated processor*/

### Section 4.3

`BGP UPDATE messages could be extended to propagate IPsec-related attributes ` does the absence of references mean that this not possible now ? I.e., no IETF RFC for this extension ?

Same ambiguity in UPDATE2 of section 5.3.


### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg tool to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-)

[Ballot comment]
# IESG review of draft-ietf-bess-bgp-sdwan-usage-31

CC @MikeBishop

## Comments

### Inconsistent reference

Both `[MEF70.2]` and `[MEF-70.2]` are referenced; presumably
they are the same?

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `traditional`; alternatives might be `classic`, `classical`, `common`,
  `conventional`, `customary`, `fixed`, `habitual`, `historic`,
  `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
  `time-honored`, `universal`, `widely used`, `widespread`
* Terms `native` and `natively`; alternatives might be `built-in`,
  `fundamental`, `ingrained`, `intrinsic`, `original`

### Boilerplate

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License".

### Uncited references

Uncited references: `[BCP195]` and `[RFC5246]`.

### Outdated references

Reference `[RFC5246]` to `RFC5246`, which was obsoleted by `RFC8446` (this may
be on purpose). The title of the reference says TLS 1.3, but RFC5246 is TLS 1.2.

### Grammar/style

#### Section 3.1.3, paragraph 4
```
providing the installer with a pre-configured USB flash drive containing the
                              ^^^^^^^^^^^^^^
```
Do not mix variants of the same word ("pre-configure" and "preconfigure")
within a single text.

#### Section 7, paragraph 1
```
April 1998. [RFC2332] J. Luciani, et al, "NBMA Next Hop Resolution Protocol
                                  ^^^^^
```
A period is misplaced or missing. (This applies to multiple references.)

#### Section 8, paragraph 4
```
ct 2023. 11. Acknowledgments Acknowledgements to Gunter van de Velde, Andrew
                            ^^^^^^^^^^^^^^^^
```
Do not mix variants of the same word ("acknowledgement" and "acknowledgment")
within a single text.

[Ballot 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).

## 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?

Likewise, do you confirm that these are deployed today:

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.


# 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.

## 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.

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

# Is really DPI required?

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).

# MEF, BGP, IPsec, and more are normative

  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.

[Ballot comment]
# I don’t parse how IP prefix is a service.

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

# 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).

Cheers,
Med

[Ballot comment]
I am balloting ABSTAIN to allow the document to proceed to publication to serve the needs of the WG.  The following areas are unclear in my review.

(1) With the notional goal of:

==[ snip ]==
  This document captures the SD-WAN scenarios, control-plane
  behaviors, and forwarding considerations that motivate current and
  future IETF work on SD-WAN.
==[ snip ]==

It is unclear in a number of areas of the document where existing protocol mechanics are already specified, the text is intended for future work, or the mechanics described are out of scope for the scenario.

A few examples:

** Section 3.1.4.  Is the “Zero Touch Provisioning” intended to be standardized or motivate future work?  How much of this is built on existing work?
-- what is “secure Email”?  Is that S/MIME?  OPENPGP?  New work?
-- as pointed out by SECDIR review, how do trust anchors work for “establishing] the transport layer secure connection [RFC8446] to its Device Onboarding Server” to make this ZTP?

** Section 3.1.5
  An SD-WAN edge must use a secure channel, such as TLS [RFC5246]
  [RFC8446] or IPsec, to its designated RR for exchanging BGP UPDATE
  messages.

How does one use TLS to exchange BGP?  Is this new or existing work?  Why not QUIC, https://datatracker.ietf.org/doc/draft-retana-idr-bgp-quic/?

** Sections 5.2, 5.3, and 6.1.1 reference the use of the Tunnel Encapsulation Attribute to pass configuration.  Section 5.2 explicitly cites [SD-WAN- Discovery].  The others don’t.  Is there new work or existing work?  Are all of the needed attributes defined?

(3) Section 7
  Since
  the RR is configured with policies that identify authorized peers,
  the peer-wise IPsec IKE (Internet Key Exchange) authentication
  process is significantly simplified.

Are there manageability considerations for using TLS as the secure channel?

(2) Section 8
  SD-WAN operation relies on the existing security mechanisms
  defined for BGP and IPsec.

Since TLS can be used for the secure channel wouldn’t the TLS mechanism apply here too?

[Ballot comment]
Thank you for bringing this work to the IETF. I have reviewed this from a transport perspective and I have the following COMMENTS that I hope will improve this document.

These are non-blocking comments, but I would none-the-less hope for a response to improve my own understanding:

## (1) The current background text says:
"matching one or multiple fields in the IP header, rather than solely relying on destination IP addresses [RFC9522].".
- Since this seems to be about identifying a dlow by specific fields in the packet's IP header, I'd expected this to also mention/refer to the diffserv [RFC2474] field as a classifier? This is a core Internet Transport specification and I did not see any mention of the differentiated services (diffserv) architecture. Does this apply, could it be mentioned as an example field or in some other way?

## (2) Looking at section 6.3.2:  I realised this document is focussed on routing rather than forwarding, but I wondered if section 3.1.1 could have noted the considerations for best current practice for ECN when talking about the alternatives for encapsulation, as specified in RFC 9599: Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP. Is this relevent when SDWAN is being configured/used and if so could you add a reference for people wishing to find out more?

## (3) When the document mentions UDP port 4500, could it please include a reference? (e.g., to RFC 5996.)

## (4) In Section 6.1.2, last paragraph. I understand there might be challenges in deploying IPSEC with multicast key exchange, etc. But is the current text in this paragaph justified, and whey does it not refer to RFC 5374 as a basis for IPsec and multicast?

## (5) I see section 3.1.5 refers equally to both TLSv1.2 and TLSv1.3, without noting that the newer TLS 1.3 is the current specification. I gear that could be read as an endorsement somehow of TLS 1.2, and therefore I wonder whether this really ought to be phrased to say TLS is required and point to TLS 1.3, or to provide some other justification, our security reviewers may have more suggestions of suitable wording.

Best wishes,

Gorry

Request for IETF Last Call review by SECDIR Completed: Has Issues. Reviewer: Stephen Farrell. Sent review to list. Submission of review completed at an earlier date.

The following Last Call announcement was sent out (ends 2026-04-22):

From: The IESG
To: IETF-Announce
CC: bess-chairs@ietf.org, bess@ietf.org, draft-ietf-bess-bgp-sdwan-usage@ietf.org, gunter@vandevelde.cc, matthew.bocci@nokia.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (BGP Usage for SD-WAN Overlay Networks) to Informational RFC


The IESG has received a request from the BGP Enabled ServiceS WG (bess) to
consider the following document: - 'BGP Usage for SD-WAN Overlay Networks'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2026-04-22. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document explores the complexities involved in managing large
  scale Software Defined WAN (SD-WAN) overlay networks, along with
  various SD-WAN scenarios. Its objective is to illustrate how a
  BGP-based control plane can effectively manage these overlay
  networks by distributing edge service reachability information,
  WAN port attributes, and underlay path details, thereby minimizing
  manual provisioning.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document has been developed over a number of years in the working group and has received broad exposure. I believe it represents broad consensus.
v12 of the draft was previously submitted to the IESG, but was sent back to the working group due to a restrictive clause in the boilerplate text.
This has now been removed and new WG adoption and WG last call polls concluded. Review comments were received from members of the IESG during this period. Reviews were
also conducted by multiple directorates and a further Routing Area Directorate review of v28. A liaison was also sent to the MPLIFY Alliance who responded with no significant technical issues. I believe that the authors have
addressed all comments.

The document addresses the following BESS WG milestone:

Dec 2025: Submit BGP Usage for SD-WAN Overlay Networks to IESG as Informational

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No particularly controversial points.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

None indicated.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This is an informational document that does not define new protocol or extensions.
Related implementations of draft-ietf-idr-sdwan-edge-discovery are noted on the following page:
https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-sdwan-edge-discovery

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

All of the work in BESS utilizes BGP, which is owned by the IDR working group. Drafts which make significant changes to BGP or use it in new ways are generally cross-reviewed with IDR.
That is not the case here as this draft is simply describing the usage of existing technologies standardised within BESS to what is described as SD-WAN.
An RTGDir review of version 6 and version 28 were performed and comments addressed by the authors.
As noted above, a liaison statement was sent to the MFLIFY Alliance informing them of SD-WAN work in the IETF.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document does not use any formal languages.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The document does not contain a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

I have reviewed and commented on multiple versions. I believe the draft is ready.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No issues identified.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Informational. This is appropriate because the draft describes the applicability of existing BGP-based VPN control plane to SD-WAN. It does not propose protocol extensions.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. An IPR poll was carried out both at WG adoption and WG last call.


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The number of authors on the front page meets the RFC Editor requirement.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

ID Nits passes. There are some warnings about unused references that should be cleaned up in the next revision.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].


The references are divided into normative and informative. The categorisation of each reference seems reasonable.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

Normative references are all to published RFCs.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

There are no actions requested of IANA.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are no actions requested of IANA.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document has been developed over a number of years in the working group and has received broad exposure. I believe it represents broad consensus.
v12 of the draft was previously submitted to the IESG, but was sent back to the working group due to a restrictive clause in the boilerplate text.
This has now been removed and new WG adoption and WG last call polls concluded. Review comments were received from members of the IESG during this period. Reviews were
also conducted by multiple directorates and a further Routing Area Directorate review of v28. A liaison was also sent to the MPLIFY Alliance who responded with no significant technical issues. I believe that the authors have
addressed all comments.

The document addresses the following BESS WG milestone:

Dec 2025: Submit BGP Usage for SD-WAN Overlay Networks to IESG as Informational

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No particularly controversial points.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

None indicated.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This is an informational document that does not define new protocol or extensions.
Related implementations of draft-ietf-idr-sdwan-edge-discovery are noted on the following page:
https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-sdwan-edge-discovery

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

All of the work in BESS utilizes BGP, which is owned by the IDR working group. Drafts which make significant changes to BGP or use it in new ways are generally cross-reviewed with IDR.
That is not the case here as this draft is simply describing the usage of existing technologies standardised within BESS to what is described as SD-WAN.
An RTGDir review of version 6 and version 28 were performed and comments addressed by the authors.
As noted above, a liaison statement was sent to the MFLIFY Alliance informing them of SD-WAN work in the IETF.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document does not use any formal languages.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The document does not contain a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

I have reviewed and commented on multiple versions. I believe the draft is ready.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No issues identified.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Informational. This is appropriate because the draft describes the applicability of existing BGP-based VPN control plane to SD-WAN. It does not propose protocol extensions.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. An IPR poll was carried out both at WG adoption and WG last call.


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The number of authors on the front page meets the RFC Editor requirement.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

ID Nits passes. There are some warnings about unused references that should be cleaned up in the next revision.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].


The references are divided into normative and informative. The categorisation of each reference seems reasonable.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

Normative references are all to published RFCs.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

There are no actions requested of IANA.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are no actions requested of IANA.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document has been developed over a number of years in the working group and has received broad exposure. I believe it represents broad consensus.
v12 of the draft was previously submitted to the IESG, but was sent back to the working group due to a restrictive clause in the boilerplate text.
This has now been removed and new WG adoption and WG last call polls concluded. Review comments were received from members of the IESG during this period. Reviews were
also conducted by multiple directorates and a further Routing Area Directorate review of v28. A liaison was also sent to the MPLIFY Alliance who responded with no significant technical issues. I believe that the authors have
addressed all comments.

The document addresses the following BESS WG milestone:

Dec 2025: Submit BGP Usage for SD-WAN Overlay Networks to IESG as Informational

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No particularly controversial points.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

None indicated.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This is an informational document that does not define new protocol or extensions.
Related implementations of draft-ietf-idr-sdwan-edge-discovery are noted on the following page:
https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-sdwan-edge-discovery

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

All of the work in BESS utilizes BGP, which is owned by the IDR working group. Drafts which make significant changes to BGP or use it in new ways are generally cross-reviewed with IDR.
That is not the case here as this draft is simply describing the usage of existing technologies standardised within bess to SD-WAN.
An RTGDir review of version 6 and version 28 were performed and comments addressed by the authors.
As noted above, a liaison statement was sent to the MFLIFY Alliance informing them of SD-WAN work in the IETF.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document does not use any formal languages.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The document does not contain a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

I have reviewed and commented on multiple versions. I believe the draft is ready.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No issues identified.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Informational. This is appropriate because the draft describes the applicability of existing BGP-based VPN control plane to SD-WAN. It does not propose protocol extensions.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. An IPR poll was carried out both at WG adoption and WG last call.


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The number of authors on the front page meets the RFC Editor requirement.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

ID Nits passes. There are some warnings about unused references that should be cleaned up in the next revision.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].


The references are divided into normative and informative. The categorisation of each reference seems reasonable.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

Normative references are all to published RFCs.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

There are no actions requested of IANA.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are no actions requested of IANA.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

[Ballot comment]
I support John's and Roman's DISCUSSes.

[updated to remove a minor point I had as part of my DISCUSS outside of John's and Roman's positions, so modified my DISCUSS to a comment supporting John/Roman]

[Ballot discuss]
I support John's and Roman's DISCUSSes.

I am also a bit confused about using BGP as a authorization protocol (as per 3.1.5). A compromised node an always make up its routes to try and break out. BGP doesn't stop that if one is willing to violate the BGP protocol. I would not call BGP "well suited" for this. I also do not understand the argument that BGP can be used to simplify IPsec configuration ? The Security Considerations then seem to flip this around, saying IPsec can be used to secure this solution of using BGP ?

[Ballot comment]
No objection from transport layer protocol point of view. However, I would like know answer to the charter scope question, hence, supporting John's discussion on the charter scope point.

[Ballot comment]
- Abstract: First paragraph use of 'The document' instead of 'This document' seems awkward, I suggest using the latter. Further the second paragraph seems completely out of place, and I would suggest removing it as it does not appear to provide any value.

- Section 3.1.1 (1st paragraph) - Add references for both IPsec and MPLS VPN on first usage. Same comment for VRFs.

- Section 3.1.1 (2nd paragraph) - Please expand on what the text "Additionally, it assumes that one SD-WAN VPN can be mapped to one or multiple virtual topologies governed by the SD-WAN controller's policies" means. From the written text I am unable to understand it.

- Section 3.1.1 (3rd paragraph) - please explain what a 'Client Route' is. I assume that you mean a route generated by an attached SD-WAN site, but the text does not say that. In addition, please correct the text 'Route Target in the BGP Extended Community' - Route Target Community is defined in RFC4360 so please add with reference.

- Section 3.1.1 (4th paragraph) - "For packets carried by an IPsec tunnel, the IPsec tunnel's inner encapsulation header can have the SD-WAN VPN Identifier to distinguish the packets belonging to different SD-WAN VPNs". Can they? is there an RFC or draft defining that?

- Section 3.4 - add references for 'MPLS-in-IP/GRE-in-IPsec'.

- Section 4.3 - "In the context of a BGP-controlled SD-WAN, BGP UPDATE messages can disseminate IPsec-related attribute values for each node..." - do you mean using RFC5566 here? if so, please add a reference - if not then please add a reference on how BGP should disseminate the IPsec-related attribute values.

- Section 5.1 - add reference for NHRP (RFC2332)

[Ballot discuss]
(revised position)

** Section 8.
  In SD-WAN deployments where no secure management channel exists
  between the SD-WAN controller and the SD-WAN edges, TLS or IPsec
  can be established to bridge the gap. While beyond the scope of
  this document, conducting a comprehensive analysis is imperative
  to ensure the security of BGP over TLS [BGP-OVER-TLS].

This text would benefit from further specificity.  My feedback below is very similar to my original DISCUSS position on -15 of this document.

-- Is the “secure management channel” described here the protocol that carries the BGP? 

-- Assuming it is, what is a “secure management channel” that would allow BGP to travel over the Internet that isn’t protected by IPsec (i.e., why can’t this text roughly read, “BGP over IPsec MUST be used”).  When and how should the BGP communication be secured?  Section 3.1.5 does mentioned that the BGP connection must be secured (i.e., “As the connection between an SD-WAN edge and its RR can be over an insecured network, an SD-WAN edge must establish a secure connection to its designated RR upon power-up. The BGP UPDATE messages must be sent over the secure channel to the RR.”)

-- The imperative, comprehensive analysis of [BGP-OVER-TLS] is not sufficiently motivated and the reference to an unadopted individual document is confusing.  I agree with the recommendation of the SECDIR reviewer to drop [BGP-OVER-TLS].  Can the basis for including it be explained?

** (Missed this on my original ballot on -15) The need for “additional anti-DDoS mechanism” is mentioned in the text in Sections 6.2.2, 6.3.2, 8.  Can the expected mechanisms please be clarified.

[Ballot comment]
Thank you to Stephen Farrell for the SECDIR review.

I support the DISCUSS position of John Scudder.

** Section 2.  Editorial. If Section 3.2. defines “Homogeneous Encrypted SD-WAN” and the term isn’t used prior to that. Consider if this needs the definition.

** Section 2.
  SD-WAN IPsec SA: IPsec Security Association between two WAN ports
              of the SD-WAN nodes or between two SD-WAN nodes.

Is it “two SD-WAN nodes” or “two SD-WAN edge nodes”?  If the former, what is an “SD-WAN” node that isn’t an edge node?

** Section 3.1.2.  This sections seems to suggest that various MEF 70.1 behavior needs to be supported.  This suggests that [MEF70.1] needs to be a normative reference.

** Section 3.1.3.  Editorial.
  SD-WAN Traffic Segmentation enables the separation of the traffic
  based on the business and the security needs of different user
  groups and/or application requirements. Each user group and/or
  application may need different isolated topologies and/or policies
  to fulfill the business requirements.

Isn’t a security need also a need of the business?  Otherwise, the second sentence should read “… to fulfill the business and security requirements”.

** Section 3.1.3.  Editorial.
  The traffic from the PoS application follows a tree topology
  (denoted as "----" in the figure below), whereas other traffic can
  follow a multipoint-to-multipoint topology (denoted as "===").

In the figure, where is the PoS application, in one of the “Site #”?  Is there an assumption that traffic “flows up” from the sites to the payment gateway?  Where is the a “---” link from the “====”-connected “multi-point connection for non-payment traffic”?

** Section 3.1.4
    - Upon power-up, the SD-WAN edge can establish the transport
    layer secure connection [BCP195] to its controller, whose URL
    (or IP address) and credential for connection request can be
    preconfigured on the edge device by the manufacture, external
    USB or secure Email given to the installer.

Same feedback as provided on the ballot of the -15 version of this document:
Can the last two configuration options be clarified.

-- per “external USB”. Do you mean a USB _drive_ of some kind that is plugged in and the edge device knows to read what ever is on the drive to configure itself?  Does this mean anyone with physical access to the USB plug can power cycle the machine and can reconfigure it?

--  per “secure email”, does this mean that the installer configures the device based on something typed in?  What’s “secure” about the email?

Neither of these mechanisms seem like "Zero Touch".  They seem like the definition of human-in-the-loop.

** Section 3.1.4.  My understanding of Section 3.1.* was that it was series of requirements to be fulfilled by using BGP with SDWAN.  Per Zero Touch Provisioning, in what way is BGP involved in this provisioning? I’m not sure how this section fits into the scope of the document.

** Section 3.2
  -  A small branch office connecting to its HQ offices via the
  Internet. All traffic to/from this small branch office must be
  encrypted, usually achieved by IPsec Tunnels [RFC6071].

  -  A store in a shopping mall may need to securely connect to its
  applications in one or more Cloud DCs via the Internet. A common
  way of achieving this is to establish IPsec SAs to the Cloud DC
  gateway to carry the sensitive data to/from the store.

What is the technical difference between an “IPsec Tunnel” per the branch office use case and a “IPsec SA” in the store in the mall use case?

** Section 4.3
  In the context of a BGP-
  controlled SD-WAN, BGP UPDATE messages can disseminate IPsec-
  related attribute values for each node

Per the ballot on -15 of this draft, I asked “Please provide a reference to the specification which provides guidance on the BGP TLVs to provision IPsec.  Is that draft-ietf-idr-sdwan-edge-discovery?  This should be a normative reference.”  I still believe additional clarity is required.

** Section 5.2.
  In the figure below, the BGP UPDATE message from C-PE2 to RR can
  have the client routes encoded in the MP-NLRI Path Attribute and
  the IPsec Tunnel associated information encoded in the Tunnel-
  Encapsulation [RFC9012] Attributes.

Per https://www.iana.org/assignments/bgp-tunnel-encapsulation/bgp-tunnel-encapsulation.xhtml, is that value=25

** [SECURE-EVPN] is referenced a few times in the course of the draft.  Is the WG confident that this expired draft is appropriate to use?


** Section 8.
  Adding an Internet-facing WAN port to a C-PE can introduce the
  following security risks:

  1) Potential DDoS attacks from the Internet-facing ports.

  2) Potential risk of malicious traffic being injected via the
  Internet-facing WAN ports.

  3) For the Differential Encrypted SD-WAN deployment model, there
  is a risk of unauthorized traffic injected into the Internet-
  facing WAN ports being leaked to the L2/L3 VPN networks.

  Therefore, the additional anti-DDoS mechanism must be enabled on
  all Internet-facing ports to prevent potential attacks from those
  ports.

I’m having trouble understanding what is considered in-scope for these Security Considerations.  I was under the impression that the focus was the use of BGP as the control plane for SD-WAN communication.  Does it also include the “tunnels”/links configured by the SD-WAN via BGP.

-- If the security properties of tunnels/links configured by the SD-WAN BGP are in scope, then a reminder that links transiting non-Internet links are subject to security properties negotiated in the SLAs of that provided.

Specifically, on -15 of this document, I previously balloted “** Section 8.  The different deployment models also seem to place different levels of trust in the service providers.  Consider mentioning these differences.”

-- Likely because I don’t understand the definition of “Internet-facing ports” in the this context, I don’t see a difference between risk (2) and (3).  (2) seems like a more general version of (3).

-- What is the relationship between “anti-DDoS mechanism” and risk (2) of malicious traffic being injected?  Malicious traffic injection isn’t necessarily a DDoS.

-- I observe that there are no inherited Security Considerations from IPsec or BGP mentioned here. 

Per the ballot on -15 of the document, “This document seems to build on a number of other technologies.  Do their security considerations not apply (e.g., BGP, whatever ZTP technologies is chosen)?”, this feedback still applies.


** Section 10.1  Please provide the appropriate citation for [BCP195]

[Ballot discuss]
## DISCUSS

I have several concerns with this document, and I can't support it being published in its current form. Details are below, listed roughly in order of severity.

### What's it for?

My most fundamental concern is that I can't understand what this document is for. It doesn't specify a procedure. It doesn't provide enough detail to allow me to understand how to use the underlying technologies to build an SD-WAN service. (Also some of the details that are provided are wrong, see subsequent item.) It's not an architecture or framework document in the usual sense. It does motivate at a high level, the understanding that one *can* use BGP as the control plane, and IPSec as the data plane [*], to build an SD-WAN service, if one knows how... but do we need an RFC for that?

The closest I could find to a thesis statement was the abstract's "The document aims to demonstrate how the BGP-based control plane is used for large-scale SD-WAN overlay networks with little manual intervention." I guess if we allow the word "demonstrate" to mean "motivate at a high level" rather than "specify", then we can say it's not too far off. I don't see why we need an RFC for that, though.

[*] Or the concatenation of IPSec and "traditional" BESS VPN technologies, in the "differential" case.

### Is it in charter?

Looking at the BESS charter, I don't see how this document fits. If it weren't for the preceding question, I probably wouldn't have thought to look. But as it stands, I have to ask: why does the WG think this is a chartered work item?

### Error in how RFC 9012 is used

In Section 5.2, the Encapsulation Extended Community is misused. See https://mailarchive.ietf.org/arch/msg/idr/umBB5yfoC3mFMpIWIT2K8159Gos/ for related explanation of the error. The error recurs in Sections 5.3 and 5.4.

Also, there is no such thing as “TYPE = IPsec” (referenced in Sections 5.2 and 5.4), see https://www.iana.org/assignments/bgp-tunnel-encapsulation/bgp-tunnel-encapsulation.xhtml#tunnel-types

This one should be straightforward to fix. It does lead me to be worried about the level of review the document has received, though.

### Section 3.1.5, security model

  BGP is well suited for this purpose. RFC4684 has specified the
  procedure to constrain the distribution of BGP UPDATE to only a
  subset of nodes. Each edge node informs the Route-Reflector (RR)
  [RFC4456] on its interested SD-WAN VPNs. The RR only propagates
  the BGP UPDATE from an edge to others within the same SD-WAN VPN.
 
RFC 4684 is driven by demand -- a PE will advertise RT membership NLRI to "request" that it receive routes with the given RT. So, this means the security model is that the client router is implicitly trusted to declare its VPN membership(s) truthfully and accurately. I don't see this addressed in the Security Considerations.

[Ballot comment]
## COMMENT

### What’s a “client route”?

The document talks about "client routes", "client route updates", etc. It never defines the concept. I assume that these are analogous to a CE route in an RFC 4364 VPN, but the casual usage and lack of definition are unhelpful.

### MP-NRLI

There’s no such thing as "MP–NLRI". I guess you mean MP_REACH_NLRI and MP_UNREACH_NLRI. If you want to collectively refer to these as "MP-NLRI" then I think you need to add a definition.

### Anti-DDoS

Section 6.2.2 has

                                                    For all packets
    from the Internet-facing WAN ports, the additional anti-DDoS
    mechanism has to be enabled to prevent potential attacks from
    the Internet-facing ports.
   
What anti-DDoS mechanism is that? None is specified here, nor referenced.

### Figure 7

Figure 7 is mangled to the point of being unreadable.

[Ballot discuss]
** Section 8.
  In SD-WAN deployments where no secure management channel exists
  between the SD-WAN controller and the SD-WAN edges, TLS or IPsec
  can be established to bridge the gap. While beyond the scope of
  this document, conducting a comprehensive analysis is imperative
  to ensure the security of BGP over TLS [BGP-OVER-TLS].

This text would benefit from further specificity.  My feedback below is very similar to my original DISCUSS position on -15 of this document.

-- Is the “secure management channel” described here the protocol that carries the BGP? 

-- Assuming it is, what is a “secure management channel” that would allow BGP to travel over the Internet that isn’t protected by IPsec (i.e., why can’t this text roughly read, “BGP over IPsec MUST be used”).  When and how should the BGP communication be secured?  Section 3.1.5 does mentioned that the BGP connection must be secured (i.e., “As the connection between an SD-WAN edge and its RR can be over an insecured network, an SD-WAN edge must establish a secure connection to its designated RR upon power-up. The BGP UPDATE messages must be sent over the secure channel to the RR.”)

-- The imperative, comprehensive analysis of [BGP-OVER-TLS] is not sufficiently motivated and the reference to an unadopted individual document is confusing.  I agree with the recommendation of the SECDIR reviewer to drop [BGP-OVER-TLS].  Can the basis for including it be explained?

[Ballot comment]
Thank you to Stephen Farrell for the SECDIR review.

** Section 2.  Editorial. If Section 3.2. defines “Homogeneous Encrypted SD-WAN” and the term isn’t used prior to that. Consider if this needs the definition.

** Section 2.
  SD-WAN IPsec SA: IPsec Security Association between two WAN ports
              of the SD-WAN nodes or between two SD-WAN nodes.

Is it “two SD-WAN nodes” or “two SD-WAN edge nodes”?  If the former, what is an “SD-WAN” node that isn’t an edge node?

** Section 3.1.2.  This sections seems to suggest that various MEF 70.1 behavior needs to be supported.  This suggests that [MEF70.1] needs to be a normative reference.

** Section 3.1.3.  Editorial.
  SD-WAN Traffic Segmentation enables the separation of the traffic
  based on the business and the security needs of different user
  groups and/or application requirements. Each user group and/or
  application may need different isolated topologies and/or policies
  to fulfill the business requirements.

Isn’t a security need also a need of the business?  Otherwise, the second sentence should read “… to fulfill the business and security requirements”.

** Section 3.1.3.  Editorial.
  The traffic from the PoS application follows a tree topology
  (denoted as "----" in the figure below), whereas other traffic can
  follow a multipoint-to-multipoint topology (denoted as "===").

In the figure, where is the PoS application, in one of the “Site #”?  Is there an assumption that traffic “flows up” from the sites to the payment gateway?  Where is the a “---” link from the “====”-connected “multi-point connection for non-payment traffic”?

** Section 3.1.4
    - Upon power-up, the SD-WAN edge can establish the transport
    layer secure connection [BCP195] to its controller, whose URL
    (or IP address) and credential for connection request can be
    preconfigured on the edge device by the manufacture, external
    USB or secure Email given to the installer.

Same feedback as provided on the ballot of the -15 version of this document:
Can the last two configuration options be clarified.

-- per “external USB”. Do you mean a USB _drive_ of some kind that is plugged in and the edge device knows to read what ever is on the drive to configure itself?  Does this mean anyone with physical access to the USB plug can power cycle the machine and can reconfigure it?

--  per “secure email”, does this mean that the installer configures the device based on something typed in?  What’s “secure” about the email?

Neither of these mechanisms seem like "Zero Touch".  They seem like the definition of human-in-the-loop.

** Section 3.1.4.  My understanding of Section 3.1.* was that it was series of requirements to be fulfilled by using BGP with SDWAN.  Per Zero Touch Provisioning, in what way is BGP involved in this provisioning? I’m not sure how this section fits into the scope of the document.

** Section 3.2
  -  A small branch office connecting to its HQ offices via the
  Internet. All traffic to/from this small branch office must be
  encrypted, usually achieved by IPsec Tunnels [RFC6071].

  -  A store in a shopping mall may need to securely connect to its
  applications in one or more Cloud DCs via the Internet. A common
  way of achieving this is to establish IPsec SAs to the Cloud DC
  gateway to carry the sensitive data to/from the store.

What is the technical difference between an “IPsec Tunnel” per the branch office use case and a “IPsec SA” in the store in the mall use case?

** Section 4.3
  In the context of a BGP-
  controlled SD-WAN, BGP UPDATE messages can disseminate IPsec-
  related attribute values for each node

Per the ballot on -15 of this draft, I asked “Please provide a reference to the specification which provides guidance on the BGP TLVs to provision IPsec.  Is that draft-ietf-idr-sdwan-edge-discovery?  This should be a normative reference.”  I still believe additional clarity is required.

** Section 5.2.
  In the figure below, the BGP UPDATE message from C-PE2 to RR can
  have the client routes encoded in the MP-NLRI Path Attribute and
  the IPsec Tunnel associated information encoded in the Tunnel-
  Encapsulation [RFC9012] Attributes.

Per https://www.iana.org/assignments/bgp-tunnel-encapsulation/bgp-tunnel-encapsulation.xhtml, is that value=25

** [SECURE-EVPN] is referenced a few times in the course of the draft.  Is the WG confident that this expired draft is appropriate to use?


** Section 8.
  Adding an Internet-facing WAN port to a C-PE can introduce the
  following security risks:

  1) Potential DDoS attacks from the Internet-facing ports.

  2) Potential risk of malicious traffic being injected via the
  Internet-facing WAN ports.

  3) For the Differential Encrypted SD-WAN deployment model, there
  is a risk of unauthorized traffic injected into the Internet-
  facing WAN ports being leaked to the L2/L3 VPN networks.

  Therefore, the additional anti-DDoS mechanism must be enabled on
  all Internet-facing ports to prevent potential attacks from those
  ports.

I’m having trouble understanding what is considered in-scope for these Security Considerations.  I was under the impression that the focus was the use of BGP as the control plane for SD-WAN communication.  Does it also include the “tunnels”/links configured by the SD-WAN via BGP.

-- If the security properties of tunnels/links configured by the SD-WAN BGP are in scope, then a reminder that links transiting non-Internet links are subject to security properties negotiated in the SLAs of that provided.

Specifically, on -15 of this document, I previously balloted “** Section 8.  The different deployment models also seem to place different levels of trust in the service providers.  Consider mentioning these differences.”

-- Likely because I don’t understand the definition of “Internet-facing ports” in the this context, I don’t see a difference between risk (2) and (3).  (2) seems like a more general version of (3).

-- What is the relationship between “anti-DDoS mechanism” and risk (2) of malicious traffic being injected?  Malicious traffic injection isn’t necessarily a DDoS.

-- I observe that there are no inherited Security Considerations from IPsec or BGP mentioned here. 

Per the ballot on -15 of the document, “This document seems to build on a number of other technologies.  Do their security considerations not apply (e.g., BGP, whatever ZTP technologies is chosen)?”, this feedback still applies.


** Section 10.1  Please provide the appropriate citation for [BCP195]

[Ballot comment]
# Internet AD comments for draft-ietf-bess-bgp-sdwan-usage-20
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S1

* Not entirely sure, but consider whether MEF 70.2 is better (or up-to-date)
  reference. (If you do change this reference, the Table 7 & 8 mentions need
  to be revised to Table 8 & 9, if I'm not mistaken).

* I cannot seem to find mention of the IPv6 Flow Label in MEF 70.1, nor in
  MEF 70.2.  I agree that it seems like it should be supported, but these
  tables seem to list requirements for support, and flow label seems to be
  absent.

### S6.3.2

* Is it necessary for IKE to be open if the requisite IPsec tunnel parameters
  can be shared via a BGP UPDATE message instead (vis. S4.3)?

## Nits

### S3.3

* The C3<->D2 connector reads "without encrypt over Untrusted".  Should that
  be "without encryption"?

### S6.1.1

* "six one-directional" ->
  "six unidirectional"?

### S6.2.1

* "wAN ports" -> "WAN ports"

### S6.3.2

* "target Pes" -> "target PEs"?

[Ballot comment]
# GEN AD review of draft-ietf-bess-bgp-sdwan-usage-15

CC @larseggert

Thanks to Dan Romascanu for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/1wTFLnMrWOSsJrziXpMDBcyv6GM).

## Comments

### Section 10.1, paragraph 1
```
    [BCP195]  RFC8996, RFC9325.
```
Not really acceptable as a normative reference.

### Missing references

No reference entries found for these items, which were mentioned in the text:
`[RFC8388]`, `[RFC6514]`, `[RFC7988]`, and `[RFC6513]`.

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Terms `traditionally` and `traditional`; alternatives might be `classic`,
  `classical`, `common`, `conventional`, `customary`, `fixed`, `habitual`,
  `historic`, `long-established`, `popular`, `prescribed`, `regular`,
  `rooted`, `time-honored`, `universal`, `widely used`, `widespread`
* Terms `natively` and `native`; alternatives might be `built-in`,
  `fundamental`, `ingrained`, `intrinsic`, `original`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Boilerplate

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License".

There is other outdated content in the boilerplate.

### Uncited references

Uncited references: `[MEF70.1]`.

### Outdated references

Document references `draft-ietf-rtgwg-net2cloud-problem-statement-26`, but
`-30` is the latest available revision.

### Grammar/style

#### Section 3.1.3, paragraph 5
```
uthorized to communicate with a small number of other SD-WAN edge nodes. In t
                              ^^^^^^^^^^^^^^^^^
```
Specify a number, remove phrase, use "a few", or use "some". (Also elsewhere.)

#### Section 6.2.2, paragraph 6
```
March 2004. [RFC3947] T. Kivinen, et al, "Negotiation of NAT Traversal in t
                                  ^^^^^
```
A period is misplaced or missing. (Also elsewhere.)

#### Section 6.2.2, paragraph 9
```
ov 2021. 11. Acknowledgments Acknowledgements to Andrew Alston, Adrian Farre
                            ^^^^^^^^^^^^^^^^
```
Do not mix variants of the same word ("acknowledgement" and "acknowledgment")
within a single text.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document has been developed over a number of years in the working group and has received broad exposure. I believe it represents broad consensus.
v12 of the draft was previously submitted to the IESG, but was sent back to the working group due to a restrictive clause in the boiler plate text.
This has now been removed and new WG adoption and WG last call polls concluded. Review comments were received from members of the IESG during this period. I believe that the authors have
addressed these.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No particularly controversial points.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

None indicated.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This is an informational document that does not define new protocol or extensions.
Related implementations of draft-ietf-idr-sdwan-edge-discovery-12 are noted on the datatracker page.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

All of the work in BESS utilizes BGP, which is owned by the IDR working group. Drafts which make significant changes to BGP or use it in new ways are generally cross-reviewed with IDR.
That is not the case here as this draft is simply describing the usage of existing technologies standardised within bess to SD-WAN.
An RTGDir review of version 6 was performed and found to be ready.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document does not use any formal languages.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The document does not contain a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

I have provided a detailed review of v7 of the draft, and reviewed and commented on subsequent versions. I believe the draft is ready.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No issues identified.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Informational. This is appropriate because the draft describes the applicability of existing BGP-based VPN control plane to SD-WAN. It does not propose protocol extensions.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. An IPR poll was carried out both at WG adoption and WG last call.


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The number of authors on the front page meets the RFC Editor requirement.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

ID Nits passes. There is one warning about showing IPv6 equivalents of IPv4 addresses in examples. However, the use of IPv4 here is considered adequate.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].


The references are divided into normative and informative. The categorisation of each reference seems reasonable.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

Normative references are all to published RFCs.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

There are no actions requested of IANA.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are no actions requested of IANA.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-bess-bgp-sdwan-usage-19, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-02-15):

From: The IESG
To: IETF-Announce
CC: andrew-ietf@liquid.tech, bess-chairs@ietf.org, bess@ietf.org, draft-ietf-bess-bgp-sdwan-usage@ietf.org, matthew.bocci@nokia.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (BGP Usage for SD-WAN Overlay Networks) to Informational RFC


The IESG has received a request from the BGP Enabled ServiceS WG (bess) to
consider the following document: - 'BGP Usage for SD-WAN Overlay Networks'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-02-15. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The document discusses the usage and applicability of BGP as the
  control plane for multiple SD-WAN scenarios. The document aims to
  demonstrate how the BGP-based control plane is used for large-
  scale SD-WAN overlay networks with little manual intervention.

  SD-WAN edge nodes are commonly interconnected by multiple types of
  underlay networks owned and managed by different network
  providers.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/



No IPR declarations have been submitted directly on this I-D.

Requesting a second last call on this after the document was returned to the working group to address a restrictive boiler plate issue.  Since various changes were made (including the boiler plate) before this came back to me, I felt it warranted a second IESG wide last call.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document has been developed over a number of years in the working group and has received broad exposure. I believe it represents broad consensus.
v12 of the draft was previously submitted to the IESG, but was sent back to the working group due to a restrictive clause in the boiler plate text.
This has now been removed and new WG adoption and WG last call polls concluded. Review comments were received from members of the IESG during this period. I believe that the authors have
addressed these.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No particularly controversial points.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

None indicated.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This is an informational document that does not define new protocol or extensions.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

All of the work in BESS utilizes BGP, which is owned by the IDR working group. Drafts which make significant changes to BGP or use it in new ways are generally cross-reviewed with IDR.
That is not the case here as this draft is simply describing the usage of existing technologies standardised within bess to SD-WAN.
An RTGDir review of version 6 was performed and found to be ready.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document does not use any formal languages.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The document does not contain a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

I have provided a detailed review of v7 of the draft, and reviewed and commented on subsequent versions. I believe the draft is ready.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No issues identified.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Informational. This is appropriate because the draft describes the applicability of existing BGP-based VPN control plane to SD-WAN. It does not propose protocol extensions.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. An IPR poll was carried out both at WG adoption and WG last call.


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The number of authors on the front page meets the RFC Editor requirement.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

ID Nits passes. There is one warning about showing IPv6 equivalents of IPv4 addresses in examples. However, the use of IPv4 here is considered adequate.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].


The references are divided into normative and informative. The categorisation of each reference seems reasonable.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

Normative references are all to published RFCs.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

There are no actions requested of IANA.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are no actions requested of IANA.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document has been developed over a number of years in the working group and has received broad exposure. I believe it represents broad consensus.
v12 of the draft was previously submitted to the IESG, but was sent back to the working group due to a restrictive clause in the boiler plate text.
This has now been removed and new WG adoption and WG last call polls concluded. Review comments were received from members of the IESG during this period. I believe that the authors have
addressed these.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No particularly controversial points.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

None indicated.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This is an informational document that does not define new protocol or extensions.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

All of the work in BESS utilizes BGP, which is owned by the IDR working group. Drafts which make significant changes to BGP or use it in new ways are generally cross-reviewed with IDR.
That is not the case here as this draft is simply describing the usage of existing technologies standardised within bess to SD-WAN.
An RTGDir review of version 6 was performed and found to be ready.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document does not use any formal languages.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The document does not contain a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

I have provided a detailed review of v7 of the draft, and reviewed and commented on subsequent versions. I believe the draft is ready.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No issues identified.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Informational. This is appropriate because the draft describes the applicability of existing BGP-based VPN control plane to SD-WAN. It does not propose protocol extensions.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. An IPR poll was carried out both at WG adoption and WG last call.


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The number of authors on the front page meets the RFC Editor requirement.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

ID Nits passes. There is one warning about showing IPv6 equivalents of IPv4 addresses in examples. However, the use of IPv4 here is considered adequate.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].


The references are divided into normative and informative. The categorisation of each reference seems reasonable.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

Normative references are all to published RFCs.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

There are no actions requested of IANA.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are no actions requested of IANA.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document has been developed over a number of years in the working group and has received broad exposure. I believe it represents broad consensus.
v12 of the draft was previously submitted to the IESG, but was sent back to the working group due to a restrictive clause in the boiler plate text.
This has now been removed. Review comments were received from members of the IESG during this period. I believe that the authors have
addressed these.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No particularly controversial points.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

None indicated.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This is an informational document that does not define new protocol or extensions.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

All of the work in BESS utilizes BGP, which is owned by the IDR working group. Drafts which make significant changes to BGP or use it in new ways are generally cross-reviewed with IDR.
That is not the case here as this draft is simply describing the usage of existing technologies standardised within bess to SD-WAN.
An RTGDir review of version 6 was performed and found to be ready.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document does not use any formal languages.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The document does not contain a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

I have provided a detailed review of v7 of the draft, and reviewed and commented on subsequent versions. I believe the draft is ready.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No issues identified.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Informational. This is appropriate because the draft describes the applicability of existing BGP-based VPN control plane to SD-WAN. It does not propose protocol extensions.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. An IPR poll was carried out both at WG adoption and WG last call.


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The number of authors on the front page meets the RFC Editor requirement.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

ID Nits passes. There is one warning about showing IPv6 equivalents of IPv4 addresses in examples. However, the use of IPv4 here is considered adequate.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].


The references are divided into normative and informative. The categorisation of each reference seems reasonable.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

Normative references are all to published RFCs.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

There are no actions requested of IANA.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are no actions requested of IANA.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

Resetting the working group state - since this document boiler plate contains a clause that would not allow for it to be adopted.  Please see https://trustee.ietf.org/documents/trust-legal-provisions/tlp-5/ Section 6(c)(i)

Document returned to working group due to the fact that it contains a publication limitation clause.  As per https://trustee.ietf.org/documents/trust-legal-provisions/tlp-5/ Section 6(c)(i)  This document in its current state cannot be a working group document - as such - it also cannot have passed working group last call.  I will also be setting the working state on this document as individual submission.  Should the authors choose to remove the clause in question - the document will need to go through another adoption call, and another last call.

[Ballot discuss]
# GEN AD review of draft-ietf-bess-bgp-sdwan-usage-15

CC @larseggert

Thanks to Dan Romascanu for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/1wTFLnMrWOSsJrziXpMDBcyv6GM).

## Discuss

### Boilerplate

Document has an IETF Trust Provisions (TLP) Section 6.c(i) Publication
Limitation clause. This means it can in most cases not be a WG document.

[Ballot comment]
## Comments

### Section 10.1, paragraph 1
```
    [BCP195]  RFC8996, RFC9325.
```
Not really acceptable as a normative reference.

### Missing references

No reference entries found for these items, which were mentioned in the text:
`[RFC8388]`, `[RFC6514]`, `[RFC7988]`, and `[RFC6513]`.

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Terms `traditionally` and `traditional`; alternatives might be `classic`,
  `classical`, `common`, `conventional`, `customary`, `fixed`, `habitual`,
  `historic`, `long-established`, `popular`, `prescribed`, `regular`,
  `rooted`, `time-honored`, `universal`, `widely used`, `widespread`
* Terms `natively` and `native`; alternatives might be `built-in`,
  `fundamental`, `ingrained`, `intrinsic`, `original`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Boilerplate

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License".

There is other outdated content in the boilerplate.

### Uncited references

Uncited references: `[MEF70.1]`.

### Outdated references

Document references `draft-ietf-rtgwg-net2cloud-problem-statement-26`, but
`-30` is the latest available revision.

### Grammar/style

#### Section 3.1.3, paragraph 5
```
uthorized to communicate with a small number of other SD-WAN edge nodes. In t
                              ^^^^^^^^^^^^^^^^^
```
Specify a number, remove phrase, use "a few", or use "some". (Also elsewhere.)

#### Section 6.2.2, paragraph 6
```
March 2004. [RFC3947] T. Kivinen, et al, "Negotiation of NAT Traversal in t
                                  ^^^^^
```
A period is misplaced or missing. (Also elsewhere.)

#### Section 6.2.2, paragraph 9
```
ov 2021. 11. Acknowledgments Acknowledgements to Andrew Alston, Adrian Farre
                            ^^^^^^^^^^^^^^^^
```
Do not mix variants of the same word ("acknowledgement" and "acknowledgment")
within a single text.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot discuss]
** Section 3.1.5. 
  The BGP UPDATE messages must be sent over the secure channel
  (TLS, DTLS, etc.) to the RR.

Can this text say a bit more on the expectations of secure transport?  My understanding was the IPsec was the common practice if confidentiality was desired.  Are there pointers for BGP over DTLS? Over TLS?  The closest I was able to find was BGP over QUIC per https://datatracker.ietf.org/doc/draft-retana-idr-bgp-quic/.

** Section 8.  This document seems to build on a number of other technologies.  Do their security considerations not apply (e.g., BGP, whatever ZTP technologies is chosen)?

[Ballot comment]
Thank you to Stephen Farrell for the SECDIR review.

** Section 1.  Editorial. s/Corporate HQ/corporate headquarters/.  Expand acronym on first use.

** Section 1.
    - Some traffic can be forwarded by edge nodes, based on their
      application identifiers

What are “application identifiers”?  Is an application in this context "HTTP" or "a particular video streaming service provider"?

** Section 2.
              NSP usually provides more
              advanced network services, such as MPLS VPN, private
              leased lines, or managed Secure WAN connections, often
              within a private, trusted domain. In contrast, an ISP
              usually provides plain Internet services over public
              untrusted domains.

There is a distinction between made between NSP vs. ISP.  I understand the idea of an NSP providing value added services.  What I could use help with is understanding what “plain Internet service over public untrusted domains” means.  How does an ISP provide services in a domain other than its own?
As far as I can tell, there is no subsequent text which relies on this nuanced definition of NSP vs. ISP.

** Section 3.1.4.

... such as the device series number

Should this read as “serial number”?

** Section 3.1.4
  - Upon power-up, the SD-WAN edge can establish the transport layer
    secure connection (such as TLS, DTLS) [BCP195] to its controller,
    whose URL (or IP address) can be preconfigured on the edge device
    by manufacture default, external USB or secure Email given to the
    installer.

Can the last two configuration options be clarified.

-- per “external USB”. Do you mean a USB _drive_ of some kind that is plugged in and the edge device knows to read what ever is on the drive to configure itself?  Does this mean anyone with physical access to the USB plug can power cycle the machine and can reconfigure it?

--  per “secure email”, does this mean that the installer configures the device based on something typed in?  What’s “secure” about the email?

Neither of these mechanisms seem like "Zero Touch".  They seems like the definition of human-in-the-loop.

** Section 3.1.4
    - The SD-WAN Controller authenticates the ZTP request from the
    remote SD-WAN edge with its configurations.

If only a URL is passed per the previous step, how is authentication of the device realized?

** Section 3.1.5
  In this circumstance, the
  property of the SD-WAN edge node cannot be propagated to other nodes
  that are not authorized to communicate.
...
  Therefore, SD-WAN
  deployment needs to have a central point to distribute the
  properties of an SD-WAN edge node to its authorized peers.


-- I got confused here.  What is a property?  How do properties propagate (or not)?

-- What does the SD-WAN distribute?  Is it a configuration or some kind of credential?

** Section 3.2
  Homogeneous Encrypted SD-WAN has some properties similar to the
  commonly deployed IPsec VPN, albeit the IPsec VPN is usually point-
  to-point among a small number of nodes and with heavy manual
  configuration for IPsec between nodes. In contrast, an SD-WAN
  network can have many edge nodes and a central controller to manage
  the configurations on the edge nodes.

There is a contrast being made that I don’t understand.  If the SD-WAN can manage the configuration of many edge notes, why can’t it manage IPSec VPNs on many edge nodes.  Doesn’t Section 4.3 describe IPsec provisioning?  Aren’t IPsec VPNs part of what can secure some of the links over commodity internet links?

** Section 3.3
    Also, the connection between C-PEs and their Controller (RR) might
    be via the untrusted public network. It is necessary to encrypt
    the communication between RR and C-PEs, by TLS, DTLS, etc.

-- Is the use of TLS and DTLS are hard requirement? 

-- Why do other sections say “secure transport (e.g., TLS, DTLS ...)”?

** Section 3.4.  Editorial.
  Throughout this document, this scenario is also called Internet
  Offload for Private VPN, or PE-based SD-WAN.

My crude search suggest that these scenario names are not used in the rest of the document.

** Section 4.2.  Editorial.
  Policies are needed
  to govern which underlay paths can carry an application flow, as
  described by Section 8 of MEF70.1

Something got mangled in the document rendering.  What is “MEF70.1”?

** Section 4.3
  SD-WAN edge nodes must negotiate the supported IPsec encryption
  algorithms (AES256, AES192, AES128, etc.), the hash algorithm (SHA2
  512, SHA2 384, SHA2256, etc.), and the DH groups to establish IPsec
  tunnels between them.

Recommend removing the different algorithm names.  At the level of abstraction of this text, it isn't clear that it is necessary to even call which IPsec parameters need to get negotiated.

NEW
SD-WAN edge nodes must negotiate various cryptographic parameters to establish IPsec tunnels between them.

** Section 4.3.
  For a BGP-controlled SD-WAN, BGP UPDATE
  messages can propagate each node's IPsec-related attribute values
  for peers to choose the common values supported, traditionally done
  by IPsec IKEv2 [RFC7296].

Please provide a reference to the specification which provides guidance on the BGP TLVs to provision IPsec.  Is that draft-ietf-idr-sdwan-edge-discovery?  This should be a normative reference.

** Section 5.1

  For an SD-WAN network with a small number of nodes, the traditional
  hub and spoke model utilizing Next Hop Resolution Protocol (NHRP) or
  Dynamic Smart VPN (DSVPN)/Dynamic Multipoint VPN (DMVPN) protocol
  has been found to work reasonably well.

-- Please provide a citation to DSVPN and DMVPN?

-- What does “work[s] reasonably well” intended to convey?  Does it not “work”?

** Section 5.2
  In the figure below, the BGP UPDATE message from C-PE2 to RR can
  have the client routes encoded in the MP-NLRI Path Attribute and the
  IPsec Tunnel associated information encoded in the Tunnel-Encap
  [RFC9012] Path Attributes as described in the [SECURE-EVPN].

Where in [SECURE-EVPN] is this relevant guidance?  Please provide the relevant section in the text.

** Section 8.
  2) Potential risk of illegal traffic being injected via the
  Internet-facing WAN ports.

What is “illegal” traffic?  What are the issues of legality?  Is this perhaps “malicious traffic” or “traffic prohibited by policy”?

** Section 8.  The different deployment models also seem to place different levels of trust in the service providers.  Consider mentioning these differences.

[Ballot comment]
I am balloting NoObjection, but am quite uncomfortable with it -- I will steal some of Eric V's ballot text - "... I find it ***weak*** on several points (see below) and more accurate language will be welcome rather than hand waving. I strongly suggest that the authors/WG have a second pass on the document."

The document is very hand-wavey, and, based on the number of open comments and nits, does not appear to have had significant detailed review; I almost balloted DISCUSS because of this.


This document would benefit from copy-editing.

1: The document opens with: "Here are some of the main characteristics of "SD-WAN" networks: [...]"
-- I don't really think that most of these are "the main characteristics of "SD-WAN" networks" - e.g: "Instead of all traffic hauled to Corporate HQ for centralized policy control, direct Internet breakout from remote branch offices is allowed." - this is a characteristic of many many different technologies and VPN solutions. The implication of this sentence so early in the document is that a: these are differentiating characteristics, and b: that they are the **main** characteristics. 

2: Editorial: "Instead of all traffic hauled to Corporate HQ for centralized policy control, direct Internet breakout from remote branch offices is allowed." - "Instead of hauling all traffic to ..." or "Instead of having all traffic hauled to..." or...

3: "Some traffic can be forwarded by edge nodes, based on their application identifiers instead of destination IP addresses, by placing the traffic onto specific overlay paths based on the application-specific policies." - the subject of this sentence is very unclear. What is this "some traffic" (why not all? what does "some" do in this sentence?). Same for "their" in "their application identifiers".

4: "CPE-Based VPN: Virtual Private Secure network formed among CPEs. This differentiates from more commonly used PE-based VPNs". How does "VPN" expand to "Virtual Private Secure network"? **How** this this "differentiates" from more commonly used PE-based VPNs? ("This differs from more commonly used PE-based VPNs as it is formed between CPE" would sort of work, but it is still very unclear *why* this is being noted.

5: "SD-WAN:    Software Defined Wide Area Network is an overlay network ..." - this is a much better definition than how the document was opened. I suggest that it be used if you want to introduce what SD-WAN **is**.

6: "Conventions used in this document [...] SD-WAN over Hybrid Networks: SD-WAN over Hybrid Networks typically have edge nodes...
You never actually use that term - you *do* use Hybrid Underlay (e.g "SD-WAN with Hybrid Underlays") a bunch of times though.

7: "For multicast packets forwarding" -> "For multicast packet forwarding"

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-bess-bgp-sdwan-usage-15

Thank you for the work put into this document. It could be useful but, honestly, I find it ***weak*** on several points (see below) and more accurate language will be welcome rather than hand waving. I strongly suggest that the authors/WG have a second pass on the document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Matthew Bocci for the shepherd's detailed write-up including the WG consensus ***and*** the justification of the intended status.

Please note that Juan-Carlos Zúñiga is the Internet directorate reviewer (at my request) and you may want to consider this int-dir review as well when it will be available (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/reviewrequest/18155/

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS

## Mixing IPsec SA and IPsec-protected tunnels

I am afraid that the text often mixes "IPsec SA" and "IPsec-protected tunnels" (the latter could be VXLAN/GRE/IPinIP tunnels).

## Absence of QUIC

Suggest to also add QUIC as a secure channel in addition to TLS.

## Abstract

Unsure about the usefulness of the last paragraph.

Isn't "SW-WAN overlay" an pleonasm ? I.e., are there SD-WAN without an overlay ?

## Section 1

`based on their application identifiers instead of destination IP addresses` what are those "application identifiers" ?

## Section 2

Should "PE-based VPN" be defined on its own ?

`plain Internet services` what are those services ? I guess mainly "IP packet forwarding", but this should be qualified.

Please explain what "ZTP" is.

## Section 3.1.1

Which part of the inner header is relevant to `the IPsec tunnel's inner encapsulation header can have the SD-WAN VPN Identifier to distinguish the packets belonging to different SD-WAN VPNs.` ?

## Section 3.1.2

What are `L3VPN service requirements` ?

Please expand "HR" as it is not part of https://www.rfc-editor.org/materials/abbrev.expansion.txt

## Section 3.1.5

Even of a SD-WAN edge does not receive a BGP UPDATE for a specific prefix, a manual static route could still forward traffic to this prefix. Should this security issue be mentioned ?

## Section 3.2

Please add a reference to "NVo3".

"Homogeneous" also seems to indicate that all IPsec SAs use the same security parameters (crypto alg, key length, ...). Is it mandatory for this document ? If not, then suggest to use "ubiquitous encrypted SD-WAN".

## Section 3.3

Unsure whether I agree with `it is more desirable for traffic over a private VPN to be forwarded without encryption.`.

## Section 5.1

The first paragraph mentions DMVPN/DSVPN that appears to be marketing terms from some vendors. Are those terms required ?

## Sections 5.2, 5.3, ...

Rather than using legacy IPv4 addresses, IPv6 examples would be more suitable in 2023.

## Section 5.4

If 192.0.2.9/30 is assumed to be a prefix, then it is *NOT* as it is part of 192.0.2.8/30.

## Section 6 does it belong to a BGP document ?

I fail to see how the whole section 6 is part of a BGP document. It is nice to read but what is the link with BGP ?

## Section 6.1.1

`six one-directional IPsec SAs must be established:` but then only 3 are show, suggest to either do not list the bidirectional arrows or use unidirectional arrows.

## Section 6.1.2

What is "inner encapsulation key" in `Different client traffic can be differentiated by a unique value in the inner encapsulation key or ID field` ?

Why are loopback addresses used here ? I would have assumed that for a public edge CPE, it would be the address of the public interface.

Neither IPv6 nor IPv4 headers have a header field "Protocol-code". Please use the right term.

The use of 'protected' for IPsec tunnel is ambiguous (at first read, I read it as *very secure/confidential*) in `C-PE Node-based IPsec tunnel is inherently protected`. E.g., in section 6.2 'protected' is used with a different semantic.

Is it really Figure 2 from pages before ?

I would expect that VXLAN/GRE encapsulation would cope better with multicast traffic. Would RFC 3740 and 6407 be useful for mcast traffic ?

## Section 6.2 (and other places)

The usual term is 'clear text' rather than 'native'.

## Section 6.2.2

Please describe or add a reference for `additional anti-DDoS mechanism`.

Figure 8 probably misses a link between A3 and PE.

## Section 6.3

Unsure whether the NAT part is useful, again what has this to do with BGP ? And/or how can a BGP session traverse a NAT ?

What is `Scenario #2` ?

## Section 8

I would have expected some security consideration about the centralization of security in the RR.

## Section 11

It is inconsistent with the authors' list in the header.

# NITS

## Section 1

s/IP Packets/IP packets/

A couple of places where "Tunnel" should rather be "tunnel".

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-bess-bgp-sdwan-usage-15

Thank you for the work put into this document. It could be useful but, honestly, I find it ***weak*** on several points (see below) and more accurate language will be welcome rather than hand waving. I strongly suggest that the authors/WG have a second pass on the document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Matthew Bocci for the shepherd's detailed write-up including the WG consensus ***and*** the justification of the intended status.

Please note that Bernie Volz is the Internet directorate reviewer (at my request) and you may want to consider this int-dir review as well when it will be available (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/reviewrequest/18155/

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS

## Mixing IPsec SA and IPsec-protected tunnels

I am afraid that the text often mixes "IPsec SA" and "IPsec-protected tunnels" (the latter could be VXLAN/GRE/IPinIP tunnels).

## Absence of QUIC

Suggest to also add QUIC as a secure channel in addition to TLS.

## Abstract

Unsure about the usefulness of the last paragraph.

Isn't "SW-WAN overlay" an pleonasm ? I.e., are there SD-WAN without an overlay ?

## Section 1

`based on their application identifiers instead of destination IP addresses` what are those "application identifiers" ?

## Section 2

Should "PE-based VPN" be defined on its own ?

`plain Internet services` what are those services ? I guess mainly "IP packet forwarding", but this should be qualified.

Please explain what "ZTP" is.

## Section 3.1.1

Which part of the inner header is relevant to `the IPsec tunnel's inner encapsulation header can have the SD-WAN VPN Identifier to distinguish the packets belonging to different SD-WAN VPNs.` ?

## Section 3.1.2

What are `L3VPN service requirements` ?

Please expand "HR" as it is not part of https://www.rfc-editor.org/materials/abbrev.expansion.txt

## Section 3.1.5

Even of a SD-WAN edge does not receive a BGP UPDATE for a specific prefix, a manual static route could still forward traffic to this prefix. Should this security issue be mentioned ?

## Section 3.2

Please add a reference to "NVo3".

"Homogeneous" also seems to indicate that all IPsec SAs use the same security parameters (crypto alg, key length, ...). Is it mandatory for this document ? If not, then suggest to use "ubiquitous encrypted SD-WAN".

## Section 3.3

Unsure whether I agree with `it is more desirable for traffic over a private VPN to be forwarded without encryption.`.

## Section 5.1

The first paragraph mentions DMVPN/DSVPN that appears to be marketing terms from some vendors. Are those terms required ?

## Sections 5.2, 5.3, ...

Rather than using legacy IPv4 addresses, IPv6 examples would be more suitable in 2023.

## Section 5.4

If 192.0.2.9/30 is assumed to be a prefix, then it is *NOT* as it is part of 192.0.2.8/30.

## Section 6 does it belong to a BGP document ?

I fail to see how the whole section 6 is part of a BGP document. It is nice to read but what is the link with BGP ?

## Section 6.1.1

`six one-directional IPsec SAs must be established:` but then only 3 are show, suggest to either do not list the bidirectional arrows or use unidirectional arrows.

## Section 6.1.2

What is "inner encapsulation key" in `Different client traffic can be differentiated by a unique value in the inner encapsulation key or ID field` ?

Why are loopback addresses used here ? I would have assumed that for a public edge CPE, it would be the address of the public interface.

Neither IPv6 nor IPv4 headers have a header field "Protocol-code". Please use the right term.

The use of 'protected' for IPsec tunnel is ambiguous (at first read, I read it as *very secure/confidential*) in `C-PE Node-based IPsec tunnel is inherently protected`. E.g., in section 6.2 'protected' is used with a different semantic.

Is it really Figure 2 from pages before ?

I would expect that VXLAN/GRE encapsulation would cope better with multicast traffic. Would RFC 3740 and 6407 be useful for mcast traffic ?

## Section 6.2 (and other places)

The usual term is 'clear text' rather than 'native'.

## Section 6.2.2

Please describe or add a reference for `additional anti-DDoS mechanism`.

Figure 8 probably misses a link between A3 and PE.

## Section 6.3

Unsure whether the NAT part is useful, again what has this to do with BGP ? And/or how can a BGP session traverse a NAT ?

What is `Scenario #2` ?

## Section 8

I would have expected some security consideration about the centralization of security in the RR.

## Section 11

It is inconsistent with the authors' list in the header.

# NITS

## Section 1

s/IP Packets/IP packets/

A couple of places where "Tunnel" should rather be "tunnel".

[Ballot comment]
Several nits & comments for the authors to consider:

## Section 1:
    - Some traffic can be forwarded by edge nodes, based on their
      application identifiers instead of destination IP addresses, by
      placing the traffic onto specific overlay paths based on the
      application-specific policies.

* Do the authors have a reference for this - does this imply DPI requirements or some other method to determine the application carried within the packets? What specifically is an 'application identifier'?

## Section 3.1.1

* Please expand on MPLS-VPN on the first usage with reference - RFC8388 does not document MPLS-VPN as a well-known term.

## Section 3.1.1:
  For IP-based client interfaces, L3VPN service requirements are
  applicable.

* What are these 'L3VPN service requirements'? is there a reference so that the reader can understand what these requirements are?

## Section 3.1.3

* The figure has no reference - it should be 'Figure 1' - Please correct this.

## Section 3.2

* Expand 'SA' to 'Security Association (SA)' on first usage.

## Section 3.4

* Please provide references for 'MPLS-in-IP/GRE-in-IPsec'.

## Section 5.1
  Dynamic Smart VPN (DSVPN)/Dynamic Multipoint VPN (DMVPN) protocol
  has been found to work reasonably well.

* Neither DSVPN nor DMVPN are protocols - suggest removing 'protocol' from the above text. Also, you should provide a reference for both of these for readers who are not familiar with these solutions.

## Section 5.2
  When using two separate BGP UPDATE messages, which is described by
  Section 4 and 8 of [RFC9012], UPDATE U1 has its Nexthop to the node
  loopback address and is recursively resolved to the IPsec SA tunnel
  detailed attributes advertised by the UPDATE U2 for the Node
  Loopback address.

* Section 4 of RFC9012 simply describes the Encapsulation Extended Community so I am not sure how that is relevant to the above paragraph. Section 8 describes recursive next-hop resolution which seems to be what you are describing here so is probably the only reference that you need.

[Ballot comment]
This document would benefit from copy-editing.

1: The document opens with: "Here are some of the main characteristics of "SD-WAN" networks: [...]"
-- I don't really think that most of these are "the main characteristics of "SD-WAN" networks" - e.g: "Instead of all traffic hauled to Corporate HQ for centralized policy control, direct Internet breakout from remote branch offices is allowed." - this is a characteristic of many many different technologies and VPN solutions. The implication of this sentence so early in the document is that a: these are differentiating characteristics, and b: that they are the **main** characteristics. 

2: Editorial: "Instead of all traffic hauled to Corporate HQ for centralized policy control, direct Internet breakout from remote branch offices is allowed." - "Instead of hauling all traffic to ..." or "Instead of having all traffic hauled to..." or...

3: "Some traffic can be forwarded by edge nodes, based on their application identifiers instead of destination IP addresses, by placing the traffic onto specific overlay paths based on the application-specific policies." - the subject of this sentence is very unclear. What is this "some traffic" (why not all? what does "some" do in this sentence?). Same for "their" in "their application identifiers".

4: "CPE-Based VPN: Virtual Private Secure network formed among CPEs. This differentiates from more commonly used PE-based VPNs". How does "VPN" expand to "Virtual Private Secure network"? **How** this this "differentiates" from more commonly used PE-based VPNs? ("This differs from more commonly used PE-based VPNs as it is formed between CPE" would sort of work, but it is still very unclear *why* this is being noted.

5: "SD-WAN:    Software Defined Wide Area Network is an overlay network ..." - this is a much better definition than how the document was opened. I suggest that it be used if you want to introduce what SD-WAN **is**.

6: "Conventions used in this document [...] SD-WAN over Hybrid Networks: SD-WAN over Hybrid Networks typically have edge nodes...
You never actually use that term - you *do* use Hybrid Underlay (e.g "SD-WAN with Hybrid Underlays") a bunch of times though.

7: "For multicast packets forwarding" -> "For multicast packet forwarding"

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-bess-bgp-sdwan-usage-14, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2023-08-01):

From: The IESG
To: IETF-Announce
CC: andrew-ietf@liquid.tech, bess-chairs@ietf.org, bess@ietf.org, draft-ietf-bess-bgp-sdwan-usage@ietf.org, matthew.bocci@nokia.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (SD-WAN edge nodes are commonly interconnected by multiple types of underlay networks owned and managed by different network providers.) to Informational RFC


The IESG has received a request from the BGP Enabled ServiceS WG (bess) to
consider the following document: - 'SD-WAN edge nodes are commonly
interconnected by multiple types of
  underlay networks owned and managed by different network providers.'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-08-01. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The document discusses the usage and applicability of BGP as the
  control plane for multiple SD-WAN scenarios. The document aims to
  demonstrate how the BGP-based control plane is used for large-scale
  SD-WAN overlay networks with little manual intervention.

  SD-WAN edge nodes are commonly interconnected by multiple types of
  underlay networks owned and managed by different network providers.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document has been developed over a number of years in the working group and has received broad exposure. I believe it represents broad consensus.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No particularly controversial points.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

None indicated.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This is an informational document that does not define new protocol or extensions.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

All of the work in BESS utilizes BGP, which is owned by the IDR working group. Drafts which make significant changes to BGP or use it in new ways are generally cross-reviewed with IDR. That is not the case here as this draft is simply describing the usage of existing technologies standardised within bess to SD-WAN.
An RTGDir review of version 6 was performed and found to be ready.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document does not use any formal languages.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The document does not contain a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

I have provided a detailed review of v7 of the draft, and reviewed and commented on subsequent versions. I believe the draft is ready.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No issues identified.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Informational. This is appropriate because the draft describes the applicability of existing BGP-based VPN control plane to SD-WAN. It does not propose protocol extensions.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. An IPR poll was carried out both at WG adoption and WG last call.


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The number of authors on the front page meets the RFC Editor requirement.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

ID Nits passes. There is one warning about showing IPv6 equivalents of IPv4 addresses in examples. However, the use of IPv4 here is considered adequate.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].


The references are divided into normative and informative. The categorisation of each reference seems reasonable.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

Normative references are all to published RFCs.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

There are no actions requested of IANA.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are no actions requested of IANA.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document has been developed over a number of years in the working group and has received broad exposure. I believe it represents broad consensus.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No particularly controversial points.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

None indicated.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This is an informational document that does not define new protocol or extensions.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

All of the work in BESS utilizes BGP, which is owned by the IDR working group. Drafts which make significant changes to BGP or use it in new ways are generally cross-reviewed with IDR. That is not the case here as this draft is simply describing the usage of existing technologies standardised within bess to SD-WAN.
An RTGDir review of version 6 was performed and found to be ready.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document does not use any formal languages.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The document does not contain a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

I have provided a detailed review of v7 of the draft, and reviewed and commented on subsequent versions. I believe the draft is ready.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No issues identified.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Informational. This is appropriate because the draft describes the applicability of existing BGP-based VPN control plane to SD-WAN. It does not propose protocol extensions.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. An IPR poll was carried out both at WG adoption and WG last call.


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The number of authors on the front page meets the RFC Editor requirement.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

ID Nits passes. There is one warning about showing IPv6 equivalents of IPv4 addresses in examples. However, the use of IPv4 here is considered adequate.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].


The references are divided into normative and informative. The categorisation of each reference seems reasonable.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

Normative references are all to published RFCs.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

There are no actions requested of IANA.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are no actions requested of IANA.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/