[homenet] Configuration must not be carried by the routing protocol

[Juliusz Chroboczek <[e-mail]>]

Dear editors, dear group,

After the recent thread on this list, and a number of private mail
exchanges, I'm under the impression that there might be a consensus
that configuration information should not be carried over the routing
protocol.  In this mail, I argue that

  configuration information should be carried by a protocol separate
  from the routing protocol.

We should therefore make serious efforts to ensure that nothing in the
arch documents prevents carrying configuration information in
a separate protocol.  Ideally, we should include language in the arch
document that encourages such a separate implementation, but I'm not
sure if we can build consensus at this point.

This mail is structured as follows:

1. advantages of carrying configuration information over the routing protocol;
2. advantages of carrying configuration information over a separate protocol;
3. possible configuration protocols;
4. conclusions.


1. Advantages of carrying configuration information over the routing
   protocol

I've heard the following advantages claimed for conflating the two functions:

(i)  it is not necessary to implement a new flooding protocol, which
     saves space on resource-limited routers;
(ii) all routers participate in the routing protocol, while a new
     configuration protocol requires ensuring that all routers forward
     the configuration information.

As I've shown with AHCP[1,2], however, a reasonably efficient, purely
user-space, increasing diameter flooding protocol can be implemented
in a hundred lines of C code or so, and takes just a few kB of flash
and a few bytes of memory; this is why I find point (i) above
unconvincing.  Additionally, since homenet is planning to mandate the
implementation of a new routing protocol on all home routers, mandating
a configuration forwarding daemon does not break compatibility any further.


2. Advantages of separating configuration from routing

There are significant advantages to distributing configuration
information over a separate protocol.

(i)   distributing configuration information on a simple dedicated
      protocol makes monitoring and trouble-shooting easier;
(ii)  the architecture is more robust -- issues with the routing protocol
      do not prevent configuration information from being distributed;
(iii) should new requirements arise, it is possible to reuse most of the
      homenet architecture with a new routing protocol;
(iv)  should new requireent arise, it is possible to reuse most of the
      homenet architecture while running multiple routing protocols.

Point (i) is important -- experience with DHCPv4 and RA shows how easy
it is to run into issues with configuration protocols, and how useful
it is to be able to identify and decode configuration packets without
having a full understanding of a complex routing protocol.

Point (ii) is probably of secondary interest, since all implemen-
tations of link-state protocols are perfectly robust and completely
debugged.  However, we all know the pain of recovering a router that
has lost its IP addresses, anything that avoids such pain should be
welcome.

Points (iii) and (iv) are very important to me.  I firmly believe that
once homenet starts being deployed, smart amateurs are going to start
building topologies that we don't even dream of, using link
technologies that we never heard of.  Most probably, the homenet
routing protocol can then be extended to deal with the new topologies;
but before this happens it will be important that people can reuse the
homenet architecture with a different protocol.  Hence, it is vitally
important that the homenet architecture be modular enough to allow
switching routing protocols.


3. Possible configuration protocols

3.1 RA

RAs are ignored by routers, and rightly so -- RAs have no loop
avoidance mechanism, and using RAs to configure routers leads to
a number of problems that I believe to be unsolvable.  Extending the
RA protocol to be suitable for configuring routers is probably not
worth the hassle, and will lead to confusion.

3.2 DHCPv6

There is an IETF standard configuration protocol, and that's DHCPv6.
Other people on this list are more knowledgeable about DHCPv6, so I'll
refrain from making a fool of myself; however, I'll take the risk of
claiming that DHCPv6 (probably with extensions) looks like an
eminently suitable protocol for configuring homenet routers.

3.3 A new protocol

In the Babel experiment, I have designed a new protocol, which
I called AHCP[1,2].  Since AHCP is designed to run before routing is
functional, it makes minimal assumptions about the network -- it only
requires each interface to have a link-local IPv6 address and to be
able to participate in link-local multicast traffic.  An AHCP client
implements an increasing diameter search for an AHCP server.

The full AHCP implementation (client+server+forwarder, with support
for Linux and BSD Unix), consists of 3500 lines of C and 350 lines of
bourne shell code, and compiles to less than 40 kB.  Subset implemen-
tations are possible.  We have found AHCP to be very robust and
reasonably fast even in the presence of massive packet loss.  The
traffic generated is very reasonable, even when simultaneously
rebooting the whole network.

I am not pushing AHCP as the homenet configuration protocol, since
I have good hope that a variant of DHCPv6 can be used.  However, I do
hope that the results of the AHCP experiment can serve as useful input
for this group.


4. Conclusions

For the reasons outlined above, it is my firm opinion that configuration
information should not be carried by the Homenet routing protocol.  Homenet
routers should either be configured by a variant of DHCPv6, or a new
protocol should be designed.

The arch document should be carefully reviewed, and anything that
risks impeding such a solution must be eliminated.  Ideally, the arch
document should encourage separating configuration distribution from
routing.

Should DHCPv6 be finally chosen, I will be glad to collaborate on writing
a tiny DHCPv6 daemon suitable for homenet.  (And I have a fair amount
of experience with writing tiny network daemons to run on 8MB routers.)


[1] http://tools.ietf.org/html/draft-chroboczek-ahcp
[2] http://www.pps.univ-paris-diderot.fr/~jch/software/ahcp/