Genius Documentation¶

Use Cases¶

Use cases addressed by this feature.

Pipeline changes¶

Any changes to pipeline must be captured explicitly in this section.

Yang changes¶

This should detail any changes to yang models.

Configuration impact¶

Any configuration parameters being added/deprecated for this feature? What will be defaults for these? How will it impact existing deployments?

Note that outright deletion/modification of existing configuration is not allowed due to backward compatibility. They can only be deprecated and deleted in later release(s).

Clustering considerations¶

This should capture how clustering will be supported. This can include but not limited to use of CDTCL, EOS, Cluster Singleton etc.

Other Infra considerations¶

This should capture impact from/to different infra components like MDSAL Datastore, karaf, AAA etc.

Security considerations¶

Document any security related issues impacted by this feature.

Scale and Performance Impact¶

What are the potential scale and performance impacts of this change? Does it help improve scale and performance or make it worse?

Targeted Release¶

What release is this feature targeted for?

Alternatives¶

Alternatives considered and why they were not selected.

Features to Install¶

odl-genius-ui

Identify existing karaf feature to which this change applies and/or new karaf features being introduced. These can be user facing features which are added to integration/distribution or internal features to be used by other projects.

REST API¶

Sample JSONS/URIs. These will be an offshoot of yang changes. Capture these for User Guide, CSIT, etc.

CLI¶

Any CLI if being added.

Assignee(s)¶

Who is implementing this feature? In case of multiple authors, designate a primary assignee and other contributors.

Primary assignee:

<developer-a>

Other contributors:

<developer-b> <developer-c>

Work Items¶

Break up work into individual items. This should be a checklist on Trello card for this feature. Give link to trello card or duplicate it.

Unit Tests¶

Integration Tests¶

CSIT¶

Use Cases¶

This feature will support the following use cases.

• Use case 1: ITM will create a full tunnel mesh when it receives the configuration from NBI. Tunnel ports or OF based tunnels will be created on the switches directly by ITM, by-passing interface manager.
• Use case 2: ITM will support a config parameter which can be used to select the old or the new way of tunnel mesh creation. Changing this flag dynamically after configuration will not be supported. If one needs to switch the implementation, then the controller needs to be restarted.
• Use case 3: ITM will detect the tunnel state changes and publish it to the applications.
• Use case 4: ITM will provide the tunnel egress actions irrespective of the presence of tunnel in the dataplane.
• Use case 5: ITM will support a config parameter to enable/disable monitoring on a per tunnel basis
• Use case 6: ITM will support BFD event dampening during initial BFD config.
• Use Case 7: ITM will support a config parameter to turn ON/OFF the alarm generation based on tunnel status.
• Use case 8: ITM will support traffic switch over in dataplane based on the tunnel state.
• Use case 9: ITM will cache appropriate MDSAL data to further improve the performance.

Pipeline changes¶

Pipeline will change as the egress action will be pointing to a group instead of output on port

• ITM will install Tunnel Ingress Table Table 0. Match on in_port and goto INTERNAL_TUNNEL_TABLE or L3_LFIB_TABLE. Metadata will contain LPort tag cookie=0x8000001, duration=6627.550s, table=0, n_packets=1115992, n_bytes=72424591, priority=5,in_port=6 actions=write_metadata:0x199f0000000001/0x1fffff0000000001,goto_table:36 cookie=0x8000001, duration=6627.545s, table=0, n_packets=280701, n_bytes=19148626, priority=5,in_port=7 actions=write_metadata:0x19e90000000001/0x1fffff0000000001,goto_table:20
• ITM will create group-id for each (destination) DPN and install the group on all other DPNs to reach this destination DPN.
• ITM will update the group with watch-port as the tunnel openflow port. group_id=800000,type=ff, bucket=weight:100,watch_port=5,actions=output:5
• ITM will program Table 220 with match on Lport Tag and output: [group id]
• ITM will provide the RPC get-Egress-Action-For-Interface with the following actions, – set Tunnel Id – Load Reg6 (with IfIndex) – Resubmit to Table 220

Yang changes¶

A new container dpn-teps-state will be added. This will be a config DS

                     list dpns-teps {

                       key "source-dpn-id";

                       leaf source-dpn-id {
                                type uint64;
                       }
                       leaf tunnel-type {
                           type identityref {
                              base odlif:tunnel-type-base;
                           }
                       }
                       leaf group-id {
                           type uint32;
                       }

                       /* Remote DPNs to which this DPN-Tep has a tunnel */
                       list remote-dpns {

                            key "destination-dpn-id";

                              leaf destination-dpn-id {
                                 type uint64;
                              }
                              leaf tunnel-name {
                                  type string;
                              }
                              leaf monitor-enabled { // Will be enhanced to support monitor id.
                                   type boolean;
                                   default true;
                              }
                          }
                      }
 }

 A new Yang ''odl-itm-meta.yang'' will be create to store OVS bridge related information.

 container bridge-tunnel-info {
         description "Contains the list of dpns along with the tunnel interfaces configured on them.";

         list ovs-bridge-entry {
             key dpid;
             leaf dpid {
                 type uint64;
             }

             leaf ovs-bridge-reference {
                 type southbound:ovsdb-bridge-ref;
                 description "This is the reference to an ovs bridge";
             }
             list ovs-bridge-tunnel-entry {
                 key tunnel-name;
                 leaf tunnel-name {
                     type string;
                 }
             }
         }
     }

     container ovs-bridge-ref-info {
         config false;
         description "The container that maps dpid with ovs bridge ref in the operational DS.";

         list ovs-bridge-ref-entry {
             key dpid;
             leaf dpid {
                 type uint64;
             }

             leaf ovs-bridge-reference {
                 type southbound:ovsdb-bridge-ref;
                 description "This is the reference to an ovs bridge";
             }
         }
     }

     container if-indexes-tunnel-map {
            config false;
            list if-index-tunnel {
                key if-index;
                leaf if-index {
                    type int32;
                }
                leaf interface-name {
                    type string;
                }
            }
    }

     New config parameters to be added to ``interfacemanager-config``

 New config parameters to be added to ``itm-config``

The RPC call itm-rpc:get-egress-action will return the group Id which will point to tunnel port (when the tunnel port is created on the switch) between the source and destination dpn id.

     rpc get-egress-action {
         input {
              leaf source-dpid {
                   type uint64;
              }

              leaf destination-dpid {
                   type uint64;
              }

              leaf tunnel-type {
                  type identityref {
                       base odlif:tunnel-type-base;
                  }
              }
        }

        output {
             leaf group-id {
                  type uint32;
             }
        }
     }

ITM will also support another RPC ``get-tunnel-type``

 rpc get-tunnel-type {
          description "to get the type of the tunnel interface(vxlan, vxlan-gpe, gre, etc.)";
              input {
                  leaf intf-name {
                      type string;
                  }
              }
              output {
                  leaf tunnel-type {
                      type identityref {
                          base odlif:tunnel-type-base;
                      }
              }
          }
 }

For the two above RPCs, when this feature is enabled ITM will service the two RPCs for internal tunnels and for the external tunnels, ITM will forward it to interfacemanager. When this feature is disabled, ITM will forward the RPCs for both internal and external to interfacemanager. Applications should now start using the above two RPCs from ITM and not interfacemanager.

ITM will enhance the existing RPCs create-terminating-service-actions and remove-terminating-service-actions.

New RPC will be supported by ITM to enable monitoring of individual tunnels - internal or external.

 rpc set-bfd-enable-on-tunnel {
        description "used for turning ON/OFF to monitor individual tunnels";
        input {
            leaf source-node {
               type string;
            }
            leaf destination-node {
               type string;
            }
            leaf monitoring-params {
               type itmcfg:tunnel-monitor-params;
            }
        }
 }

Configuration impact¶

Following are the configuration changes and impact in the OpenDaylight.

