Open Source Routing Overview

Open Source Routing (OSR) is an ISC project to assist in improving the quality and broaden
the operational applicability of the quagga routing software.

OSR’s goal is providing the appropriate resources and processes enabling the community to
develop a commercial quality, operationally trusted version of Quagga. This version will become
a strong stable baseline to enable networking innovation across multiple market segments.

OSR is not only working with the community of developers and contributors, but also
contributing our own resources (testers and developers) in improving Quagga

All the things we do will be open for community input and the results shared with the
community unless there is a specific extenuating circumstance.

We see quagga as a key element for the evolution of networking infrastructure and want to
move it to a commercial quality enabling operational alternatives to existing vendor products,
and enabling innovation in academic universities and service providers.

Our work will be focused on finding and fixing bugs, adding features that fill gaps and
helping with merging code back into the common pool for quagga.
How OSR fits into the quagga community

OSR sees itself as contributing to the community and not taking it over. We are committed to
maintaining the open design and architecture that exists with quagga today. OSR is working
with the community to provide the following capabilities:

a) Community contributed testing - a well defined and reusable test bed to ensure,
compliance, interoperability, resiliency, functional viability, and ensure scale and
performance on Quagga releases, patches, and bug fixes
b) Community re-integration - provide guidance and process around release
management, such as integration of private, public, and large patches which have been
orphaned - not integrated.
c) provide development resources to fix bugs, and potentially develop and integrate
features (based on major customer and community needs).

When new features are either contributed through OSR or developed by OSR, we will bring
the design and the code to the community to discuss and review. In the case of new work, this
will be done before development. In the case of finished work, the discussion will need to cover
the appropriateness for inclusion in the quagga mainline and things that need to be changed to
have it included.
Development
OSR is staffing up our development team now. Our initial target is to fix bugs and improve
the code quality. As time moves on, we will get into feature development and more involved
work. We are working on development guidelines for our work, and will share those with the
community. This is not done as a mandate but as a contribution for consideration in the broader
development effort. OSR development will be tightly coupled to our testing, as one would
expect.
We are looking at 3 typical workflows right now:

• bug fixes:

These are simple to moderate work against public code. We will submit patches for
review and incorporation. If the change is more complex, we will include a unit test for
validation. There is a subcase of this related to “bug bashes” where the community
comes together to fix lots of bugs in a short time.

• new features:

OSR will develop design documents for public review. We will then develop code and
unit tests which will then receive public review. Merging code into the mainline will be
handled the same way non-OSR submissions are.
 • critical fixes/vulnerabilities:

These require a very different approach. When an issue is discovered in the wild, the fix
must be done as quickly as possible, and OSR will put its development staff on the
problem if it has not been fixed by others in the community. If the issue is found by OSR
but it is not in the wild, OSR will contact a key developer list as well as CERT-FI and
immediately allocate staff to fix the bug. Coordination will be through CERT-FI.

Testing
OSR has identified a number of areas of testing that we will be focusing on. In each of these
areas, we will be developing test plans, providing them to the community for review and seeking
contributions from the community to improve the testing of quagga. We encourage others to run
our tests and look for areas where our testing needs further development.

Protocol conformance

We have one tool for protocol compliance testing, and have used that against OSPF, BGP
and RIP. We are in the process of testing it against IS-IS and the v6 protocols .We are are
looking at additional tools and ways to test for conformance and welcome things from the
community as well. One of the nice things about compliance tests is that they are designed to
run automatically, making them good, if slow, regression tests.
We have logged a series of bugs against bgpd and are preparing a set against ofpfd.

Interoperability

OSR is developing a lab of routers and other devices to verify interoperability. There is an
issue to be resolved when the RFCs say one thing and the major router vendors do something
different. It may be necessary to have a mode that turns off strict compliance when major
routers do something different.

Resiliency and vulnerability

This is a major area of concern for operational deployment of quagga. We have found on
crashing bug in OSPF and a locked up state in BGP with this work. We consider neither of
these to be significant vulnerabilities because they depend on man in the middle attacks that are
well known issues for unprotected routing protocol messages.
We have not yet begun vulnerability testing of quagga.

Scale and performance

This is an area where the OSR staff have significant prior expertise. We are developing a
strong set of traffic sources, from hardware testers to multiple ISP default free BGP feeds to
software generation, replay and manipulation tools. Early testing has shown BGP to have load
related race conditions and crashes, which we need to reduce into reproducible bugs.
In addition to finding bugs, demonstrating that quagga can process difficult live network
conditions is an goal of our work.
Performance metrics for various protocols will also be generated, so people can understand
the sizing requirements of various situations.
Field trials

OSR plans to gather a number of groups in diverse situations who are willing to introduce
new turns of quagga into places in their network. In anything other than a lab, this will need to
be part of a release testing process, as there needs to be reasonable assurance that the
software is well tested and expected to work.

Release testing

OSR will be doing our own releases to have control of the testing and merging aspects of
the release process. This will include increasing levels of testing, from running developer unit
tests through system testing to pre-releases into selected field environments. We will be
following an exit criteria model for our release work, such that all elements need to meet a set of
criteria to move to the next stage. We will be documenting this and putting it out for public
comment. There is a general timeframe to the release cycle, but it is the state of the entire code
base that determines the progress toward release.
This is done to tightly control the release testing process in OSR, not to usurp the process
for quagga releases. All the code is available to quagga for inclusion in releases as the
community decides.
Part of reaching the release testing goal is a significant automation of the testing system.
We are at the beginning of this effort and will be seeking community input on this work. We will
share all our work and hope that these automation tools will be of use beyond OSR.

Community participation

As of now, all existing code bugs found or new features tested will be added into
[Link]’s bugzilla. If it is decided that some other process would be better, we will work with
the community to develop what makes the most sense for the community
One of our focuses is to make the testing understood and available to the community. This
will include test plans, test cases, guidelines, support tools and anything else we can share.
Community feedback on this makes the overall testing stronger. This is and will always be a
work in progress, new features and new bugs create new tests and regression cases. We hope
this will make it easy for others to use our tests and increase the overall testing of quagga.

Reintegration
Reintegration is a special process for dealing with large code changes that have developed
without reintroduction to the mainline. There are a number of areas that have seen code that is
not part of the common quagga code and wants to be recombined. We will work with the
community to develop the process for this special work and will shepherd the process for code
areas that involve OSR and OSR member work.
This becomes most difficult when there are contributions for which the code change is major
and is likely to create incompatibilities with other code. The worst case is when there are more
than one major reworks against the same code. Each part of quagga will be its own
reintegration project and will address the specific situation.