5.1. VXLAN/NVGRE Encapsulation (Encapsulation VXLAN/NVGRE)

VXLAN et NVGRE sont des exemples de technologies qui fournissent une encapsulation du plan de données utilisée pour transporter un paquet sur l'infrastructure IP physique commune entre les Network Virtualization Edges (NVEs) - par exemple, les VXLAN Tunnel End Points (VTEPs) 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 pour 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 typiquement un mappage un-à-un vers le VID du tenant, comme décrit dans [RFC7348]. Dans ce scénario, le VTEP d'entrée n'inclut pas de tag VLAN interne sur la trame encapsulée, et le VTEP de sortie rejette les trames avec un tag VLAN interne. Ce mode de fonctionnement dans [RFC7348] correspond au VLAN-Based Service dans [RFC7432], où un VID de tenant est mappé à un EVI.

VXLAN fournit également une option d'inclusion d'un tag VLAN interne dans la trame encapsulée, si explicitement configuré au VTEP. Ce mode de fonctionnement peut correspondre au VLAN Bundle Service dans [RFC7432] car toutes les trames étiquetées du tenant sont mappées à une seule table de pont / MAC-VRF, et le tag VLAN interne n'est pas utilisé 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 GRE Key optionnel, qui porte le VSID. Il existe un mappage un-à-un entre le VSID et le VID du tenant, comme décrit dans [RFC7637]. L'inclusion d'un tag VLAN interne est interdite. Ce mode de fonctionnement dans [RFC7637] correspond au VLAN Based Service dans [RFC7432].

Comme décrit dans la section suivante, il n'y a aucun changement à l'encodage des routes EVPN pour supporter l'encapsulation VXLAN ou NVGRE, sauf pour l'utilisation de la BGP Encapsulation Extended Community pour indiquer le type d'encapsulation (par exemple, VXLAN ou NVGRE). Cependant, il y a un impact potentiel sur les procédures EVPN selon l'emplacement du NVE (c'est-à-dire dans l'hyperviseur ou ToR) et si des capacités de multihoming sont requises.

5.1.1. Virtual Identifiers Scope (Portée des identifiants virtuels)

Bien que les VNI soient définis comme des valeurs globalement uniques de 24 bits, il existe des scénarios dans lesquels il est souhaitable d'utiliser une valeur localement significative pour le VNI, en particulier dans le contexte d'une interconnexion de centres de données.

5.1.1.1. Data-Center Interconnect with Gateway (Interconnexion de centres de données avec passerelle)

Dans le cas où les NVE dans différents centres de données doivent être interconnectés, et les NVE doivent utiliser des VNI comme identifiants globalement uniques au sein d'un centre de données, alors une passerelle (GW) doit être employée au bord du réseau du centre de données (DCN). C'est parce que la passerelle fournira la fonctionnalité de traduction du VNI lors du franchissement des frontières réseau, qui peuvent s'aligner avec les limites de contrôle de l'opérateur. À titre d'exemple, considérez le réseau de la Figure 1. Supposons qu'il y ait trois opérateurs réseau: un pour chacun des réseaux DC1, DC2 et WAN. Les passerelles au bord des centres de données sont responsables de la traduction des VNI entre les valeurs utilisées dans chacun des DCN et les valeurs utilisées dans le WAN.

                        +--------------+
                        |              |
      +---------+       |     WAN      |       +---------+
+----+ |        +---+  +----+        +----+  +---+        |  +----+
|NVE1|-|        |   |  |WAN |        |WAN |  |   |        |-|NVE3|
+----+ |IP      |GW |-|Edge|        |Edge|--|GW | IP     |  +----+
+----+ |Fabric  +---+  +----+        +----+  +---+ Fabric |  +----+
|NVE2|-|         |       |              |       |         |-|NVE4|
+----+ +---------+       +--------------+       +---------+  +----+

|<------ DC 1 ------>                          <------ DC2  ------>|

         Figure 1: Data-Center Interconnect with Gateway

