Roman Danyliw has entered the following ballot position for draft-ietf-bess-bgp-sdwan-usage-30: Abstain
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: ---------------------------------------------------------------------- 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? _______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
