>>> 0. As far as I'm concerned, this is not "The Homenet Configuration
>>> Protocol", this is a configuration protocol for unmanaged routers that
>>> happens to have been designed by the Homenet group. Please keep this
>>> in mind when you read the following.
> The thing is how much do we want to speculate to make it suitable for
> other unknown usecases. I don't really want to overengineer it based
> upon unknown requirements.
Agreed. I'm looking at it from the point of view of "when can I dump
AHCP", which might not be relevant for this working group. On the
other hand, we've done a lot of experimenting with AHCP, so I would
claim that learning from the (few) relevant bits of AHCP wisdom might
be beneficial.
>>> 2. Related to the previous point, is everything MUST, or should some
>>> parts be made optional? I'd personally like the DNS proxy stuff to be
>>> made optional.
> I suppose we want to differentiate between transport and payload here.
Yes.
> I'm not sure if splitting it up into individual drafts might make sense
My personal preference would be to keep it a single draft, and only split
it if we find out that one part is holding up the others (i.e. if we find
that the transport part is ready to go RFC, but payload still needs work).
>>> 3. There would appear to be no way to specify "please carve this
>>> prefix into /64 or shorter" as opposed to "please feel free to grab
>>> a /128 in this prefix”.
> I would see this as a special case to aid in meshing
That's of course the intended application, but there are others.
VPNs, point-to-point links, management interfaces.
>>> 4. Do we want the ability to mark an option as mandatory,
>> I’m slightly concerned about that
> I'm not sure if that makes sense either.
Ok, point taken.
>>> 5. I don't think the routing protocol should be negotiated by the
>>> config protocol, since that implies that the routing daemon is started
>>> by the config daemon.
> I would disagree here. I don't see the point in starting the daemons for
> homenet-interfaces here if they have to wait for HNCP to assign prefixes
> / addresses anyway.
Let me try to explain where I'm coming from. There are two arguments.
(1) IPv6 based routing protocols (including at least RIPng, OSPFv3 and
Babel) are able to route over unnumbered interfaces using link-local
addresses. OSPFv3 and Babel start sending hellos as soon as there is
a link-local address on the interface, and establish adjacencies
straight away. If the local addresses change, the adjacencies are not
torn down as long as the link-local address remains the same.
AHCP versions 0 and 0.5 (protocol version, not the version of the
software) used to negociate the routing protocol over AHCP. The
result was that whenever the AHCP configuration changed, the routing
daemon was stopped, lost all adjacencies, including the Hello history.
In AHCP version 1 (protocol version), the routing protocol runs in
parallel to AHCP. When AHCP changes configuration, the routing
protocol keeps running -- retains all adjacencies and link-quality
data. Loss of connectivity is on the order of milliseconds.
Now AHCP is used in mesh networks, with often have poor connectivity.
Spurious AHCP expirations happen regularly (not often, just regularly).
Users like the fact that connectivity resumes as soon as they get back
into range -- and that's due to retaining the Hello history.
(2) With AHCP version 0/0.5, the OpenWRT and Debian init scripts used
to check if AHCP is installed before deciding to start Babel -- the
assumption was that AHCP would start Babel when it got configuration
information. With AHCP version 1, Babel is started unconditionally.
The packagers like that -- it feels much less brittle. And I like
happy packagers.
>> Add a no-routing-TLV (zero content) which means that routes towards
>> this node have to be done without routing protocol (by other HNCP
>> nodes that support real routing protocol).
Could you please spell out what problem you're trying to solve? If
the problem is nodes with limited resources, then let's choose
a protocol that allows minimal implementations. Snooping on RIPng or
Babel and installing a default route (using a hackish system("ip route add"))
can be done in two hundred lines of code or so. (Yes, I'm volunteering.)
-- Juliusz
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
