7. Single-Homing NVEs - NVE Residing in Hypervisor (NVE résidant dans l'hyperviseur - NVE à hébergement unique)

Lorsqu'un NVE et ses hôtes/VM sont co-localisés dans le même périphérique physique, par exemple, lorsqu'ils résident dans un serveur, les liens entre eux sont virtuels et ils partagent généralement le même destin. C'est-à-dire que les hôtes/VM en question ne sont généralement pas multihébergés ou, s'ils le sont, le multihébergement est une question purement locale au serveur hébergeant les VM et les NVE, et il n'a pas besoin d'être "visible" pour les autres NVE résidant sur d'autres serveurs. Ainsi, cela ne nécessite aucun mécanisme de protocole spécifique. Le cas le plus courant est lorsque le NVE réside sur l'hyperviseur.

Dans les sous-sections qui suivent, nous discuterons de l'impact sur les procédures EVPN pour le cas où le NVE réside sur l'hyperviseur et où l'encapsulation VXLAN (ou NVGRE) est utilisée.

7.1. Impact on EVPN BGP Routes & Attributes for VXLAN/NVGRE Encapsulations (Impact sur les routes et attributs BGP EVPN pour les encapsulations VXLAN/NVGRE)

Dans les scénarios où différents groupes de centres de données se trouvent sous différents domaines administratifs, et ces centres de données sont connectés via un ou plusieurs fournisseurs de cœur de backbone comme décrit dans [RFC7365], le RD doit être une valeur unique par EVI ou par NVE comme décrit dans [RFC7432]. En d'autres termes, chaque fois qu'il y a plus d'un domaine administratif pour un VNI global, un RD unique doit être utilisé; ou, chaque fois que la valeur VNI a une signification locale, un RD unique doit être utilisé. Par conséquent, il est recommandé d'utiliser un RD unique comme décrit dans [RFC7432] en tout temps.

Lorsque les NVE résident sur l'hyperviseur, les routes et attributs BGP EVPN associés au multihébergement ne sont plus nécessaires. Cela réduit les routes et attributs requis au sous-ensemble suivant de quatre sur un total de huit listés dans la Section 7 de [RFC7432]:

MAC/IP Advertisement Route
Inclusive Multicast Ethernet Tag Route
MAC Mobility Extended Community
Default Gateway Extended Community

Cependant, comme noté dans la Section 8.6 de [RFC7432], afin de permettre à un NVE d'entrée à hébergement unique de profiter de la convergence rapide, de l'Aliasing et du Backup Path lors de l'interaction avec des NVE de sortie multihébergés attachés à un ES donné, le NVE d'entrée à hébergement unique devrait être capable de recevoir et de traiter les routes qui sont Ethernet A-D par ES et Ethernet A-D par EVI.

7.2. Impact on EVPN Procedures for VXLAN/NVGRE Encapsulations (Impact sur les procédures EVPN pour les encapsulations VXLAN/NVGRE)

Lorsque les NVE résident sur les hyperviseurs, les procédures EVPN associées au multihébergement ne sont plus nécessaires. Cela limite les procédures sur le NVE au sous-ensemble suivant:

Apprentissage local des adresses MAC reçues des VM selon la Section 10.1 de [RFC7432].
Annonce des adresses MAC apprises localement dans BGP en utilisant les routes MAC/IP Advertisement.
Exécution de l'apprentissage distant en utilisant BGP selon la Section 9.2 de [RFC7432].
Découverte d'autres NVE et construction des tunnels multicast en utilisant les routes IMET.
Gestion des événements de mobilité d'adresse MAC selon les procédures de la Section 15 de [RFC7432].

Cependant, comme noté dans la Section 8.6 de [RFC7432], afin de permettre à un NVE d'entrée à hébergement unique de profiter de la convergence rapide, de l'Aliasing et du Backup Path lors de l'interaction avec des NVE de sortie multihébergés attachés à un ES donné, un NVE d'entrée à hébergement unique devrait implémenter le traitement des nœuds d'entrée des routes qui sont Ethernet A-D par ES et Ethernet A-D par EVI comme défini dans les Sections 8.2 ("Fast Convergence") et 8.4 ("Aliasing and Backup Path") de [RFC7432].