Thank you Flavio, forgive my description, when i say "external" border node i am not refering to either the default border or handoff to a fusion router.
This would be the border or border/control plane router connected to an upstream carrier network providing internal intersite connecivity for the company ie: MPLS/DMVPN etc.
Based on the CVD, there seems to be 3 options to achieve this, although only the last one seems valid in this scenario.
● VRF Aware—A border node will be VRF-aware. All user-defined VNs in the fabric site are instantiated and provisioned as VRFs.
● Site Prefixes in VRF—The EID-space prefixes associated with the fabric site will be in VRF routing tables on the border node.
● Upstream Infrastructure—The border nodes will be connected to a next-hop device and further routing infrastructure (referenced simply as next-hop, for brevity). This upstream infrastructure, while a necessary part of the overall design, is not part of the fabric site and is therefore not automated though SD-Access workflows in Cisco DNA Center.
This deployment type begins with VRF-lite automated on the border node, and the peer manually configured, though not VRF-aware. For each VN that is handed off on the border node, a corresponding interface is configured on the peer device in the global routing table. This deployment option is commonly used when the fabric site hands off to a WAN circuit, ISP, an MPLS CE or PE device, other upstream routing infrastructure, or even a firewall which is special-case non-VRF peer discussed further in the Firewall section.
This deployment type is common in WAN infrastructure. If this next-hop peer is an MPLS CE, routes are often merged into a single table to reduce the number of VRFs to be carried across the backbone, generally reducing overall operational costs. If the next-hop peer is an MPLS PE or ISP equipment, it is outside of the administrative domain of the fabric network operator. The result is that there is little flexibility in controlling the configuration on the upstream infrastructure. Many times, ISPs have their own peering strategies and themselves are presenting a Layer 3 handoff to connected devices.
Non-VRF aware means that peer router is not performing VRF-lite. It may have the functionality to support VRFs, but it is not configured with corresponding fabric VRFs the way a VRF-Aware peer would be. The non-VRF aware peer is commonly used to advertise a default route to the endpoint-space in the fabric site.