5. Encapsulation Options for EVPN Overlays (Options d'encapsulation pour les superpositions EVPN)
5. Encapsulation Options for EVPN Overlays (Options d'encapsulation pour les superpositions EVPN)
Cette section décrit les différentes options d'encapsulation disponibles pour les superpositions EVPN et leurs caractéristiques. Les principaux types d'encapsulation couverts sont:
5.1. VXLAN/NVGRE Encapsulation (Encapsulation VXLAN/NVGRE)
VXLAN et NVGRE sont tous deux des exemples de technologies qui fournissent une encapsulation de plan de données utilisée pour transporter un paquet sur l'infrastructure IP physique commune entre les périphériques de virtualisation de réseau (NVE) - par exemple, les points d'extrémité de tunnel VXLAN (VTEP) dans un réseau VXLAN. Ces deux technologies incluent l'identifiant de l'instance NVO spécifique, VNI dans VXLAN et VSID dans NVGRE, dans chaque paquet. Dans le reste de ce document, nous utilisons VNI comme représentation de l'instance NVO avec la compréhension que VSID peut également être utilisé si l'encapsulation est NVGRE, sauf indication contraire.
Notez qu'un PE est équivalent à un NVE/VTEP.
L'encapsulation VXLAN est basée sur UDP, avec un en-tête de 8 octets suivant l'en-tête UDP. VXLAN fournit un VNI de 24 bits, qui fournit généralement un mappage un-à-un avec le VID du locataire, comme décrit dans [RFC7348]. Dans ce scénario, le VTEP d'entrée n'inclut pas de balise VLAN interne sur la trame encapsulée, et le VTEP de sortie rejette les trames avec une balise VLAN interne. Ce mode de fonctionnement dans [RFC7348] correspond au service basé sur VLAN dans [RFC7432], où un VID de locataire est mappé sur un EVI.
VXLAN offre également une option d'inclusion d'une balise VLAN interne dans la trame encapsulée, si elle est explicitement configurée au niveau du VTEP. Ce mode de fonctionnement peut correspondre au service de bundle VLAN dans [RFC7432] car toutes les trames balisées du locataire sont mappées sur une seule table de pont / MAC-VRF, et la balise VLAN interne n'est pas utilisée pour la recherche par le PE de disposition lors de l'exécution de la décapsulation VXLAN comme décrit dans la section 6 de [RFC7348].
L'encapsulation [RFC7637] est basée sur l'encapsulation GRE, et elle impose l'inclusion du champ de clé GRE optionnel, qui transporte le VSID. Il existe un mappage un-à-un entre le VSID et le VID du locataire, comme décrit dans [RFC7637]. L'inclusion d'une balise VLAN interne est interdite. Ce mode de fonctionnement dans [RFC7637] correspond au service basé sur VLAN dans [RFC7432].
Comme décrit dans la section suivante, il n'y a aucun changement dans l'encodage des routes EVPN pour prendre en charge l'encapsulation VXLAN ou NVGRE, à l'exception de l'utilisation de la communauté étendue d'encapsulation BGP pour indiquer le type d'encapsulation (par exemple, VXLAN ou NVGRE). Cependant, il existe un impact potentiel sur les procédures EVPN en fonction de l'emplacement du NVE (c'est-à-dire, dans l'hyperviseur ou ToR) et de la nécessité de capacités de multihébergement.
5.2. MPLS over GRE (MPLS sur GRE)
Le plan de données EVPN est modélisé comme une couche client EVPN MPLS située au-dessus d'une couche serveur de tunnel MPLS PSN. Certaines des fonctions EVPN (split-horizon, Aliasing et Backup Path) sont liées à la couche client MPLS. Si l'encapsulation MPLS over GRE est utilisée, alors la couche client EVPN MPLS peut être transportée de manière transparente sur un tunnel IP PSN. Par conséquent, il n'y a aucun impact sur les procédures EVPN et l'opération du plan de données associée.
[RFC4023] définit la norme d'utilisation de l'encapsulation MPLS over GRE, qui peut être utilisée à cette fin. Cependant, lorsque MPLS over GRE est utilisé en conjonction avec EVPN, il est recommandé que le champ de clé GRE soit présent et soit utilisé pour fournir une valeur d'entropie de 32 bits uniquement si les nœuds P peuvent effectuer un hachage de chemin à coût égal (ECMP) basé sur la clé GRE; sinon, l'en-tête GRE ne devrait pas (SHOULD NOT) inclure le champ de clé GRE. Les champs Checksum et Sequence Number ne doivent pas (MUST NOT) être inclus, et les bits C et S correspondants dans l'en-tête GRE doivent (MUST) être définis sur zéro. Un PE capable de prendre en charge cette encapsulation devrait (SHOULD) annoncer ses routes EVPN avec la communauté étendue d'encapsulation de tunnel indiquant l'encapsulation MPLS over GRE comme décrit dans la section précédente.