[Resending the email] Hi Linda,
Thank you for responding. Please see in-line with tag [SD]. Regards. Saumya. From: Linda Dunbar [mailto:linda.dun...@futurewei.com] Sent: Thursday, March 7, 2024 1:52 AM To: Dikshit, Saumya <saumya.diks...@hpe.com<mailto:saumya.diks...@hpe.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: RE: Queries and comments on draft-ietf-bess-bgp-sdwan-usage 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<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. [SD] I agree with you that this is not the right placeholder for analyzing underlay paths. My intention was to analyze them in detail in perspective of SD-WAN and qualify them as secure/unsecure as that's the core motive of this literature. >>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-sdwan-usage-20#section-3.1.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. [SD] Can we add an explicit reference to EVPN as well in this section. >>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-sdwan-usage-20#section-3.1.3<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? [SD] * Dynamic segmentation is another term for unified role based access and policies for clients in typical campus/enterprise network. * "Dynamically provisioned policies" is different than "dynamic segmentation". The idea is to leveraging RR to dynamically update/precolate the policies to SD-WAN end-points, by reacting to new security updates (fabric management inputs) without bringing down the BGP sessions. The dynamic inferences are out of scope of this document. This can be some analytics tool or Policy manager sitting behind the RR and doing the needful. An extension to what WAN optimization can in the data path. >>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-sdwan-usage-20#section-3.1.5<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." [SD] * Not sure if (inter-AS on SD-WAN end points) cases were overlooked, as RFC4456 is specific to ibgp deployments. * Whereas sites/branches/fabrics can be provisioned disparately with different AS across geographies. * Propagation/relaying of NLRIs by RR is an integral part of optimizing the Control plane optimization in intra-AS BGP deployments to avoid full mesh via hub-spoke modelling. o This is generalized via Route Server Concept, which can do the needful for inter-AS route relaying between two SD-WAN end points. >>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-sdwan-usage-20#section-3.1<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? [SD] Yes, this is specific to BGP control plane when SD-WAN device is leveraged as site/fabric/branch border. It can be a handoff point between EVPN and L3VPN solutions with same or different underlying fabrics (MPLS all the way or Vxlan + MPLS). In either case, ot can be achieved via route filtering, default routes for vrf stretch and vlan stretch in the tenant space. >>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-sdwan-usage-20#section-4.1<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. [SD] The client prefixes which are not overlapping between sites/fabric/branches; aggregation and summarization techniques can help scale down the number of NLRIs exchanged in BGP UPDATE messages. >>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-sdwan-usage-20#section-5.1<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. [SD] BGP is a TCP transport protocol, and as TLS (Transport Layer Security) was design to work on top of resilient and reliable transport; TCP is a naturalized choice for the same. Hence BGP can leverage TLS as a security wrapper for sessions between RR and SD-WAN devices. Regards, Saumya.
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
