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

Sia VXLAN che NVGRE sono esempi di tecnologie che forniscono un incapsulamento del piano dati utilizzato per trasportare un pacchetto sulla comune infrastruttura IP fisica tra Network Virtualization Edges (NVE) - ad esempio, VXLAN Tunnel End Points (VTEPs) nella rete VXLAN. Entrambe queste tecnologie includono l'identificatore dell'istanza NVO specifica, VNI in VXLAN e VSID in NVGRE, in ogni pacchetto. Nel resto di questo documento usiamo VNI come rappresentazione per l'istanza NVO con la comprensione che VSID può essere ugualmente utilizzato se l'incapsulamento è NVGRE a meno che non sia altrimenti indicato.

Si noti che un PE è equivalente a un NVE/VTEP.

L'incapsulamento VXLAN è basato su UDP, con un header di 8 byte che segue l'header UDP. VXLAN fornisce un VNI di 24 bit, che tipicamente fornisce un mapping uno-a-uno al VID del tenant, come descritto in [RFC7348]. In questo scenario, il VTEP di ingresso non include un tag VLAN interno sul frame incapsulato, e il VTEP di uscita scarta i frame con un tag VLAN interno. Questa modalità di operazione in [RFC7348] corrisponde al VLAN-Based Service in [RFC7432], dove un VID del tenant viene mappato a un EVI.

VXLAN fornisce anche un'opzione per includere un tag VLAN interno nel frame incapsulato, se esplicitamente configurato al VTEP. Questa modalità di operazione può corrispondere al VLAN Bundle Service in [RFC7432] perché tutti i frame taggati del tenant vengono mappati a una singola tabella di bridge / MAC-VRF, e il tag VLAN interno non viene utilizzato per la ricerca da parte del PE di disposizione quando si esegue la decapsulazione VXLAN come descritto nella Sezione 6 di [RFC7348].

L'incapsulamento [RFC7637] è basato sull'incapsulamento GRE, e richiede l'inclusione del campo GRE Key opzionale, che trasporta il VSID. Esiste un mapping uno-a-uno tra il VSID e il VID del tenant, come descritto in [RFC7637]. L'inclusione di un tag VLAN interno è proibita. Questa modalità di operazione in [RFC7637] corrisponde al VLAN Based Service in [RFC7432].

