[bess] return decision for draft-ietf-bess-bgp-sdwan-usage to allow additional WG time

["Gunter van de Velde (Nokia)" <[e-mail]>]

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