opendaylight at comcast chris luke sr. principal engineer
Post on 17-Dec-2015
216 Views
Preview:
TRANSCRIPT
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.
top related