Building a Router

Editor's Notes

• #2: Dear <name>, thanks for giving me the opportunity to present my my upcoming venture called ‘rtbrick’. As the name ‘brick’ implies we want to build a modular, scalable routing software targeted to a disintegrated network market.
• #4: Our mission & vision is to make Application and Networking integration seamless. Up to today it is hardly possible to set a massive amount of networking state from an application. If an Application wants to influence forwarding state or a routing policy one has to go through detours of vendor proprietary command line and scripting interfaces. Too often those proprietary interfaces have upper boundaries on the amount of transactions they can process. – Depending on the vendor and OS being used this can vary from one transaction every 10 seconds to a few 10s of transactions per second. The bottleneck also applies to export of telemetry data like link utilization, delay measurements - using the SNMP and netconf vehicles only a few 10s to 100s of state information may get extracted. This clearly does not work if you want to implement fast feedback loops between applications and the network.
• #5: Our view of the network is that it has to be a hybrid across all layers (overlay and underlay). It is the combination of dynamic routing-protocols and Controller information which make networks manageable and resilient. Dynamic Routing Protocols are a good tool for discovering the topology and bootstrapping the internal network. For the time being, Internet Routing will rely on BGP4 and extensions.
• #6: Companies like Google, FB, Netflix have demonstrated the clear value of DevOps as an organizational model. It improves time-to-revenue in every possible angle. However, many SPs are yet undecided if they want to build up software development expertise due to the perceived high entry cost Hence our core offering is to reduce the cost of running a DEVOPS model - the toolkits that we provide allows rapid feature introduction from development down to an integrated test environment.
• #7: The inherent promise of DEVOPS is to reduce the Time-to-revenue of new network functionality which is today order of months Using our system new network functionality can be developed, tested and rolled-out in a a few days
• #8: Our Offering is build around 4 Principles
• #9: The core of the system is a distributed data store which holds every state in the system. Irrespective if it is interface information, IS-IS adjacencies, BGP RIBs or forwarding tables – every state is stored in the back store. Brick Data Store (BDS) it is a model-driven indexing and data replication vehicle. BDS has been designed for speed and consistency – data insertion can progress as fast as 1M updates per second per CPU core. The back store is configured by defining tables, objects and its attributes akin to a SQL server using a json config file. The back store also allows to quickly locate who is the originator of a an object and generate local replicas of that data for local (in-situ) processing. BDS is fully horizontal scalable, so if there are large tables (like for example RIB-ins) then it can shard the workload across a set of worker processes) all of the shard-ing can happen without changing a single-line of code The database centric design allows us to do all the cool-HA things, like doing live-software upgrades, restart of components without loss of service, etc. – Furthermore this design paradigm greatly minimizes the amount of boiler-plate code that one has to do to develop new networking code.
• #10: Before coming to conclusions about what is broken in the Industries’ prevailing software delivery model, one first has to analyze how software is built, extended, and maintained over time. Assume Vendor A has a working, scalable implementation of a piece of networking software; let’s say a routing protocol. Over time, Service Provider customers, come up with all sorts of enhancement requests; some more useful than others. Usually, the enhancement request gets prototyped first, validated, and then merged back into the main line code. The fundamental problem here, is that it is not possible to de-feature certain functionality once merged. It is not possible to custom-tailor what the customer wants. There is no package manager that allows you to mix and match packages. There is no component that allows you to uninstall certain packages that you do not need. Just ask your networking vendor for the following tailor-made software release: IS-IS, BGP for IPv4 and IPv6, no OSPF. no LDP, no RSVP Not possible? - Reason it is not possible is because things have been constructed as a monolithic system, mostly by just compiling a new feature. Most often, a given feature is intimately linked to the underlying infrastructure (like an in-memory database, or some event queue processor), and, removing it out of the code base, may get to an effort as large as originally developing the feature. In most cases there is no dedication on how to clean things up later. Every added feature will make future feature additions harder. If you just make the number of supported software features large enough, you can extrapolate, that at some point, this will become unmaintainable. At RtBrick we have a small core and all functionality is added using the Debian package manager, All of our App source code get published on GitHub such that App developers can have a look at it.
• #11: An old saying in the SW industry is: show me your testing and integration code and I’ll show you the quality of your code. As such any open-source effort that comes without the accompanying test-environment is futile. At RtBrick we’ll share the test and integration framework together with our devops customers. They way it works is at follows – first a real world network topology, configuration and interface names gets pulled from the live network into a model. Based on that synthesized network model the to-be-rolled-out code gets unit and integrations tested.
• #12: If there is no nuclear blowout, then the code finally gets deployed using the fleet manager. Our Devops customers are encouraged to publish their test-cases on Github, such that we can leverage the network effect in testing and rapidly harden the quality of the shared code.