Re: [bess] Queries and comments on draft-ietf-bess-bgp-sdwan-usage

["Dikshit, Saumya" <[e-mail]>]

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 <[e-mail]>; [e-mail]; John E Drake <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]
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 <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; John E Drake <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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.