10. Data-Center Interconnections (DCIs) (Interconnexions de centres de données)

Pour les DCI, les deux scénarios principaux suivants sont considérés lors de la connexion de centres de données exécutant evpn-overlay (comme décrit ici) sur un réseau central MPLS/IP:

Scénario 1: DCI utilisant des GW
Scénario 2: DCI utilisant des ASBR

Les deux sous-sections suivantes décrivent les opérations pour chacun de ces scénarios.

10.1. DCI Using GWs (DCI utilisant des passerelles)

Il s'agit du scénario typique pour interconnecter des centres de données sur WAN. Dans ce scénario, les routes EVPN sont terminées et traitées dans chaque GW et les routes MAC/IP sont toujours re-annoncées du DC vers le WAN mais du WAN vers le DC, elles ne sont pas re-annoncées si des adresses MAC inconnues (et une adresse IP par défaut) sont utilisées dans les NVE. Dans ce scénario, chaque GW maintient une MAC-VRF (et/ou IP-VRF) pour chaque EVI. Le principal avantage de cette approche est que les NVE n'ont pas besoin de maintenir des adresses MAC et IP de centres de données distants lorsque des routes IP par défaut et des routes MAC inconnues sont utilisées; c'est-à-dire qu'ils n'ont besoin de maintenir que des routes locales à leur propre DC. Lorsque des routes IP par défaut et des routes MAC inconnues sont utilisées, tous les paquets IP et MAC inconnus des NVE sont transférés vers les GW où toutes les routes MAC et IP VPN sont maintenues. Cette approche réduit considérablement la taille de la MAC-VRF et de l'IP-VRF au niveau des NVE. De plus, elle entraîne un temps de convergence plus rapide lors d'une défaillance de lien ou de NVE dans un scénario de réseau multihébergé ou de redondance de périphérique, car les routes BGP liées à la défaillance (telles que le message de retrait massif) n'ont pas besoin d'être propagées jusqu'aux NVE distants dans les DC distants. Cette approche est décrite en détail dans la section 3.4 de [DCI-EVPN-OVERLAY].

10.2. DCI Using ASBRs (DCI utilisant des ASBR)

Cette approche peut être considérée comme l'opposé de la première approche. Elle favorise la simplification au niveau des dispositifs DCI plutôt qu'au niveau des NVE, de sorte que des tables MAC-VRF (et IP-VRF) plus grandes doivent être maintenues sur les NVE; tandis que les dispositifs DCI n'ont pas besoin de maintenir de tables de transfert MAC (et IP). De plus, les dispositifs DCI n'ont pas besoin de terminer et de traiter les routes liées au multihébergement mais plutôt de relayer ces messages pour l'établissement d'un Label Switched Path (LSP) de bout en bout. En d'autres termes, les dispositifs DCI dans cette approche fonctionnent de manière similaire aux ASBR pour l'option B inter-AS (voir section 10 de [RFC4364]). Cela nécessite l'utilisation de VNI assignés localement tout comme les étiquettes VPN MPLS assignées en aval où, à toutes fins pratiques, les VNI fonctionnent comme des étiquettes VPN de 24 bits. Cette approche est également applicable aux centres de données (ou réseaux Ethernet d'opérateur) avec encapsulation MPLS.

Dans l'option B inter-AS, lorsque l'ASBR reçoit une route EVPN de son DC via internal BGP (iBGP) et la re-annonce à d'autres ASBR, il re-annonce la route EVPN en réécrivant le prochain saut BGP vers lui-même, perdant ainsi l'identité du PE qui a émis l'annonce. Cette réécriture du prochain saut BGP impacte négativement la route de retrait massif EVPN (Ethernet A-D par ES) et sa procédure. Cependant, elle n'impacte pas le mécanisme/la procédure d'Aliasing EVPN car lorsque les routes d'Aliasing (Ethernet A-D par EVI) sont annoncées, le PE récepteur résout d'abord une adresse MAC pour un EVI donné en son <ES, EVI> correspondant, et, par la suite, il résout le <ES, EVI> en plusieurs chemins (et leurs prochains sauts associés) via lesquels le <ES, EVI> est accessible. Étant donné que les routes d'Aliasing et MAC sont toutes deux annoncées sur une base par EVI et qu'elles utilisent le même RD et RT (par EVI), le PE récepteur peut les associer ensemble sur une base par chemin BGP (par exemple, par PE d'origine). Ainsi, il peut effectuer une résolution de route récursive, par exemple, une MAC est accessible via un <ES, EVI> qui, à son tour, est accessible via un ensemble de chemins BGP; ainsi, la MAC est accessible via l'ensemble de chemins BGP. En raison de la base par EVI, l'association des routes MAC et de la route d'Aliasing correspondante est fixe et déterminée par le même RD et RT; il n'y a pas d'ambiguïté lorsque le prochain saut BGP pour ces routes est réécrit lorsque ces routes passent par des ASBR. C'est-à-dire, le PE récepteur peut recevoir plusieurs routes d'Aliasing pour le même EVI à partir d'un seul prochain saut (un seul ASBR), et il peut toujours créer plusieurs chemins vers ce <ES, EVI>.

