Hi Hang, I don't think binding SID is an option here or future direction. Once the traffic lands in the Cloud Backbone, several principals and technologies are in place to maintain proper SLA on the traffic. Note that the Cloud Backbone is not a public Internet. When the traffic traverses through the Cloud Regions Backbone, they get the best services to maintain proper SLA. I don't think Cloud Backbone is a concern in maintaining the SLA.
Yes, when the traffic traverses through the public internet, there might be a question on the SLA. In this Draft, we used Geneve-based encoding, a popular option for carrying Metadata information. From the Draft standpoint, there is no such restriction if the Vendors want to use SR-TE on top of a Geneve header on the Public internet; that is Vendor's choice. Though, with the MS Azure hat on, the better option is to use Azure Edge Pops from the nearest Branch location. The Express Route connections start from the Edge MSEE (Microsoft Enterprise Edge ExpressRoute) Routers. The Branch CPE traffic can enter Azure Cloud Backbone through MSEE Routers and use the Cloud Backbone for most of the part to maintain certain SLA. That way, most parts of the public internet can be avoided. Public documents are available on Azure Express Route Connections, please feel free to explore, or I can send you some links offline. Happy to have more discussions in the IETF. Thanks, Kausik From: Shihang(Vincent) <[email protected]> Sent: Wednesday, July 12, 2023 1:29 AM To: Kausik Majumdar <[email protected]>; Linda Dunbar <[email protected]>; Aseem Choudhary <[email protected]>; [email protected] Cc: [email protected] Subject: [EXTERNAL] RE: draft-dmk-rtgwg-multisegment-sdwan-00 Hi Kausik, Got it. I agree the best option is to keep two administrative domains loosely coupled. Is binding SID (RFC 9256) such an option? Thanks, Hang From: rtgwg <[email protected]<mailto:[email protected]>> On Behalf Of Kausik Majumdar Sent: Wednesday, July 12, 2023 1:38 PM To: Shihang(Vincent) <[email protected]<mailto:[email protected]>>; Linda Dunbar <[email protected]<mailto:[email protected]>>; Aseem Choudhary <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: RE: draft-dmk-rtgwg-multisegment-sdwan-00 Hi Hang, The Cloud Backbone will not expose the detail of TE service to the outside world thus end to end SR is not an option. The best option to keep two administrative domains loosely coupled. How traffic is steered inside Cloud Backbone that is internal to any Cloud providers. Thanks, Kausik From: Shihang(Vincent) <[email protected]<mailto:[email protected]>> Sent: Tuesday, July 11, 2023 9:00 PM To: Kausik Majumdar <[email protected]<mailto:[email protected]>>; Linda Dunbar <[email protected]<mailto:[email protected]>>; Aseem Choudhary <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: [EXTERNAL] RE: draft-dmk-rtgwg-multisegment-sdwan-00 Hi Kausik, You says: In addition to what Linda mentioned, the TE or SRv6 is not an option within the Cloud Backbone. I wonder why SRv6 is not an option within the Cloud Backbone. Do you mean that the Cloud Backbone will not use SRv6 for TE at all or it will not expose the detail of TE to the outside world thus end to end SR is not an option? Thanks, Hang From: rtgwg <[email protected]<mailto:[email protected]>> On Behalf Of Kausik Majumdar Sent: Wednesday, July 12, 2023 12:48 AM To: Linda Dunbar <[email protected]<mailto:[email protected]>>; Aseem Choudhary <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> 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 <[email protected]<mailto:[email protected]>> Sent: Tuesday, July 11, 2023 7:53 AM To: Aseem Choudhary <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> 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 <[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] https://www.ietf.org/mailman/listinfo/rtgwg
