Not sure what the original poster's reasoning was but we have a similar need.
We want to extend MPLS VRF's to hundreds of branch locations. However, using AT&T AVPN MPLS services we can't do this without using DMVPN as they won't PASS-THROUGH tags through their cloud. Too bad because one of the criteria for us to to maintain control over the tagging. This is the old carrier-in-carrier issue. DMVPN solves these issues for us.
However, DMPVN in voice environments over WAN doesn't have the performance to support VoIP spoke to spoke (also on the road map for us) so we are stuck with Hub and Spoke-only deployments. I guess we can live with that.
However, GETVPN may very well be the better choice long term, once it is VRF aware. Also we already have lots of WAN sites using GETVPN. Further, if we switch to DMVPN with encryption and move away from GET for the interim, in a couple years we may find ourselves wanting to got back to GETVPN. Not a big deal with 5 sites, but with hundreds, each change is a multi-month project, training, re-training, documenting, etc...
So, the ideal solution seems to be, Introduce DMVPN WITH GETVPN. Do this until GET is VRF-aware so we can maintain the GET facility we have today while also allowing MPLS transport of our own tags through a service provider. Once GET is VRF-aware (this is an assumption on my part) we then peel off the DMVPN and just use GET. And, we might end up gaining spoke-to-spoke routing capability at the same time.
NOTE 1: early feedback is, headend multicast replication penalty when using DMVPN would be eliminated as well. Haven't looked at this aspect in detail myself.
NOTE 2: we just found out that ATT has a plan to increase their current MTU of 1500 within their MPLS AVPN cloud to 2000 some time later this year. This makes control of our own tag stack possible and in turn, faster less expensive move add change sequences.)
So, if anybody knows if this is even possible, holler.
P.S. Post, posting note: we aren't alone in seeing the need. Here is a link to somebody else who took it out for a spin:
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...