REconfiguration matters
Network configuration and management is an important problem
for all network operators. IP networks are
implemented by using a large number of switches and routers from
different vendors. All these devices must be configured by the operators
to maximise the performance of the network. In some networks,
configuration files contain several tens of thousands of lines per
device. Managing all these configurations is costly in large networks.
Some researchers have worked on analysing the complexity of these
networks and proposing abstractions to allow operators to better
configure their network. Still, network configuration and management is often closer to an art than
to science.
Researchers often consider the network configuration problem as a design
problem. Starting from a blank sheet, how can a network operator define
his/her objectives and then derive the configuration files that meet these
objectives. This is not how networks are operated. Network operators
almost never have the opportunity to design and configure a network from
scratch. This only happens in new datacenters or new entreprise
networks. In their recent work, Laurent Vanbever,
Stefano Vissicchio and other
colleagues have addressed a slightly different but much more relevant problem :
network REconfiguration. There are only two letters of difference between
network configuration and network REconfiguration, but these two
letters reflect one of the important sources of complexity in managing a
network and introducting new services. Once a network has been
configured, it must remain in operation 24h per day, 365 days per year.
Network equipment can remain in operation for 5-10 years and during
their period their role in the network changes. All these changes must
be done with as few impact as possible on the network.
To better understand the difficulty of reconfiguring a network, it is interesting to have
a brief look at earlier papers that deal with similar problems. A decade
ago, routing sessions had to be reset for each policy change or when the
operating system of the router had to be upgraded. Aman Shaikh and
others have shown that it is possible to update the control plane of a
router without disrupting the dataplane [SDV06].
Various graceful shutdown and
graceful restart techniques have been proposed and implemented for the
major control plane protocols. Another simple example of a
reconfiguration problem is when operators need to change the OSPF weight
associated to one link. This can happen for traffic engineering or
maintenance purposes. This change triggers an OSPF convergence than can
cause transient loops. Pierre Francois and others have proposed
techniques that allow these simple reconfigurations to occur without
causing transient forwarding problems [FB07][FSB07].
Another step to aid network
reconfiguration was the shadow configuration paper [AWY08]
that shows how to run different configurations in the same network at a given time.
During the last years, several network Reconfiguration problems have been addressed.
The first problem is the migration from one configuration of a
link-state routing protocol (e.g. OSPF without areas) to another
link-state routing protocol (e.g. IS-IS with areas). At first glance,
this problem could appear to be simple. However, network operators who
have performed such a transition have spent more than half a year to
plan the transition and analyse all the problems that could occur.
[VVP+11] provides first a theoretical framework that
shows the problems that could occur during such a reconfiguration. It
shows that it is possible to avoid transient forwarding problems during
the reconfiguration by using a ships-in-the night approach and updating
the configuration of the routers in a specific order. Unfortunately,
finding this ordering is an NP-complete problem. However, the paper
proposes heuristics that find a suitable ordering and applies it to real
networks and provides measurements from a prototype reconfigurator that
manages an emulated network.
A second problem are the BGP reconfigurations. Given the complexity of BGP, it is
not surprising that BGP reconfigurations are more difficult than IGP
reconfigurations. [VCVB12] first shows that signalling and forwarding
correctness that are usually used to very iBGP configuration are not
sufficient properties. Dissemination correctness must be ensured in
addition to these two properties. :cite:`6327628`_ analyses several iBGP
reconfiguration problems and identifies some problematic configurations.
To allow an iBGP reconfiguration, this paper proposes and evaluates a BGP
multiplexer that combined with encapsulation enables iBGP
reconfigurations. The proposed solution provably enables lossless BGP
reconfigurations by leveraging existing technology to run multiple
isolated control-planes in parallel.
This work on REconfiguration has already lead up to some follow-up work. For example,
[RFR+12] has proposed techniques that use tagging
to allow software-defined networks to support migrations in a seamless manner. We can expect to rad
more papers that deal with REconfiguration problems in the coming years.
| [RFR+12] | Mark Reitblatt, Nate Foster, Jennifer Rexford, Cole Schlesinger, and David Walker. Abstractions for network update. In Proceedings of the ACM SIGCOMM 2012 conference on Applications, technologies, architectures, and protocols for computer communication, SIGCOMM ‘12, 323–334. New York, NY, USA, 2012. ACM. URL: http://doi.acm.org/10.1145/2342356.2342427, doi:10.1145/2342356.2342427. |
| [VVP+11] | Laurent Vanbever, Stefano Vissicchio, Cristel Pelsser, Pierre Francois, and Olivier Bonaventure. Seamless network-wide igp migrations. In Proceedings of the ACM SIGCOMM 2011 conference, SIGCOMM ‘11, 314–325. New York, NY, USA, 2011. ACM. URL: http://inl.info.ucl.ac.be/publications/seamless-network-wide-igp-migrations, doi:10.1145/2018436.2018473. |