• Following parameter is added to the genius-interfacemanager-config.xml:
• itm-direct-tunnels: this is boolean type parameter which enables or disables the new ITM realization of the tunnel mesh. Default value is false.
• Following parameters are added to the genius-itm-config.xml:
  • alarm-generation-enabled: this is boolean type parameter which enables or disables the new generation of alarms by ITM. Default value is true.
  • bfd-dampening-timeout: timeout in seconds. Config parameter which the dampening logic will use

           <interfacemanager-config xmlns="urn:opendaylight:genius:itm:config">
               <itm-direct-tunnels>false</itm-direct-tunnels>
           </interfacemanager-config>

     <itm-config xmlns="urn:opendaylight:genius:itm:config">
         <alarm-generation-enabled>true</alarm-generation-enabled>
         <bfd-dampening-timeout>30</bfd-dampening-timeout> -- value in seconds. Whats the ideal default value ?
     </itm-config>

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

Clustering considerations¶

The solution is supported on a 3-node cluster.

Upgrade Support¶

Upgrading ODL versions from the previous ITM tunnel mesh creation logic to this new tunnel mesh creation logic will be supported. When the itm-direct-tunnels flag changes from disable from previous version to enable in this version, ITM will automatically mesh tunnels in the new way and clean up any data that was persisted in the previous tunnel creation method.

Other Infra considerations¶

N.A.

Security considerations¶

N.A.

Scale and Performance Impact¶

This solution will improve scale numbers by reducing no. of interfaces created in ietf-interfaces and this will cut down on the additional processing done by interface manager. This feature will provide fine granularity in bfd monitoring per tunnels. This should considerably reduce the number bfd events generated for all the tunnels, instead monitoring only those tunnels that are required. Overall this should improve the ITM performance and scale numbers.

Targeted Release¶

Oxygen

Alternatives¶

N.A

Features to Install¶

This feature doesn’t add any new karaf feature.Installing any of the below features can enable the service:

odl-genius-rest odl-genius

REST API¶

     <interfacemanager-config xmlns="urn:opendaylight:genius:interface:config">
         <itm-direct-tunnels>true</itm-direct-tunnels>
     </interfacemanager-config>

{
 "transport-zone": [
     {
         "zone-name": "TZA",
         "subnets": [
             {
                 "prefix": "192.168.56.0/24",
                 "vlan-id": 0,
                 "vteps": [
                     {
                         "dpn-id": "1",
                         "portname": "eth2",
                         "ip-address": "192.168.56.101",
                     },
                     {
                         "dpn-id": "2",
                         "portname": "eth2",
                         "ip-address": "192.168.56.102",
                     }
                 ],
                 "gateway-ip": "0.0.0.0"
             }
         ],
         "tunnel-type": "odl-interface:tunnel-type-vxlan"
     }
 ]
}

CLI¶

This feature will not add any new CLI for configuration. Some debug CLIs to dump the cache information may be added for debugging purpose.

Assignee(s)¶

Primary assignee:

<Hema Gopalakrishnan>

Work Items¶

Trello card:

• Add support for the configuration parameter itm-direct-tunnels.
• Implement listeners for Topology Operational DS for OvsdbBridgeAugmentation.
• Implement listeners to Inventory Operational DS for FlowCapableNodeConnector.
• Implement support for creation / deletion of tunnel ports
• Implement support for installing / removal of Ingress flows
• Implement API/caches to access bridge-interface-info, bridge-ref-info from odl-itm-meta.yang.
• Add support for the config parameter alarm-generation-enabled.
• Implement the dampening logic for bfd states.
• Add support to populate the new data store dpn-teps-state in itm-state.yang.
• Add support for getting group id from ID Manager for each DPN and install it on all other switches.
• Add support to update the group with the tunnel port when OfPort add DCN is received.
• Add support for RPC - getEgressAction, getTunnelType, set-bfd-enable-on-tunnel.
• Enhance the existing createTerminationServiceActions and removeTerminatingServiceActions
• Add caches whereever required - this includes adding data to cache, cleaning them up, CLIs to dump the cache.
• Add support for upgrade from previous tunnel creation way to this new way of tunnel creation.

The following work items will be taken up later

• Add support for OF Tunnel based implementation.
• Removal of dependency on DPN Id for Tunnel mesh creation.

Unit Tests¶

Appropriate UTs will be added for the new code coming in for this feature. This includes but not limited to :-

1. Add ITM configuration enabling this new feature, configure two TEPs and check if the tunnels are created. Check ietf interfaces to verify that interface manager is bypassed, check if groups are created on the switch.
2. Delete the TEPs and verify if the tunnels are deleted appropriately.
3. Toggle the alarm-generation-enabled and check if the alarm were generated / supressed based on the flag.
4. Enable monitoring on a specific tunnel and make the tunnel down on the dataplane and verify if the tunnel status is reflected correctly on the controller.

Integration Tests¶

1. Configure ITM to build a larger tunnel mesh and check * if the tunnels are created correctly, * the tunnels are UP * the time taken to create the tunnel mesh * the tunnels come back up correctly after controller restart.
2. Increase the number of configured DPNs and find out the maximum configurable DPNs for which the tunnel mesh works properly.

CSIT¶

The following test cases will be added to genius CSIT.

