Hi Authors, All, Please review the information regarding the return decision for draft-ietf-bess-bgp-sdwan-usage. There are unresolved foundational technical issues that require significant attention and a consensus within the working group. Consequently, allowing additional time for this draft within the Working Group will be beneficial. This approach will ensure the document is thoroughly vetted and refined before further IETF processing.
Questions to the BESS WG community: ================================ * A recurring issue noted during the IESG review concerns the ambiguous purpose of the document. The draft-ietf-bess-bgp-sdwan-usage broadly suggests the possibility of utilizing BGP for the control plane and IPSec for the data plane. The necessity of an RFC to establish this practice is questionable. * The rationale for considering draft-ietf-bess-bgp-sdwan-usage within the scope of the BESS charter is unclear. BESS is not mandated to define, specify, or expand upon every possible network service using any conceivable forwarding plane merely because BGP serves as the control plane. About draft-ietf-bess-bgp-sdwan-usage technology: ========================================== * RFC5566, which is obsolete, is currently utilized as a foundational component within draft-ietf-bess-bgp-sdwan-usage. It is advisable that newly proposed RFCs should avoid incorporating obsolete technologies. * There appears to be a misuse of the Encapsulation Extended Community, as detailed in https://mailarchive.ietf.org/arch/msg/idr/umBB5yfoC3mFMpIWIT2K8159Gos/ . * The "Encapsulation Extended Community: TYPE = IPsec" does not exist, according to the IANA registry of BGP tunnel encapsulation types. see https://www.iana.org/assignments/bgp-tunnel-encapsulation/bgp-tunnel-encapsulation.xhtml#tunnel-types * Newly proposed RFCs should not assume the existence of unestablished code-points as if they were established; if a new tunnel type for IPsec Tunnel underlay paths is required, it must be formally defined prior to implementation. * RFC 9012 includes mechanisms for selecting or preferring NLRIs using the Color Extended Community, which might interact with the draft-ietf-bess-bgp-sdwan-usage's TYPE = IPsec proposal. * The term "Policy" is used variably throughout several sections, possibly leading to confusion about its application to different objectives. Clarity could be improved by specifying the types of policy being discussed. * Section 3.1.5 mentions that "Route-Reflectors... has the policy governing communication among peers", suggesting existing knowledge of route destinations, thereby questioning the necessity of RFC 4684. * The security architecture concerning BGP-based structures and tunnel signaling should be more thoroughly explored, particularly in Section 8, rather than being briefly mentioned in Section 3.1.5. * Section 8 requires enhancements to adequately address the issues raised in Roman's discuss items. * The text in Sections 6.2.2, 6.3.2, and 8 mentions the need for "additional anti-DDoS mechanisms." This requires further specification of the expected mechanisms. * A variety of editorial suggestions have been made by the IESG community during the review of draft-ietf-bess-bgp-sdwan-usage-20. See https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/ballot/971205/. Kind Regards, Gunter Van de Velde RTG AD _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