Cependant, lorsque l'adresse de prochain saut BGP correspondant au PE d'origine est réécrite, l'association entre la route de retrait massif (Ethernet A-D par ES) et ses routes MAC correspondantes ne peut pas être faite en fonction de leurs RD et RT car le RD pour la route de retrait massif est différent de celui des routes MAC. Par conséquent, la fonctionnalité nécessaire au niveau des ASBR et des PE récepteurs dépend du fait que la route de retrait massif soit émise ou non et qu'il soit nécessaire de gérer l'ambiguïté de résolution de route pour cette route. Les deux sous-sections suivantes décrivent la fonctionnalité nécessaire par les ASBR et les PE récepteurs selon que les NVE résident dans des hyperviseurs ou dans des commutateurs ToR.

10.2.1. ASBR Functionality with Single-Homing NVEs (Fonctionnalité ASBR avec NVE monohébergés)

Lorsque les NVE résident dans des hyperviseurs comme décrit dans la section 7.1, il n'y a pas de multihébergement; ainsi, il n'y a pas besoin pour le NVE d'origine d'envoyer des routes Ethernet A-D par ES ou Ethernet A-D par EVI. Cependant, comme noté dans la section 7, afin de permettre à un NVE d'entrée monohébergé de profiter de la convergence rapide, de l'Aliasing et du chemin de secours lors de l'interaction avec des NVE de sortie multihébergés attachés à un ES donné, le NVE monohébergé doit être capable de recevoir et de traiter les routes Ethernet A-D par ES et Ethernet A-D par EVI. La gestion de ces routes est décrite dans la section suivante.

10.2.2. ASBR Functionality with Multihoming NVEs (Fonctionnalité ASBR avec NVE multihébergés)

Lorsque les NVE résident dans des commutateurs ToR et fonctionnent en mode de redondance multihébergé, il y a un besoin, comme décrit dans la section 8, pour le NVE multihébergé d'origine d'envoyer des routes Ethernet A-D par ES (utilisées pour le retrait massif) et des routes Ethernet A-D par EVI (utilisées pour l'Aliasing). Comme décrit ci-dessus, la réécriture du prochain saut BGP par les ASBR crée des ambiguïtés lorsque les routes Ethernet A-D par ES sont reçues par le NVE distant dans un AS différent car le NVE récepteur ne peut pas associer cette route avec les routes MAC/IP de cet ES annoncées par le même NVE d'origine. Cette ambiguïté inhibe la fonction de retrait massif par ES par le NVE récepteur dans un AS différent.

À titre d'exemple, considérez un scénario où un CE est multihébergé vers PE1 et PE2, où ces PE sont connectés via ASBR1 puis ASBR2 au PE3 distant. De plus, considérez que PE1 reçoit M1 de CE1 mais pas PE2. Par conséquent, PE1 annonce Ethernet A-D par ES1, Ethernet A-D par EVI1 et M1; tandis que PE2 annonce uniquement Ethernet A-D par ES1 et Ethernet A-D par EVI1. ASBR1 reçoit toutes ces cinq annonces et les transmet à ASBR2 (avec lui-même comme prochain saut BGP). ASBR2, à son tour, les transmet au PE3 distant, avec lui-même comme prochain saut BGP. PE3 reçoit ces cinq routes où toutes ont le même prochain saut BGP (c'est-à-dire ASBR2). De plus, les deux routes Ethernet A-D par ES reçues par PE3 ont les mêmes informations, c'est-à-dire le même ESI et le même prochain saut BGP. Bien que ces deux routes soient maintenues par le processus BGP dans PE3 (car elles ont des RD différents et sont donc traitées comme des routes BGP différentes), les informations d'une seule d'entre elles sont utilisées dans la table de routage L2 (L2 RIB).

                  PE1
                 /   \
                CE     ASBR1---ASBR2---PE3
                 \   /
                  PE2

                Figure 3: Option B inter-AS