1. Add ITM configuration enabling this new feature, configure two TEPs and check if the tunnels are created. Check ietf interfaces to verify that interface manager is bypassed,,check if groups are created on the switch.
2. Delete the TEPs and verify if the tunnels are deleted appropriately.
3. Toggle the alarm-generation-enabled and check if the alarm were generated / supressed based on the flag.
4. Enable monitoring on a specfic tunnel and make the tunnel down on the dataplane and verify if the tunnel status is reflected correctly on the controller.

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.
• Use case 14: Allow dynamic change for local_ip tep configuration via change in Openvswitch table’s other_config parameter local_ip.

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 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. Also, openvswitch:external_ids:of-tunnel is not required to be configured, and will default to false, as described below in Yang changes section.

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;
     }
 }

 container not-hosted-transport-zones {
     config false;
     list tepsInNotHostedTransportZone {
         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 . other_config:local_ip=192.168.56.102
ovs-vsctl    set O . external_ids:transport-zone=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 and other_config
  column from OVS table:

ovs-vsctl clear O . external_ids
ovs-vsctl clear O . other_config

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

ovs-vsctl remove O . other_config local_ip
ovs-vsctl remove O . external_ids transport-zone

* 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 tepsInNotHostedTransportZone list in operational datastore to store TEP received with transport-zone not-configured from northbound.
12. Add code to move TEP from tepsInNotHostedTransportZone list to transport-zone configured from REST.
13. Check tunnel mesh is formed for TEPs after their movement from tepsInNotHostedTransportZone 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 tepsInNotHostedTransportZone to transport-zone when transport-zone is configured from northbound.
10. Verify local_ip dynamic update is possible and corresponding tunnels are also updated.
11. Verify ITM tunnel details persist after OpenDaylight controller restart, switch restart.

Use Cases¶

• Forwarding of VxLAN traffic between hypervisors with multiple network cards connected to L2 switches in different networks.
• Forwarding of VxLAN traffic between hypervisors with multiple network cards connected to the same L2 switch.

ITM Changes¶

The ITM will continue to create tunnels based on transport-zone configuration similarly to the current implementation - TEP IP per DPN per transport zone. When ITM creates TEP interfaces, in addition to creating the actual tunnels, it will create logical tunnel interface for each pair of DPNs in the ietf-interface config data-store representing the tunnel aggregation group between the DPNs. The logical tunnel interface be created only when the first tunnel interface on each OVS is created. In addition, this feature will be guarded by a global configuration option in the ITM and will be turned off by default. Only when the feature is enabled, the logical tunnel interfaces will be created.

Creation of transport-zone with multiple IPs per DPN is out of the scope of this document and will be described in [2] However, the limitation of configuring no more than one TEP ip per transport zone will remain.

The logical tunnel will reference all member tunnel interfaces in the group using interface-child-info model. In addition, it would be possible to add weight to each member of the group to support unequal load-sharing of traffic.

The proposed feature depends on egress tunnel service binding functionality detailed in [3].

When the logical tunnel interface is created, a default egress service would be bound to it. The egress service will create an OF select group based on the actual list of tunnel members in the logical group. Each tunnel member can be assigned a weight field that will be applied on it’s corresponding bucket in the OF select group. If weight was not defined, the bucket weight will be configured with a default value of 1 resulting in uniform distribution if weight was not configured for any of the buckets. Each bucket in the select group will route the egress traffic to one of the tunnel members in the group by loading the lport-tag of the tunnel member interface to NXM register6.

Logical tunnel egress service pipeline example:

cookie=0x6900000, duration=0.802s, table=220, n_packets=0, n_bytes=0, priority=6,reg6=0x500
actions=load:0xe000500->NXM_NX_REG6[],write_metadata:0xe000500000000000/0xfffffffffffffffe,group:80000
cookie=0x8000007, duration=0.546s, table=220, n_packets=0, n_bytes=0, priority=7,reg6=0x600 actions=output:3
cookie=0x8000007, duration=0.546s, table=220, n_packets=0, n_bytes=0, priority=7,reg6=0x700 actions=output:4
cookie=0x8000007, duration=0.546s, table=220, n_packets=0, n_bytes=0, priority=7,reg6=0x800 actions=output:5
group_id=800000,type=select,
bucket=weight:50,watch_port=3,actions=load:0x600->NXM_NX_REG6[],resubmit(,220),
bucket=weight:25,watch_port=4,actions=load:0x700->NXM_NX_REG6[],resubmit(,220),
bucket=weight:25,watch_port=5,actions=load:0x800->NXM_NX_REG6[],resubmit(,220)

Each bucket of the LB group will set the watch_port property to be the tunnel member OF port number. This will allow the OVS to monitor the bucket liveness and route egress traffic only to live buckets.

BFD monitoring is required to probe the tunnel state and update the OF select group accordingly. Using OF tunnels [4] or turning off BFD monitoring will not allow the logical group service to respond to tunnel state changes.

OF select group for logical tunnel can contain a mix of IPv4 and IPv6 tunnels, depending on the transport-zone configuration.

A new pool will be allocated to generate OF group ids of the default select group and the policy groups described in [2]. The pool name VXLAN_GROUP_POOL will allocate ids from the id-manager in the range 300,000-310,000. ITM RPC calls to get internal tunnel interface between source and destination DPNs will return the logical tunnel interface group name if such exits, otherwise the lower layer tunnel will be returned.

IFM Changes¶

The logical tunnel group is an ietf-interface thus it has an allocated lport-tag. RPC call to getEgressActionsForInterface for the logical tunnel will load register6 with its corresponding lport-tag and resubmit the traffic to the egress dispatcher table.

The state of the logical tunnel group is affected by the states of the group members. If at least one of the tunnels is in oper-status UP, the logical group is considered UP.

If the logical tunnel was set as admin-status DOWN, all the tunnel members will be set accordingly.

Ingress traffic from VxLAN tunnels would not be bounded to any logical group service as part of this feature and it will continue to use the same workflow while traversing the ingress services pipeline.

Other applications would be able to utilize this infrastructure to introduce new services over logical tunnel group interface e.g. policy-based path selection. These services will take precedence over the default egress service for logical tunnel.

Netvirt Changes¶

L3 models map each combination of VRF id and destination prefix to a list of nexthop ip addresses. When calling getInternalOrExternalInterfaceName RPC from the FIB manager, if the DPN id of the remote nexthop is known it will be sent along with the nexthop ip. If logical tunnel exists between the source and destination DPNs it will be set as the lport-tag of register6 in the remote nexthop actions.

Pipeline changes¶

For the flows below it is assumed that a logical tunnel group was configured for both ingress and egress DPNs. The logical tunnel group is composed of { tunnnel1, tunnel2 } and bound to the default logical tunnel egress service.

Yang changes¶

The following changes would be required to support configuration of logical tunnel group:

identity tunnel-type-logical-group {
    description "Aggregation of multiple tunnel endpoints between two DPNs";
    base tunnel-type-base;
}

 grouping tunnel-optional-params {
     leaf tunnel-source-ip-flow {
         type boolean;
         default false;
     }

     leaf tunnel-remote-ip-flow {
         type boolean;
         default false;
     }

     leaf weight {
        type uint16;
     }

     ...
 }

 list vteps {
      key "dpn-id portname";
      leaf dpn-id {
          type uint64;
      }

      leaf portname {
           type string;
      }

      leaf ip-address {
           type inet:ip-address;
      }

      leaf weight {
           type unit16;
           default 1;
      }

      leaf option-of-tunnel {
           type boolean;
           default false;
      }
 }

container tunnel-list {
    list internal-tunnel {
        key "source-DPN destination-DPN transport-type";
        leaf source-DPN {
            type uint64;
        }

        leaf destination-DPN {
            type uint64;
        }

        leaf transport-type {
            type identityref {
                base odlif:tunnel-type-base;
            }
        }

        leaf-list tunnel-interface-name {
             type string;
        }
    }
}

 rpc get-internal-or-external-interface-name {
     input {
          leaf source-dpid {
               type uint64;
          }

          leaf destination-dpid {
               type uint64;
          }

          leaf destination-ip {
               type inet:ip-address;
          }

          leaf tunnel-type {
              type identityref {
                   base odlif:tunnel-type-base;
              }
          }
    }

    output {
         leaf interface-name {
              type string;
         }
    }
 }

Configuration impact¶

Creation of logical tunnel group will be guarded by configuration in itm-config per tunnel-type

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

    leaf def-tz-tunnel-type {
       type string;
       default "vxlan";
    }

    list tunnel-aggregation {
       key "tunnel-type";
       leaf tunnel-type {
           type string;
       }

       leaf enabled {
           type boolean;
           default false;
       }
    }
 }

Clustering considerations¶

None

Other Infra considerations¶

None

Security considerations¶

None

Scale and Performance Impact¶

This feature is expected to increase the datapath throughput by utilizing all available network resources.

Targeted Release¶

Carbon

Alternatives¶

There are certain use cases where it would be possible to add the network cards to a separate bridge with LACP enabled and patch it to br-int but this alternative was rejected since it imposes limitations on the type of links and the overall capacity.

Features to Install¶

This feature doesn’t add any new karaf feature.

REST API¶

{
   "transport-zone": [
    {
        "zone-name": "underlay-net1",
        "subnets": [
        {
          "prefix": "0.0.0.0/0",
          "vteps": [
            {
              "dpn-id": 273348439543366,
              "portname": "tunnel_port",
              "ip-address": "20.2.1.2",
              "option-of-tunnel": false
            },
            {
              "dpn-id": 110400932149974,
              "portname": "tunnel_port",
              "ip-address": "20.2.1.3",
              "option-of-tunnel": false
            }
          ],
          "gateway-ip": "0.0.0.0",
          "vlan-id": 0
        }
       ],
      "tunnel-type": "odl-interface:tunnel-type-vxlan"
    },
    {
        "zone-name": "underlay-net2",
        "subnets": [
        {
          "prefix": "0.0.0.0/0",
          "vteps": [
            {
              "dpn-id": 273348439543366,
              "portname": "tunnel_port",
              "ip-address": "30.3.1.2",
              "option-of-tunnel": false
            },
            {
              "dpn-id": 110400932149974,
              "portname": "tunnel_port",
              "ip-address": "30.3.1.3",
              "option-of-tunnel": false
            }
          ],
          "gateway-ip": "0.0.0.0",
          "vlan-id": 0
        }
       ],
      "tunnel-type": "odl-interface:tunnel-type-vxlan"
    },
   {
        "zone-name": "underlay-net3",
        "subnets": [
        {
          "prefix": "0.0.0.0/0",
          "vteps": [
            {
              "dpn-id": 273348439543366,
              "portname": "tunnel_port",
              "ip-address": "40.4.1.2",
              "option-of-tunnel": false
            },
            {
              "dpn-id": 110400932149974,
              "portname": "tunnel_port",
              "ip-address": "40.4.1.3",
              "option-of-tunnel": false
            }
          ],
          "gateway-ip": "0.0.0.0",
          "vlan-id": 0
        }
       ],
      "tunnel-type": "odl-interface:tunnel-type-vxlan"
    }
  ]
 }

{
   "input": {
       "source-dpid": "40146672641571",
       "destination-dpid": "102093507130250",
       "tunnel-type": "odl-interface:tunnel-type-vxlan"
   }
}

{
   "input": {
       "source-dpid": "40146672641571",
       "destination-dpid": "102093507130250",
       "tunnel-type": "odl-interface:tunnel-type-vxlan"
   }
}

CLI¶

tep:show-state will be enhanced to extract the state of the logical tunnel interface in addition to the actual TEP state.

Assignee(s)¶

Primary assignee:

Olga Schukin <olga.schukin@hpe.com>

Other contributors:

Tali Ben-Meir <tali@hpe.com>

Work Items¶

Trello card: https://trello.com/c/Q7LgiHH7/92-multiple-vxlan-endpoints-for-compute

• Add support to ITM for creation of multiple tunnels between pair of DPNs
• Create logical tunnel group in ietf-interface if more than one tunnel exist between two DPNs. Update the interface-child-info model with the list of individual tunnel members
• Bind a default service for the logical tunnel interface to create OF select group based on the tunnel members
• Change ITM RPC calls to getTunnelInterfaceName and getInternalOrExternalInterfaceName to prefer the logical tunnel group over the tunnel members
• Support OF weighted select group

Unit Tests¶

• ITM unitests will be enhanced with test cases of multiple tunnels
• IFM unitests will be enhanced to handle CRUD operations on logical tunnel group

Integration Tests¶

CSIT¶

Use Cases¶

This feature will support following use cases:

• Use case 1: Allow user to specify if they want to use flow based tunnels at the time of configuration.
• Use case 2: Create single OVS Tunnel Interface if flow based tunnels are configured and this is the first tunnel on this device/tep.
• Use case 3: Flow based and non flow based tunnels should be able to exist in a given transport zone.
• Use case 4: On tep delete, if this is the last tunnel interface on this tep/device and it is flow based tunnel, delete the OVS Tunnel Interface.

Following use cases will not be supported:

• Configuration of flow based and non-flow based tunnels of same type on the same device. OVS requires one of the following: remote_ip, local_ip, type and key to be unique. Currently we don’t support multiple local_ip and key is always set to flow. So remote_ip and type are the only unique identifiers. remote_ip=flow is a super set of remote_ip=<fixed-ip> and we can’t have two interfaces with all other fields same except this.
• Changing tunnel from one flow based to non-flow based at runtime. Such a change will require deletion and addition of tep. This is inline with existing model where tunnel-type cannot be changed at runtime.
• Configuration of Source IP for tunnel through flow. It will still be fixed. Though we’re adding option in IFM YANG for this, implementation for it won’t be done till we get use case(s) for it.

Using OVSDB Plugin¶

OVSDB Plugin provides following field in Interface to configure options:

 list options {
     description "Port/Interface related optional input values";
     key "option";
     leaf option {
         description "Option name";
         type string;
     }
     leaf value {
         description "Option value";
         type string;
     }

For flow based tunnels we will set option name remote_ip to value flow.

MDSALUtil changes¶

Following new actions will be added to mdsalutil/ActionType.java

• set_tunnel_src_ip
• set_tunnel_dest_ip

Following new matches will be added to mdsalutil/NxMatchFieldType.java

• tun_src_ip
• tun_dest_ip

Pipeline changes¶

This change adds a new match in Table0. Today we match in in_port to determine which tunnel interface this pkt came in on. Since currently each tunnel maps to a source-destination pair it tells us about source device. For interfaces configured to use flow based tunnels this will add an additional match for tun_src_ip. So, in_port+tunnel_src_ip will give us which tunnel interface this pkt belongs to.

When services call getEgressActions(), they will get one additional action, ``set_tunnel_dest_ip before the output:ofport action.

YANG changes¶

Changes will be needed in itm.yang and odl-interface.yang to allow configuring a tunnel as flow based or not.

 list vteps {
     key "dpn-id portname";
     leaf dpn-id {
         type uint64;
     }
     leaf portname {
         type string;
     }
     leaf ip-address {
         type inet:ip-address;
     }
     leaf option-of-tunnel {
         type boolean;
         default false;
     }
 }

 list tunnel-end-points {
     ordered-by user;
     key "portname VLAN-ID ip-address tunnel-type";
     /* Multiple tunnels on the same physical port but on different VLAN can be supported */

     leaf portname {
         type string;
     }
     ...
     ...
     leaf option-of-tunnel {
         type boolean;
         default false;
     }
 }

 grouping tunnel-optional-params {
     leaf tunnel-source-ip-flow {
         type boolean;
         default false;
     }

     leaf tunnel-remote-ip-flow {
         type boolean;
         default false;
     }

     list tunnel-options {
         key "tunnel-option";
         leaf tunnel-option {
             description "Tunnel Option name";
             type string;
         }
         leaf value {
             description "Option value";
             type string;
         }
     }
 }

 augment "/if:interfaces/if:interface" {
     ext:augment-identifier "if-tunnel";
     when "if:type = 'ianaift:tunnel'";
     ...
     ...
     uses tunnel-optional-params;
     uses monitor-params;
 }

Workflow¶

Configuration impact¶

This change doesn’t add or modify any configuration parameters.

Clustering considerations¶

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

Other Infra considerations¶

N.A.

Security considerations¶

N.A.

Scale and Performance Impact¶

This solution will help improve scale numbers by reducing no. of interfaces created on devices as well as no. of interfaces and ports present in inventory and network-topology.

Targeted Release(s)¶

Carbon. Boron-SR3.

Known Limitations¶

BFD monitoring will not work when OF Tunnels are used. Today BFD monitoring in OVS relies on destination_ip configured in remote_ip when creating tunnel port to determine target IP for BFD packets. If we use flow it won’t know where to send BFD packets. Unless OVS allows adding destination IP for BFD monitoring on such tunnels, monitoring cannot be enabled.

Alternatives¶

LLDP/ARP based monitoring was considered for OF tunnels to overcome lack of BFD monitoring but was rejected because LLDP/ARP based monitoring doesn’t scale well. Since driving requirement for this feature is scale setups, it didn’t make sense to use an unscalable solution for monitoring.

XML/CFG file based global knob to enable OF tunnels for all tunnel interfaces was rejected due to inflexible nature of such a solution. Current solution allows a more fine grained and device based configuration at runtime. Also, wanted to avoid adding yet another global configuration knob.

Features to Install¶

This feature doesn’t add any new karaf feature.

REST API¶

{
 "transport-zone": [
     {
         "zone-name": "TZA",
         "subnets": [
             {
                 "prefix": "192.168.56.0/24",
                 "vlan-id": 0,
                 "vteps": [
                     {
                         "dpn-id": "1",
                         "portname": "eth2",
                         "ip-address": "192.168.56.101",
                         "option-of-tunnel":"true"
                     }
                 ],
                 "gateway-ip": "0.0.0.0"
             }
         ],
         "tunnel-type": "odl-interface:tunnel-type-vxlan"
     }
 ]
}

{
 "interfaces": {
 "interface": [
     {
         "name": "vxlan_tunnel",
         "type": "iana-if-type:tunnel",
         "odl-interface:tunnel-interface-type": "odl-interface:tunnel-type-vxlan",
         "odl-interface:datapath-node-identifier": "1",
         "odl-interface:tunnel-source": "192.168.56.101",
         "odl-interface:tunnel-destination": "192.168.56.102",
         "odl-interface:tunnel-remote-ip-flow": "true",
         "odl-interface:monitor-enabled": false,
         "odl-interface:monitor-interval": 10000,
         "enabled": true
     }
  ]
 }
}

CLI¶

A new boolean option, remoteIpFlow will be added to tep:add command.

DESCRIPTION
  tep:add
  adding a tunnel end point

SYNTAX
  tep:add [dpnId] [portNo] [vlanId] [ipAddress] [subnetMask] [gatewayIp] [transportZone]
  [remoteIpFlow]

ARGUMENTS
  dpnId
          DPN-ID
  portNo
          port-name
  vlanId
          vlan-id
  ipAddress
          ip-address
  subnetMask
          subnet-Mask
  gatewayIp
          gateway-ip
  transportZone
          transport_zone
  remoteIpFlow
          Use flow for remote ip

Assignee(s)¶

Primary assignee:

<Vishal Thapar>

Other contributors:

<Vacancies available>

Work Items¶

1. YANG changes
2. Add relevant match and actions to MDSALUtil
3. Add set_tunnel_dest_ip action to actions returned in getEgressActions() for OF Tunnels.
4. Add match on tun_src_ip in Table0 for OF Tunnels.
5. Add CLI.
6. Add UTs.
7. Add ITs.
8. Add CSIT.
9. Add Documentation

Unit Tests¶

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

Integration Tests¶

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

CSIT¶

CSIT already has test cases for tunnels which test with non OF Tunnels. Similar test cases will be added for OF Tunnels. Alternatively, some of the existing test cases that use multiple teps can be tweaked to use OF Tunnels for one of them.

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

1. Create a TZ with more than one TEPs set to use OF Tunnels and test datapath.
2. Create a TZ with mix of OF and non OF Tunnels and test datapath.
3. Delete a TEP using OF Tunnels and add it again with non OF tunnels and test the datapath.
4. Delete a TEP using non OF Tunnels and add it again with OF Tunnels and test datapath.

Use Cases¶

Use case 1: Allow Unimgr to shape egress traffic from UNI

Pipeline changes¶

New ‘set_queue’ action will be supported in Egress Dispatcher table

Yang changes¶

A new augment “ovs-qos” is added to if:interface in odl-interface.yang

/* vlan port to qos queue */
 augment "/if:interfaces/if:interface" {
     ext:augment-identifier "ovs-qos";
     when "if:type = 'ianaift:l2vlan'";

     leaf ovs-qos-ref {
         type instance-identifier;
         description
           "represents whether service port has associated qos. A reference to a ovsdb QoS entry";
     }
     leaf service-queue-number {
         type uint32;
         description
           "specific queue number within the list of queues in the qos entry";
     }
 }

Configuration impact¶

None

Clustering considerations¶

None

Other Infra considerations¶

None

Security considerations¶

None

Scale and Performance Impact¶

Additional OpenFlow action will be performed on part of the packages. Egress packages will be processed via linux-htp if service configured accordanly.

Targeted Release¶

Carbon

Alternatives¶

The unified REST API for ovsdb port adjustment could be created if future release. The QoS engress queues and ingress rate limiting should be a part of this API. Usage ===== User will configure unimgr service with egress rate limits. That will follow to process described above.

Features to Install¶

• odl-genius (unimgr using genius feature for flows creation)

REST API¶

None

CLI¶

None

Assignee(s)¶

Primary assignee:

konsta.pozdeev@hpe.com

Work Items¶

Unit Tests¶

Integration Tests¶

CSIT¶

Use Cases¶

This feature will support following use cases:

• Use case 1: IFM should support binding services based on tunnel type.
• Use case 2: All application traffic ingressing on a tunnel should go through the LPORT DISPATCHER TABLE(17).
• Use case 3: IFM should support binding multiple ingress services on tunnels.
• Use case 4: IFM should support priority based ingress service handling for tunnels.
• Use case 5: IFM should support unbinding ingress services on tunnels.
• Use case 6: IFM should support binding multiple egress services on tunnels.
• Use case 7: IFM should support priority based egress service handling for tunnels.
• Use case 8: All application traffic egressing on a tunnel should go through the egress dispatcher table(220).
• Use case 9: Datapath should be intact even if there is no egress service bound on the tunnel.
• Use case 10: IFM should support unbinding egress services on tunnels.
• Use case 11: IFM should support handling of lower layer interface deletions gracefully.
• Use case 12: IFM should support binding services based on tunnel type and lport-tag on the same tunnel interface on a priority basis.
• Use case 13: Applications should bind on specific tunnel types on module startup
• Use case 13: IFM should take care of programming the tunnel type based binding flows on each DPN.

Following use cases will not be supported:

• Use case 1 : Update of service binding on tunnels. Any update should be done as delete and re-create

Pipeline changes¶

There is a pipeline change introduced as part of this feature for tunnel egress as well as ingress, and is captured in genius pipeline document patch [2].

With this feature, all traffic from INTERFACE_INGRESS_TABLE(0) will be dispatched to LPORT_DISPATCHER_TABLE(17), from where the packets will be dispatched to the respective applications on a priority basis.

Register6 will be used to set the ingress tunnel-type in Table0, and this can be used to match in Table17 to identify the respective applications bound on the tunnel-type. Remaining logic of ingress service binding will remain as is, and service-priority and interface-tag will be set in metadata as usual. The bits from 25-28 of Register6 will be used to indicate tunnel-type.

After the ingress service processing, packets which are identified to be egressed on tunnel interfaces, currently directly go to the tunnel port. With this feature, these packets will goto Egress Dispatcher Table[Table 220] first, where the packet will be processed by Egress Services on the tunnel interface one by one, and finally will egress the switch.

Register6 will be used to indicate service priority as well as interface tag for the egress tunnel interface, in Egress Dispatcher Table, and when there are N services bound on a tunnel interface, there will be N+1 entries in Egress Dispatcher Table, the additional one for the default tunnel entry. The first 4 bits of Register6 will be used to indicate the service priority and the next 20 bits for interface Tag, and this will be the match criteria for packet redirection to service pipeline in Egress Dispatcher Table. Before sending the packet to the service, Egress Dispatcher Table will set the service index to the next service’ priority. Same as ingress, Register6 will be used for egress tunnel-type matching, if there are services bound on tunnel-type.

RPC Changes¶

GetEgressActionsForInterface RPC in interface-manager currently returns the output:port action for tunnel interfaces. This will be changed to return set_field_reg6(default-service-index + interface-tag) and resubmit(egress_dispatcher_table).

Yang changes¶

No yang changes are needed, as binding on tunnel-type is enabled by having reserved keywords for interface-names

Workflow¶

Configuration impact¶

This change doesn’t add or modify any configuration parameters.

Clustering considerations¶

The solution is supported on a 3-node cluster.

Other Infra considerations¶

N.A.

Security considerations¶

N.A.

Scale and Performance Impact¶

• The feature adds one extra transaction during tunnel port creation, since the default Egress Dispatcher Table entry has to be programmed for each tunnel.
• The feature provides support for service-binding on tunnel type with the primary purpose of minimizing the number of flow entries in ingress/egress dispatcher tables.

Targeted Release¶

Carbon.

Alternatives¶

N/A

Features to Install¶

This feature doesn’t add any new karaf feature.Installing any of the below features can enable the service:

odl-genius-ui odl-genius-rest odl-genius

REST API¶

{
 "interfaces": {
 "interface": [
     {
         "name": "vxlan_tunnel",
         "type": "iana-if-type:tunnel",
         "odl-interface:tunnel-interface-type": "odl-interface:tunnel-type-vxlan",
         "odl-interface:datapath-node-identifier": "1",
         "odl-interface:tunnel-source": "192.168.56.101",
         "odl-interface:tunnel-destination": "192.168.56.102",
         "odl-interface:monitor-enabled": false,
         "odl-interface:monitor-interval": 10000,
         "enabled": true
     }
  ]
 }
}

{
   "bound-services": [
     {
       "service-name": "service1",
       "flow-priority": "5",
       "service-type": "service-type-flow-based",
       "instruction": [
        {
         "order": 1,
         "go-to-table": {
            "table_id": 88
          }
        }],
       "service-priority": "2",
       "flow-cookie": "1"
     }
   ]
}

CLI¶

N.A.

Assignee(s)¶

Primary assignee:

Faseela K

Work Items¶

1. Create Table 0 tunnel entries to set tunnel-type and lport_tag and point to LPORT_DISPATCHER_TABLE
2. Support of reserved keyword in interface-names for tunnel type based service binding.
3. Program tunnel-type based service binding flows on DPN connect events.
4. Program Lport Dispatcher Flows(17) on bind service
5. Remove Lport Dispatcher Flows(17) on unbind service
6. Handle multiple service bind/unbind on tunnel interface
7. Create default Egress Service for Tunnel on Tunnel Creation
8. Add set_field_reg_6 and resubmit(220) action to actions returned in getEgressActionsForInterface() for Tunnels.
9. Program Egress Dispatcher Table(220) Flows on bind service
10. Remove Egress Dispatcher Table(220) Flows on unbind service
11. Handle multiple egress service bind/unbind on tunnel interface
12. Delete default Egress Service for Tunnel on Tunnel Deletion
13. Add UTs.
14. Add CSIT.
15. Add Documentation
16. Trello Card : https://trello.com/c/S8lNGd9S/6-service-binding-on-tunnel-interfaces

Unit Tests¶

New junits will be added to InterfaceManagerConfigurationTest to cover the following :

1. Bind/Unbind single ingress service on tunnel-type
2. Bind/Unbind single egress service on tunnel-type
3. Bind single ingress service on tunnel-interface
4. Unbind single ingress service on tunnel-interface
5. Bind multiple ingress services on tunnel in priority order
6. Unbind multiple ingress services on tunnel in priority order
7. Bind multiple ingress services out of priority order
8. Unbind multiple ingress services out of priority order
9. Delete tunnel port to check if ingress dispatcher flows for bound services get deleted
10. Add tunnel port back to check if ingress dispatcher flows for bound services get added back
11. Bind single egress service on tunnel
12. Unbind single egress service on tunnel
13. Bind multiple egress services on tunnel in priority order
14. Unbind multiple egress services on tunnel in priority order
15. Bind multiple egress services out of priority order
16. Unbind multiple egress services out of priority order
17. Delete tunnel port to check if egress dispatcher flows for bound services get deleted
18. Add tunnel port back to check if egress dispatcher flows for bound services get added back

Integration Tests¶

CSIT¶

The following TCs should be added to CSIT to cover this feature:

1. Bind/Unbind single ingress/egress service on tunnel-type to see the corresponding table entries are created in switch.
2. Bind single ingress service on tunnel to see the corresponding table entries are created in switch.
3. Unbind single ingress service on tunnel to see the corresponding table entries are deleted in switch.
4. Bind multiple ingress services on tunnel in priority order to see if metadata changes are proper on the flow table.
5. Unbind multiple ingress services on tunnel in priority order to see if metadata changes are proper on the flow table on each unbind.
6. Bind multiple ingress services out of priority order to see if metadata changes are proper on the flow table.
7. Unbind multiple ingress services out of priority order.
8. Delete tunnel port to check if ingress dispatcher flows for bound services get deleted.
9. Add tunnel port back to check if ingress dispatcher flows for bound services get added back.
10. Bind single egress service on tunnel to see the corresponding table entries are created in switch.
11. Unbind single egress service on tunnel to see the corresponding table entries are deleted in switch.
12. Bind multiple egress services on tunnel in priority order to see if metadata changes are proper on the flow table.
13. Unbind multiple egress services on tunnel in priority order to see if metadata changes are proper on the flow table on each unbind.
14. Bind multiple egress services out of priority order to see if metadata changes are proper on the flow table.
15. Unbind multiple egress services out of priority order.
16. Delete tunnel port to check if egress dispatcher flows for bound services get deleted.
17. Add tunnel port back to check if egress dispatcher flows for bound services get added back.

Use Cases¶

This feature will support following use cases:

• Use Case 1: Provide RPC and CLI to trigger reinstall of a service.
• Use Case 2: Provide RPC and CLI to trigger recover a service.
• Use Case 3: Provide RPC and CLI to trigger recovery of specific instance object managed by a service, referred to as service instance.

SRM Terminology¶

SRM will introduce concept of service entities and operations.

Out of Scope¶

• SRM will not be implementing actual recovery mechanisms, it will only act as intermediary between user and individual services.
• SRM will not provide status of services. Status and Diagnostic (SnD) framework is expected to provide service status.

Pipeline changes¶

N.A.

Yang changes¶

We’ll be adding three new yang files

 module srm-types {
     namespace "urn:opendaylight:genius:srm:types";
     prefix "srmtypes";

     revision "2017-05-31" {
         description "ODL Services Recovery Manager Types Module";
     }

     /* Entity TYPEs */

     identity entity-type-base {
         description "Base identity for all srm entity types";
     }
     identity entity-type-service {
         description "SRM Entity type service";
         base entity-type-base;
     }
     identity entity-type-instance {
         description "SRM Entity type instance";
         base entity-type-base;
     }


     /* Entity NAMEs */

     /* Entity Type SERVICE names */
     identity entity-name-base {
         description "Base identity for all srm entity names";
     }
     identity genius-ifm {
         description "SRM Entity name for IFM service";
         base entity-type-base;
     }
     identity genius-itm {
         description "SRM Entity name for ITM service";
         base entity-type-base;
     }
     identity netvirt-vpn {
         description "SRM Entity name for VPN service";
         base entity-type-base;
     }
     identity netvirt-elan {
         description "SRM Entity name for elan service";
         base entity-type-base;
     }
     identity ofplugin {
         description "SRM Entity name for openflowplugin service";
         base entity-type-base;
     }


     /* Entity Type INSTANCE Names */

     /* Entity types supported by GENIUS */
     identity genius-itm-tep {
         description "SRM Entity name for ITM's tep instance";
         base entity-type-base;
     }
     identity genius-itm-tz {
         description "SRM Entity name for ITM's transportzone instance";
         base entity-type-base;
     }

     identity genius-ifm-interface {
         description "SRM Entity name for IFM's interface instance";
         base entity-type-base;
     }

     /* Entity types supported by NETVIRT */
     identity netvirt-vpninstance {
         description "SRM Entity name for VPN instance";
         base entity-type-base;
     }

     identity netvirt-elaninstance {
         description "SRM Entity name for ELAN instance";
         base entity-type-base;
     }


     /* Service operations */
     identity service-op-base {
         description "Base identity for all srm operations";
     }
     identity service-op-reinstall {
         description "Reinstall or restart a service";
         base service-op-base;
     }
     identity service-op-recover {
         description "Recover a service or instance";
         base service-op-recover;
     }

 }

 module srm-ops {
     namespace "urn:opendaylight:genius:srm:ops";
     prefix "srmops";

     import srm-types {
         prefix srmtype;
     }

     revision "2017-05-31" {
         description "ODL Services Recovery Manager Operations Model";
     }

     /* Operations  */

     container service-ops {
         config false;
         list services {
             key service-name
             leaf service-name {
                 type identityref {
                     base srmtype:entity-name-base
                 }
             }
             list operations {
                 key entity-name;
                 leaf entity-name {
                     type identityref {
                         base srmtype:entity-name-base;
                     }
                 }
                 leaf entity-type {
                     type identityref {
                         base srmtype:entity-type-base;
                         mandatory true;
                     }
                 }
                 leaf entity-id {
                     description "Optional when entity-type is service. Actual
                                  id depends on entity-type and entity-name"
                     type string;
                 }
                 leaf trigger-operation {
                     type identityref {
                         base srmtypes:service-op;
                         mandatory true;
                     }
                 }
             }
         }
     }

 }

 module srm-rpcs {
     namespace "urn:opendaylight:genius:srm:rpcs";
     prefix "srmrpcs";

     import srm-types {
         prefix srmtype;
     }

     revision "2017-05-31" {
         description "ODL Services Recovery Manager Rpcs Module";
     }

     /* RPCs */

     rpc reinstall {
         description "Reinstall a given service";
         input {
             leaf entity-name {
                 type identityref {
                     base srmtype:entity-name-base;
                     mandatory true;
                 }
             }
             leaf entity-type {
                 description "Currently supported entity-types:
                                 service";
                 type identityref {
                     base srmtype:entity-type-base;
                     mandatory false;
                 }
             }
         }
         output {
             leaf successful {
                 type boolean;
             }
             leaf message {
                 type string;
             }
         }
     }


     rpc recover {
         description "Recover a given service or instance";
         input {
             leaf entity-name {
                 type identityref {
                     base srmtype:entity-name-base;
                     mandatory true;
                 }
             }
             leaf entity-type {
                 description "Currently supported entity-types:
                                 service, instance";
                 type identityref {
                     base srmtype:entity-type-base;
                     mandatory true;
                 }
             }
             leaf entity-id {
                 description "Optional when entity-type is service. Actual
                              id depends on entity-type and entity-name"
                 type string;
                 mandatory false;
             }
         }
         output {
             leaf response {
                 type identityref {
                     base rpc-result-base;
                     mandatory true;
                 }
             }
             leaf message {
                 type string;
                 mandatory false;
             }
         }
     }

     /* RPC RESULTs */

     identity rpc-result-base {
         description "Base identity for all SRM RPC Results";
     }
     identity rpc-success {
         description "RPC result successful";
         base rpc-result-base;
     }
     identity rpc-fail-op-not-supported {
         description "RPC failed:
                         operation not supported for given parameters";
         base rpc-result-base;
     }
     identity rpc-fail-entity-type {
         description "RPC failed:
                         invalid entity type";
         base rpc-result-base;
     }
     identity rpc-fail-entity-name {
         description "RPC failed:
                         invalid entity name";
         base rpc-result-base;
     }
     identity rpc-fail-entity-id {
         description "RPC failed:
                         invalid entity id";
         base rpc-result-base;
     }
     identity rpc-fail-unknown {
         description "RPC failed:
                         reason not known, check message string for details";
         base rpc-result-base;
     }
 }

Configuration impact¶

N.A.

Clustering considerations¶

SRM will provide RPCs, which will only be handled on one of the nodes. In turn, it will write to srm-ops.yang and each individual service will have Clustered Listeners to track operations being triggered. Individual services will decide, based on service and instance on which recovery is triggered, if it needs to run on all nodes on cluster or individual nodes.

Other Infra considerations¶

Status and Diagnostics (SnD) may need to be updated to user service names similar to ones used in SRM.

Security considerations¶

Providing RPCs to trigger service restarts will eliminate the need to give administrative access to non-admin users just so they can trigger recovery though bundle restarts from karaf CLI. Expectation is access to these RPCs will be role based, but role based access and its implementation is out of scope of this feature.

Scale and Performance Impact¶

This feature allows recovery at a much fine grained level than full controller or node restart. Such restarts impact and trigger recovery of services that didn’t need to be recover. Every restart of controller cluster or individual nodes has a significant overhead that impacts scale and performance. This feature aims to eliminate these overheads by allowing targeted recovery.

Targeted Release¶

Nitrogen.

Alternatives¶

Using existing karaf CLI for feature and bundle restart was considered but rejected due to reasons already captured in earlier sections.

Features to Install¶

odl-genius

REST API¶

TBD.

CLI¶

DESCRIPTION
  srm:reinstall
  reinstall a given service

SYNTAX
  srm:reinstall <service-name>

ARGUMENTS
  service-name
          Name of service. to re-install e.g. itm/ITM, ifm/IFM etc.

EXAMPLE
  srm:reinstall ifm

DESCRIPTION
  srm:recover
  recover a service or service instance

SYNTAX
  srm:recover <entity-type> <entity-name> [<entity-id>]

ARGUMENTS
  entity-type
          Type of entity as defined in srm-types.
          e.g. service, instance etc.
  entity-name
          Entity name as defined in srm-types.
          e.g. itm, itm-tep etc.
  entity-id
          Entity Id for instances, requierd for entity-type instance.
          e.g. 'TZA', 'tunxyz' etc.

EXAMPLES
  srm:recover service itm
  srm:recover instance itm-tep TZA
  srm:recover instance vpn-instance e5e2e1ee-31a3-4d0c-a8d8-b86d08cd14b1

Assignee(s)¶

Primary assignee:

Vishal Thapar

Other contributors:

Faseela K Hema Gopalakrishnan

Work Items¶

1. Add srm modules and features
2. Add srm yang models
3. Add code for CLI
4. Add backend implementation for RPCs to tigger SRM Operations
5. Optionally, for each service and supported instances, add implementation for SRM Operations
6. Add UTs
7. Add CSITs

Unit Tests¶

Integration Tests¶

CSIT¶

Use Cases¶

This change is primarily introduced to correctly support assigning a FIP to an Octavia VIP:

https://jira.opendaylight.org/browse/NETVIRT-1402

An Octavia VIP is a Neutron port that is not bound to any VM and is therefor not added to br-int. The VM containing the active HaProxy sends gratuitous ARPs for the VIP’s IP and ODL intercepts those and programs flows to forward VM traffic to the VMs port.

The ODL code responsible for configuring the FIP association flows on OVS currently relies on a southbound openflow port that corresponds to the neutron FIP port. The only real reason this is required is so that ODL can decide which switch should get the flows. In the case of the VIP port, there is no corresponding southbound port so the flows never get configured.

To resolve this, ODL can know which switch to program the flows on from the gratuitous ARP packet-in event which will come from the right switch (we already listen for those.) So, basically we just respond to the gratuitous ARP by correlating it with the Neutron port, checking that the port is an Octavia VIP (the owner field), and programming the flows.

Pipeline changes¶

N/A

Yang changes¶

In arputil-api, add dpn-id fields to the the arp-request-received and arp-response-received yang notifications

Configuration impact¶

N/A

Clustering considerations¶

N/A

Other Infra considerations¶

N/A

Security considerations¶

N/A

Scale and Performance Impact¶

N/A

Targeted Release¶

Nitrogen and preferably backported to Oxygen

Alternatives¶

N/A

Features to Install¶

odl-genius

REST API¶

This change simply adds a field to an existing yang notification and therefor does not change any APIs.

CLI¶

N/A

Assignee(s)¶

Josh Hershberg, jhershbe@redhat.com

Work Items¶

Simple change, see the gerrit patch above.

Unit Tests¶

N/A

Integration Tests¶

N/A

CSIT¶

TBD

Testbed Topologies¶

This suit uses the default Genius topology.

+--------+       +--------+
|  BR1   | data  |  BR2   |
|        <------->        |
+---^----+       +----^---+
    |       mgmt      |
+---v-----------------v---+
|                         |
|           ODL           |
|                         |
|        odl-genius       |
|                         |
+-------------------------+

Hardware Requirements¶

N.A.

Software Requirements¶

OVS 2.6+ Mininet ???

Test Suite Bringup¶

Following steps are followed at beginning of test suite:

• Bring up ODL with odl-genius feature installed
• Add bridge to DPN
• Add tap interfaces to bridge created above
• Add OVSDB manager to DPN using ovs-vsctl set-manager
• Connect bridge to OpenFlow using ovs-vsctl set-controller
• Repeat above steps for other DPNs
• Create REST session to ODL

Test Suite Cleanup¶

Following steps are followed at beginning of test suite:

• Delete bridge DPN
• Delete OVSDB manager ‘ovs-vsctl del-manager’
• Repeat above steps for other DPNs
• Delete REST session to ODL

Debugging¶

Following DataStore models are captured at end of each test case:

• config/itm-config:tunnel-monitor-enabled
• config/itm-config:tunnel-monitor-interval
• config/itm-state:dpn-endpoints
• config/itm-state:external-tunnel-list
• config/itm:transport-zones
• config/network-topology:network-topology
• config/opendaylight-inventory:nodes
• operational/ietf-interfaces:interfaces
• operational/ietf-interfaces:interfaces-state
• operational/itm-config:tunnel-monitor-enabled
• operational/itm-config:tunnel-monitor-interval
• operational/itm-state:tunnels_state
• operational/network-topology:network-topology
• operational/odl-interface-meta:bridge-ref-info

Create l2vlan Transparent Interface¶

This creates a transparent l2vlan interface between two dpns

Delete l2vlan Transparent Interface¶

This testcase deletes the l2vlan transparent interface created in previous test case.

Create l2vlan Trunk Interface¶

This testcase creates a l2vlan trunk interface between 2 DPNs.

Create l2vlan Trunk Member Interface¶

This testcase creates a l2vlan Trunk member interface for the l2vlan trunk interface created in previous testcase.

Bind service on Interface¶

This testcase binds service to the L2vlan Trunk Interface earlier.

Unbind service on Interface¶

This testcase Unbinds the services which were bound in previous testcase.

Delete L2vlan Trunk Interface¶

Delete l2vlan trunk interface created and used in earlier test cases

Assignee(s)¶

Primary assignee:

<developer-a>

Other contributors:

<developer-b> <developer-c>

Work Items¶

N.A.

Links¶

• Link to implementation patche(s) in CSIT - TBD

Testbed Topologies¶

Topology device software and inter node communication details -

1. ODL Node – 1 or 3 Node ODL Environment should be used
2. Switch Node - 2 or 3 Nodes with OVS 2.6

+--------+       +--------+
|  BR1   | data  |  BR2   |
|        <------->        |
+---^----+       +----^---+
    |       mgmt      |
+---v-----------------v---+
|                         |
|           ODL           |
|                         |
|        odl-genius       |
|                         |
+-------------------------+

Hardware Requirements¶

1. 1 controller with 2 OVS for functional testing
2. 3 controller with 2 OVS for functional testing

Software Requirements¶

N.A.

Test Suite Bringup¶

In test suit bringup build the topology as described in the Test Topology. Bring all the tunnels UP.

Test Suite Cleanup¶

Final steps after all tests in suite are done. This should include any cleanup, sanity checks, configuration etc. that needs to be done once all test cases in suite are done.

Debugging¶

Capture any debugging information that is captured at start of suite and end of suite.

Verify Tunnel Creation with enabled IFM Bypass¶

Change the config parameter to enable IFM Bypass of ITM provisioning and Verify Tunnel Creation is successful.

Verify Tunnel Creation with disabled IFM Bypass¶

Change the config parameter to enable without IFM Bypass of ITM provisioning and Verify Tunnel Creation is successful.

Change ITM provisioning parameter to enable IFM Bypass¶

Clean up existing ITM config, change ITM provisioning parameter to provide IFM Bypass, Verify ITM creation succeeds.

Change ITM provisioning parameter to disable IFM Bypass¶

Clean up existing ITM config, change ITM provisioning parameter to disable IFM Bypass, Verify ITM creation succeeds.

Bring DOWN the datapath¶

Configure ITM tunnel Mesh, Bring DOWN the datapath and Verify Tunnel status is updated in ODL.

Bring UP the datapath¶

Configure ITM tunnel Mesh, Bring UP the datapath and Verify Tunnel status is updated in ODL.

Enable BFD Monitoring for ITM Tunnels¶

Change ITM config parameters to enable IFM Bypass and Verify BFD monitoring can be enabled for ITM tunnels.

Disable BFD Monitoring for ITM Tunnels¶

Change ITM config parameters to enable IFM Bypass and Verify BFD monitoring can be disabled for ITM tunnels

Enable/Disable BFD to verify tunnel status alarm¶

Enable BFD and check for the data path alarm and as well as control path alarms.

Verify Tunnel down alarm is reported¶

Enable Tunnel status alarm and Bring down the Tunnel port, and verify Tunnel down alarm is reported.

Verify Tunnel status for the Disconnected DPN¶

Disconnect DPN from ODL and verify Tunnel status is shown as UNKNOWN for the Disconnected DPN.

Verify Tunnel down alarm is cleared¶

Enable Tunnel status alarm and Bring up the Tunnel port which is down, and verify Tunnel down alarm is cleared.

Perform ODL reboot¶

Create ITM with provisioning config parameter set to true, Perform ODL reboot and Verify dataplane is intact.

Verify Re-sync is successful once connection is up¶

Create ITM with provisioning config parameter set to true for IFM Bypass, bring down control plane connection(between ODL–OVS), modify ODL config, Verify Re-sync is successful once connection is up.

Verify ITM creation with 2 DPNs¶

Verify TEP Creation¶

Add new TEP’s and verify Creation is successful

Verify TEP Deletion¶

Delete few TEP’s and verify Deletion is successful and no stale(flows,config) is left.

Verify ITM creation by Re-adding TEPs¶

Re-add deleted TEP’s and Verify ITM creation is successful

Verify Deletion of All TEPs¶

Delete all TEP’s and verify Deletion is successful and no stale(flows,config) is left

Assignee(s)¶

Who is contributing test cases? In case of multiple authors, designate a primary assignee and other contributors. Primary assignee is also expected to be maintainer once test code is in.

Primary assignee:

Faseela K

Other contributors:

Nidhi Adhvaryu, Sathwik Boggarapu

Work Items¶

N.A.

Links¶

• Link to implementation patche(s) in CSIT

Testbed Topologies¶

This suit uses the default Genius topology.

+--------+       +--------+
|  BR1   | data  |  BR2   |
|        <------->        |
+---^----+       +----^---+
    |       mgmt      |
+---v-----------------v---+
|                         |
|           ODL           |
|                         |
|        odl-genius       |
|                         |
+-------------------------+

Hardware Requirements¶

N.A

Software Requirements¶

OVS 2.6+

Test Suite Bringup¶

Following steps are followed at beginning of test suite:

• Bring up ODL with odl-genius feature installed
• Add bridge to DPN
• Add tap interfaces to bridge created above
• Add OVSDB manager to DPN using ovs-vsctl set-manager
• Connect bridge to OpenFlow using ovs-vsctl set-controller
• Repeat above steps for other DPNs
• Create REST session to ODL

Test Suite Cleanup¶

Following steps are followed at the end of test suite:

• Delete bridge DPN
• Delete OVSDB manager ‘ovs-vsctl del-manager’
• Repeat above steps for other DPNs
• Delete REST session to ODL

Debugging¶

Capture any debugging information that is captured at start of suite and end of suite.

ITM TEP Recovery¶

Verify SRM by recovering TEP instance by using transportzone name and TEP’s ip address.

ITM Transportzone Recovery¶

Verify SRM by recovering TZ instance using transportzone name.

ITM Service Recovery¶

Verify SRM by recovering service ITM.

IFM Instance Recovery¶

Verify SRM instance recovery using interface port name.

IFM Service Recovery¶

Verify SRM by recovering service IFM.

Assignee(s)¶

Who is contributing test cases? In case of multiple authors, designate a primary assignee and other contributors. Primary assignee is also expected to be maintainer once test code is in.

Primary assignee:

Nidhi Adhvaryu

Other contributors:

N.A

Work Items¶

N.A.

Links¶

• Link to implementation patche(s) in CSIT