docs/specs/l3vpn-over-vxlan-with-evpn-rt5.rst

   1 .. contents:: Table of Contents
   2       :depth: 5
   3
   4 =======================================================
   5 Support of VXLAN based connectivity across Datacenters
   6 =======================================================
   7
   8 https://git.opendaylight.org/gerrit/#/q/topic:EVPN_RT5
   9
  10 Enable realization of L3 connectivity over VXLAN tunnels using L3 BGPVPNs,
  11 internally taking advantage of EVPN as the BGP Control Plane mechanism.
  12
  13 Problem description
  14 ===================
  15
  16 OpenDaylight NetVirt service today supports VLAN-based,
  17 VXLAN-based connectivity and MPLSOverGRE-based overlays.
  18
  19 In this VXLAN-based underlay is supported only for traffic
  20 within the DataCenter.   For all the traffic that need to
  21 go via the DC-Gateway the only supported underlay is MPLSOverGRE.
  22
  23 Though there is a way to provision an external VXLAN tunnel
  24 via the ITM service in Genius, the BGPVPN service in
  25 NetVirt does not have the ability to take advantage of such
  26 a tunnel to provide inter-DC connectivity.
  27
  28 This spec attempts to enhance the BGPVPN service (runs on
  29 top of the current L3 Forwarding service) in NetVirt to
  30 embrace inter-DC L3 connectivity over external VXLAN tunnels.
  31
  32 In scope
  33 ---------
  34
  35 The scope primarily includes providing ability to support Inter-subnet
  36 connectivity across DataCenters over VXLAN tunnels by modeling a
  37 new type of L3VPN which will realize this connectivity using
  38 EVPN BGP Control plane semantics.
  39
  40 When we mention that we are using EVPN BGP Control plane, this
  41 spec proposes using the RouteType 5 explained in EVPN_RT5_ as the primary
  42 means to provision the control plane en enable inter-DC connectivity
  43 over external VXLAN tunnels.
  44
  45 This new type of L3VPN will also inclusively support:
  46
  47 * Intra-subnet connectivity within a DataCenter over VXLAN tunnels.
  48 * Inter-subnet connectivity within a DataCenter over VXLAN tunnels.
  49
  50 Out of scope
  51 ------------
  52 * Does not cover providing VXLAN connectivity between hypervisors (with OVS Datapath) and Top-Of-Rack switches that might be positioned within such DataCenters.
  53 * Does not cover providing intra-subnet connectivity across DCs.
  54
  55 Both the points above will be covered by another spec that will be Phase 2 of realizing intra-subnet inter-DC connectivity.
  56
  57 Use Cases
  58 ---------
  59
  60 The following high level use-cases will be realized by the implementation of this Spec.
  61
  62 DataCenter access from a WAN-client via DC-Gateway (Single Homing)
  63 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  64
  65 This use case involves communication within the DataCenter by tenant VMs and also
  66 communication between the tenant VMs to a remote WAN-based client via DC-Gateway.
  67 The dataplane between the tenant VMs themselves and between the tenant VMs
  68 towards the DC-Gateway will be over VXLAN Tunnels.
  69
  70 The dataplane between the DC-Gateway to its other WAN-based BGP Peers is
  71 transparent to this spec.  It is usually MPLS-based IPVPN.
  72
  73 The BGP Control plane between the ODL Controller and the DC-Gateway will be
  74 via EVPN RouteType 5 as defined in EVPN_RT5_.
  75
  76 The control plane between the DC-Gateway and it other BGP Peers in the WAN
  77 is transparent to this spec, but can be IP-MPLS.
  78
  79 In this use-case:
  80
  81 1. We will have only a single DCGW for WAN connectivity
  82 2. IP prefix exchange between ODL controller and DC-GW (iBGP) using EVPN RT5
  83 3. WAN control plane will use L3VPN IP-MPLS route exchange.
  84 4. On the DC-Gateway, the VRF instance will be configured with two sets of import/export targets. One set of import/export route targets belong to L3VPN inside DataCenter (realized using EVPN RT5) and the second set of import/export route target belongs to WAN control plane.
  85 5. EVPN single homing to be used in all RT5 exchanges inside the DataCenter i.e., ESI=0 for all prefixes sent from DataCenter to the DC-Gateway.
  86 6. Inter AS option B is used at DCGW, route regeneration at DCGW
  87
  88 Datacenter access from another Datacenter over WAN via respective DC-Gateways (L3 DCI)
  89 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  90
  91 This use-case involves providing inter-subnet connectivity between two DataCenters.
  92 Tenant VMs in one datacenter will be able to communicate with tenant VMs on the other
  93 datacenter provided they are part of the same L3VPN and they are on different subnets.
  94
  95 Both the Datacenters can be managed by different ODL Controllers, but the L3VPN configured on
  96 both ODL Controllers will use identical RDs and RTs.
  97
  98 Proposed change
  99 ===============
 100
 101 The following components of an Openstack-ODL-based solution need to be enhanced to provide
 102 intra-subnet and inter-subnet connectivity across DCs using EVPN IP Prefix Advertisement
 103 (Route Type 5) mechanism (refer EVPN_RT5_):
 104
 105 * Openstack Neutron BGPVPN Driver
 106 * OpenDaylight Controller (NetVirt)
 107 * BGP Quagga Stack to support EVPN with RouteType 5 NLRI
 108 * DC-Gateway BGP Neighbour that supports EVPN with RouteType 5 NLRI
 109
 110 The changes required in Openstack Neutron BGPVPN Driver and BGP Quagga Stack
 111 are captured in the Solution considerations section down below.
 112
 113 Pipeline changes
 114 ----------------
 115
 116 For both the use-cases above, we have put together the required pipeline changes here.
 117 For ease of understanding, we have made subsections that talk about Intra-DC
 118 traffic and Inter-DC traffic.
 119
 120 INTRA DC
 121 +++++++++
 122
 123 Intra Subnet, Local DPN: VMs on the same subnet, same VPN, same DPN
 124 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 125
 126 There are no explicit pipeline changes for this use-case.  However the tables that
 127 a packet will traverse through is shown below for understanding purposes.
 128
 129 | Classifier Table (0) =>
 130 | Lport Dispatcher Table (17) ``l3vpn service: set vpn-id=l3vpn-id`` =>
 131 | L3 Gateway MAC Table (19) ``tablemiss: goto_table=17`` =>
 132 | Lport Dispatcher Table (17) ``elan service: set elan-id=elan-tag`` =>
 133 | ELAN Source MAC Table (50) ``match: elan-id=elan-tag, src-mac=source-vm-mac`` =>
 134 | ELAN Destination MAC Table (51) ``match: elan-id=elan-tag, dst-mac=dst-vm-mac set output to port-of-dst-vm``
 135
 136 Intra Subnet, Remote DPN: VMs on two different DPNs, both VMs on the same subnet and same VPN
 137 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 138
 139 There are no explicit pipeline changes for this use-case.  However the tables that
 140 a packet will traverse through is shown below for understanding purposes.
 141
 142 VM sourcing the traffic (Ingress DPN)
 143 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 144
 145 | Classifier Table (0) =>
 146 | Lport Dispatcher Table (17) ``l3vpn service: set vpn-id=l3vpn-id`` =>
 147 | L3 Gateway MAC Table (19) ``l3vpn service: tablemiss: goto_table=17`` =>
 148 | Lport Dispatcher Table (17) ``elan service: set elan-id=elan-tag`` =>
 149 | ELAN Source MAC Table (50) ``match: elan-id=elan-tag, src-mac=source-vm-mac`` =>
 150 | ELAN Destination MAC Table (51) ``match: elan-id=elan-tag, dst-mac=dst-vm-mac set tun-id=dst-vm-lport-tag, output to vxlan-tun-port``
 151
 152
 153 VM receiving the traffic (Egress DPN)
 154 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 155
 156 | Classifier Table (0) =>
 157 | Internal Tunnel Table (36) ``match: tun-id=lport-tag set reg6=dst-vm-lport-tag`` =>
 158 | Lport Egress Table (220) ``Output to dst vm port``
 159
 160 Inter Subnet, Local DPN: VMs on different subnet, same VPN, same DPN
 161 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 162
 163 There are no explicit pipeline changes for this use-case.  However the tables that
 164 a packet will traverse through is shown below for understanding purposes.
 165
 166 | Classifier Table (0) =>
 167 | Lport Dispatcher Table (17) ``l3vpn service: set vpn-id=l3vpn-id`` =>
 168 | L3 Gateway MAC Table (19) ``match: vpn-id=l3vpn-id, dst-mac=vpn-subnet-gateway-mac-address`` =>
 169 | L3 FIB Table (21) ``match: vpn-id=l3vpn-id, nw-dst=dst-vm-ip-address set output to nexthopgroup-dst-vm`` =>
 170 | NextHopGroup-dst-vm: ``set-eth-dst dst-mac-vm, reg6=dst-vm-lport-tag`` =>
 171 | Lport Egress Table (220) ``Output to dst vm port``
 172
 173 .. code-block:: bash
 174
 175    cookie=0x8000000, table=0, priority=4,in_port=1 actions=write_metadata:0x10000000000/0xffffff0000000001,goto_table:17
 176    cookie=0x8000001, table=17, priority=5,metadata=0x5000010000000000/0xffffff0000000000 actions=write_metadata:0x60000100000222e0/0xfffffffffffffffe,goto_table:19
 177    cookie=0x8000009, table=19, priority=20,metadata=0x222e0/0xfffffffe,dl_dst=de:ad:be:ef:00:01 actions=goto_table:21
 178    cookie=0x8000003, table=21, priority=42,ip,metadata=0x222e0/0xfffffffe,nw_dst=10.0.0.2 actions=apply_actions(group:150001)
 179
 180 Inter Subnet, Remote DPN: VMs on two different DPNs, both VMs on different subnet, but same VPN
 181 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 182
 183 For this use-case there is a change in the remote flow rule to L3 Forward the traffic to the remote VM.
 184 The flow-rule will use the LPortTag as the vxlan-tunnel-id, in addition to setting the destination mac address of the
 185 remote destination vm.
 186
 187 VM sourcing the traffic (Ingress DPN)
 188 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 189
 190 | Classifier Table (0) =>
 191 | Lport Dispatcher Table (17) ``l3vpn service: set vpn-id=l3vpn-id`` =>
 192 | L3 Gateway MAC Table (19) ``match: vpn-id=l3vpn-id, dst-mac=vpn-subnet-gateway-mac-address`` =>
 193 | L3 FIB Table (21) ``match: vpn-id=l3vpn-id, nw-dst=dst-vm-ip-address set eth-dst-mac=dst-vm-mac, tun-id=dst-vm-lport-tag, output to vxlan-tun-port``
 194
 195 .. code-block:: bash
 196
 197    cookie=0x8000000, table=0, priority=4,in_port=1 actions=write_metadata:0x10000000000/0xffffff0000000001,goto_table:17
 198    cookie=0x8000001, table=17, priority=5,metadata=0x5000010000000000/0xffffff0000000000 actions=write_metadata:0x60000100000222e0/0xfffffffffffffffe,goto_table:19
 199    cookie=0x8000009, table=19, priority=20,metadata=0x222e0/0xfffffffe,dl_dst=de:ad:be:ef:00:01 actions=goto_table:21
 200    cookie=0x8000003, table=21, priority=42,ip,metadata=0x222e0/0xfffffffe,nw_dst=10.0.0.2 actions=apply_actions(group:150001)
 201    cookie=0x8000003, table=21, priority=42,ip,metadata=0x222e0/0xfffffffe,nw_dst=10.0.0.3 actions=apply_actions(set_field:fa:16:3e:f8:59:af->eth_dst,set_field:0x2->tun_id,output:2)
 202
 203 As you can notice 0x2 set in the above flow-rule as tunnel-id is the LPortTag assigned to VM holding IP Address 10.0.0.3.
 204
 205 VM receiving the traffic (Egress DPN)
 206 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 207
 208 | Classifier Table (0) =>
 209 | Internal Tunnel Table (36) ``match: tun-id=lport-tag set reg6=lport-tag-dst-vm`` =>
 210 | Lport Egress Table (220) ``Output to dst vm port``
 211
 212 .. code-block:: bash
 213
 214    cookie=0x8000001, table=0, priority=5,in_port=2 actions=write_metadata:0x40000000001/0xfffff0000000001,goto_table:36
 215    cookie=0x9000001, table=36, priority=5,tun_id=0x2 actions=load:0x400->NXM_NX_REG6[],resubmit(,220)
 216
 217 As you notice, 0x2 tunnel-id match in the above flow-rule in INTERNAL_TUNNEL_TABLE (Table 36), is the LPortTag assigned
 218 to VM holding IP Address 10.0.0.3.
 219
 220 INTER DC
 221 +++++++++
 222
 223 Intra Subnet
 224 ^^^^^^^^^^^^^
 225
 226 Not supported in this Phase
 227
 228 Inter Subnet
 229 ^^^^^^^^^^^^
 230
 231 For this use-case we are doing a couple of pipeline changes:
 232
 233 a. Introducing a new Table aka L3VNI_EXTERNAL_TUNNEL_DEMUX_TABLE (Table 23).
 234 **L3VNI_EXTERNAL_TUNNEL_DEMUX_TABLE (Table 23)** -  This table is a new table in the L3VPN pipeline and will be
 235 responsible only to process VXLAN packets coming from External VXLAN tunnels.
 236
 237 The packets coming from External VXLAN Tunnels (note: not Internal VXLAN Tunnels), would be directly punted
 238 to this new table from the CLASSIFIER TABLE (Table 0) itself. Today when multiple services bind to a
 239 tunnel port on GENIUS, the service with highest priority binds directly to Table 0 entry for the tunnel port.
 240 So such a service should make sure to provide a fallback to Dispatcher Table so that subsequent service interested
 241 in that tunnel traffic would be given the chance.
 242
 243 The new table  L3VNI_EXTERNAL_TUNNEL_DEMUX_TABLE will have flows to match on VXLAN
 244 VNIs that are L3VNIs.  On a match, their action is to fill the metadata with the VPNID, so that further
 245 tables in the L3VPN pipeline would be able to continue and operate with the VPNID metadata seamlessly.
 246 After filling the metadata, the packets are resubmitted from this new table to the L3_GW_MAC_TABLE (Table 19).
 247 The TableMiss in L3VNI_EXTERNAL_TUNNEL_DEMUX_TABLE will resubmit the packet to LPORT_DISPATCHER_TABLE to enable
 248 next service if any to process the packet ingressing from the external VXLAN tunnel.
 249
 250 b. For all packets going from VMs within the DC, towards the external gateway device via the External VXLAN Tunnel,
 251 we are setting the VXLAN Tunnel ID to the L3VNI value of VPNInstance to which the VM belongs to.
 252
 253 Traffic from DC-Gateway to Local DPN (SYMMETRIC IRB)
 254 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 255
 256 | Classifier Table (0) =>
 257 | L3VNI External Tunnel Demux Table (23) ``match: tun-id=l3vni set vpn-id=l3vpn-id`` =>
 258 | L3 Gateway MAC Table (19) ``match: vpn-id=l3vpn-id, dst-mac=vpn-subnet-gateway-mac-address`` =>
 259 | L3 FIB Table (21) ``match: vpn-id=l3vpn-id, nw-dst=dst-vm-ip-address set output to nexthopgroup-dst-vm`` =>
 260 | NextHopGroup-dst-vm: ``set-eth-dst dst-mac-vm, reg6=dst-vm-lport-tag`` =>
 261 | Lport Egress Table (220) ``Output to dst vm port``
 262
 263
 264 .. code-block:: bash
 265
 266    cookie=0x8000001, table=0, priority=5,in_port=9 actions=write_metadata:0x70000000001/0x1fffff0000000001,goto_table:23
 267    cookie=0x8000001, table=19, priority=20,metadata=0x222e0/0xffffffff,dl_dst=de:ad:be:ef:00:06 actions=goto_table:21
 268    cookie=0x8000001, table=23, priority=5,tun_id=0x16 actions= write_metadata:0x222e0/0xfffffffe,resubmit(19)
 269    cookie=0x8000001, table=23, priority=0,resubmit(17)
 270    cookie=0x8000003, table=21, priority=42,ip,metadata=0x222e0/0xfffffffe,nw_dst=10.0.0.2 actions=apply_actions(group:150001)
 271    cookie=0x8000003, table=21, priority=42,ip,metadata=0x222e0/0xfffffffe,nw_dst=10.0.0.3 actions=apply_actions(set_field:fa:16:3e:f8:59:af->eth_dst,set_field:0x2->tun_id,output:2)
 272
 273 In the above flow rules, Table 23 is the new L3VNI_EXTERNAL_TUNNEL_DEMUX_TABLE.  The in_port=9 reprsents an
 274 external VXLAN Tunnel port.
 275
 276 Traffic from Local DPN to DC-Gateway (SYMMETRIC IRB)
 277 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 278
 279 | Classifier Table (0) =>
 280 | Lport Dispatcher Table (17) ``l3vpn service: set vpn-id=l3vpn-id`` =>
 281 | L3 Gateway MAC Table (19) ``match: vpn-id=l3vpn-id, dst-mac=vpn-subnet-gateway-mac-address`` =>
 282 | L3 FIB Table (21) ``match: vpn-id=l3vpn-id, nw-dst=ext-ip-address set eth-dst-mac=dst-mac-address, tun-id=l3vni, output to ext-vxlan-tun-port``
 283
 284 .. code-block:: bash
 285
 286    cookie=0x7000001, table=0, priority=5,in_port=8, actions=write_metadata:0x60000000001/0x1fffff0000000001,goto_table:17
 287    cookie=0x7000001, table=17, priority=5,metadata=0x60000000001/0x1fffff0000000001 actions=goto_table:19
 288    cookie=0x7000001, table=19, priority=20,metadata=0x222e0/0xffffffff,dl_dst=de:ad:be:ef:00:06 actions=goto_table:21
 289    cookie=0x7000001, table=23, priority=5,tun_id=0x16 actions= write_metadata:0x222e0/0xfffffffe,resubmit(19)
 290    cookie=0x7000001, table=23, priority=0,resubmit(17)
 291    cookie=0x7000003, table=21, priority=42,ip,metadata=0x222e0/0xfffffffe,nw_dst=10.0.0.2 actions=apply_actions(group:150001)
 292    cookie=0x7000003, table=21, priority=42,ip,metadata=0x222e0/0xfffffffe,nw_dst=10.0.0.3 actions=apply_actions(set_field:fa:16:3e:f8:59:af->eth_dst,set_field:0x2->tun_id,output:2)
 293
 294
 295 SNAT pipeline (Access to External Network Access over VXLAN)
 296 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 297
 298 SNAT Traffic from Local DPN to External IP (assuming this DPN is NAPT Switch)
 299 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 300
 301 | Classifier Table (0) =>
 302 | Lport Dispatcher Table (17) ``l3vpn service: set vpn-id=l3vpn-id`` =>
 303 | L3 Gateway MAC Table (19) ``match: vpn-id=l3vpn-id, dst-mac=vpn-subnet-gateway-mac-address`` =>
 304 | L3 FIB Table (21) ``match: vpn-id=l3vpn-id`` =>
 305 | PSNAT Table (26) ``match: vpn-id=l3vpn-id`` =>
 306 | Outbound NAPT Table (46) ``match: nw-src=vm-ip,port=int-port set src-ip=router-gateway-ip,src-mac=external-router-gateway-mac-address,vpn-id=external-vpn-id,port=ext-port`` =>
 307 | NAPT PFIB Table (47) ``match: vpn-id=external-vpn-id`` =>
 308 | L3 FIB Table (21) ``match: vpn-id=external-vpn-id nw-dst=external-entity-ip set eth-dst=external-entity-mac tun-id=external-l3vni, output to ext-vxlan-tun-port``
 309
 310 SNAT Reverse Traffic from External IP to Local DPN (assuming this DPN is NAPT Switch)
 311 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 312
 313 | Classifier Table (0) =>
 314 | L3VNI External Tunnel Demux Table (23) ``match: tun-id=external-l3vni set vpn-id=external-vpn-id`` =>
 315 | L3 Gateway MAC Table (19) ``match: vpn-id=external-vpn-id, dst-mac=external-router-gateway-mac-address`` =>
 316 | Inbound NAPT Table (44) ``match: vpn-id=external-vpn-id nw-dst=router-gateway-ip port=ext-port set vpn-id=l3vpn-id, dst-ip=vm-ip``
 317 | NAPT PFIB Table (47) ``match: vpn-id=l3vpn-id`` =>
 318 | L3 FIB Table (21) ``match: vpn-id=l3vpn-id, nw-dst=dst-vm-ip-address set output to nexthopgroup-dst-vm`` =>
 319 | NextHopGroup-dst-vm: ``set-eth-dst dst-mac-vm, reg6=dst-vm-lport-tag`` =>
 320 | Lport Egress Table (220) ``Output to dst vm port``
 321
 322 DNAT pipeline (Access from External Network over VXLAN)
 323 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 324
 325 DNAT Traffic from External IP to Local DPN
 326 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 327
 328 | Classifier Table (0) =>
 329 | L3VNI External Tunnel Demux Table (23) ``match: tun-id=external-l3vni set vpn-id=external-vpn-id`` =>
 330 | L3 Gateway MAC Table (19) ``match: vpn-id=external-vpn-id, eth-dst=floating-ip-dst-vm-mac-address`` =>
 331 | PDNAT Table (25) ``match: nw-dst=floating-ip,eth-dst=floating-ip-dst-vm-mac-address set ip-dst=dst-vm-ip, vpn-id=l3vpn-id`` =>
 332 | DNAT Table (27)  ``match: vpn-id=l3vpn-id,nw-dst=dst-vm-ip`` =>
 333 | L3 FIB Table (21) ``match: vpn-id=l3vpn-id, nw-dst=dst-vm-ip set output to nexthopgroup-dst-vm`` =>
 334 | NextHopGroup-dst-vm: ``set-eth-dst dst-mac-vm, reg6=dst-vm-lport-tag`` =>
 335 | Lport Egress Table (220) ``Output to dst vm port``
 336
 337
 338 DNAT Reverse Traffic from Local DPN to External IP
 339 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 340
 341 | Classifier Table (0) =>
 342 | Lport Dispatcher Table (17) ``l3vpn service: set vpn-id=l3vpn-id`` =>
 343 | L3 Gateway MAC Table (19) ``match: vpn-id=l3vpn-id, dst-mac=vpn-subnet-gateway-mac-address`` =>
 344 | L3 FIB Table (21) ``match: vpn-id=l3vpn-id`` =>
 345 | PSNAT Table (26) ``match: vpn-id=l3vpn-id nw-src=src-vm-ip set ip-src=floating-ip-src-vm, vpn-id=external-vpn-id`` =>
 346 | SNAT Table (28) ``match: vpn-id=external-vpn-id nw-src=floating-ip-src-vm set eth-src=floating-ip-src-vm-mac-address`` =>
 347 | L3 FIB Table (21) ``match: vpn-id=external-vpn-id nw-dst=external-floating-ip set eth-dst=external-mac-address tun-id=external-l3vni, output to ext-vxlan-tun-port``
 348
 349 DNAT to DNAT Traffic (Intra DC)
 350 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 351 a) FIP VM to FIP VM on Different Hypervisor
 352
 353 DPN1:
 354 ~~~~~~~~
 355 | Classifier Table (0) =>
 356 | Lport Dispatcher Table (17) ``l3vpn service: set vpn-id=l3vpn-id`` =>
 357 | L3 Gateway MAC Table (19) ``match: vpn-id=l3vpn-id, dst-mac=vpn-subnet-gateway-mac-address`` =>
 358 | L3 FIB Table (21) ``match: vpn-id=l3vpn-id`` =>
 359 | PSNAT Table (26) ``match: vpn-id=l3vpn-id nw-src=src-vm-ip set ip-src=floating-ip-src-vm, vpn-id=external-vpn-id`` =>
 360 | SNAT Table (28) ``match: vpn-id=external-vpn-id nw-src=floating-ip-src-vm set eth-src=floating-ip-src-vm-mac-address`` =>
 361 | L3 FIB Table (21) ``match: vpn-id=external-vpn-id nw-dst=destination-floating-ip set eth-dst=floating-ip-dst-vm-mac-address tun-id=external-l3vni, output to vxlan-tun-port``
 362
 363 DPN2:
 364 ~~~~~~~~
 365 | Classifier Table (0) =>
 366 | Internal Tunnel Table (36) ``match: tun-id= external-l3vni`` =>
 367 | PDNAT Table (25) ``match: nw-dst=floating-ip eth-dst=floating-ip-dst-vm-mac-address set ip-dst=dst-vm-ip, vpn-id=l3vpn-id`` =>
 368 | DNAT Table (27)  ``match: vpn-id=l3vpn-id,nw-dst=dst-vm-ip`` =>
 369 | L3 FIB Table (21) ``match: vpn-id=l3vpn-id, nw-dst=dst-vm-ip set output to nexthopgroup-dst-vm`` =>
 370 | NextHopGroup-dst-vm: ``set-eth-dst dst-mac-vm, reg6=dst-vm-lport-tag`` =>
 371 | Lport Egress Table (220) ``Output to dst vm port``
 372
 373
 374 In the above flow rules ``INTERNAL_TUNNEL_TABLE`` (table=36) will take the packet to the ``PDNAT_TABLE``
 375 (table 25) for an exact match with floating-ip and floating-ip-dst-vm-mac-address in ``PDNAT_TABLE``.
 376
 377 In case of a successful floating-ip and floating-ip-dst-vm-mac-address match, ``PDNAT_TABLE`` will set IP destination as VM IP and VPN ID as internal l3 VPN ID then it will pointing to ``DNAT_TABLE`` (table=27)
 378
 379 In case of no match, the packet will be redirected to the SNAT pipeline towards the
 380 ``INBOUND_NAPT_TABLE`` (table=44). This is the use-case where ``DPN2`` also acts as
 381 the NAPT DPN.
 382
 383 In summary, on an given NAPT switch, if both DNAT and SNAT are configured, the incoming traffic
 384 will first be sent to the ``PDNAT_TABLE`` and if there is no FIP and FIP Mac match found, then it will be
 385 forwarded to ``INBOUND_NAPT_TABLE`` for SNAT translation.
 386 As part of the response, the ``external-l3vni`` will be used as ``tun_id`` to reach floating
 387 IP VM on ``DPN1``.
 388
 389 b) FIP VM to FIP VM on same Hypervisor
 390
 391 | Classifier Table (0) =>
 392 | Lport Dispatcher Table (17) ``l3vpn service: set vpn-id=l3vpn-id`` =>
 393 | L3 FIB Table (21) ``match: vpn-id=l3vpn-id`` =>
 394 | PSNAT Table (26) ``match: vpn-id=l3vpn-id nw-src=src-vm-ip set ip-src=floating-ip-src-vm, vpn-id=external-vpn-id`` =>
 395 | SNAT Table (28) ``match: vpn-id=external-vpn-id nw-src=floating-ip-src-vm set eth-src=floating-ip-src-vm-mac-address`` =>
 396 | L3 FIB Table (21) ``match: vpn-id=external-vpn-id nw-dst=destination-floating-ip set eth-dst= floating-ip-dst-vm-mac-address`` =>
 397 | PDNAT Table (25) ``match: nw-dst=floating-ip eth-dst=floating-ip-dst-vm-mac-address set ip-dst=dst-vm-ip, vpn-id=l3vpn-id`` =>
 398 | DNAT Table (27)  ``match: vpn-id=l3vpn-id,nw-dst=dst-vm-ip`` =>
 399 | L3 FIB Table (21) ``match: vpn-id=l3vpn-id, nw-dst=dst-vm-ip set output to nexthopgroup-dst-vm`` =>
 400 | NextHopGroup-dst-vm: ``set-eth-dst dst-mac-vm, reg6=dst-vm-lport-tag`` =>
 401 | Lport Egress Table (220) ``Output to dst vm port``
 402
 403
 404 SNAT to DNAT Traffic (Intra DC)
 405 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 406
 407 SNAT Hypervisor:
 408 ~~~~~~~~~~~~~~~~
 409 | Classifier Table (0) =>
 410 | Lport Dispatcher Table (17) ``l3vpn service: set vpn-id=l3vpn-id`` =>
 411 | L3 Gateway MAC Table (19) ``match: vpn-id=l3vpn-id, dst-mac=vpn-subnet-gateway-mac-address`` =>
 412 | L3 FIB Table (21) ``match: vpn-id=l3vpn-id`` =>
 413 | PSNAT Table (26) ``match: vpn-id=l3vpn-id`` =>
 414 | Outbound NAPT Table (46) ``match: nw-src=vm-ip,port=int-port set src-ip=router-gateway-ip,src-mac=external-router-gateway-mac-address,vpn-id=external-vpn-id,port=ext-port`` =>
 415 | NAPT PFIB Table (47) ``match: vpn-id=external-vpn-id`` =>
 416 | L3 FIB Table (21) ``match: vpn-id=external-vpn-id nw-dst=destination-floating-ip set eth-dst=floating-ip-dst-vm-mac-address tun-id=external-l3vni, output to vxlan-tun-port``
 417
 418 DNAT Hypervisor:
 419 ~~~~~~~~~~~~~~~~
 420 | Classifier Table (0) =>
 421 | Internal Tunnel Table (36) ``match: tun-id= external-l3vni`` =>
 422 | PDNAT Table (25) ``match: nw-dst=floating-ip eth-dst= floating-ip-dst-vm-mac-address set ip-dst=dst-vm-ip, vpn-id=l3vpn-id``=>
 423 | DNAT Table (27)  ``match: vpn-id=l3vpn-id,nw-dst=dst-vm-ip`` =>
 424 | L3 FIB Table (21) ``match: vpn-id=l3vpn-id, nw-dst=dst-vm-ip set output to nexthopgroup-dst-vm`` =>
 425 | NextHopGroup-dst-vm: ``set-eth-dst dst-mac-vm, reg6=dst-vm-lport-tag`` =>
 426 | Lport Egress Table (220) ``Output to dst vm port``
 427
 428
 429 Non-NAPT to NAPT Forward Traffic (Intra DC)
 430 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 431
 432 Non-NAPT Hypervisor:
 433 ~~~~~~~~~~~~~~~~~~~~
 434 | Classifier Table (0) =>
 435 | Lport Dispatcher Table (17) ``l3vpn service: set vpn-id=l3vpn-id`` =>
 436 | L3 Gateway MAC Table (19) ``match: vpn-id=l3vpn-id, dst-mac=vpn-subnet-gateway-mac-address`` =>
 437 | L3 FIB Table (21) ``match: vpn-id=l3vpn-id`` =>
 438 | PSNAT Table (26) ``match: vpn-id=l3vpn-id set tun-id=router-lport-tag,group`` =>
 439 | group: ``output to NAPT vxlan-tun-port``
 440
 441 NAPT Hypervisor:
 442 ~~~~~~~~~~~~~~~~
 443 | Classifier Table (0) =>
 444 | Internal Tunnel Table (36) ``match: tun-id=router-lport-tag`` =>
 445 | Outbound NAPT Table (46) ``match: nw-src=vm-ip,port=int-port set src-ip=router-gateway-ip,src-mac=external-router-gateway-mac-address,vpn-id=external-vpn-id,port=ext-port`` =>
 446 | NAPT PFIB Table (47) ``match: vpn-id=external-vpn-id`` =>
 447 | L3 FIB Table (21) ``match: vpn-id=external-vpn-id nw-dst=external-entity-ip set eth-dst=external-entity-mac tun-id=external-l3vni, output to ext-vxlan-tun-port``
 448
 449 For forwarding the traffic from Non-NAPT to NAPT DPN the tun-id will be setting with "router-lport-tag" which will be carved out per router.
 450
 451
 452 NAPT to Non-NAPT Reverse Traffic (Intra DC)
 453 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 454
 455 NAPT Hypervisor:
 456 ~~~~~~~~~~~~~~~~
 457 | Classifier Table (0) =>
 458 | L3VNI External Tunnel Demux Table (23) ``match: tun-id=external-l3vni set vpn-id=external-vpn-id`` =>
 459 | L3 Gateway MAC Table (19) ``match: vpn-id=external-vpn-id, dst-mac=external-router-gateway-mac-address`` =>
 460 | Inbound NAPT Table (44) ``match: vpn-id=external-vpn-id nw-dst=router-gateway-ip port=ext-port set vpn-id=l3vpn-id, dst-ip=vm-ip`` =>
 461 | NAPT PFIB Table (47) ``match: vpn-id=l3vpn-id`` =>
 462 | L3 FIB Table (21) ``match: vpn-id=l3vpn-id, nw-dst=dst-vm-ip-address set eth-dst-mac=dst-vm-mac, tun-id=dst-vm-lport-tag, output to vxlan-tun-port``
 463
 464 Non-NAPT Hypervisor:
 465 ~~~~~~~~~~~~~~~~~~~~
 466 | Classifier Table (0) =>
 467 | Internal Tunnel Table (36) ``match: tun-id=dst-vm-lport-tag`` =>
 468 | L3 FIB Table (21) ``match: vpn-id=l3vpn-id, nw-dst=dst-vm-ip set output to nexthopgroup-dst-vm`` =>
 469 | NextHopGroup-dst-vm: ``set-eth-dst dst-mac-vm, reg6=dst-vm-lport-tag`` =>
 470 | Lport Egress Table (220) ``Output to dst vm port``
 471
 472
 473 More details of the NAT pipeline changes are in the NAT Service section of this spec.
 474
 475 Yang changes
 476 ------------
 477 Changes will be needed in ``l3vpn.yang`` , ``odl-l3vpn.yang`` , ``odl-fib.yang`` and
 478 ``neutronvpn.yang`` to start supporting EVPN functionality.
 479
 480 L3VPN YANG changes
 481 +++++++++++++++++++
 482 A new leaf l3vni and a new leaf type will be added to container ``vpn-instances``
 483
 484 .. code-block:: none
 485    :caption: l3vpn.yang
 486
 487     leaf type {
 488               description
 489               "The type of the VPN Instance.
 490               ipvpn indicates it is an L3VPN.
 491               evpn indicates it is EVPN”;
 492
 493               type enumeration {
 494                     enum ipvpn {
 495                     value "0";
 496                     description “L3VPN";
 497                     }
 498                     enum evpn {
 499                     value "1";
 500                     description "EVPN";
 501                     }
 502               }
 503               default "ipvpn";
 504     }
 505
 506     leaf l3vni {
 507                description
 508                "The L3 VNI to use for this L3VPN Instance.
 509                If this attribute is non-zero, it indicates
 510                this L3VPN will do L3Forwarding over VXLAN.
 511                If this value is non-zero, and the type field is ‘l2’,
 512                it is an error.
 513                If this value is zero, and the type field is ‘l3’, it is
 514                the legacy L3VPN that will do L3Forwarding
 515                with MPLSoverGRE.
 516                If this value is zero, and the type field is ‘l2’, it
 517                is an EVPN that will provide L2 Connectivity with
 518                Openstack supplied VNI”.
 519
 520                type uint24;
 521                mandatory false;
 522     }
 523
 524     The **type** value comes from Openstack BGPVPN ODL Driver based on what type of BGPVPN is
 525     orchestrated by the tenant. That same **type** value must be retrieved and stored into
 526     VPNInstance model above maintained by NeutronvpnManager.
 527
 528 ODL-L3VPN YANG changes
 529 ++++++++++++++++++++++
 530 A new leaf l3vni and a new leaf type will be added to container ``vpn-instance-op-data``
 531
 532 .. code-block:: none
 533    :caption: odl-l3vpn.yang
 534
 535    leaf type {
 536              description
 537              "The type of the VPN Instance.
 538              ipvpn indicates it is an L3VPN.
 539              evpn indicates it is EVPN”;
 540
 541              type enumeration {
 542                    enum ipvpn {
 543                    value "0";
 544                    description “L3VPN";
 545                    }
 546                    enum evpn {
 547                    value "1";
 548                    description "EVPN";
 549                    }
 550              }
 551              default "ipvpn";
 552    }
 553
 554    leaf l3vni {
 555               description
 556               "The L3 VNI to use for this L3VPN Instance.
 557               If this attribute is non-zero, it indicates
 558               this L3VPN will do L3Forwarding over VXLAN.
 559               If this value is non-zero, and the type field is ‘l2’,
 560               it is an error.
 561               If this value is zero, and the type field is ‘l3’, it is
 562               the legacy L3VPN that will do L3Forwarding
 563               with MPLSoverGRE.
 564               If this value is zero, and the type field is ‘l2’, it
 565               is an EVPN that will provide L2 Connectivity with
 566               Openstack supplied VNI”.
 567
 568               type uint24;
 569               mandatory false;
 570    }
 571
 572    For every interface in the cloud that is part of an L3VPN which has an L3VNI setup, we should
 573    extract that L3VNI from the config VPNInstance and use that to both program the flows as well
 574    as advertise to BGP Neighbour using RouteType 5 BGP Route exchange.
 575    Fundamentally, what we are accomplishing is L3 Connectivity over VXLAN tunnels by using the
 576    EVPN RT5 mechanism.
 577
 578 ODL-FIB YANG changes
 579 ++++++++++++++++++++
 580 Few new leafs like mac_address , gateway_mac_address , l2vni, l3vni and a leaf encap-type will
 581 be added to container ``fibEntries``
 582
 583 .. code-block:: none
 584    :caption: odl-fib.yang
 585
 586    leaf encap-type {
 587       description
 588       "This flag indicates how to interpret the existing label field.
 589       A value of mpls indicates that the label will continue to
 590       be considered as an MPLS Label.
 591       A value of vxlan indicates that vni should be used to
 592       advertise to bgp.
 593       type enumeration {
 594           enum mplsgre {
 595               value "0";
 596               description "MPLSOverGRE";
 597           }
 598           enum vxlan {
 599               value "1";
 600               description “VNI";
 601           }
 602       }
 603       default "mplsgre";
 604    }
 605
 606    leaf mac_address {
 607        type string;
 608        mandatory false;
 609    }
 610
 611    leaf l3vni {
 612        type uint24;
 613        mandatory false;
 614    }
 615
 616    leaf l2vni {
 617        type uint24;
 618        mandatory false;
 619    }
 620
 621    leaf gateway_mac_address {
 622        type string;
 623        mandatory false;
 624    }
 625    Augment:parent_rd {
 626        type string;
 627        mandatory false;
 628    }
 629
 630 The encaptype indicates whether an MPLSOverGre or VXLAN encapsulation should be used
 631 for this route. If the encapType is MPLSOverGre then the usual label field will carry
 632 the MPLS Label to be used in datapath for traffic to/from this VRFEntry IP prefix.
 633
 634 If the encaptype is VXLAN, the VRFEntry implicitly refers that this route is reachable
 635 via a VXLAN tunnel. The L3VNI will carry the VRF VNI and there will also be an L2VNI which
 636 represents the VNI of the network to which the VRFEntry belongs to.
 637
 638 Based on whether Symmetric IRB (or) Asymmetric IRB is configured to be used by the CSC
 639 (see section on Configuration Impact below). If Symmetric IRB is configured, then the L3VNI
 640 should be used to program the flows rules. If Asymmetric IRB is configured, then L2VNI should
 641 be used in the flow rules.
 642
 643 The mac_address field must be filled for every route in an EVPN. This mac_address field
 644 will be used for support intra-DC communication for both inter-subnet and intra-subnet routing.
 645
 646 The gateway_mac_address must always be filled for every route in an EVPN.[AKMA7] [NV8]
 647 This gateway_mac_address will be used for all packet exchanges between DC-GW and the
 648 DPN in the DC to support L3 based forwarding with Symmetric IRB.
 649
 650 NEUTRONVPN YANG changes
 651 +++++++++++++++++++++++
 652 One new leaf l3vni will be added to container grouping ``vpn-instance``
 653
 654 .. code-block:: none
 655    :caption: odl-fib.yang
 656
 657    leaf l3vni {
 658        type uint32;
 659        mandatory false;
 660    }
 661
 662
 663 Solution considerations
 664 -----------------------
 665
 666 Proposed change in Openstack Neutron BGPVPN Driver
 667 +++++++++++++++++++++++++++++++++++++++++++++++++++
 668 The Openstack Neutron BGPVPN’s ODL driver in Newton release needs to be changed, so that
 669 it is able to relay the configured L2 BGPVPNs, to the OpenDaylight Controller.
 670 As of Mitaka release, only L3 BGPVPNs configured in Openstack are being relayed to the
 671 OpenDaylight Controller. So in addition to addressing the ODL BGPVPN Driver changes in
 672 Newton, we will provide a Mitaka based patch that will integrate into Openstack.
 673
 674 The Newton changes for the BGPVPN Driver has merged and is here:
 675 https://review.openstack.org/#/c/370547/
 676
 677 Proposed change in BGP Quagga Stack
 678 ++++++++++++++++++++++++++++++++++++
 679 The BGP Quagga Stack is a component that interfaces with ODL Controller to enable ODL Controller itself
 680 to become a BGP Peer.  This BGP Quagga Stack need to be enhanced so that it is able to embrace EVPN
 681 with Route Type 5 on the following two interfaces:
 682
 683 * Thrift Interface where ODL pushes routes to BGP Quagga Stack
 684 * Route exchanges from BGP Quagga Stack to other BGP Neighbors (including DC-GW).
 685
 686 Proposed change in OpenDaylight-specific features
 687 +++++++++++++++++++++++++++++++++++++++++++++++++
 688
 689 The following components within OpenDaylight Controller needs to be enhanced:
 690
 691 * NeutronvpnManager
 692 * VPN Engine (VPN Manager and VPN Interface Manager)
 693 * FIB Manager
 694 * BGP Manager
 695 * VPN SubnetRoute Handler
 696 * NAT Service
 697
 698 Import Export RT support for EVPN
 699 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 700 Currently Import/Export logic for L3VPN uses a LabelRouteInfo structure to build information
 701 about imported prefixes using MPLS Label as the key. However, this structure cannot be used
 702 for EVPN as the L3VNI will be applicable for an entire EVPN Instance instead of the MPLS Label.
 703 In lieu of LabelRouteInfo, we will maintain an IPPrefixInfo keyed structure that can be used
 704 for facilitating Import/Export of VRFEntries across both EVPNs and L3VPNs.
 705
 706 .. code-block:: none
 707    :caption: odl-fib.yang
 708
 709    list ipprefix-info {
 710
 711        key "prefix, parent-rd"
 712        leaf prefix {
 713            type string;
 714        }
 715
 716        leaf parent-rd {
 717            type string;
 718        }
 719
 720        leaf label {
 721            type uint32;
 722        }
 723
 724        leaf dpn-id {
 725            type uint64;
 726        }
 727
 728        leaf-list next-hop-ip-list {
 729            type string;
 730        }
 731
 732        leaf-list vpn-instance-list {
 733            type string;
 734        }
 735
 736        leaf parent-vpnid {
 737            type uint32;
 738        }
 739
 740        leaf vpn-interface-name {
 741            type string;
 742        }
 743
 744        leaf elan-tag {
 745            type uint32;
 746        }
 747
 748        leaf is-subnet-route {
 749            type boolean;
 750        }
 751
 752        leaf encap-type {
 753            description
 754            "This flag indicates how to interpret the existing label field.
 755            A value of mpls indicates that the l3label should be considered as an MPLS
 756            Label.
 757            A value of vxlan indicates that l3label should be considered as an VNI.
 758            type enumeration {
 759                enum mplsgre {
 760                    value "0";
 761                    description "MPLSOverGRE";
 762                }
 763                enum vxlan {
 764                    value "1";
 765                    description “VNI";
 766                }
 767                default "mplsgre";
 768            }
 769        }
 770
 771        leaf l3vni {
 772            type uint24;
 773            mandatory false;
 774        }
 775
 776        leaf l2vni {
 777            type uint24;
 778            mandatory false;
 779        }
 780
 781        leaf gateway_mac_address {
 782            type string;
 783            mandatory false;
 784        }
 785    }
 786
 787 SubnetRoute support on EVPN
 788 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 789 The subnetRoute feature will continue to be supported on EVPN and we will use RT5 to publish
 790 subnetRoute entries with either the router-interface-mac-address if available (or) if not
 791 available use the pre-defined hardcoded MAC Address described in section Configuration Impact.
 792 For both ExtraRoutes and MIPs (invisible IPs) discovered via subnetroute, we will continue
 793 to use RT5 to publish those prefixes.[AKMA9] [NV10]
 794 On the dataplane, VXLAN packets from the DC-GW will carry the MAC Address of the gateway-ip
 795 for the subnet in the inner DMAC.
 796
 797 NAT Service support for EVPN
 798 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 799 However, since external network NAT should continue to be supported on VXLAN, making NAT
 800 service work on L3VPNs that use VXLAN as the tunnel type becomes imperative.
 801
 802 Existing SNAT/DNAT design assumed internetVpn to be using mplsogre as the connectivity
 803 from external network towards DCGW. This needs to be changed such that it can handle even
 804 EVPN case with VXLAN connectivity as well.
 805
 806 As of the implementation required for this specification, the workflow will be to create
 807 InternetVPN with and associate a single external network to that is of VXLAN Provider Type.
 808 The Internet VPN itself will be an L3VPN that will be created via the ODL RESTful API and
 809 during creation an L3VNI parameter will be supplied to enable this L3VPN to operate on a
 810 VXLAN dataplane. The L3VNI provided to the Internet VPN can be different from the VXLAN
 811 segmentation ID associated to the external network.
 812
 813 However, it will be a more viable use-case in the community if we mandate in our workflow
 814 that both the L3VNI configured for Internet VPN and the VXLAN segmentation id of the
 815 associated external network to the Internet VPN be the same.
 816 NAT service can use vpninstance-op-data model to classify the DCGW connectivity for internetVpn.
 817
 818 For the Pipeline changes for NAT Service, please refer to 'Pipeline changes' section.
 819
 820 SNAT to start using Router Gateway MAC, in translated entry in table 46 (Outbound SNAT table)
 821 and in table 19 (L3_GW_MAC_Table). Presently Router gateway mac is already stored in odl-nat model
 822 in External Routers.
 823
 824 DNAT to start using Floating MAC, in table 28 (SNAT table) and in table 19 (L3_GW_MAC Table).
 825 Change in pipeline mainly reverse traffic for SNAT and DNAT so that when packet arrives from DCGW,
 826 it goes to 0->38->17->19 and based on Vni and MAC matching, take it back to SNAT or DNAT pipelines.
 827
 828 Also final Fib Entry pointing to DCGW in forward direction also needs modification where we should
 829 start using VXLAN’s vni, FloatingIPMAC (incase of DNAT) and ExternalGwMacAddress(incase of SNAT)
 830 and finally encapsulation type as VXLAN.
 831
 832 For SNAT advertise to BGP happens during external network association to Vpn and during High
 833 availability scenarios where you need to re-advertise the NAPT switch. For DNAT we need to
 834 advertise when floating IP is associated to the VM.
 835 For both SNAT and DNAT this IS mandates that we do only RT5 based advertisement. That RT5
 836 advertisement must carry the external gateway mac address assigned for the respective Router
 837 for SNAT case while for DNAT case the RT5 will carry the floating-ip-mac address.
 838
 839 ARP request/response and MIP handling Support for EVPN
 840 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 841 Will not support ARP across DCs, as we donot support intra-subnet inter-DC scenarios.
 842
 843 * For intra-subnet intra-DC scenarios, the ARPs will be serviced by existing ELAN pipeline.
 844 * For inter-subnet intra-DC scenarios, the ARPs will be processed by ARP Responder implementation that is already pursued in Carbon.
 845 * For inter-subnet inter-DC scenarios, ARP requests won’t be generated by DC-GW.  Instead the DC-GW will use ‘gateway mac’ extended attribute MAC Address information and put that directly into DSTMAC field of Inner MAC Header by the DC-GW for all packets sent to VMs within the DC.
 846 * As quoted, intra-subnet inter-DC scenario is not a supported use-case as per this Implementation Spec.
 847
 848 Tunnel state handling Support
 849 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 850 We have to handle both the internal and external tunnel events for L3VPN (with L3VNI) the same way
 851 it is handled for current L3VPN.
 852
 853 InterVPNLink support for EVPN
 854 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 855 Not supported as this is not a requirement for this Spec.
 856
 857 Supporting VLAN Aware VMs (Trunk and SubPorts)
 858 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 859 Not supported as this is not a requirement for this Spec.
 860
 861 VM Mobility with RT5
 862 ^^^^^^^^^^^^^^^^^^^^
 863 We will continue to support cold migration of VMs across hypervisors across L3VPNs as supported
 864 already in current ODL Carbon Release.
 865
 866 Reboot Scenarios
 867 ^^^^^^^^^^^^^^^^
 868 This feature support all the following Reboot Scenarios for EVPN:
 869
 870 *  Entire Cluster Reboot
 871 *  Leader PL reboot
 872 *  Candidate PL reboot
 873 *  OVS Datapath reboots
 874 *  Multiple PL reboots
 875 *  Multiple Cluster reboots
 876 *  Multiple reboots of the same OVS Datapath.
 877 *  Openstack Controller reboots
 878
 879
 880 Configuration impact
 881 --------------------
 882 The following parameters have been initially made available as configurable for EVPN. These
 883 configurations can be made via the RESTful interface:
 884
 885 **1.Multi-homing-mode** – For multi-homing use cases where redundant DCGWs are used ODL can be configured with ‘none’, ‘all-active’ or ‘single-active’ multi-homing mode.  Default will be ‘none’.
 886
 887 **2.IRB-mode** – Depending upon the support on DCGW, ODL can be configured with either ‘Symmetric’ or ‘Asymmetric’ IRB mode.  Default is ‘Symmetric’.
 888
 889 There is another important parameter though it won’t be configurable:
 890
 891 **MAC Address Prefix for EVPN** – This MAC Address prefix represents the MAC Address prefix that will be hardcoded and that MACAddress will be used as the gateway mac address if it is not supplied from Openstack.  This will usually be the case when networks are associated to an L3VPN with no gateway port yet configured in Openstack for such networks.
 892
 893
 894 Clustering considerations
 895 -------------------------
 896 The feature should operate in ODL Clustered environment reliably.
 897
 898 Other Infra considerations
 899 --------------------------
 900 N.A.
 901
 902 Security considerations
 903 -----------------------
 904 N.A.
 905
 906 Scale and Performance Impact
 907 ----------------------------
 908 Not covered by this Design Document.
 909
 910 Targeted Release
 911 ----------------
 912 Carbon.
 913
 914 Alternatives
 915 ------------
 916 Alternatives considered and why they were not selected.
 917
 918 Usage
 919 =====
 920
 921 Features to Install
 922 -------------------
 923 This feature can be used by installing odl-netvirt-openstack.
 924 This feature doesn't add any new karaf feature.
 925
 926 REST API
 927 --------
 928 The creational RESTful API for the L3VPN will be enhanced to accept
 929 the L3VNI as an additional attribute as in the below request format:
 930
 931 .. code-block:: none
 932
 933    {'input': {
 934        'l3vpn': [
 935            {'name': 'L3VPN2',
 936             'export-RT': ['50:2'],
 937             'route-distinguisher': ['50:2'],
 938             'import-RT': ['50:2'],
 939             'id': '4ae8cd92-48ca-49b5-94e1-b2921a260007',
 940             ‘l3vni’: ‘200’,
 941             'tenant-id': 'a565b3ed854247f795c0840b0481c699'
 942    }]}}
 943
 944 There is no change in the REST API for associating networks, associating routers (or) deleting
 945 the L3VPN.
 946
 947 On the Openstack-side configuration, the vni_ranges configured in Openstack Neutron ml2_conf.ini
 948 should not overlap with the L3VNI provided in the ODL RESTful API.
 949 In an inter-DC case, where both the DCs are managed by two different Openstack Controller
 950 Instances, the workflow will be to do the following:
 951
 952 1. Configure the DC-GW2 facing OSC2 and DC-GW1 facing OSC1 with the same BGP configuration parameters.
 953 2. On first Openstack Controller (OSC1) create an L3VPN1 with RD1 and L3VNI1
 954 3. Create a network Net1 and Associate that Network Net1 to L3VPN1
 955 4. On second Openstack Controller (OSC2) create an L3VPN2 with RD1 with L3VNI2
 956 5. Create a network Net2 on OSC2 and associate that Network Net2 to L3VPN2.
 957 6. Spin-off VM1 on Net1 in OSC1.
 958 7. Spin-off VM2 on Net2 in OSC2.
 959 8. Now VM1 and VM2 should be able to communicate.
 960
 961
 962 Implementation
 963 ==============
 964
 965 Assignee(s)
 966 -----------
 967
 968 Primary assignee:
 969   Kiran N Upadhyaya (kiran.n.upadhyaya@ericsson.com)
 970
 971   Sumanth MS (sumanth.ms@ericsson.com)
 972
 973   Basavaraju Chickmath (basavaraju.chickmath@ericsson.com)
 974
 975 Other contributors:
 976   Vivekanandan Narasimhan (n.vivekanandan@ericsson.com)
 977
 978 Work Items
 979 ----------
 980 The Trello cards have already been raised for this feature
 981 under the EVPN_RT5.
 982
 983 Here is the link for the Trello Card:
 984 https://trello.com/c/Tfpr3ezF/33-evpn-evpn-rt5
 985
 986 New tasks into this will be added to cover Java UT and
 987 CSIT.
 988
 989 Dependencies
 990 ============
 991 Requires a DC-GW that is supporting EVPN RT5 on BGP Control plane.
 992
 993 Testing
 994 =======
 995 Capture details of testing that will need to be added.
 996
 997 Unit Tests
 998 ----------
 999 Appropriate UTs will be added for the new code coming in once framework is in place.
