NetVirt Planning

OpenDaylight DDF 2017

Sam Hague

Daya Kamath

Vivekanandan Narasimhan

Agenda

• karaf 4
• Clustering and High Availability
• NetVirt and VPP Integration
• DPDK
• SR-IOV
• Port Status Update
• Upgradability
• Hitless Switch Resynchronization
• hw_vtep and L2GW
• Quality and Testing
• Scaling and Performance
• Scaling and Performance Testing
• Code Quality, Cleanup and Readability
• Documentation

• Neutron Port Allocation for DHCP
• Vims Support By Enabling extra-route NetHops to be Non-Neutron IPs
• Newton Based QoS Parameters
• Dynamic Tunnels for L3 Service (Including ITM Tunnel Scalability)
• IPv6 Dual Stack and IPv6 External Network Support with Dual Stack
• OVS 2.7 Migration
• SmartNic Integration
• InfraUtils: FCAPs Counters
• InfraUtils: Common Cache
• OPNFV Requests
• Octavia

Features Delivered in Carbon

• ACLs
• Statistics
• Remote ACLs
• Conntrack-based SNAT
• CSIT Coverage
• DHCP Server with Dynamic Allocation Pool
• ECMP Support for BGP-based L3VPN
• Hairpinning of Floating IPs in Flat/VLAN Provider Networks
• IPv6 L3 North-South support for Flat/VLAN Provider Networks

• SFC Classifier
• VxLAN-based L2 connectivity across data centers
• VxLAN-based connectivity across data centers
• Temporary SMAC learning
• VLAN provider network enhancements
• VNI-based L2 switching, L3 forwarding and NATing

Nitrogen Schedule (Tentative)

• Nitrogen is a short cycle intended to complete Karaf 4 migration
• What features can we add?
• Should we limit new features and focus on stability and quality?
• Carbon SR1: 7/6/17 or 7/13/17

Karaf 4

• Nitrogen is intended to be a short release to finish Karaf 4 migration
• Does ODL fit the Karaf lifecycle model?
• Might need to make modules restartable or express dependencies in a way that avoids reloading

To do:

• Core team to do some initial investigation before next steps?
• Build karaf 4 distro (karaf4-parent)
• Merge features in integration distro and use kara 4 distro
• Test in Nitrogen CSIT
• Continue work on Carbon

Clustering and High Availability

• NetVirt-specific monitoring?
• Switch load-balancing (OVSDB) and OpenFlow - currently the connection determines the ODL owner
• CSIT does not pass 100% and needs troubleshooting

NetVirt VPP Integration

• ELAN/L2
• Basic Layer 2 connectivity between Neutron VMs on VPP nodes
• PoC available: https://git.opendaylight.org/gerrit/#/c/50259/
• Security Groups
• VPP Renderer needs to be enhanced to listen to Genius and ACL Service models
• VLAN provider & VLAN Transparency & VLAN trunking
• Requires VPP enhancements
• Connectivity to Bare Metal/SR-IOV
• L3/VPN
• Finalize Netvirt-GBP convergence architecture for Layer 3 feature set: L3 East-West, L3 North-South (External Connectivity), L3 BGPVPN
• VPP Renderer for VPN Manager and FIB Manager components
• SFC
• Finalize Netvirt-GBP convergence architecture for Service Function chaining
• VPP Renderer for Netvirt Classifiers
• Hybrid deployments
• Support tenant virtual network services in a hybrid environment with both OVS and FD.io/VPP simultaneously

OVS with DPDK

Missing OVS DPDK features:

• SNAT with conntrack (patch series in development)
• what else ?

​

Hostconfig and Psuedo port binding features present in Neutron NB

• Missing - CI support (NetVirt & Neutron)

​

SR-IOV

Order of ML2 plugins is significant - sriovnicswitch must be before opendaylight

• https://bugs.launchpad.net/networking-odl/+bug/1693325

​

​

​

Port Status Update

• Currently, ODL (master) supports port status notifications to ACTIVE when port is created. Waiting for merge of networking-odl patches.
• Need the ability to report the port status for admin-port UP/DOWN.

​