Come descritto nella sezione successiva, non vi è alcun cambiamento alla codifica delle route EVPN per supportare l'incapsulamento VXLAN o NVGRE, tranne per l'uso della BGP Encapsulation Extended Community per indicare il tipo di incapsulamento (ad esempio, VXLAN o NVGRE). Tuttavia, vi è un potenziale impatto sulle procedure EVPN a seconda di dove si trova il NVE (cioè nell'hypervisor o ToR) e se sono richieste capacità di multihoming.

5.1.1. Virtual Identifiers Scope (Ambito degli identificatori virtuali)

Sebbene i VNI siano definiti come valori globalmente univoci a 24 bit, esistono scenari in cui è desiderabile utilizzare un valore localmente significativo per il VNI, specialmente nel contesto di un'interconnessione di data center.

5.1.1.1. Data-Center Interconnect with Gateway (Interconnessione di data center con gateway)

Nel caso in cui i NVE in diversi data center debbano essere interconnessi, e i NVE debbano utilizzare i VNI come identificatori globalmente univoci all'interno di un data center, allora un Gateway (GW) deve essere impiegato al margine della rete del data center (DCN). Questo perché il Gateway fornirà la funzionalità di traduzione del VNI quando attraversa i confini di rete, che possono allinearsi con i confini di controllo dell'operatore. Come esempio, consideriamo la rete della Figura 1. Supponiamo che ci siano tre operatori di rete: uno per ciascuna delle reti DC1, DC2 e WAN. I Gateway al margine dei data center sono responsabili della traduzione dei VNI tra i valori utilizzati in ciascuno dei DCN e i valori utilizzati nella 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 (Interconnessione di data center senza gateway)

Nel caso in cui i NVE in diversi data center debbano essere interconnessi, e i NVE debbano utilizzare VNI assegnati localmente (ad esempio, simili alle label MPLS), potrebbe non essere necessario impiegare Gateway al margine del DCN. Più specificamente, il valore VNI utilizzato dal NVE trasmittente è allocato dal NVE che riceve il traffico (in altre parole, questo è simile a una label MPLS "assegnata a valle"). Questo consente di disaccoppiare lo spazio VNI tra diversi DCN senza la necessità di un Gateway dedicato al margine dei data center. Questo argomento è trattato nella Sezione 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 (Mappatura degli identificatori virtuali a EVI)

Proprio come in [RFC7432], dove esistevano due opzioni per mappare i domini di broadcast (rappresentati da ID VLAN) a un EVI, quando il piano di controllo EVPN viene utilizzato in congiunzione con VXLAN (o incapsulamento NVGRE), esistono anche due opzioni per mappare i domini di broadcast rappresentati da VNI VXLAN (o VSID NVGRE) a un EVI:

Option 1: A Single Broadcast Domain per EVI (Un singolo dominio di broadcast per EVI)

In questa opzione, un singolo dominio di broadcast Ethernet (ad esempio, subnet) rappresentato da un VNI viene mappato a un EVI univoco. Questo corrisponde al VLAN-Based Service in [RFC7432], dove un'interfaccia rivolta al tenant, un'interfaccia logica (ad esempio, rappresentata da un VID) o un'interfaccia fisica viene mappata a un EVI. Come tale, un BGP Route Distinguisher (RD) e Route Target (RT) sono necessari per VNI su ogni NVE. Il vantaggio di questo modello è che consente l'utilizzo dei meccanismi di constraint BGP RT per limitare la propagazione e l'importazione di route solo ai NVE interessati a un dato VNI. Lo svantaggio di questo modello può essere l'overhead di provisioning se il RD e RT non sono derivati automaticamente dal VNI.

In questa opzione, la tabella MAC-VRF è identificata dal RT nel piano di controllo e dal VNI nel piano dati. In questa opzione, la tabella MAC-VRF specifica corrisponde solo a una singola tabella di bridge.

Option 2: Multiple Broadcast Domains per EVI (Più domini di broadcast per EVI)

In questa opzione, più subnet, ciascuna rappresentata da un VNI univoco, vengono mappate a un singolo EVI. Ad esempio, se un tenant ha più segmenti/subnet ciascuno rappresentato da un VNI, allora tutti i VNI per quel tenant vengono mappati a un singolo EVI; ad esempio, l'EVI in questo caso rappresenta il tenant e non una subnet. Questo corrisponde al VLAN-aware bundle service in [RFC7432]. Il vantaggio di questo modello è che non richiede il provisioning di un RD/RT per VNI. Tuttavia, questo è un punto controverso rispetto all'Opzione 1 dove viene utilizzata l'auto-derivazione. Lo svantaggio di questo modello è che le route verrebbero importate da NVE che potrebbero non essere interessati a un dato VNI.

In questa opzione, la tabella MAC-VRF è identificata dal RT nel piano di controllo; una tabella di bridge specifica per quella MAC-VRF è identificata dal <RT, Ethernet Tag ID> nel piano di controllo. In questa opzione, il VNI nel piano dati è sufficiente per identificare una tabella di bridge specifica.

5.1.2.1. Auto-Derivation of RT (Auto-derivazione del RT)

Al fine di semplificare la configurazione, quando viene utilizzata l'opzione di un singolo VNI per EVI, il RT utilizzato per EVPN può essere auto-derivato. Il RD può essere auto-generato come descritto in [RFC7432], e il RT può essere auto-derivato come descritto di seguito.

Poiché un PE gateway come rappresentato nella Figura 1 partecipa sia alle sessioni BGP DCN che WAN, è importante che, quando i valori RT sono auto-derivati dai VNI, non vi sia conflitto negli spazi RT tra DCN e WAN, assumendo che entrambi operino all'interno dello stesso Autonomous System (AS). Possono anche esserci scenari in cui entrambi gli incapsulamenti VXLAN e NVGRE possono essere necessari all'interno dello stesso DCN, e i loro VNI corrispondenti sono amministrati indipendentemente, il che significa che gli spazi VNI possono sovrapporsi. Al fine di evitare conflitti negli spazi RT, i valori RT a 6 byte con numero AS a 2 ottetti per i DCN possono essere auto-derivati come segue:

 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.)      |
+-------------------------------+

Il campo RT a 6 ottetti consiste di due sotto-campi:

Global Administrator sub-field: 2 ottetti. Questo sotto-campo contiene un numero AS assegnato dall'IANA <https://www.iana.org/assignments/as-numbers/>.
Local Administrator sub-field: 4 ottetti
- A: Un campo a singolo bit che indica se questo RT è auto-derivato
  - 0: auto-derivato
  - 1: derivato manualmente
- Type: Un campo a 3 bit che identifica lo spazio in cui gli altri 3 byte sono definiti. Sono definiti i seguenti spazi:
  - 0: VID (802.1Q VLAN ID)
  - 1: VXLAN
  - 2: NVGRE
  - 3: I-SID
  - 4: EVI
  - 5: dual-VID (QinQ VLAN ID)
- D-ID: Un campo a 4 bit che identifica il domain-id. Il valore predefinito del domain-id è zero, indicando che esiste solo un singolo spazio di numerazione per una data tecnologia. Tuttavia, se esiste più di uno spazio di numerazione per una data tecnologia (ad esempio, spazi VXLAN sovrapposti), allora ciascuno degli spazi di numerazione deve essere identificato dal suo corrispondente domain-id a partire da 1.
- Service ID: Questo campo a 3 ottetti è impostato su VNI, VSID, I-SID o VID.

