Dikshit, Sorry for the late reply. Please see below resolutions ([Linda2]) to the comments you have raised.
From: Dikshit, Saumya <saumya.diks...@hpe.com> Sent: Saturday, April 20, 2024 4:10 AM To: Linda Dunbar <linda.dun...@futurewei.com>; saja...@gmail.com; John E Drake <jdr...@juniper.net>; basil.na...@bell.ca Cc: bess-cha...@ietf.org; bess@ietf.org Subject: RE: Queries and comments on draft-ietf-bess-bgp-sdwan-usage Hi Linda, Not sure if you these emails are making it to the forum đ so resending it. Regards, Suamya. From: Dikshit, Saumya Sent: Thursday, April 4, 2024 9:01 AM 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: RE: Queries and comments on draft-ietf-bess-bgp-sdwan-usage Hi Linda, If any of the below comments were addressed in the latest version of the draft. Regards, Saumya. 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. [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. [Linda2] Can you please check the latest revision https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/ to see if there is anything you would like to add or change? >>> 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. [Linda2] The draft is mainly about two layers of advertisement: 1. underlay port IP address (and associated properties) advertisement, and 2. client prefix advertises. The client prefixes advertisements remain the same. EVPN is about Layer 2 over IP. All EVPN services advertisement remain the same. If you see any additional text to be added, please provide a constructive wording to be added. >>> 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. [Linda2] so it is about the polices to RR, which is out of the scope of document. Maybe we can add some wording on the policy to RR. Please provide the wording you would like to add. Thank you. >>> 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. * This is generalized via Route Server Concept, which can do the needful for inter-AS route relaying between two SD-WAN end points. [Linda2] for SD-WAN, it is iBGP. >>> 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. [Linda] In terms of underlay WAN ports address advertisement, are there any changes? >>> 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. [Linda] Client advertisement remains the same as L3VPN, L2VPN, and EVPN. >>> 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. [Linda] very good point. We have added this to the revision -23. Thank you, Linda Regards, Saumya.
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