1000
1001 Integration Tests
1002 -----------------
1003 There won't be any Integration tests provided for this feature.
1004
1005 CSIT
1006 ----
1007 CSIT will be enhanced to cover this feature by providing new CSIT tests.
1008
1009 Documentation Impact
1010 ====================
1011 This will require changes to User Guide and Developer Guide.
1012
1013 User Guide will need to add information on how OpenDaylight can
1014 be used to deploy L3 BGPVPNs and enable communication across
1015 datacenters between virtual endpoints in such L3 BGPVPN.
1016
1017 Developer Guide will capture the ODL L3VPN API changes to enable
1018 management of an L3VPN that can use VXLAN overlay to enable
1019 communication across datacenters.
1020
1021 References
1022 ==========
1023 [1] `EVPN_RT5 <https://tools.ietf.org/html/draft-ietf-bess-evpn-prefix-advertisement-03>`_
1024
1025 [2] `Network Virtualization using EVPN <https://www.ietf.org/id/draft-ietf-bess-evpn-overlay-07.txt>`_
1026
1027 [3] `Integrated Routing and Bridging in EVPN <https://tools.ietf.org/html/draft-ietf-bess-evpn-inter-subnet-forwarding-04>`_
1028
1029 [4] `VXLAN DCI using EVPN <https://tools.ietf.org/html/draft-boutros-bess-vxlan-evpn-02>`_
1030
1031 [5] `BGP MPLS-Based Ethernet VPN <https://tools.ietf.org/html/rfc7432>`_
1032
1033 * http://docs.opendaylight.org/en/latest/documentation.html
1034 * https://wiki.opendaylight.org/view/Genius:Carbon_Release_Plan