Maintenant, lorsque l'AC entre le PE2 et le CE échoue et que PE2 envoie un retrait Network Layer Reachability Information (NLRI) pour la route Ethernet A-D par ES, et que ce retrait est propagé et reçu par le PE3, le processus BGP dans PE3 supprime la route BGP correspondante; cependant, il ne supprime pas les informations associées (à savoir ESI et prochain saut BGP) de la table de routage L2 (L2 RIB) car il a toujours l'autre route Ethernet A-D par ES (provenant de PE1) avec les mêmes informations. C'est pourquoi le mécanisme de retrait massif ne fonctionne pas lors de la réalisation de DCI avec l'option B inter-AS. Cependant, comme décrit précédemment, la fonction d'Aliasing fonctionne et il en va de même pour le "retrait massif par EVI" (qui est associé au retrait de la route EVPN associée à l'Aliasing, c'est-à-dire la route Ethernet A-D par EVI).

Dans l'exemple ci-dessus, le PE3 reçoit deux routes d'Aliasing avec le même prochain saut BGP (ASBR2) mais des RD différents. L'une des routes d'Aliasing a le même RD que la route MAC annoncée (M1). PE3 suit la procédure de résolution de route spécifiée dans [RFC7432] lors de la réception des deux routes d'Aliasing; c'est-à-dire qu'il résout M1 en <ES, EVI1>, et, par la suite, il résout <ES, EVI1> en une liste de chemins BGP avec deux chemins ainsi que les VNI/étiquettes MPLS correspondants (un associé à PE1 et l'autre associé à PE2). Il convient de noter que même si les deux chemins sont annoncés par le même prochain saut BGP (ASRB2), le PE3 récepteur peut les gérer correctement. Par conséquent, M1 est accessible via deux chemins. Cela crée deux LSP de bout en bout, de PE3 à PE1 et de PE3 à PE2, pour M1 de sorte que lorsque PE3 veut transférer le trafic destiné à M1, il peut équilibrer la charge entre les deux LSP. Bien que la résolution de route pour les routes d'Aliasing avec le même prochain saut BGP ne soit pas explicitement mentionnée dans [RFC7432], c'est l'opération attendue; ainsi, elle est élaborée ici.

Lorsque l'AC entre le PE2 et le CE échoue et que PE2 envoie un retrait NLRI pour les routes Ethernet A-D par EVI, et que ces retraits sont propagés et reçus par le PE3, le PE3 supprime la route d'Aliasing et met à jour la liste de chemins; c'est-à-dire qu'il supprime le chemin correspondant au PE2. Par conséquent, toutes les routes MAC correspondantes pour ce <ES, EVI> qui pointent vers cette liste de chemins auront maintenant la liste de chemins mise à jour avec un seul chemin associé à PE1. Cette action peut être considérée comme le retrait massif au niveau par EVI. Le retrait massif au niveau par EVI a un temps de convergence plus long que le retrait massif au niveau par ES; cependant, il est beaucoup plus rapide que le temps de convergence lorsque le retrait est effectué sur une base par MAC.

Si un PE devient détaché d'un ES donné, alors, en plus de retirer ses routes Ethernet A-D par ES précédemment annoncées, il DOIT également retirer ses routes Ethernet A-D par EVI précédemment annoncées pour cet ES. Pour un PE distant qui est séparé du PE en retrait par un ou plusieurs ASBR d'option B inter-AS EVPN, le retrait des routes Ethernet A-D par ES n'est pas actionnable. Cependant, un PE distant est capable de corréler une route Ethernet A-D par EVI précédemment annoncée avec toutes les routes MAC/IP Advertisement également annoncées par le PE en retrait pour ce <ES, EVI, BD>. Par conséquent, lorsqu'il reçoit le retrait d'une route Ethernet A-D par EVI, il DEVRAIT supprimer le PE en retrait comme prochain saut pour toutes les adresses MAC associées à ce <ES, EVI, BD>.

Dans l'exemple précédent, lorsque l'AC entre PE2 et le CE échoue, PE2 retirera ses routes Ethernet A-D par ES et par EVI. Lorsque PE3 reçoit le retrait d'une route Ethernet A-D par EVI, il supprime PE2 comme prochain saut valide pour toutes les adresses MAC associées au <ES, EVI, BD> correspondant. Par conséquent, tous les prochains sauts MAC pour ce <ES, EVI, BD> auront maintenant un seul prochain saut, à savoir le LSP vers PE1.

En résumé, on peut voir que la fonctionnalité d'Aliasing (et de chemin de secours) devrait fonctionner telle quelle pour l'option B inter-AS sans nécessiter de fonctionnalité supplémentaire dans les ASBR ou les PE. Cependant, la fonctionnalité de retrait massif revient du mode par ES au mode par EVI pour l'option B inter-AS. C'est-à-dire que les PE recevant une route de retrait massif du même AS prennent des mesures sur la route Ethernet A-D par ES; tandis que les PE recevant des routes de retrait massif de différents AS prennent des mesures sur la route Ethernet A-D par EVI.