ITM Tunnel Auto-Configuration¶

Use Cases¶

This feature will support following use cases:

• Use case 1: Add tep to existing transport-zone from southbound interface(SBI).
• Use case 2: Delete tep from SBI.
• Use case 3: Move the tep from one transport zone to another from SBI.
• Use case 4: User can specify the Datapath Node (DPN) bridge for tep other than br-int from SBI.
• Use case 5: Allow user to configure a tep from SBI if they want to use flow based tunnels.
• Use case 6: TEP-IP, Port, vlan, subnet, gateway IP are optional parameters for creating a transport zone from REST.
• Use case 7: User must configure Transport zone name and tunnel type parameters while creating a transport zone from REST, as both are mandatory parameters.
• Use case 8: Store teps received on OVS connect for transport-zone which is not yet created and also allow to move such teps into transport-zone when it gets created from northbound.
• Use case 9: Allow user to control creation of default transport zone through start-up configurable parameter def-tz-enabled in config file.
• Use case 10: Tunnel-type for default transport zone should be configurable through configurable parameter def-tz-tunnel-type in config file.
• Use case 11: Allow user to change def-tz-enabled configurable parameter from OFF to ON during OpenDaylight controller restart.
• Use case 12: Allow user to change def-tz-enabled configurable parameter from ON to OFF during OpenDaylight controller restart.
• Use case 13: Default value for configurable parameter def-tz-enabled is OFF and if it is not changed by user, then it will be OFF after OpenDaylight controller restart as well.

Following use cases will not be supported:

• If a switch gets disconnected, the corresponding TEP entries will not get cleared off from the ITM config datastore (DS) and operator must explicitly clean it up.
• Operator is not supposed to delete default-transport-zone from REST, such scenario will be taken as incorrect configuration.
• Dynamic change in the bridge for tunnel creation via change in Openvswitch table’s external_ids parameter br-name is not supported.
• Dynamic change for of-tunnel tep configuration via change in Openvswitch table’s external_ids parameter of-tunnel is not supported.
• Dynamic change for configurable parameters def-tz-enabled and def-tz-tunnel-type is not supported.

OVSDB changes¶

Below table covers how ITM TEP parameter are mapped with OVSDB and which fields of OVSDB would provide ITM TEP parameter values.

NOTE: If openvswitch:external_ids:br-name is not configured, then by default br-int will be considered to fetch DPN-ID which in turn would be used for tunnel creation.

MDSALUtil changes¶

getDpnId() method is added into MDSALUtil.java.

 /**
  * This method will be utility method to convert bridge datapath ID from
  * string format to BigInteger format.
  *
  * @param datapathId datapath ID of bridge in string format
  *
  * @return the datapathId datapath ID of bridge in BigInteger format
  */
 public static BigInteger getDpnId(String datapathId);

Pipeline changes¶

N.A.

Yang changes¶

Changes are needed in itm.yang and itm-config.yang which are described in below sub-sections.

 list transport-zone {
     ordered-by user;
     key zone-name;
     leaf zone-name {
         type string;
         mandatory true;
     }
     leaf tunnel-type {
         type identityref {
             base odlif:tunnel-type-base;
         }
         mandatory true;
     }
 }

 list tepsNotHostedInTransportZone {
     key zone-name;
     leaf zone-name {
         type string;
     }
     list unknown-vteps {
         key "dpn-id";
         leaf dpn-id {
             type uint64;
         }
         leaf ip-address {
             type inet:ip-address;
         }
         leaf of-tunnel {
             description "Use flow based tunnels for remote-ip";
             type boolean;
             default false;
         }
     }
 }

 container itm-config {
    config true;
    leaf def-tz-enabled {
       type boolean;
       default false;
    }
    leaf def-tz-tunnel-type {
       type string;
       default "vxlan";
    }
 }

Workflow¶

Configuration impact¶

Following are the configuation changes and impact in the OpenDaylight.

• genius-itm-config.xml configuation file is introduced newly into ITM in which following parameters are added:
  • def-tz-enabled: this is boolean type parameter which would create or delete default-transport-zone if it is configured true or false respectively. Default value is false.
  • def-tz-tunnel-type: this is string type parameter which would allow user to configure tunnel-type for default-transport-zone. Default value is vxlan.

 <itm-config xmlns="urn:opendaylight:genius:itm:config">
     <def-tz-enabled>false</def-tz-enabled>
     <def-tz-tunnel-type>vxlan</def-tz-tunnel-type>
 </itm-config>

Runtime changes to the parameters of this config file would not be taken into consideration.

Clustering considerations¶

Any clustering requirements are already addressed in ITM, no new requirements added as part of this feature.

Other Infra considerations¶

N.A.

Security considerations¶

N.A.

Scale and Performance Impact¶

This feature would not introduce any significant scale and performance issues in the OpenDaylight.

Targeted Release¶

OpenDaylight Carbon

Known Limitations¶

