Hi Linda My experience with telco cloud to Hyperscaler IT cloud via CXP COLO exchange point to CSPs such as AWS, GCP, Azure, OCP etc, the CXPs have direct access to all the local CSPs within close proximity to the public cloud DC. When creating the CSP VPC account and provisioning of the VPC, the VPCs for the account are provisioned in availability zones xyz within that local CSP POP. So the VPCs are local to that CSP and not spread across other DC availability zones within other CSP DC across their backbone AFAIK.
So I don’t think you would run into the problem described in the above case. I think in provisioning the VPCs if you have a single regional attachment via CXP COLO to the CSP, then you may want to spread the VPCs across all the CSP DC within the CSP internal network. So maybe in this case you may need to attach the meta data for the Geo location information for optimal routing. I think this may have been an issue prior to CXP COLOs becoming popular for multi cloud hybrid cloud for telco’s which gives you the proximity routing directly to all the multi cloud CSP POPs. However if you have multiple region based connections via CXP to CSP then you can keep the VPCs and advertisements local within the CSP POPs local DC set availability zone. Don’t have to rely on the Geo metadata. Kind Regards Gyan On Sun, Feb 5, 2023 at 10:51 PM Linda Dunbar <[email protected]> wrote: > > > MPLS experts: > > > > Section 4.3 of > https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/ > describes the behavior of extending MPLS based VPNs to Hybrid Cloud DCs > for enterprises’ workloads hosted in Cloud DCs. > > > > We really appreciate your feedback on this description. > > > > > 4.3. Extending MPLS-based VPNs to Hybrid Cloud DCs > > Traditional MPLS-based VPNs have been widely deployed as an effective way > to support businesses and organizations that require network performance > and reliability. MPLS shifted the burden of managing a VPN service from > enterprises to service providers. The CPEs attached to MPLS VPNs are > simpler and less expensive because they do not need to manage routes to > remote sites; they pass all outbound traffic to the MPLS VPN PEs to which > the CPEs are attached (albeit multi-homing scenarios require more > processing logic on CPEs). MPLS has addressed the problems of scale, > availability, and fast recovery from network faults, and incorporated > traffic-engineering capabilities. > > However, traditional MPLS-based VPN solutions are sub-optimized for > dynamically connecting to workloads/applications in cloud DCs. The Provider > Edge (PE) nodes of the enterprise’s VPNs might not have direct connections > to the third-party cloud DCs used by the enterprise to provide easy access > to its end users. When the user base changes, the enterprise’s > workloads/applications may be migrated to a new cloud DC location closest > to the new user base. The existing MPLS VPN provider might not have PEs at > the new location. Deploying PEs routers at new locations is not trivial, > which defeats one of the benefits of Clouds’ geographically diverse > locations allowing workloads to be as close to their end-users as possible. > > To mitigate those problems, IPsec tunnels can be used to dynamically > connecting MPLS PEs with the desired Cloud DCs. As MPLS VPN provide more > secure and higher quality services, it is desirable to locate the PEs with > the least cost (including routing distance and capacity cost) for the > dynamic IPsec tunnels to the Cloud DC GW. > > An enterprise can connect to multiple Cloud DC locations and establish > different BGP peers with Cloud GW routers at different locations. As > multiple Cloud DCs are interconnected by the Cloud provider's own internal > network, the Cloud GW BGP session might advertise all of the prefixes of > the enterprise's VPC, regardless of which Cloud DC a given prefix is > actually in. This can result in inefficient routing for the end-to-end data > path. To get around this problem, virtual routers in Cloud DCs can be used > to attach metadata (e.g., GENEVE header or IPv6 optional header) to > indicate Geo-location of the Cloud DCs. > > > > ------------------------------------- > > Thank you very much > > Linda Dunbar > > > _______________________________________________ > rtgwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