5.1.1.2. Data-Center Interconnect without Gateway (Interconnexion de centres de données sans passerelle)

Dans le cas où les NVE dans différents centres de données doivent être interconnectés, et les NVE doivent utiliser des VNI assignés localement (par exemple, similaires aux étiquettes MPLS), il peut ne pas être nécessaire d'employer des passerelles au bord du DCN. Plus spécifiquement, la valeur VNI utilisée par le NVE émetteur est allouée par le NVE qui reçoit le trafic (en d'autres termes, ceci est similaire à une étiquette MPLS "assignée en aval"). Cela permet de découpler l'espace VNI entre différents DCN sans nécessiter une passerelle dédiée au bord des centres de données. Ce sujet est couvert dans la Section 10.2.

                         +--------------+
                         |              |
         +---------+     |     WAN      |    +---------+
 +----+ |         |   +----+        +----+  |         |  +----+
 |NVE1|-|         |   |ASBR|        |ASBR|  |         |-|NVE3|
 +----+ |IP Fabric|---|    |        |    |--|IP Fabric|  +----+
 +----+ |         |   +----+        +----+  |         |  +----+
 |NVE2|-|         |     |              |    |         |-|NVE4|
 +----+ +---------+     +--------------+    +---------+  +----+

 |<------ DC 1 ----->                        <---- DC2  ------>|

          Figure 2: Data-Center Interconnect with ASBR

5.1.2. Virtual Identifiers to EVI Mapping (Mappage des identifiants virtuels vers EVI)

