[mpls] Need your feedback on extending MPLS network to Cloud DC for workloads hosted in Cloud DCs described in draft-ietf-rtgwg-net2cloud-problem-statement

[Linda Dunbar <[e-mail]>]

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