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

[Ole Troan <[e-mail]>]

what do we need for distributing configuration information between routers?
a distributed database.

what's a routing protocol?
a distributed database.

do we need to invent a separate distributed database for each class of information?

cheers,
Ole


On Jun 25, 2013, at 12:30 , Juliusz Chroboczek <[e-mail]> wrote:

> 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/
> _______________________________________________
> homenet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/homenet