Saumya, Thank you very much for reviewing the document and providing the comments. Please see the detailed resolutions to your comments below.
Linda From: Dikshit, Saumya Sent: Sunday, March 3, 2024 5:14 PM To: Linda Dunbar <linda.dun...@futurewei.com<mailto:linda.dun...@futurewei.com>>; saja...@gmail.com<mailto:saja...@gmail.com>; John E Drake <jdr...@juniper.net<mailto:jdr...@juniper.net>>; basil.na...@bell.ca<mailto:basil.na...@bell.ca> Cc: bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>; bess@ietf.org<mailto:bess@ietf.org> Subject: Queries and comments on draft-ietf-bess-bgp-sdwan-usage-20 Hello Authors of draft-ietf-bess-bgp-sdwan-usage, I have following comments/queries: >>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-sdwan-usage-20#section-1: >>> "over one or more underlay connectivity services by recognizing >>> applications and determining forwarding" [SD] "Underlay" is being very generic ? it can be hierarchy of overlays on top of which "real security overlay is provisioned between the SD0WAN end points". I think it should be changed. [Linda] some underlay paths are provider VPN, some underlay paths are unsecure network. Over unsecure networks, IPsec tunnel needs to be established. It is out of the scope of this document to analyze the underlay details. Details of the various underlay can be found in the reference MEF70.1. >>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-sdwan-usage-20#section-3.1.1 >>> "As SD-WAN is an overlay network arching over multiple types of networks, >>> MPLS >>> L2VPN[RFC4761][RFC4762<https://datatracker.ietf.org/doc/html/rfc4762>]/L3VPN[RFC4364][RFC4659<https://datatracker.ietf.org/doc/html/rfc4659>] >>> or pure L2 underlay can continue using the VPN ID (Virtual Private Network >>> Identifier), VN-ID (Virtual Network Identifier), or VLAN (Virtual LAN) in >>> the data plane to differentiate packets belonging to different SD-WAN VPNs. [SD] Why only native MPLS VPNs. EVPN based MPLS or over Vxlan fabric can also be extended over IPSec, or underlying MPLS underlay. [Linda] Yes, they can all go over IPsec tunnel, that is the Scenario #1 (Section 3.2). However IPsec requires extensive processing, that is why the draft has Scenario #2. >>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-sdwan-usage-20#section-3.1.3 [SD] The section should explicitly mention, "dynamically provisioned policies based on evolving security threats and service provisioning" and also "dynamic segmentation" [Linda] What is the Dynamic Segmentation? Can you provide some wording to use? >>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-sdwan-usage-20#section-3.1.5: >>> "Each edge node informs the Route-Reflector (RR) >>> [RFC4456<https://datatracker.ietf.org/doc/html/rfc4456>] on its interested >>> SD-WAN VPNs. The RR only propagates the BGP UPDATE from an edge to others >>> within the same SD-WAN VPN." [SD] Route-Reflector should be generalized to include Route-Servers in a over-the-WAN deployment of network fabrics. This may involve BGP instances deployments in different ASs (eBGP) [Linda] The wording has been changed to per AD review and comments: "Route-Reflector (RR) [RFC4456], as an integral part of the SD-WAN controller, has the policy governing communication among peers. The RR only propagates the BGP UPDATE from an edge to others within the same SD-WAN VPN." >>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-sdwan-usage-20#section-3.1 [SD] there is not requirement "scope for optimization of client routes at the WAN Gateway in the control plane" as the CE device can be lowly scaled w.r.t to FIB/RIB tables and performance/convergence of control plane. This one is not specific to dataplane/traffic optimization [Linda] Interesting. Can you elaborate more? Is it related to using BGP as control plane for SD-WAN? >>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-sdwan-usage-20#section-4.1 >>> : Client Service Provisioning Model [SD] Aggregation/Summarization of routes is an integral part of client provisioning [Linda] Yes. Add your suggested wording. >>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-sdwan-usage-20#section-5.1: >>> Why BGP as Control Plane for SD-WAN? [SD] One organic reason is that BPG is a tcp based protocol and hence can easily align with TLS based security. [Linda] Very good point, add your suggested wording. Regards, Saumya.
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
