La force des VPN BGP-MPLS comme nous l’avons vu est de permettre une très grande montée en charge, beaucoup de flexibilité dans la configuration des VPN ainsi qu’une évolutivité très importante des infrastructures.
On peut ainsi, dans les configurations les plus avancées imaginer des situations où plusieurs FAI connectent leur backbone BGP-MPLS les uns aux autres. Ceci permettant à des clients de se connecter à des partenaires passant par d’autres FAI, éventuellement dans d’autres pays. On peut aussi imaginer une multinationale qui en fonction des sites qu’elle possède dans le monde, choisit l’opérateur avec les meilleures prestations (ou le meilleur tarif) dans chaque pays où elle possède des sites. Les différents FAI reliant leur infrastructure BGP-MPLS entre eux.
Le futur de la technologie est également assuré grâce à sa compatibilité IPv6. La RFC 4659 présente des extensions à la RFC 4364 permettant de relier des clients IPv6 à un backbone BGP-MPLS en définissant une nouvelle famille d’adresse : VPN-IPv6 et en utilisant l’extension MultiProtocol de BGP.
Bien qu’à la base développé par les équipementiers Cisco et Juniper, cette technologie est adoptée par de plus en plus de constructeurs comme Alcatel ou Nortel. Il est évident que plus les équipementiers vont adhérer à cette technologie, moins les clients vont être réticents à faire reposer leur architecture dessus.
Nous n’avons pas beaucoup abordés dans cet exposé les problématiques de sécurité. En fait, il est supposé qu’un VPN BGP-MPLS offre au minimum la même sécurité qu’un VPN à travers un réseau opérateur qui utilise par exemple la technologie Frame Relay ou des liaisons louées. C'est-à-dire que les clients ont la même probabilité que sur un réseau opérateur traditionnel d’arriver à « sortir » du VPN. A condition bien évidemment que les équipements soient correctement configurés.
Pour les clients souhaitant encore plus de sécurité, i.e. les services de bases que peuvent apporter la cryptographie : authentification, intégrité et confidentialité, divers possibilités sont envisageables, comme le tunneling. Un brouillon IETF (février 2006, Architecture for the Use of PE-PE IPsec Tunnels in BGP/MPLS IP VPN) est en cours d’élaboration pour que les liaisons PE/PE soient encapsulées dans un tunnel IPsec.
Concernant la QoS plusieurs solutions sont possibles. On peut utiliser la partie expérimentale de la RFC 3032 (MPLS Label stack encoding) qui permet d’ajouter des tags concernant la QoS dans l’en-tête MPLS. Sinon, sur un backbone utilisant ATM comme technologie de niveau 2, les possibilités de QoS d’ATM peuvent être utilisées. Il est également possible d’utiliser les solutions présentées dans la RFC 3209 (Extensions to RSVP for LSP Tunnels) présenant les extensions à RSVP pour supporter MPLS.