• In an ideal world, we should have real reliable async “messaging” between e.g. ODL and networking-odl - what we’re doing currently is working around issues which are due to how we interface between these “systems” with HTTP REST and web socket (WS).

Upgradeability (1/2)

• Use DAEXIM project to export config DS to JSON, then “migrate it somehow” to accommodate major schema changes (which we are very sceptical will be able to guarantee to completely avoid, over the years to come...), and full re-import into a new major release.
• Use DAEXIM but only export small subset of config data, incl. e.g. idmanager mappings, and re-import just that, and let the rest sync from OpenStack using networking-odl “full sync”. This should work in principle, but we’ve (a) observed it to be much slower than we think it should be, and (b) hit a few bugs in this area.

Upgradeability (2/2)

• daexim import-on-boot new feature, using new infrautils.ready (which itself uses odlparent’s bundle-test, same code as SingleFeatureTest). This can be used for both full and partial re-import on-boot.
• Partial re-import for non-Openstack driven ODL configurations.
• Genius idmanager will have to block on daexim import-on-boot
• We need DAEXIM in (auto) release ASAP... any new volunteers? ;-)

Hitless Switch Resynchronization

• Required for Upgrade-ability without any OVS data plane downtime
• OpenFlow bundle concept should an “atomic” switch over (TBC?)
• Completely avoid any need for (complicated!) “flow migration”

​

• Also useful to be able to force a “resync” (manually or perhaps even automatically periodically) to fix up “glitches” when OVS/ODL view of the world about flows get out of sync, due to bugs in ODL code.

hw_vtep and L2GW

• L3 support
• https://docs.google.com/presentation/d/1-HptEPKGF7V1fcJfLNGinhOD-1wuEZbBpKtQc4la9gk/edit?usp=sharing
• CSIT test coverage
• fix what’s there first to get to 100%, then use it to gate all patches
• add more...
• Schema update - needed for Security groups
• https://wiki.opendaylight.org/view/OVSDB_Integration:HWVTEP_Schema_support
• Security groups on TOR ACLs
• Source_node replication for Logical Switch
• https://git.opendaylight.org/gerrit/#/c/57209/
• Cluster testing for HWVTEP plugin
• High Availability
• https://docs.google.com/document/d/1U7M78uNhBp8eZIu0YH04u6Vzj6t2NpvDY4peX8svsXY/edit#heading=h.xochfa5fqf06
• Error Reporting and logging.
• Underlay correlation - create a topology map to eliminate use of L2-GW API.

Quality and Testing

• Finish push to achieve consistently 100% passing
• Need to add scale and longevity jobs
• Job combinations need to be more efficient
• Finish ocata jobs
• XCI w/ OPNFV apex snapshots. hopeful to use for gerrit gates
• Smarter debugging steps in automation
• Better validation for each suite (e.g., env should be the same before and after)

Scaling and Performance

• What do we know so far? Need to add some numbers for below:
• Flow programming
• Nodes supported, vms supported
• Memory usage
• MDSAL reads and writes (bigger instead of single “auto commit” transactions?)
• Start identifying low hanging fruit areas vs architectural requirements work
• Must do real Java code level profiling of real world functional load use cases

Scaling and Performance Testing

• What testing is already being done?
• OPNFV: had trouble with ODL duration tests: sync and memory issues (e.g. Bug 7370)
• Red Hat
• Control plane: create networks, subnets routers
• Data plane:
• pps (TCP and UDP): L2, L3 East-West, North-South
• latency: TCP Request-Response
• Networking-ODL: journal threads lock up on slow queries
• Ericsson
• Intel
• Ansible based scale setup with multiple compute containers per host
• Plan to test with Rally - including instance creation
• Rally port emulation testing, ovsdb emulation testing
• What testing should we add?
• Scale and longevity
• Performance (rally?)

Code Quality, Clean Up and Readability

• remove @Deprecated APIs (and adjust code using it)
• adopt Checkstyle enforcement in even more projects than we now have
• null safety (NullPointerException avoidance) w. Optional and non-null collections, lastnpe.org?
• adopt FindBugs enforcement
• More Java test coverage, both unit as well as component tests

