docs/specs/oxygen/ipv6-interdc-l3vpn.rst

   1 .. contents:: Table of Contents
   2          :depth: 3
   3
   4 =============================================================================
   5 IPv6 Inter-DC L3 North-South connectivity using L3VPN provider network types.
   6 =============================================================================
   7
   8 https://git.opendaylight.org/gerrit/#/q/topic:ipv6-interdc-l3vpn
   9
  10 In this specification we will be discussing the high level design of
  11 IPv6 Inter-Datacenter North-South connectivity support in OpenDaylight
  12 using L3VPN provider network type use-case.
  13
  14 Problem description
  15 ===================
  16
  17 Provide IPv6 connectivity to virtual machines located in different subnets
  18 spread over multiple sites or Data center can be achieved through use of
  19 Globally Unique Addresses and capacity to update enough routing tables to
  20 forge a path between the two. Even if IPv6 is made to interconnect hosts
  21 without the help of any NAT mechanisms, routing with the best efficienty
  22 (shortest path) or policy (route weight, commercial relationships) must
  23 be configured using only few parameters, automatically updating routes
  24 for each VM spawned in new network.
  25
  26 Keep in mind that key aspects of L3VPN connectivity is Route Targets and
  27 VPN-IPv6 address family.
  28 Assuming an operator can configure both data center gateways with same
  29 Route Distinguisher or set of imported Route Targets, each time a virtual
  30 machine is spawned within a new subnet, it will trigger the send of a BGP UPDATE
  31 message containing MP-BGP attributes required for reaching the VM.
  32 Such behavior can be achieved by configuring a neutron router a default gateway.
  33
  34
  35 Only IPv6 Globally Unique Address (eg /128) are advertised, this is not a scaling
  36 architecture since it implies as much routes to process as the number of spawned
  37 VMs, but with such BGP routing information base, DCGW can select the Compute Node
  38 to which a packet coming from the WAN should be forwarded to.
  39
  40
  41 Following schema could help :
  42
  43 ::
  44
  45  +-----------------+                                         +-----------------+
  46  | +-------------+ |                                         | +-------------+ |
  47  | |VM1          | +---+                                 +---+ |VM1          | |
  48  | | Subnet C::4 | |   |              BGP table          |   | | Subnet A::2 | |
  49  | +-------------+ |OVS|              Prefix Subnet A::2 |OVS| +-------------+ |
  50  | +-------------+ | A |              Label L1           | A | +-------------+ |
  51  | |VM2          | |   |              Next Hop OVS A     |   | |VM2          | |
  52  | | Subnet D::4 | +-+-+                                 +-+-+ | Subnet B::2 | |
  53  | +-------------+ | |     +------+       +-------+        | | +-------------+ |
  54  +-----------------+ |     |      |       |       |        | +-----------------+
  55                      +-----+      |       |       +--------+
  56                            | DCGW +--WAN--+ DCGW  |
  57  +-----------------+ +-----+      |       |       +--------+ +-----------------+
  58  | +-------------+ | |     |      |       |       |        | | +-------------+ |
  59  | |VM3          | +-+-+   +------+       +-------+      +-+-+ |VM3          | |
  60  | | Subnet C::5 | |   |                                 |   | | Subnet A::3 | |
  61  | +-------------+ |OVS|                                 |OVS| +-------------+ |
  62  | +-------------+ | B |                                 | B | +-------------+ |
  63  | |VM4          | |   |                                 |   | |VM4          | |
  64  | | Subnet D::5 | +---+                                 +---+ | Subnet B::3 | |
  65  | +-------------+ |                                         | +-------------+ |
  66  +-----------------+                                         +-----------------+
  67
  68 BGP protocol and its MP-BGP extension would do the job as long as all BGP
  69 speakers are capable of processing UPDATE messages containing VPN-IPv6 address
  70 family, which AFI value is 2 and SAFI is 128. It is not required that BGP
  71 speakers peers using IPv6 LLA or GUA, IPv4 will be used to peer speakers
  72 together.
  73
  74 Opendaylight is already able to support the VPN-IPv4 address family (AFI=1,
  75 SAFI=128), and this blueprint focuses on specific requirements to VPN-IPv6.
  76
  77 One big question concerns the underlying transport IP version used with MPLS/GRE
  78 tunnels established between Data center Gateway (DCGW), and compute nodes
  79 (CNs). There is one MPLS/GRE tunnel setup from DCGW to each Compute Node involved
  80 in the L3VPN topology. Please note that this spec doesn't covers the case of
  81 VxLAN tunnels between DCGW and Compute Nodes.
  82
  83 According to RFC 4659 §3.2.1, the encoding of the nexthop attribute in
  84 MP-BGP UPDATE message differs if the tunneling transport version required is
  85 IPv4 or IPv6. In this blueprint spec, the assumption of transport IP version of
  86 IPv4 is prefered. This implies that any nexthop set for a prefix in FIB will be
  87 IPv4.
  88
  89 Within BGP RIB table, for each L3VPN entry, the nexthop and label are key
  90 elements for creating MPLS/GRE tunnel endpoints, and the prefix is used for
  91 programming netvirt pipeline. When a VM is spawned, the prefix advertised by BGP
  92 is 128 bits long and the nexthop carried along within UPDATE message is the ip
  93 address of the DPN interface used for DCGW connection.
  94 Since DCGW can be proprietary device, it may not support MPLS/GRE tunnel endpoint
  95 setup according to its internal BGP table. A static configuration of such tunnel
  96 endpoint may be required.
  97
  98 Use Cases
  99 ---------
 100
 101 Inter Datacenter IPv6 external connectivity for VMs spawned on tenant networks,
 102 routes exchanged between BGP speakers using same Route Distinguisher.
 103
 104 Steps in both data centers :
 105
 106   - Configure ODL and Devstack networking-odl for BGP VPN.
 107   - Create a tenant network with IPv6 subnet using GUA prefix or an
 108     admin-created-shared-ipv6-subnet-pool.
 109   - This tenant network is separated to an external network where the DCGW is
 110     connected. Separation between both networks is done by DPN located on compute
 111     nodes. The subnet on this external network is using the same tenant as an IPv4
 112     subnet used for MPLS over GRE tunnels endpoints between DCGW and DPN on
 113     Compute nodes. Configure one GRE tunnel between DPN on compute node and
 114     DCGW.
 115   - Create a Neutron Router and connect its ports to all internal subnets that
 116     will belong to the same L3 BGPVPN identified by a Route Distinguisher.
 117   - Start BGP stack managed by ODL, possibly on same host as ODL.
 118   - Create L3VPN instance.
 119   - Associate the Router with the L3VPN instance.
 120   - Spawn VM on the tenant network, L3 connectivity between VMs located on
 121     different datacenter sharing same Route Distinguisher must be successful.
 122
 123 When both data centers are set up, there are 2 use cases per data center:
 124
 125   - Traffic from DC-Gateway to Local DPN (VMS on compute node)
 126   - Traffic from Local DPN to DC-Gateway
 127
 128 Proposed change
 129 ===============
 130
 131 ODL Controller would program the necessary pipeline flows to support IPv6
 132 North South communication through MPLS/GRE tunnels out of compute node.
 133
 134 BGP manager would be updated to process BGP RIB when entries are IPv6 prefixes.
 135
 136 FIB manager would be updated to take into acount IPv6 prefixes.
 137
 138 Thrift interface between ODL and BGP implementation (Quagga BGP) must be
 139 enhanced to support new AFI=2. Thrift interface will still carry IPv4 Nexthops,
 140 and it will be the Quagga duty to transform this IPv4 Nexthop address into an
 141 IPv4-mapped IPv6 address in every NLRI fields. Here is the new api proposed :
 142
 143 ::
 144
 145  enum af_afi {
 146      AFI_IP = 1,
 147      AFI_IPV6 = 2,
 148  }
 149  i32 pushRoute(1:string prefix, 2:string nexthop, 3:string rd, 4:i32 label,
 150                5:af_afi afi)
 151  i32 withdrawRoute(1:string prefix, 2:string rd, 3:af_afi afi)
 152  oneway void onUpdatePushRoute(1:string rd, 2:string prefix,
 153                                3:i32 prefixlen, 4:string nexthop,
 154                                5:i32 label, 6:af_afi afi)
 155  oneway void onUpdateWithdrawRoute(1:string rd, 2:string prefix,
 156                                    3:i32 prefixlen, 4:string nexthop,
 157                                    5:af_afi afi)
 158  Routes getRoutes(1:i32 optype, 2:i32 winSize, 3:af_afi afi)
 159
 160 BGP implementation (Quagga BGP) announcing (AFI=2,SAFI=128) capability as well
 161 as processing UPDATE messages with such address family. Note that the required
 162 changes in Quagga is not part of the design task covered by this blueprint.
 163
 164 Pipeline changes
 165 ----------------
 166
 167 Regarding the pipeline changes, we can use the same BGPVPNv4 pipeline
 168 (Tables Dispatcher (17), DMAC (19), LFIB (20), L3FIB (21), and NextHop Group
 169 tables) and enhance those tables to support IPv6 North-South communication
 170 through MPLS/GRE.
 171
 172 Traffic from DC-Gateway to Local DPN (SYMMETRIC IRB)
 173 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 174
 175 | Classifier Table (0) =>
 176 | LFIB Table (20) ``match: tun-id=mpls_label set vpn-id=l3vpn-id, pop_mpls label, set output to nexthopgroup-dst-vm`` =>
 177 | NextHopGroup-dst-vm: ``set-eth-dst dst-mac-vm, reg6=dst-vm-lport-tag`` =>
 178 | Lport Egress Table (220) ``Output to dst vm port``
 179
 180 Please note that ``vpn-subnet-gateway-mac-address`` stands for MAC address of
 181 the neutron port of the internal subnet gateway router.
 182
 183 Traffic from Local DPN to DC-Gateway (SYMMETRIC IRB)
 184 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 185
 186 | Classifier Table (0) =>
 187 | Lport Dispatcher Table (17) ``match: LportTag l3vpn service: set vpn-id=l3vpn-id`` =>
 188 | DMAC Service Filter (19) ``match: dst-mac=router-internal-interface-mac l3vpn service: set vpn-id=l3vpn-id`` =>
 189 | L3 FIB Table (21) ``match: vpn-id=l3vpn-id, nw-dst=ext-ip-address set tun-id=mpls_label output to MPLSoGRE tunnel port`` =>
 190
 191 Please note that ``router-internal-interface-mac`` stands for MAC address of
 192 the neutron port of the internal subnet gateway router.
 193
 194 Yang changes
 195 ------------
 196
 197 Changes will be needed in ``ebgp.yang`` to start supporting IPv6 networks
 198 advertisements.
 199
 200
 201 EBGP YANG changes
 202 +++++++++++++++++
 203 A new leaf afi will be added to container ``networks``
 204
 205 .. code-block:: none
 206    :caption: ebgp.yang
 207
 208    list networks {
 209        key "rd prefix-len";
 210
 211        leaf rd {
 212              type string;
 213        }
 214
 215        leaf prefix-len {
 216              type string;
 217        }
 218
 219        leaf afi {
 220              type uint32;
 221              mandatory "false";
 222        }
 223
 224        leaf nexthop {
 225              type inet:ipv4-address;
 226              mandatory "false";
 227        }
 228
 229        leaf label {
 230              type uint32;
 231              mandatory "false";
 232        }
 233    }
 234
 235 Configuration impact
 236 ---------------------
 237 None
 238
 239 Clustering considerations
 240 -------------------------
 241 None
 242
 243 Other Infra considerations
 244 --------------------------
 245 None
 246
 247 Security considerations
 248 -----------------------
 249 None
 250
 251 Scale and Performance Impact
 252 ----------------------------
 253 Impact on scaling inside datacenter essentially grow with the number of VM
 254 connected to subnets associated with the L3VPN.
 255 Since Globally Unique Address are used and there is no NAT involved in the
 256 datapath, it implies prefixes advertised are all /128.
 257 At the end, it means that every prefix advertised will have its entry
 258 in BGP RIB of all ODL controllers and DCGW involved in L3VPN (ie all bgp aware
 259 equipment will handle all prefixes advertised wihtin a Route Distinguisher).
 260
 261 This may imply BGP table with very high number of entries. This also implies a
 262 high number of entries in ODL routing table and equivalent number of flows
 263 inserted in OVS, since prefix advertised add matching ip destination in OVS
 264 tables.
 265
 266 This fact also impact the scaling of the BGP speaker implementation (Quagga
 267 BGP) with many thousands of BGPVPNv4 and BGPVPNv6 prefixes (as much as number
 268 of spawned VMs) with best path selection algorithm on route updates, graceful
 269 restart procedure, and multipath.
 270
 271 Targeted Release
 272 -----------------
 273 Carbon
 274
 275 Alternatives
 276 ------------
 277 None
 278
 279 Usage
 280 =====
 281
 282 * Configure MPLS/GRE tunnel endpoint on DCGW connected to public-net network
 283
 284 * Configure neutron networking-odl plugin
 285
 286 * Configure BGP speaker in charge of retrieving prefixes for/from data center
 287   gateway in ODL through the set of vpnservice.bgpspeaker.host.name in
 288   etc/custom.properties. No REST API can configure that parameter.
 289   Use config/ebgp:bgp REST api to start BGP stack and configure VRF, address
 290   family and neighboring
 291
 292 ::
 293
 294  POST config/ebgp:bgp
 295  {
 296      "ebgp:as-id": {
 297            "ebgp:stalepath-time": "360",
 298            "ebgp:router-id": "<ip-bgp-stack>",
 299            "ebgp:announce-fbit": "true",
 300            "ebgp:local-as": "<as>"
 301      },
 302      "ebgp:vrfs": [
 303       {
 304         "ebgp:export-rts": [
 305           "<export-rts>"
 306         ],
 307         "ebgp:rd": "<RD>",
 308         "ebgp:import-rts": [
 309           "<import-rts>"
 310         ]
 311       }
 312     ],
 313     "ebgp:neighbors": [
 314       {
 315         "ebgp:remote-as": "<as>",
 316         "ebgp:address-families": [
 317           {
 318             "ebgp:afi": "2",
 319             "ebgp:peer-ip": "<neighbor-ip-address>",
 320             "ebgp:safi": "128"
 321           }
 322         ],
 323         "ebgp:address": "<neighbor-ip-address>"
 324       }
 325     ],
 326  }
 327
 328 * Configure BGP speaker on DCGW to exchange prefixes with ODL BGP stack. Since
 329   DCGW should be a vendor solution, the configuration of such equipment is out of
 330   the scope of this specification.
 331
 332
 333 * Create an internal tenant network with an IPv6 (or dual-stack) subnet and
 334   connect ports.
 335
 336 ::
 337
 338  neutron net-create private-net
 339  neutron subnet-create private-net 2001:db8:0:2::/64 --name ipv6-int-subnet
 340  --ip-version 6 --ipv6-ra-mode slaac --ipv6-address-mode slaac
 341  neutron port-create private-net --name port1_private1
 342
 343 * Create a router and associate it to internal subnets.
 344
 345 ::
 346
 347  neutron router-create router1
 348  neutron router-interface-add router1 ipv6-int-subnet
 349
 350 * Use neutronvpn:createL3VPN REST api to create L3VPN
 351
 352 ::
 353
 354  POST /restconf/operations/neutronvpn:createL3VPN
 355  {
 356     "input": {
 357        "l3vpn":[
 358           {
 359              "id":"vpnid_uuid",
 360              "name":"vpn1",
 361              "route-distinguisher": [100:1],
 362              "export-RT": [100:1],
 363              "import-RT": [100:1],
 364              "tenant-id":"tenant_uuid"
 365           }
 366        ]
 367     }
 368  }
 369
 370 * Associate L3VPN To Routers
 371
 372 ::
 373
 374  POST /restconf/operations/neutronvpn:associateRouter
 375  {
 376    "input":{
 377       "vpn-id":"vpnid_uuid",
 378       "router-id":[ "router_uuid" ]
 379     }
 380  }
 381
 382 * Create MPLSoGRE tunnel between DPN and DCGW
 383
 384 ::
 385
 386  POST /restconf/operations/itm-rpc:add-external-tunnel-endpoint
 387  {
 388    "itm-rpc:input": {
 389      "itm-rpc:destination-ip": "dcgw_ip",
 390      "itm-rpc:tunnel-type": "odl-interface:tunnel-type-mpls-over-gre"
 391    }
 392  }
 393
 394 * Spawn a VM in the tenant network
 395
 396 ::
 397
 398  nova boot --image <image-id> --flavor <flavor-id> \
 399       --nic net-id=port1_private1_uuid VM1
 400
 401 * Dump ODL BGP FIB
 402
 403 ::
 404
 405  GET /restconf/config/odl-fib:fibEntries
 406  {
 407    "fibEntries": {
 408      "vrfTables": [
 409        {
 410          "routeDistinguisher": <rd-uuid>
 411        },
 412        {
 413          "routeDistinguisher": <rd>,
 414          "vrfEntry": [
 415            {
 416              "destPrefix": <IPv6_VM1/128>,
 417              "label": <label>,
 418              "nextHopAddressList": [
 419                <DPN_IPv4>
 420              ],
 421              "origin": "l"
 422            },
 423          ]
 424        }
 425      ]
 426    }
 427  }
 428
 429
 430 Features to Install
 431 -------------------
 432 odl-netvirt-openstack
 433
 434 REST API
 435 --------
 436
 437 CLI
 438 ---
 439
 440 A new option ``--afi`` will be added to command ``odl:bgp-network``:
 441
 442 .. code-block:: none
 443
 444  opendaylight-user@root>
 445  odl:bgp-network --prefix 2001:db8::1/128 --rd 100:1 --nexthop 192.168.0.2
 446                  --label 700 --afi 2 add/del
 447
 448
 449 Implementation
 450 ==============
 451
 452 Assignee(s)
 453 -----------
 454 Primary assignee:
 455   Julien Courtat <julien.courtat@6wind.com>
 456
 457 Other contributors:
 458   Noel de Prandieres <prandieres@6wind.com>
 459   Valentina Krasnobaeva <valentina.krasnobaeva@6wind.com>
 460   Philippe Guibert <philippe.guibert@6wind.com>
 461
 462 Work Items
 463 ----------
 464
 465 * Implement necessary APIs to allocate a transport over IPv6 requirement
 466   configuration for a given Route Target as the primary key.
 467 * Support of BGPVPNv6 prefixes within MD-SAL. Enhance RIB-manager to support
 468   routes learned from other bgp speakers, [un]set static routes.
 469 * BGP speaker implementation, Quagga BGP, to support BGPVPN6 prefixes exchanges
 470   with other BGP speakers (interoperability), and thrift interface updates.
 471 * Program necessary pipeline flows to support IPv6 to MPLS/GRE (IPv4) communication.
 472
 473 Dependencies
 474 ============
 475 Quagga from 6WIND is publicly available at the following url
 476
 477  * https://github.com/6WIND/quagga
 478  * https://github.com/6WIND/zrpcd
 479
 480 Testing
 481 =======
 482
 483 Unit Tests
 484 ----------
 485 Unit tests provided for the BGPVPNv4 versions will be enhanced to also support
 486 BGPVPNv6. No additional unit tests will be proposed.
 487
 488 Integration Tests
 489 -----------------
 490 TBD
 491
 492 CSIT
 493 ----
 494 CSIT provided for the BGPVPNv4 versions will be enhanced to also support
 495 BGPVPNv6. No additional CSIT will be proposed.
 496
 497
 498 Documentation Impact
 499 ====================
 500 Necessary documentation would be added on how to use this feature.
 501
 502 References
 503 ==========
 504 [1] `OpenDaylight Documentation Guide <http://docs.opendaylight.org/en/latest/documentation.html>`__
 505
 506 [2] https://specs.openstack.org/openstack/nova-specs/specs/kilo/template.html
 507
 508 [3] http://docs.openstack.org/developer/networking-bgpvpn/overview.html
 509
 510 [4] `Spec to support IPv6 North-South support for Flat/VLAN Provider Network.
 511 <https://git.opendaylight.org/gerrit/#/q/topic:ipv6-cvr-north-south>`_
 512
 513 [5] `BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN
 514 <https://tools.ietf.org/html/rfc4659>`_
 515
 516 .. note::
 517
 518   This template was derived from [2], and has been modified to support our project.
 519
 520   This work is licensed under a Creative Commons Attribution 3.0 Unported License.
 521   http://creativecommons.org/licenses/by/3.0/legalcode