OpenDaylight at Comcast

Chris Luke

Sr. Principal Engineer

2

General long-term network direction

• Strong desire to reduce complexity.

- Both configuration and operational complexity are undesirable.

- The core should not be intimately involved in virtual networks.

• Heavy emphasis on IPv6.

- Lean IPv6-only core. IPv6-only access.

- Virtual networks signaled by segment routing, LISP, or similar.

- Encapsulation doesn’t matter, so long as IPv6 is the underlay.

- IPv4 internet becomes a virtual network.

• Improved network automation.

- Broader network engineer involvement in the automation mechanisms.

- More software but less closed-box and driven by network engineers.

- Less OSS/BSS. More Yang/Netconf/Orchestration and abstract interfaces.

- Less CLI. More operational tooling, including for break-fix.

• Lightweight CPE. Lightweight PE.

- Combined, virtualized, PE/CPE role. Dump the distinction.

3

Early experiments with ODL

• Very, very, early on….

• Obviously, we fired it up with mininet!

- …and was underwhelmed.

• And then we got adventurous:

- Using ODL to discover topology (BGP-LS, etc)…

- To build a mapping service for segments…

- Which fed data into a process running in userspace on an Arista…

- To which packets were punted so they could be IPv6 segment routed.

• It worked. But configuring ODL was painful.

• (and BGP-LS has some badly thought out semantics; could do with being replaced by something simpler)

4

Hydrogen

• Last summer, there was an Intern…

• Project scope was to work out and report on the state of ODL.

• And in particular, the scope and direction ODL was taking with path computation.

• First finding: Service Provider edition was huge.

• So huge, it wouldn’t run in a VM on his laptop!

• Ultimate finding was that though ODL had matured significantly since pre-Hydrogen, it still (unsurprisingly) had the feeling of a young project growing fast; difficult to track.

• Path compute was also not quite what was expected; The Affinity project did cool stuff, but didn’t expose a generic path compute API.

• Not even simple SPF was exposed as an API service.

• Not quite ready to jump in to the community; no specific use cases from which to give direction.

5

Helium

• Devised an internal PoC to demonstrate the value of abstract network intelligence to other groups in the company.

• We don’t want to program the network here; rather we want to enable an application to make better use of it.

• In this case, the internal CDN service.

• Conceptually we wanted an SDN App above ODL that would provide a very simple mechanism to help the CDN choose a better cache from which to deliver content to a given client.

• Aim was to provide better responses to load or failure of either CDN or the network but without requiring the CDN team to get intimate with the network.

• SDN App would compute the favorability of servers for a given client based on various metrics: distance, capacity, etc. It would eliminate some paths and rank the remainder. Stateless API.

• Intention was to use topology discovery in ODL (BGP-LS) and path compute.

• Again, limited path compute API exposure meant we implemented SPF in the SDN app.

6

Current work involving ODL

• Investigating how to turn the IP CDN work described earlier into a production service.

- ALTO project may be able to subsume most of the functionality.

- ALTO however feels far more complicated than we wanted this to be.

- ALTO implementations are thin on the ground and lack completeness.

• Using the LISP mapping service to build l3vpn’s.

- Using the LISP endpoints to program an OVS in a CPE-like device.

- Collapsing the LISP-based CPE into a cloudish service; dumb NID and layer 2 access overlay.

• Parallel work relating to SoftGRE and MPLS; might use ODL for this:

- Origination of the labelled BGP update message that indicates the NID end of a tunnel.

- Determination of the best termination point in the network for the local end of that tunnel.

- Would allow tight PCEP integration to signal the LSP path between PE’s.

7

Observations

• Usable documentation continues to be a challenge (though maybe I am only looking at the new projects all the time!)

• The startup time for ODL is beginning to rival big-iron devices.

• XML-based configuration is painful. Especially when it’s not well documented.

- I want network engineers to run the network. Not XML administrators.

• Vendor-supported ODL builds with secret-sauce plugins only available on that supported build are …undesirable.