This Draft has nothing to do with SRv6. Please feel free to use SRv6 encap/decap in the Provider network. Within the single CSP Domain how the traffic is steered that won't be controlled by the external Domains and not going to be exposed. Yes, DSCP based QoS services can be used in future. Though, that is not the purpose of this Draft. The main purpose of this Draft not to terminate the IPSec Tunnels in the Cloud Transit GWs.
Thanks, Kausik From: Gyan Mishra <[email protected]> Sent: Sunday, July 16, 2023 12:32 PM To: Linda Dunbar <[email protected]> Cc: Aseem Choudhary <[email protected]>; [email protected]; [email protected] Subject: [EXTERNAL] Re: draft-dmk-rtgwg-multisegment-sdwan-00 Hi Linda I reviewed the draft and had some questions and ideas for expansion of the draft to expand on use free using SRv6 uSID. We can discuss in separate email. The connection from CPE to any cloud GW being on Prem part of enterprise or off Prem to CSP would always be an eBGP peering to the gateway for both single segment and multi segment. Section 5.1 and 5.2 single and multi segment transit GW as iBGP. Would that not always be eBGP to the GW for both on Prem or off Prem GW. GENEVE is a DC specific overlay over IP underlay L2 centric extensibility. Since we are providing IP over SD WAN transitivity it seems having the complexity of the NVO GENEVE encapsulation seems quite a lot of overhead with outer MAC / IP / UDP / GENEVE / inner Ethernet / Payload. I believe Next SID SRv6 uSID as it uses native IP DA uSID carrier for steering up to 5 GW hops and SRv6 as it uses IPv6 data plane and IPv6 has native IPSEC with extension header you can do secure SRv6 uSID steering multi hop multi segment through CSP waypoints for end to end optimized SD WAN steering capabilities and all done natively with uSID which utilizes simplified IP DA address as uSID carrier for 6 hops of steering using uN shift and forward function within the DA IP uSID carrier as opposed to Replace SID which copies from SRH to DA requiring SRH to be present on the CSP GW multi hop endpoints. Another idea is maybe to use RFC 9012 BGP tunnel encapsulation attribute leverage to build the single and multi hop IP tunnels between the CSP gateways. Thanks Gyan On Tue, Jul 11, 2023 at 10:53 AM Linda Dunbar <[email protected]<mailto:[email protected]>> wrote: Aseem, Thanks for reviewing the draft. Answers to your questions are inserted below: Linda From: Aseem Choudhary <[email protected]<mailto:[email protected]>> Sent: Tuesday, July 11, 2023 1:13 AM To: [email protected]<mailto:[email protected]> Subject: Re: draft-dmk-rtgwg-multisegment-sdwan-00 Fixed a typo. From: Aseem Choudhary <[email protected]<mailto:[email protected]>> Date: Sunday, July 9, 2023 at 9:33 PM To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: draft-dmk-rtgwg-multisegment-sdwan-00 Hello Authors, Thanks for the document, Great work! Having gone through the document, I have some questions/clarifications: 1. Section 3.3, it is mentioned SRv6/mpls-te not the best way. If there are multiple Cloud GW's and traffic need to be steered through for serviceability and performance, why SRv6 not an option? [Linda] The draft proposes to use GENEVE header simply because wide adoption of GENEVE by cloud operators. In addition, when the traffic from on-prem CPEs to Cloud GWs via the public Internet, TE and SRv6 is not supported by the Internet. Internet can only forward traffic based on the packets' destination addresses. 1. Section 4.5: Can there be multiple Egress GW Sub-TLV (or Next GW Sub-TLV) to steer traffic. [Linda] The Egress GW Sub-TLV carries the information of the SD-WAN end point which is used by the egress GW to forward the traffic to. 1. Section 4.6/4.7: What is the best way to encode AZ/Regions? Is it possible to include/exclude specific Transit GW's? [Linda] Probably will be "name" for the AZ/Regions, as most cloud operators do today, as the actual GW address of different AZ/Regions might be hidden from the end users. I may have further comments. -thanks, Aseem _______________________________________________ rtgwg mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/rtgwg -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/> Gyan Mishra Network Solutions Architect Email [email protected]<mailto:[email protected]> M 301 502-1347
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
