docs/specs/itm-tunnel-auto-config.rst

   1 =============================
   2 ITM Tunnel Auto-Configuration
   3 =============================
   4
   5 https://git.opendaylight.org/gerrit/#/q/topic:itm-auto-config
   6
   7 Internal Transport Manager (ITM) Tunnel Auto configuration feature  proposes a
   8 solution to migrate from REST/CLI based Tunnel End Point (TEP) configuration to
   9 automatic learning of Openvswitch (OVS) TEPs from the switches, thereby triggering
  10 automatic configuration of tunnels.
  11
  12 Problem description
  13 ===================
  14
  15 User has to use ITM REST APIs for addition/deletion of TEPs into/from Transport zone.
  16 But, OVS and other TOR switches that support OVSDB can be configured for TEP without
  17 requring TEP configuration through REST API, which leads to redundancy and makes the
  18 process cumbersome and error-prone.
  19
  20 Use Cases
  21 ---------
  22 This feature will support following use cases:
  23
  24 * Use case 1: Add tep to existing transport-zone from southbound interface(SBI).
  25 * Use case 2: Delete tep from SBI.
  26 * Use case 3: Move the tep from one transport zone to another from SBI.
  27 * Use case 4: User can specify the Datapath Node (DPN) bridge for tep other
  28   than ``br-int`` from SBI.
  29 * Use case 5: Allow user to configure a tep from SBI if they want to use
  30   flow based tunnels.
  31 * Use case 6: TEP-IP, Port, vlan, subnet, gateway IP are optional parameters
  32   for creating a transport zone from REST.
  33 * Use case 7: User must configure Transport zone name and tunnel type parameters
  34   while creating a transport zone from REST, as both are mandatory parameters.
  35 * Use case 8: Store teps received on OVS connect for transport-zone which is not yet
  36   created and also allow to move such teps into transport-zone when it gets created
  37   from northbound.
  38 * Use case 9: Allow user to control creation of default transport zone through
  39   start-up configurable parameter ``def-tz-enabled`` in config file.
  40 * Use case 10: Tunnel-type for default transport zone should be configurable through configurable
  41   parameter ``def-tz-tunnel-type`` in config file.
  42 * Use case 11: Allow user to change ``def-tz-enabled`` configurable parameter from OFF to ON
  43   during OpenDaylight controller restart.
  44 * Use case 12: Allow user to change ``def-tz-enabled`` configurable parameter from ON to OFF
  45   during OpenDaylight controller restart.
  46 * Use case 13: Default value for configurable parameter ``def-tz-enabled`` is OFF and if it is
  47   not changed by user, then it will be OFF after OpenDaylight controller restart as well.
  48
  49 Following use cases will not be supported:
  50
  51 * If a switch gets disconnected, the corresponding TEP entries will not get cleared
  52   off from the ITM config datastore (DS) and operator must explicitly clean it up.
  53 * Operator is not supposed to delete ``default-transport-zone`` from REST, such
  54   scenario will be taken as incorrect configuration.
  55 * Dynamic change in the bridge for tunnel creation via change in Openvswitch table’s
  56   external_ids parameter ``br-name`` is not supported.
  57 * Dynamic change for ``of-tunnel`` tep configuration via change in Openvswitch table’s
  58   external_ids parameter ``of-tunnel`` is not supported.
  59 * Dynamic change for configurable parameters ``def-tz-enabled`` and ``def-tz-tunnel-type``
  60   is not supported.
  61
  62 Proposed change
  63 ===============
  64 ITM will create a default transport zone on OpenDaylight start-up if configurable parameter
  65 ``def-tz-enabled`` is ``true`` in ``genius-itm-config.xml`` file (by default, this flag
  66 is false). When the flag is true, default transport zone is created and configured with:
  67
  68 * Default transport zone will be created with name ``default-transport-zone``.
  69 * Tunnel type: This would be configurable parameter via config file.
  70   ITM will take tunnel type value from config file for ``default-transport-zone``.
  71   Tunnel-type value cannot be changed dynamically. It will take value of
  72   ``def-tz-tunnel-type`` parameter from config file ``genius-itm-config.xml`` on startup.
  73
  74   * If ``def-tz-tunnel-type`` parameter is changed and ``def-tz-enabled`` remains ``true``
  75     during OpenDaylight restart, then ``default-transport-zone`` with previous value of
  76     tunnel-type would be first removed and then ``default-transport-zone`` would be created
  77     with newer value of tunnel-type.
  78
  79 If ``def-tz-enabled`` is configured as ``false``, then ITM will delete ``default-transport-zone``
  80 if it is present already.
  81
  82 When transport-zone is added from northbound i.e. REST interface.
  83 Few of the transport-zone parameters are mandatory and fewer are optional now.
  84
  85 ====================      =======================================================
  86 Status                    Transport zone parameters
  87 ====================      =======================================================
  88 Mandatory                 transport-zone name, tunnel-type
  89
  90 Optional                  TEP IP-Address, Subnet prefix, Dpn-id, Gateway-ip,
  91                           Vlan-id, Portname
  92 ====================      =======================================================
  93
  94 When a new transport zone is created, check for any TEPs if present in
  95 ``tepsNotHostedInTransportZone`` for that transport zone. If present,
  96 remove from ``tepsNotHostedInTransportZone`` and add them under the
  97 transport zone and include the TEP in the tunnel mesh.
  98
  99 ITM will register listeners to the Node of network topology Operational DS
 100 to receive Data Tree Change Notification (DTCN) for add/update/delete notification
 101 in the OVSDB node so that such DTCN can be parsed and changes in the ``external_ids``
 102 for TEP parameters can be determined to perform TEP add/update/delete operations.
 103
 104 **URL:** restconf/operational/network-topology:network-topology/topology/ovsdb:1
 105
 106 **Sample JSON output**
 107
 108 .. code-block:: json
 109    :emphasize-lines: 16,17,20,21,24,25
 110
 111     {
 112       "topology": [
 113         {
 114           "topology-id": "ovsdb:1",
 115           "node": [
 116           {
 117           "node-id": "ovsdb://uuid/83192e6c-488a-4f34-9197-d5a88676f04f",
 118           "ovsdb:db-version": "7.12.1",
 119           "ovsdb:ovs-version": "2.5.0",
 120           "ovsdb:openvswitch-external-ids": [
 121             {
 122               "external-id-key": "system-id",
 123               "external-id-value": "e93a266a-9399-4881-83ff-27094a648e2b"
 124             },
 125             {
 126               "external-id-key": "tep-ip",
 127               "external-id-value": "20.0.0.1"
 128             },
 129             {
 130               "external-id-key": "tzname",
 131               "external-id-value": "TZA"
 132             },
 133             {
 134               "external-id-key": "of-tunnel",
 135               "external-id-value": "true"
 136             }
 137           ],
 138           "ovsdb:datapath-type-entry": [
 139             {
 140               "datapath-type": "ovsdb:datapath-type-system"
 141             },
 142             {
 143               "datapath-type": "ovsdb:datapath-type-netdev"
 144             }
 145           ],
 146           "ovsdb:connection-info": {
 147             "remote-port": 45230,
 148             "local-ip": "10.111.222.10",
 149             "local-port": 6640,
 150             "remote-ip": "10.111.222.20"
 151           }
 152
 153           ...
 154           ...
 155
 156          }
 157         ]
 158        }
 159       ]
 160     }
 161
 162 OVSDB changes
 163 -------------
 164 Below table covers how ITM TEP parameter are mapped with OVSDB and which fields of
 165 OVSDB would provide ITM TEP parameter values.
 166
 167 ====================      ==================================================================
 168 ITM TEP parameter         OVSDB field
 169 ====================      ==================================================================
 170 DPN-ID                    ``ovsdb:datapath-id`` from bridge whose name is pre-configured
 171                           with openvswitch:external_ids:br-name:value
 172
 173 IP-Address                ``openvswitch:external_ids:tep-ip``:value
 174
 175 Transport Zone Name       ``openvswitch:external_ids:tzname``:value
 176
 177 of-tunnel                 ``openvswitch:external_ids:of-tunnel``:value
 178 ====================      ==================================================================
 179
 180 NOTE: If ``openvswitch:external_ids:br-name`` is not configured, then by default
 181 ``br-int`` will be considered to fetch DPN-ID which in turn would be used for
 182 tunnel creation.
 183
 184 MDSALUtil changes
 185 -----------------
 186 ``getDpnId()`` method is added into MDSALUtil.java.
 187
 188 .. code-block:: none
 189    :emphasize-lines: 9
 190
 191     /**
 192      * This method will be utility method to convert bridge datapath ID from
 193      * string format to BigInteger format.
 194      *
 195      * @param datapathId datapath ID of bridge in string format
 196      *
 197      * @return the datapathId datapath ID of bridge in BigInteger format
 198      */
 199     public static BigInteger getDpnId(String datapathId);
 200
 201 Pipeline changes
 202 ----------------
 203 N.A.
 204
 205 Yang changes
 206 ------------
 207 Changes are needed in ``itm.yang`` and ``itm-config.yang`` which are described in
 208 below sub-sections.
 209
 210 itm.yang changes
 211 ^^^^^^^^^^^^^^^^
 212 Following changes are done in ``itm.yang`` file.
 213
 214 1. A new list ``tepsNotHostedInTransportZone`` will be added to container
 215    ``transport-zones`` for storing details of TEP received from southbound
 216    having transport zone which is not yet hosted from northbound.
 217 2. Existing list ``transport-zone`` would be modified for leaf ``zone-name``
 218    and ``tunnel-type`` to make them mandatory parameters.
 219
 220 .. code-block:: none
 221    :caption: itm.yang
 222    :emphasize-lines: 6,12,16-35
 223
 224     list transport-zone {
 225         ordered-by user;
 226         key zone-name;
 227         leaf zone-name {
 228             type string;
 229             mandatory true;
 230         }
 231         leaf tunnel-type {
 232             type identityref {
 233                 base odlif:tunnel-type-base;
 234             }
 235             mandatory true;
 236         }
 237     }
 238
 239     list tepsNotHostedInTransportZone {
 240         key zone-name;
 241         leaf zone-name {
 242             type string;
 243         }
 244         list unknown-vteps {
 245             key "dpn-id";
 246             leaf dpn-id {
 247                 type uint64;
 248             }
 249             leaf ip-address {
 250                 type inet:ip-address;
 251             }
 252             leaf of-tunnel {
 253                 description "Use flow based tunnels for remote-ip";
 254                 type boolean;
 255                 default false;
 256             }
 257         }
 258     }
 259
 260 itm-config.yang changes
 261 ^^^^^^^^^^^^^^^^^^^^^^^
 262
 263 ``itm-config.yang`` file is modified to add new container to contain following parameters
 264 which can be configured in ``genius-itm-config.xml`` on OpenDaylight controller startup.
 265
 266 * ``def-tz-enabled``: this is boolean type parameter which would create or delete
 267   ``default-transport-zone`` if it is configured true or false respectively. By default,
 268   value is ``false``.
 269 * ``def-tz-tunnel-type``: this is string type parameter which would allow user to
 270   configure tunnel-type for ``default-transport-zone``. By default, value is ``vxlan``.
 271
 272 .. code-block:: none
 273    :caption: itm-config.yang
 274    :emphasize-lines: 1-11
 275
 276     container itm-config {
 277        config true;
 278        leaf def-tz-enabled {
 279           type boolean;
 280           default false;
 281        }
 282        leaf def-tz-tunnel-type {
 283           type string;
 284           default "vxlan";
 285        }
 286     }
 287
 288 Workflow
 289 --------
 290
 291 TEP Addition
 292 ^^^^^^^^^^^^
 293 When TEP IP ``external_ids:tep-ip`` and ``external_ids:tzname`` are configured at OVS side
 294 using ``ovs-vsctl`` commands to add TEP, then TEP parameters details are passed to the OVSDB
 295 plugin via OVSDB connection which in turn, is updated into Network Topology Operational DS.
 296 ITM listens for change in Network Topology Node.
 297
 298 When TEP parameters (like ``tep-ip``, ``tzname``, ``br-name``, ``of-tunnel``) are
 299 received in add notification of OVSDB Node, then TEP is added.
 300
 301 For TEP addition, TEP-IP and DPN-ID are mandatory. TEP-IP is obtained from ``tep-ip``
 302 TEP parameter and DPN-ID is fetched from OVSDB node based on ``br-name`` TEP parameter:
 303
 304 * if bridge name is specified, then datapath ID of the specified bridge is fetched.
 305 * if bridge name is not specified, then datapath ID of the ``br-int`` bridge is fetched.
 306
 307 TEP-IP and fetched DPN-ID would be needed to add TEP in the transport-zone.
 308 Once TEP is added in config datastore, transport-zone listener of ITM would
 309 internally take care of creating tunnels on the bridge whose DPN-ID is
 310 passed for TEP addition. It is noted that TEP parameter ``of-tunnel`` would be
 311 checked if it is true, then ``of-tunnel`` flag would be set for vtep to be added
 312 under transport-zone or ``tepsNotHostedInTransportZone``.
 313
 314 TEP would be added under transport zone with following conditions:
 315
 316 * TEPs not configured with ``external_ids:tzname`` i.e. without transport zone will be
 317   placed under the ``default-transport-zone`` if ``def-tz-enabled`` parameter is configured
 318   to true in ``genius-itm-config.xml``. This will fire a DTCN to transport zone yang listener
 319   and ITM tunnels gets built.
 320 * TEPs configured with ``external_ids:tzname`` i.e. with transport zone and
 321   if the specified transport zone exists in the ITM Config DS, then TEP will
 322   be placed under the specified transport zone. This will fire a DTCN to
 323   transport zone yang listener and the ITM tunnels gets built.
 324 * TEPs configured with ``external_ids:tzname`` i.e. with transport zone and
 325   if the specified transport zone does not exist in the ITM Config DS, then
 326   TEP will be placed under the ``tepsNotHostedInTransportZone`` under ITM
 327   config DS.
 328
 329 TEP Movement
 330 ^^^^^^^^^^^^
 331 When transport zone which was not configured earlier, is created through REST, then
 332 it is checked whether any “orphan” TEPs already exists in the ``tepsNotHostedInTransportZone``
 333 for the newly created transport zone, if present, then such TEPs are removed from
 334 ``tepsNotHostedInTransportZone``, and then added under the newly created transport zone
 335 in ITM config DS and then TEPs are added to the tunnel mesh of that transport zone.
 336
 337 TEP Updation
 338 ^^^^^^^^^^^^
 339 * TEP updation for IP address is considered as TEP deletion followed by TEP addition.
 340   Remove existing TEP-IP ``external_ids:tep-ip`` and then add new TEP-IP using ``ovs-vsctl``
 341   commands. TEP with old TEP-IP is deleted and then TEP with new TEP-IP gets added.
 342 * TEP updation for transport zone can be done dynamically. When ``external_ids:tzname``
 343   is updated at OVS side, then such change will be notified to OVSDB plugin via OVSDB
 344   protocol, which in turn is reflected in Network topology Operational DS. ITM gets
 345   DTCN for Node update. Parsing Node update notification for ``external_ids:tzname``
 346   parameter in old and new node can determine change in transport zone for TEP.
 347   If it is updated, then TEP is deleted from old transport zone and added into new
 348   transport zone. This will fire a DTCN to transport zone yang listener and
 349   the ITM tunnels gets updated.
 350
 351 TEP Deletion
 352 ^^^^^^^^^^^^
 353 When an ``openvswitch:external_ids:tep-ip`` parameter gets deleted through *ovs-vsctl*
 354 command, then network topology Operational DS gets updated via OVSB update notification.
 355 ITM which has registered for the network-topology DTCNs, gets notified and this deletes
 356 the TEP from Transport zone or ``tepsNotHostedInTransportZone`` stored in ITM config DS
 357 based on ``external_ids:tzname`` parameter configured for TEP.
 358
 359 * If ``external_ids:tzname`` is configured and corresponding transport zone exists
 360   in Configuration DS, then remove TEP from transport zone. This will fire a DTCN
 361   to transport zone yang listener and the ITM tunnels of that TEP gets deleted.
 362 * If ``external_ids:tzname`` is configured and corresponding transport zone does not
 363   exist in Configuration DS, then check if TEP exists in ``tepsNotHostedInTransportZone``,
 364   if present, then remove TEP from ``tepsNotHostedInTransportZone``.
 365 * If ``external_ids:tzname`` is not configured, then check if TEP exists in the default
 366   transport zone in Configuration DS, if and only if ``def-tz-enabled`` parameter is configured
 367   to true in ``genius-itm-config.xml``. In case, TEP is present, then remove TEP from
 368   ``default-transport-zone``. This will fire a DTCN to transport zone yang listener and
 369   ITM tunnels of that TEP gets deleted.
 370
 371 Configuration impact
 372 ---------------------
 373 Following are the configuation changes and impact in the OpenDaylight.
 374
 375 * ``genius-itm-config.xml`` configuation file is introduced newly into ITM
 376   in which following parameters are added:
 377
 378   * ``def-tz-enabled``: this is boolean type parameter which would create or delete
 379     ``default-transport-zone`` if it is configured true or false respectively. Default
 380     value is ``false``.
 381   * ``def-tz-tunnel-type``: this is string type parameter which would allow user to
 382     configure tunnel-type for ``default-transport-zone``. Default value is ``vxlan``.
 383
 384 .. code-block:: xml
 385    :caption: genius-itm-config.xml
 386
 387     <itm-config xmlns="urn:opendaylight:genius:itm:config">
 388         <def-tz-enabled>false</def-tz-enabled>
 389         <def-tz-tunnel-type>vxlan</def-tz-tunnel-type>
 390     </itm-config>
 391
 392 Runtime changes to the parameters of this config file would not be
 393 taken into consideration.
 394
 395 Clustering considerations
 396 -------------------------
 397 Any clustering requirements are already addressed in ITM, no new requirements added
 398 as part of this feature.
 399
 400 Other Infra considerations
 401 --------------------------
 402 N.A.
 403
 404 Security considerations
 405 -----------------------
 406 N.A.
 407
 408 Scale and Performance Impact
 409 ----------------------------
 410 This feature would not introduce any significant scale and performance issues in the OpenDaylight.
 411
 412 Targeted Release
 413 -----------------
 414 OpenDaylight Carbon
 415
 416 Known Limitations
 417 -----------------
 418 * Dummy Subnet prefix ``255.255.255.255/32`` under transport-zone is used to store the
 419   TEPs listened from southbound.
 420
 421 Alternatives
 422 ------------
 423 N.A.
 424
 425 Usage
 426 =====
 427
 428 Features to Install
 429 -------------------
 430 This feature doesn't add any new karaf feature. This feature would be available in
 431 already existing ``odl-genius`` karaf feature.
 432
 433 REST API
 434 --------
 435 Creating transport zone
 436 ^^^^^^^^^^^^^^^^^^^^^^^
 437
 438 As per this feature, the TEP addition is based on the southbound configuation and
 439 respective transport zone should be created on the controller to form the tunnel
 440 for the same. The REST API to create the transport zone with mandatory parameters.
 441
 442 **URL:** restconf/config/itm:transport-zones/
 443
 444 **Sample JSON data**
 445
 446 .. code-block:: json
 447
 448     {
 449         "transport-zone": [
 450             {
 451                 "zone-name": "TZA",
 452                  "tunnel-type": "odl-interface:tunnel-type-vxlan"
 453             }
 454         ]
 455     }
 456
 457 Retrieving transport zone
 458 ^^^^^^^^^^^^^^^^^^^^^^^^^
 459
 460 To retrieve the TEP configuations from all the transport zones.
 461
 462 **URL:** restconf/config/itm:transport-zones/
 463
 464 **Sample JSON output**
 465
 466 .. code-block:: json
 467
 468     {
 469         "transport-zones": {
 470            "transport-zone": [
 471               {
 472                 "zone-name": "default-transport-zone",
 473                 "tunnel-type": "odl-interface:tunnel-type-vxlan"
 474               },
 475               {
 476                 "zone-name": "TZA",
 477                 "tunnel-type": "odl-interface:tunnel-type-vxlan",
 478                 "subnets": [
 479                   {
 480                     "prefix": "255.255.255.255/32",
 481                     "vteps": [
 482                       {
 483                         "dpn-id": 1,
 484                         "portname": "",
 485                         "ip-address": "10.0.0.1"
 486                       },
 487                       {
 488                         "dpn-id": 2,
 489                         "portname": "",
 490                         "ip-address": "10.0.0.2"
 491                       }
 492                     ],
 493                     "gateway-ip": "0.0.0.0",
 494                     "vlan-id": 0
 495                   }
 496                 ]
 497               }
 498             ]
 499         }
 500     }
 501
 502 CLI
 503 ---
 504 No CLI is added into OpenDaylight for this feature.
 505
 506 OVS CLI
 507 ^^^^^^^
 508 ITM TEP parameters can be added/removed to/from the OVS switch using
 509 the ``ovs-vsctl`` command:
 510
 511 .. code-block:: none
 512   :emphasize-lines: 9,13-16,21,25,26,30
 513
 514   DESCRIPTION
 515     ovs-vsctl
 516     Command for querying and configuring ovs-vswitchd by providing a
 517     high-level interface to its configuration database.
 518     Here, this command usage is shown to store TEP parameters into
 519     ``openvswitch`` table of OVS database.
 520
 521   SYNTAX
 522     ovs-vsctl  set O . [column]:[key]=[value]
 523
 524   * To set TEP params on OVS table:
 525
 526   ovs-vsctl    set O . external_ids:tep-ip=192.168.56.102
 527   ovs-vsctl    set O . external_ids:tzname=TZA
 528   ovs-vsctl    set O . external_ids:br-name=br0
 529   ovs-vsctl    set O . external_ids:of-tunnel=true
 530
 531   * To clear TEP params in one go by clearing external_ids column from
 532     OVS table:
 533
 534   ovs-vsctl clear O . external_ids
 535
 536   * To clear specific TEP paramter from external_ids column in OVS table:
 537
 538   ovs-vsctl remove O . external_ids tep-ip
 539   ovs-vsctl remove O . external_ids tzname
 540
 541   * To check TEP params are set or cleared on OVS table:
 542
 543   ovsdb-client dump -f list  Open_vSwitch
 544
 545 Implementation
 546 ==============
 547
 548 Assignee(s)
 549 -----------
 550
 551 Primary assignee:
 552
 553 * Tarun Thakur
 554
 555 Other contributors:
 556
 557 * Sathish Kumar B T
 558 * Nishchya Gupta
 559 * Jogeswar Reddy
 560
 561 Work Items
 562 ----------
 563 #. YANG changes
 564 #. Add code to create xml config file for ITM to configure flag which would control
 565    creation of ``default-transport-zone`` during bootup and configure ``tunnel-type`` for
 566    default transport zone.
 567 #. Add code to handle changes in the ``def-tz-enabled`` configurable parameter during
 568    OpenDaylight restart.
 569 #. Add code to handle changes in the ``def-tz-tunnel-type`` configurable parameter during
 570    OpenDaylight restart.
 571 #. Add code to create listener for OVSDB to receive TEP-specific
 572    parameters configured at OVS.
 573 #. Add code to update configuation datastore to add/delete TEP received from
 574    southbound into transport-zone.
 575 #. Check tunnel mesh for transport-zone is updated correctly for TEP
 576    add/delete into transport-zone.
 577 #. Add code to update configuation datastore for handling update in TEP-IP.
 578 #. Add code to update configuation datastore for handling update in TEP's transport-zone.
 579 #. Check tunnel mesh is updated correctly against TEP update.
 580 #. Add code to create ``tepsNotHostedInTransportZone`` list in configuation datastore to
 581    store TEP received with not-configured transport-zone.
 582 #. Add code to move TEP from ``tepsNotHostedInTransportZone`` list to transport-zone
 583    configured from REST.
 584 #. Check tunnel mesh is formed for TEPs after their movement from ``tepsNotHostedInTransportZone``
 585    list to transport-zone.
 586 #. Add UTs.
 587 #. Add ITs.
 588 #. Add CSIT.
 589 #. Add Documentation.
 590
 591 Dependencies
 592 ============
 593 This feature should be used when configuration flag i.e. ``use-transport-zone`` in
 594 ``netvirt-neutronvpn-config.xml`` for automatic tunnel configuration in transport-zone
 595 is disabled in Netvirt's NeutronVpn, otherwise netvirt feature of dynamic tunnel creation
 596 may duplicate tunnel for TEPs in the tunnel mesh.
 597
 598 Testing
 599 =======
 600
 601 Unit Tests
 602 ----------
 603 Appropriate UTs will be added for the new code coming in, once UT framework is in place.
 604
 605 Integration Tests
 606 -----------------
 607 Integration tests will be added, once IT framework for ITM is ready.
 608
 609 CSIT
 610 ----
 611 Following test cases will need to be added/expanded in Genius CSIT:
 612
 613 #. Verify ``default-transport-zone`` is not created when ``def-tz-enabled`` flag is false.
 614 #. Verify tunnel-type change is considered while creation of ``default-transport-zone``.
 615 #. Verify ITM tunnel creation on default-transport-zone when TEPs are configured without
 616    transport zone or with ``default-transport-zone`` on switch when ``def-tz-enabled``
 617    flag is true.
 618 #. Verify ``default-transport-zone`` is deleted when ``def-tz-enabled flag`` is changed from
 619    true to false during OpenDaylight controller restart.
 620 #. Verify ITM tunnel creation by TEPs configured with transport zone on switch and
 621    respective transport zone should be pre-configured on OpenDaylight controller.
 622 #. Verify auto-mapping of TEPs to corresponding transport zone group.
 623 #. Verify ITM tunnel deletion by deleting TEP from switch.
 624 #. Verify TEP transport zone change from OVS will move the TEP to corresponding
 625    transport-zone in OpenDaylight controller.
 626 #. Verify TEPs movement from ``tepsNotHostedInTransportZone`` to transport-zone when
 627    transport-zone is configured from northbound.
 628 #. Verify ITM tunnel details persist after OpenDaylight controller restart, switch restart.
 629
 630 Documentation Impact
 631 ====================
 632 This will require changes to User Guide and Developer Guide.
 633
 634 User Guide will need to add information for below details:
 635
 636 * TEPs parameters to be configured from OVS side to use this feature.
 637 * TEPs added from southbound can be viewed from REST APIs.
 638 * TEPs added from southbound will be added under dummy subnet (255.255.255.255/32) in
 639   transport-zone.
 640 * Usage details of genius-itm-config.xml config file for ITM to configure ``def-tz-enabled``
 641   flag and ``def-tz-tunnel-type`` to create/delete ``default-transport-zone`` and its
 642   ``tunnel-type`` respectively.
 643 * User is explicitly required to configure ``def-tz-enabled`` as true if TEPs needed to be
 644   added into ``default-transport-zone`` from northbound.
 645
 646 Developer Guide will need to capture how to use changes in ITM to create
 647 tunnel automatically for TEPs configured from southbound.
 648
 649 References
 650 ==========
 651 * `Genius: Carbon Release Plan <https://wiki.opendaylight.org/view/Genius:Carbon_Release_Plan>`_