Ballot for draft-ietf-bess-bgp-sdwan-usage

Yes

Gunter Van de Velde

No Objection

Gorry Fairhurst

No Record

Andy Newton
Charles Eckel
Christopher Inacio
Deb Cooley
Éric Vyncke
Jim Guichard
Ketan Talaulikar
Mahesh Jethanandani
Mike Bishop
Mohamed Boucadair
Roman Danyliw
Tommy Jensen

  • Approve (15)
  • Approve (20)
  • Approve (30)

Summary: Has enough positions to pass.

Gunter Van de Velde
Yes
Gorry Fairhurst
No Objection
Comment (2026-05-05) Sent
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
Andy Newton
No Record
Charles Eckel
No Record
Christopher Inacio
No Record
Deb Cooley
No Record
Éric Vyncke
No Record
Jim Guichard
No Record
Ketan Talaulikar
No Record
Mahesh Jethanandani
No Record
Mike Bishop
No Record
Mohamed Boucadair
No Record
Roman Danyliw
No Record
Tommy Jensen
No Record