• Dummy Subnet prefix 255.255.255.255/32 under transport-zone is used to store the TEPs listened from southbound.

Alternatives¶

N.A.

Features to Install¶

This feature doesn’t add any new karaf feature. This feature would be available in already existing odl-genius karaf feature.

REST API¶

{
    "transport-zone": [
        {
            "zone-name": "TZA",
             "tunnel-type": "odl-interface:tunnel-type-vxlan"
        }
    ]
}

{
    "transport-zones": {
       "transport-zone": [
          {
            "zone-name": "default-transport-zone",
            "tunnel-type": "odl-interface:tunnel-type-vxlan"
          },
          {
            "zone-name": "TZA",
            "tunnel-type": "odl-interface:tunnel-type-vxlan",
            "subnets": [
              {
                "prefix": "255.255.255.255/32",
                "vteps": [
                  {
                    "dpn-id": 1,
                    "portname": "",
                    "ip-address": "10.0.0.1"
                  },
                  {
                    "dpn-id": 2,
                    "portname": "",
                    "ip-address": "10.0.0.2"
                  }
                ],
                "gateway-ip": "0.0.0.0",
                "vlan-id": 0
              }
            ]
          }
        ]
    }
}

CLI¶

No CLI is added into OpenDaylight for this feature.

DESCRIPTION
  ovs-vsctl
  Command for querying and configuring ovs-vswitchd by providing a
  high-level interface to its configuration database.
  Here, this command usage is shown to store TEP parameters into
  ``openvswitch`` table of OVS database.

SYNTAX
  ovs-vsctl  set O . [column]:[key]=[value]

* To set TEP params on OVS table:

ovs-vsctl    set O . external_ids:tep-ip=192.168.56.102
ovs-vsctl    set O . external_ids:tzname=TZA
ovs-vsctl    set O . external_ids:br-name=br0
ovs-vsctl    set O . external_ids:of-tunnel=true

* To clear TEP params in one go by clearing external_ids column from
  OVS table:

ovs-vsctl clear O . external_ids

* To clear specific TEP paramter from external_ids column in OVS table:

ovs-vsctl remove O . external_ids tep-ip
ovs-vsctl remove O . external_ids tzname

* To check TEP params are set or cleared on OVS table:

ovsdb-client dump -f list  Open_vSwitch

Assignee(s)¶

Primary assignee:

• Tarun Thakur

Other contributors:

• Sathish Kumar B T
• Nishchya Gupta
• Jogeswar Reddy

Work Items¶

1. YANG changes
2. Add code to create xml config file for ITM to configure flag which would control creation of default-transport-zone during bootup and configure tunnel-type for default transport zone.
3. Add code to handle changes in the def-tz-enabled configurable parameter during OpenDaylight restart.
4. Add code to handle changes in the def-tz-tunnel-type configurable parameter during OpenDaylight restart.
5. Add code to create listener for OVSDB to receive TEP-specific parameters configured at OVS.
6. Add code to update configuation datastore to add/delete TEP received from southbound into transport-zone.
7. Check tunnel mesh for transport-zone is updated correctly for TEP add/delete into transport-zone.
8. Add code to update configuation datastore for handling update in TEP-IP.
9. Add code to update configuation datastore for handling update in TEP’s transport-zone.
10. Check tunnel mesh is updated correctly against TEP update.
11. Add code to create tepsNotHostedInTransportZone list in configuation datastore to store TEP received with not-configured transport-zone.
12. Add code to move TEP from tepsNotHostedInTransportZone list to transport-zone configured from REST.
13. Check tunnel mesh is formed for TEPs after their movement from tepsNotHostedInTransportZone list to transport-zone.
14. Add UTs.
15. Add ITs.
16. Add CSIT.
17. Add Documentation.

Unit Tests¶

Appropriate UTs will be added for the new code coming in, once UT framework is in place.

Integration Tests¶

Integration tests will be added, once IT framework for ITM is ready.

CSIT¶

Following test cases will need to be added/expanded in Genius CSIT:

1. Verify default-transport-zone is not created when def-tz-enabled flag is false.
2. Verify tunnel-type change is considered while creation of default-transport-zone.
3. Verify ITM tunnel creation on default-transport-zone when TEPs are configured without transport zone or with default-transport-zone on switch when def-tz-enabled flag is true.
4. Verify default-transport-zone is deleted when def-tz-enabled flag is changed from true to false during OpenDaylight controller restart.
5. Verify ITM tunnel creation by TEPs configured with transport zone on switch and respective transport zone should be pre-configured on OpenDaylight controller.
6. Verify auto-mapping of TEPs to corresponding transport zone group.
7. Verify ITM tunnel deletion by deleting TEP from switch.
8. Verify TEP transport zone change from OVS will move the TEP to corresponding transport-zone in OpenDaylight controller.
9. Verify TEPs movement from tepsNotHostedInTransportZone to transport-zone when transport-zone is configured from northbound.
10. Verify ITM tunnel details persist after OpenDaylight controller restart, switch restart.