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

# É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 ;-)

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

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

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/