Changing the subject line (removing the version) Gentle reminder for the response from the authors
From: Dikshit, Saumya Sent: Tuesday, March 5, 2024 7:44 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-20 Kindly respond to the comments below. 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. >>> 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. >>> 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" >>> 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) >>> 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 >>> 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 >>> 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. Regards, Saumya.
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
