Gorry Fairhurst has entered the following ballot position for draft-ietf-bess-bgp-sdwan-usage-30: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/ ---------------------------------------------------------------------- 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 _______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
