Hi Aseem, On your second comment -
Section 4.5: Can there be multiple Egress GW Sub-TLV (or Next GW Sub-TLV) to steer traffic. We have analyzed. Yes, there could be multiple Egress GW Sub-TLVs that Destination CPE could be attached to due to the redundancy support/scale-out reasons. In those scenarios, the Destination CPE can propagate the Egress GWs information to the Source CPE through the Control Plane mechanism (The CP mechanism outside of this Draft scope). The Source CPE can include multiple Egress GW Sub-TLVs when Source and Destination CPEs are not in the same geographic region, and traffic needs to flow multiple Regions within the Cloud Backbone. These multi-Egress GWs allow the traffic to flow through different Egress GW endpoints to share the load. We will update to make it clear in the Draft after the IETF. Thanks for bringing this to our attention. Thanks, Kausik From: Kausik Majumdar Sent: Tuesday, July 11, 2023 1:36 PM To: Aseem Choudhary <achoudh...@aviatrix.com>; Linda Dunbar <linda.dun...@futurewei.com>; draft-dmk-rtgwg-multisegment-sdwan.auth...@ietf.org Cc: rtgwg@ietf.org Subject: RE: draft-dmk-rtgwg-multisegment-sdwan-00 Hi Aseem, Yes, #1 is a good option. We can explore further in that direction. Please feel free to suggest any text that you like to improve further. Thanks, Kausik From: Aseem Choudhary <achoudh...@aviatrix.com<mailto:achoudh...@aviatrix.com>> Sent: Tuesday, July 11, 2023 1:26 PM To: Kausik Majumdar <kmajum...@microsoft.com<mailto:kmajum...@microsoft.com>>; Linda Dunbar <linda.dun...@futurewei.com<mailto:linda.dun...@futurewei.com>>; draft-dmk-rtgwg-multisegment-sdwan.auth...@ietf.org<mailto:draft-dmk-rtgwg-multisegment-sdwan.auth...@ietf.org> Cc: rtgwg@ietf.org<mailto:rtgwg@ietf.org> Subject: [EXTERNAL] Re: draft-dmk-rtgwg-multisegment-sdwan-00 You don't often get email from achoudh...@aviatrix.com<mailto:achoudh...@aviatrix.com>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Hi Linda, Kaushik, Thanks for the response. This is certainly helpful. Also, additional questions/clarification/suggestion: 1. Any consideration of performance expectation through cloud DCs in term of intent (color) and/or DSCP? 2. Some text on AH for header authentication will help. Best, Aseem From: Kausik Majumdar <kmajum...@microsoft.com<mailto:kmajum...@microsoft.com>> Date: Tuesday, July 11, 2023 at 9:47 AM To: Linda Dunbar <linda.dun...@futurewei.com<mailto:linda.dun...@futurewei.com>>, Aseem Choudhary <achoudh...@aviatrix.com<mailto:achoudh...@aviatrix.com>>, draft-dmk-rtgwg-multisegment-sdwan.auth...@ietf.org<mailto:draft-dmk-rtgwg-multisegment-sdwan.auth...@ietf.org> <draft-dmk-rtgwg-multisegment-sdwan.auth...@ietf.org<mailto:draft-dmk-rtgwg-multisegment-sdwan.auth...@ietf.org>> Cc: rtgwg@ietf.org<mailto:rtgwg@ietf.org> <rtgwg@ietf.org<mailto:rtgwg@ietf.org>> Subject: RE: draft-dmk-rtgwg-multisegment-sdwan-00 Hi Aseem, Sorry for the late response. In addition to what Linda mentioned, the TE or SRv6 is not an option within the Cloud Backbone. The Cloud Backbone is a different administrative domain than Branch CPEs, and how the traffic steered within the Cloud Backbone that is not exposed to the Branch CPEs is internal to the Cloud. Hence, any SR-TE-based end-to-end mechanism doesn't work here. The Cloud Backbone might use some Traffic Engineering, but again that is internal to the Cloud Backbone on how they steer the traffic within their Backbone. There is only one Egress GW. It is used as an optional Sub-TLV as a last GW within the Cloud Backbone, which is connected to the Destination Branch CPE. On your 3rd point, the actual GWs within the Cloud Backbone are not exposed to the external world. That is solely control of individual Cloud Backbone. The best way to influence and encode the Cloud Regions is through Include /Exclude Transit Regions. That clearly dictates the intention that Branch CPEs want to influence the Transit Regions within the Cloud Backbone. The Cloud GW should be able to interpret these Sub-TLVs and can come up with possible paths to honor the preferred/de-preferred Regions. We haven't defined the format for these Sub-TLVs, but that might come in subsequent versions. In the initial implementation, it won't be implemented, most likely. It's the most advanced feature, but it gives us a scope to accommodate that in future to prefer/de-prefer the Regions within the Cloud Backbone. Hope it helps. We plan to present this Draft in IETF 117. Please feel free to discuss more in the IETF. Thanks, Kausik From: Linda Dunbar <linda.dun...@futurewei.com<mailto:linda.dun...@futurewei.com>> Sent: Tuesday, July 11, 2023 7:53 AM To: Aseem Choudhary <achoudh...@aviatrix.com<mailto:achoudh...@aviatrix.com>>; draft-dmk-rtgwg-multisegment-sdwan.auth...@ietf.org<mailto:draft-dmk-rtgwg-multisegment-sdwan.auth...@ietf.org> Cc: rtgwg@ietf.org<mailto:rtgwg@ietf.org> Subject: [EXTERNAL] RE: draft-dmk-rtgwg-multisegment-sdwan-00 Aseem, Thanks for reviewing the draft. Answers to your questions are inserted below: Linda From: Aseem Choudhary <achoudh...@aviatrix.com<mailto:achoudh...@aviatrix.com>> Sent: Tuesday, July 11, 2023 1:13 AM To: draft-dmk-rtgwg-multisegment-sdwan.auth...@ietf.org<mailto:draft-dmk-rtgwg-multisegment-sdwan.auth...@ietf.org> Subject: Re: draft-dmk-rtgwg-multisegment-sdwan-00 Fixed a typo. From: Aseem Choudhary <achoudh...@aviatrix.com<mailto:achoudh...@aviatrix.com>> Date: Sunday, July 9, 2023 at 9:33 PM To: draft-dmk-rtgwg-multisegment-sdwan.auth...@ietf.org<mailto:draft-dmk-rtgwg-multisegment-sdwan.auth...@ietf.org> <draft-dmk-rtgwg-multisegment-sdwan.auth...@ietf.org<mailto:draft-dmk-rtgwg-multisegment-sdwan.auth...@ietf.org>> 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 rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
