Mohamed Boucadair has entered the following ballot position for draft-ietf-bess-bgp-sdwan-usage-31: Discuss
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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi Linda, Ali, John, Basil, and Sue, Thank you for the effort put into this document. Thanks to Luis Miguel Contreras for the detailed OPSDIR review and to the authors for engaging and making changes. Given the intended Informational status of the document, I will focus on high level comments: # Lack of clear reference deployment model It is not clear to me which BGP sessions we are referring to nor why an underly PE will be involved in arrangements with an external SD-WAN provider. SD-WAN can be offered without coordination with PEs of underlying networks. There are maybe deployment assumptions that are not called out it here. Absent a clear deployment context, it is really hard (at least to me) to digest what is stated in several sections (e.g., 3.1.1). ## In the same vein, it is not clear to me whether this is documenting what is deployed as suggested by this sentence? CURRENT: By documenting how these mechanisms are used in SD-WAN deployments, this document ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ enables consistent interpretations and supports interoperability without defining new protocols. Do you confirm that [SD-WAN-Discovery] in particular is implemented and deployed as described in this document? Likewise, do you confirm that these are deployed today: CURRENT: An SD-WAN edge must use a secure channel, such as TLS following BCP195[RFC9325] or Ipsec [RFC4301], to its designated RR for exchanging BGP UPDATE messages. # Disconnect between the claimed scope vs. content ## The document deviates from the goal set (BGP-based control) and includes tangential material (e.g., onboarding, forwarding, etc.). For example, how the ZTP discussion is relevant here? Does it inform decisions about the BGP control part? Idem for the onboarding. For the forwarding part, is there any difference between how forwarding is done with proprietary control plane vs. BGP? Unless there are specifics, I suggest the main document to be trimmed to serve its claimed purpose. ## Operational Challenges CURRENT: Although BGP and IPsec are mature technologies, applying them to SD-WAN introduces challenges such as scalability, segmentation, and multi-homing. Putting aside that it is not easy to find a single place which each of these are discussed, the document includes inconsistent statements. For example, the document concludes with the following after discussing BGP/IPsec: This model emphasizes simplicity and efficiency, leveraging centralized governance to mitigate risks while ensuring scalability and interoperability of the SD-WAN. but the main body states: This approach may have scalability implications due to per-destination packet replication; optimization mechanisms are outside the scope of this document. ## Also, it is not clear if the assessment is about BGP with [SD-WAN-Discovery] or BGP without [SD-WAN-Discovery]. # Is really DPI required? CURRENT: SD-WAN: An overlay connectivity service that optimizes the transport of IP packets over one or more Underlay connectivity services by recognizing applications and ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ determining forwarding behavior by applying policies to them [MEF-70.2]. I would avoid this wording as this smells like DPI function is mandatory, while this can be basically about supplying classification rules (without having to inspect user traffic payload). # MEF, BGP, IPsec, and more are normative RFC4271 .. Software Defined Wide Area Network (SD-WAN), as described in [MEF70.2], … The detailed BGP extensions used for SD-WAN edge discovery and attribute distribution are specified in [SD-WAN-Discovery]. … The SD-WAN client interface should support IPv4 and IPv6 addresses as well as Ethernet in accordance with the [IEEE802.3] standard. … The client service at the SD-WAN edge must support the SD-WAN UNI service attributes outlined in Section 4 of [MEF 70.2]. … An SD-WAN edge must use a secure channel, such as TLS following BCP195[RFC9325] or Ipsec [RFC4301], to its designated RR for exchanging BGP UPDATE messages. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # I don’t parse how IP prefix is a service. CURRENT: Client service: A service (e.g., IP prefix or VLAN) attached to # A device is physical OLD: SD-WAN edge: A device, either physical or virtual, that participates in the SD-WAN overlay network. These nodes advertise client routes to the SD-WAN Controller (e.g., BGP RR). NEW: SD-WAN edge: A functional entity, either physical or virtual, that participates in the SD-WAN overlay network. These nodes advertise client routes to the SD-WAN Controller (e.g., BGP RR). Cheers, Med _______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