Tout comme dans [RFC7432], où deux options existaient pour mapper les domaines de diffusion (représentés par des ID VLAN) à un EVI, lorsque le plan de contrôle EVPN est utilisé conjointement avec VXLAN (ou l'encapsulation NVGRE), il existe également deux options pour mapper les domaines de diffusion représentés par des VNI VXLAN (ou des VSID NVGRE) à un EVI:

Option 1: A Single Broadcast Domain per EVI (Un seul domaine de diffusion par EVI)

Dans cette option, un seul domaine de diffusion Ethernet (par exemple, sous-réseau) représenté par un VNI est mappé à un EVI unique. Cela correspond au VLAN-Based Service dans [RFC7432], où une interface face au tenant, une interface logique (par exemple, représentée par un VID) ou une interface physique est mappée à un EVI. En tant que tel, un BGP Route Distinguisher (RD) et Route Target (RT) sont nécessaires par VNI sur chaque NVE. L'avantage de ce modèle est qu'il permet d'utiliser les mécanismes de contrainte BGP RT afin de limiter la propagation et l'importation de routes uniquement aux NVE intéressés par un VNI donné. L'inconvénient de ce modèle peut être la surcharge de provisionnement si le RD et le RT ne sont pas dérivés automatiquement du VNI.

Dans cette option, la table MAC-VRF est identifiée par le RT dans le plan de contrôle et par le VNI dans le plan de données. Dans cette option, la table MAC-VRF spécifique correspond à une seule table de pont.

Option 2: Multiple Broadcast Domains per EVI (Plusieurs domaines de diffusion par EVI)

Dans cette option, plusieurs sous-réseaux, chacun représenté par un VNI unique, sont mappés à un seul EVI. Par exemple, si un tenant a plusieurs segments/sous-réseaux chacun représenté par un VNI, alors tous les VNI pour ce tenant sont mappés à un seul EVI; par exemple, l'EVI dans ce cas représente le tenant et non un sous-réseau. Cela correspond au VLAN-aware bundle service dans [RFC7432]. L'avantage de ce modèle est qu'il ne nécessite pas le provisionnement d'un RD/RT par VNI. Cependant, c'est un point discutable par rapport à l'Option 1 où l'auto-dérivation est utilisée. L'inconvénient de ce modèle est que les routes seraient importées par des NVE qui peuvent ne pas être intéressés par un VNI donné.

Dans cette option, la table MAC-VRF est identifiée par le RT dans le plan de contrôle; une table de pont spécifique pour cette MAC-VRF est identifiée par le <RT, Ethernet Tag ID> dans le plan de contrôle. Dans cette option, le VNI dans le plan de données est suffisant pour identifier une table de pont spécifique.

5.1.2.1. Auto-Derivation of RT (Auto-dérivation du RT)

Afin de simplifier la configuration, lorsque l'option d'un seul VNI par EVI est utilisée, le RT utilisé pour EVPN peut être auto-dérivé. Le RD peut être auto-généré comme décrit dans [RFC7432], et le RT peut être auto-dérivé comme décrit ensuite.

Puisqu'un PE passerelle comme représenté dans la Figure 1 participe à la fois aux sessions BGP DCN et WAN, il est important que, lorsque les valeurs RT sont auto-dérivées des VNI, il n'y ait pas de conflit dans les espaces RT entre les DCN et les WAN, en supposant que les deux opèrent au sein du même Autonomous System (AS). Il peut également y avoir des scénarios où les encapsulations VXLAN et NVGRE peuvent être nécessaires au sein du même DCN, et leurs VNI correspondants sont administrés indépendamment, ce qui signifie que les espaces VNI peuvent se chevaucher. Afin d'éviter les conflits dans les espaces RT, les valeurs RT de 6 octets avec un numéro AS de 2 octets pour les DCN peuvent être auto-dérivées comme suit:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Global Administrator      |    Local Administrator        |
+-----------------------------------------------+---------------+
| Local Administrator (Cont.)   |
+-------------------------------+

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Global Administrator      |A| TYPE| D-ID  | Service ID    |
+-----------------------------------------------+---------------+
|       Service ID (Cont.)      |
+-------------------------------+

Le champ RT de 6 octets se compose de deux sous-champs:

Global Administrator sub-field: 2 octets. Ce sous-champ contient un numéro AS assigné par l'IANA <https://www.iana.org/assignments/as-numbers/>.
Local Administrator sub-field: 4 octets
- A: Un champ d'un seul bit indiquant si ce RT est auto-dérivé
  - 0: auto-dérivé
  - 1: dérivé manuellement
- Type: Un champ de 3 bits qui identifie l'espace dans lequel les 3 autres octets sont définis. Les espaces suivants sont définis:
  - 0: VID (802.1Q VLAN ID)
  - 1: VXLAN
  - 2: NVGRE
  - 3: I-SID
  - 4: EVI
  - 5: dual-VID (QinQ VLAN ID)
- D-ID: Un champ de 4 bits qui identifie le domain-id. La valeur par défaut du domain-id est zéro, indiquant qu'un seul espace de numérotation existe pour une technologie donnée. Cependant, si plus d'un espace de numérotation existe pour une technologie donnée (par exemple, espaces VXLAN qui se chevauchent), alors chacun des espaces de numérotation doit être identifié par son domain-id correspondant à partir de 1.
- Service ID: Ce champ de 3 octets est défini sur VNI, VSID, I-SID ou VID.

Il convient de noter que l'auto-dérivation du RT est applicable pour les numéros AS de 2 octets. Pour les numéros AS de 4 octets, le RT doit être configuré manuellement car les champs VNI de 3 octets ne peuvent pas tenir dans le champ d'administrateur local de 2 octets.

5.1.3. Constructing EVPN BGP Routes (Construction des routes BGP EVPN)

Dans EVPN, une étiquette MPLS, par exemple, identifiant la table de forwarding est distribuée par le PE de sortie via le plan de contrôle EVPN et est placée dans l'en-tête MPLS d'un paquet donné par le PE d'entrée. Cette étiquette est utilisée lors de la réception de ce paquet par le PE de sortie pour la disposition de ce paquet. Ceci est très similaire à l'utilisation du VNI par le NVE de sortie, la différence étant qu'une étiquette MPLS a une signification locale tandis qu'un VNI a typiquement une signification globale. En conséquence, et spécifiquement pour supporter l'option de VNI assignés localement, le champ MPLS Label1 dans la route MAC/IP Advertisement, le champ d'étiquette MPLS dans la route Ethernet A-D per EVI, et le champ d'étiquette MPLS dans l'attribut P-Multicast Service Interface (PMSI) Tunnel de la route Inclusive Multicast Ethernet Tag (IMET) sont utilisés pour porter le VNI. Pour le reste de ce mémo, les champs d'étiquette MPLS ci-dessus seront appelés le champ VNI. Le champ VNI est utilisé à la fois pour les VNI locaux et globaux; dans les deux cas, le champ de 24 bits entier est utilisé pour encoder la valeur VNI.

Pour le VLAN-Based Service (un seul VNI par MAC-VRF), le champ Ethernet Tag dans les routes MAC/IP Advertisement, Ethernet A-D per EVI et IMET DOIT (MUST) être défini à zéro tout comme dans le VLAN-Based Service dans [RFC7432].

Pour le VLAN-Aware Bundle Service (plusieurs VNI par MAC-VRF avec chaque VNI associé à sa propre table de pont), le champ Ethernet Tag dans les routes MAC Advertisement, Ethernet A-D per EVI et IMET DOIT (MUST) identifier une table de pont au sein d'une MAC-VRF; l'ensemble des Ethernet Tags pour cet EVI doit être configuré de manière cohérente sur tous les PE au sein de cet EVI. Pour les VNI assignés localement, la valeur annoncée dans le champ Ethernet Tag DOIT (MUST) être définie sur un VID tout comme dans le VLAN-aware bundle service dans [RFC7432]. Un tel paramétrage doit être effectué de manière cohérente sur tous les dispositifs PE participant à cet EVI au sein d'un domaine donné. Pour les VNI globaux, la valeur annoncée dans le champ Ethernet Tag DEVRAIT (SHOULD) être définie sur un VNI tant qu'elle correspond à la sémantique existante de l'Ethernet Tag, c'est-à-dire qu'elle identifie une table de pont au sein d'une MAC-VRF et l'ensemble des VNI sont configurés de manière cohérente sur chaque PE dans cet EVI.

Afin d'indiquer quel type d'encapsulation du plan de données (c'est-à-dire VXLAN, NVGRE, MPLS ou MPLS dans GRE) doit être utilisé, la BGP Encapsulation Extended Community définie dans [RFC5512] est incluse avec toutes les routes EVPN (c'est-à-dire MAC Advertisement, Ethernet A-D per EVI, Ethernet A-D per ESI, IMET et Ethernet Segment) annoncées par un PE de sortie. Cinq nouvelles valeurs ont été assignées par l'IANA pour étendre la liste des types d'encapsulation définis dans [RFC5512]; elles sont listées dans la Section 11.

Le type de tunnel d'encapsulation MPLS, listé dans la Section 11, est nécessaire afin de distinguer entre un nœud annonçant qui ne supporte que les encapsulations non-MPLS et un qui supporte les encapsulations MPLS et non-MPLS. Un nœud annonçant qui ne supporte que l'encapsulation MPLS n'a pas besoin d'annoncer de types de tunnels d'encapsulation; c'est-à-dire que si la BGP Encapsulation Extended Community n'est pas présente, alors soit l'encapsulation MPLS soit une encapsulation configurée statiquement est supposée.

Le champ Next Hop de l'attribut MP_REACH_NLRI de la route DOIT (MUST) être défini sur l'adresse IPv4 ou IPv6 du NVE. Les champs restants dans chaque route sont définis conformément à [RFC7432].

Notez que la procédure définie ici - utiliser le champ MPLS Label pour porter le VNI en présence d'une Tunnel Encapsulation Extended Community spécifiant l'utilisation d'un VNI - est alignée avec les procédures décrites dans la Section 8.2.2.2 de [TUNNEL-ENCAP] ("When a Valid VNI has not been Signaled").