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

[Acee Lindem <[e-mail]>]

In any case, I just scanned the architecture document and there doesn't appear to be anything that implies a routing protocol will be used to disseminate configuration. Hence, this discuss can be independent of the WGLC. 
Acee 
On Jun 25, 2013, at 4:23 PM, ietfdbh wrote:

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