​

Documentation

• Basic design and architecture documentation is needed
• Need to fill in content for the design framework already produced: https://goo.gl/RmsU6G
• Add CSIT methodology and troubleshooting guides
• Better release notes
• Better API documentation (incl. real JavaDoc, see https://bugs.opendaylight.org/showdependencytree.cgi?id=7873)
• Generate YANG models documentation site?
• Blueprint specs introduce new feature designs

Neutron Port Allocation for DHCP

• Enable ODL to allocate a Neutron Port for DHCP proxy service.
• Enables DHCP in L2 Deployment when L3 services provided by separate Neutron Agents.
• Enables servicing unicast DHCP requests from SR-IOV-driven workloads.

Current Status:

• Openstack Neutron ODL Driver enhancements are in progress for the Pike release.
• In ODL the ARP servicing functionality is being migrated to ELAN-service bundles. Targeted to be completed in Nitrogen release.

​

​

Enabling Extra-route NextHop to be Non-Neutron IPs

• Enable ODL to serve extra-routes with NextHops that aren’t required to be Neutron-provided IP-Addresses.

​

• Enables forwarding packets to extra-route-prefixes behind a physical/virtual gateways that are not managed via Neutron.

​

• Spec and implementation targeted for Nitrogen

Newton-Based QoS Params

• Enables ODL to support Minimum Egress Bandwidth guarantee for Neutron Ports.

​

• For more details please refer Neutron QoS Spec in Openstack here: https://specs.openstack.org/openstack/neutron-specs/specs/newton/ml2-qos-minimum-egress-bw-support.html

​

• Spec and Implementation targeted for Nitrogen

​

​

IPv6 Dual Stack and IPv6 External Network Access for DualStack

• Dualstack
• Enable ODL to support IPv4 and IPv6 addresses on the same Neutron Port.
• Enable ODL to support routing on such subnets
• Through a single Neutron router that hosts both the IPv4 and IPv6 subnets.
• Through separate Neutron Routers (ie., one per address-family)
• External Network Access
• Provide external network access via both IPv4 (NATing) and IPv6 GUA Addresses from/to tenant VMs.
• For both the above, the Specs are already under review . Implementation to be completed in Nitrogen.

Southbound Device Renderers

• Enable in ODL a Generic Southbound Access-Configuration Mechanism for third party devices.

​

• Provide new generic abstractions for each NetVirt service for Southbound Device Access and Configuration.

​

• Provide a framework for integrating third party device renderers for the above abstractions.

Refactoring ODL L3VPN and NAT

The following modules:

-> VPN Engine

-> FIB Engine

-> NAT Engine

will be refactored to:

1. Enable to make them reliably functional at scale >200 nodes (>30 VMs per node) scale
2. Enable to make the modules configure plumbing flows at nearly the rate of configuration.

InfraUtils: Common Cache

https://bugs.opendaylight.org/show_bug.cgi?id=8300

https://www.youtube.com/watch?v=h4HOSRN2aFc

https://git.opendaylight.org/gerrit/#/c/48920/

• Status: a POC has identified a small gap in the proposed API
• It’s missing explicit “put(k,v)” and “evict(k)”
• will be addressed ASAP (June, hopefully)
• needs a bit more API JavaDoc, otherwise good to go
• It’s a generic Cache API, but we expect it to be mainly used over MDSAL to replace Map<> in many places in the code; likely with a thin helper TBD (in genius not netvirt; no MDSAL in infrautils)

OPNFV Requests

• Config to enable/disable needing quagga
• Remove the need to wait for netvirt:1
• Load balancing master/slave connections to OVSDB and OF when ODL is in clustered mode
• Exceptions cleanup and removing logs that are not really errors (i.e. lock failures)
• Southbound port and flow reconciliation: https://bugs.opendaylight.org/show_bug.cgi?id=7707
• Better way to restart ODL. Currently need to remove journal, snapshot and data
• Better HA and clustering support
• Scaling and performance testing

Octavia

• Need to finish missing items
• L2 works
• L3 has issues
• Enabled CSIT tests