Si dovrebbe notare che l'auto-derivazione del RT è applicabile per i numeri AS a 2 ottetti. Per i numeri AS a 4 ottetti, il RT deve essere configurato manualmente perché i campi VNI a 3 ottetti non possono essere inseriti nel campo amministratore locale a 2 ottetti.

5.1.3. Constructing EVPN BGP Routes (Costruzione delle route BGP EVPN)

In EVPN, una label MPLS, ad esempio, che identifica la tabella di forwarding viene distribuita dal PE di uscita tramite il piano di controllo EVPN ed è collocata nell'header MPLS di un dato pacchetto dal PE di ingresso. Questa label viene utilizzata al ricevimento di quel pacchetto da parte del PE di uscita per la disposizione di quel pacchetto. Questo è molto simile all'uso del VNI da parte del NVE di uscita, con la differenza che una label MPLS ha significato locale mentre un VNI ha tipicamente significato globale. Di conseguenza, e specificamente per supportare l'opzione di VNI assegnati localmente, il campo MPLS Label1 nella route MAC/IP Advertisement, il campo label MPLS nella route Ethernet A-D per EVI, e il campo label MPLS nell'attributo P-Multicast Service Interface (PMSI) Tunnel della route Inclusive Multicast Ethernet Tag (IMET) sono utilizzati per trasportare il VNI. Per il resto di questo memo, i campi label MPLS sopra citati saranno denominati campo VNI. Il campo VNI è utilizzato sia per i VNI locali che globali; in entrambi i casi, l'intero campo a 24 bit viene utilizzato per codificare il valore VNI.

Per il VLAN-Based Service (un singolo VNI per MAC-VRF), il campo Ethernet Tag nelle route MAC/IP Advertisement, Ethernet A-D per EVI e IMET DEVE (MUST) essere impostato a zero proprio come nel VLAN-Based Service in [RFC7432].

Per il VLAN-Aware Bundle Service (più VNI per MAC-VRF con ciascun VNI associato alla propria tabella di bridge), il campo Ethernet Tag nelle route MAC Advertisement, Ethernet A-D per EVI e IMET DEVE (MUST) identificare una tabella di bridge all'interno di una MAC-VRF; l'insieme di Ethernet Tag per quell'EVI deve essere configurato in modo coerente su tutti i PE all'interno di quell'EVI. Per i VNI assegnati localmente, il valore annunciato nel campo Ethernet Tag DEVE (MUST) essere impostato su un VID proprio come nel VLAN-aware bundle service in [RFC7432]. Tale impostazione deve essere effettuata in modo coerente su tutti i dispositivi PE che partecipano a quell'EVI all'interno di un dato dominio. Per i VNI globali, il valore annunciato nel campo Ethernet Tag DOVREBBE (SHOULD) essere impostato su un VNI purché corrisponda alla semantica esistente dell'Ethernet Tag, cioè identifichi una tabella di bridge all'interno di una MAC-VRF e l'insieme di VNI sia configurato in modo coerente su ogni PE in quell'EVI.

Al fine di indicare quale tipo di incapsulamento del piano dati (cioè VXLAN, NVGRE, MPLS o MPLS in GRE) deve essere utilizzato, la BGP Encapsulation Extended Community definita in [RFC5512] è inclusa con tutte le route EVPN (cioè MAC Advertisement, Ethernet A-D per EVI, Ethernet A-D per ESI, IMET ed Ethernet Segment) annunciate da un PE di uscita. Cinque nuovi valori sono stati assegnati dall'IANA per estendere l'elenco dei tipi di incapsulamento definiti in [RFC5512]; sono elencati nella Sezione 11.

Il tipo di tunnel di incapsulamento MPLS, elencato nella Sezione 11, è necessario per distinguere tra un nodo annunciante che supporta solo incapsulamenti non-MPLS e uno che supporta incapsulamenti MPLS e non-MPLS. Un nodo annunciante che supporta solo incapsulamento MPLS non ha bisogno di annunciare alcun tipo di tunnel di incapsulamento; cioè, se la BGP Encapsulation Extended Community non è presente, allora si assume l'incapsulamento MPLS o un incapsulamento configurato staticamente.

Il campo Next Hop dell'attributo MP_REACH_NLRI della route DEVE (MUST) essere impostato sull'indirizzo IPv4 o IPv6 del NVE. I campi rimanenti in ciascuna route sono impostati come da [RFC7432].

Si noti che la procedura definita qui - utilizzare il campo MPLS Label per trasportare il VNI in presenza di una Tunnel Encapsulation Extended Community che specifica l'uso di un VNI - è allineata con le procedure descritte nella Sezione 8.2.2.2 di [TUNNEL-ENCAP] ("When a Valid VNI has not been Signaled").