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

["ietfdbh" <[e-mail]>]

Hi,

Just a comment ...
You say " There is an IETF standard configuration protocol, and that's
DHCPv6."

Actually, the IETF has a number of configuration protocol standards, not
just DHCPv6.
(Standards are wonderful; everybody should have one!)
If you are going to consider using a standard configuration protocol, then
you should also consider, depending on an analysis of the specific needs for
homenet:
 DHCP, Netconf, RADIUS, Diameter, CAPWAP, COPS-PR, and SNMP, amongst others.

 Some of these I would not recommend for homenet, but they are IETF standard
configuration protocols.

David Harrington
[e-mail]
[phone]

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Juliusz Chroboczek
Sent: Tuesday, June 25, 2013 12:31 PM
To: [e-mail] Group
Subject: [homenet] Configuration must not be carried by the routing protocol

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