Re: [homenet] HCNP: my points this morning

[Markus Stenberg <[e-mail]>]

On 4.3.2014, at 14.56, Juliusz Chroboczek <[e-mail]> wrote:
> During this morning's session, I mentioned how much I like the HCNP
> protocol, and that I'm looking into abandoning AHCP for a hacked-up
> HCNP.  I made the following points this morning:
> 
> 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.
> 
> 1. The draft seems overspecified at times.  Do we really mandate
> Trickle, or do we want just an abstract description of flooding
> requirements?  (Knowledgeable people commented that Trickle is fine.)

Problem with abstract requirements is that it’s easy to get them wrong. For example, ‘up to once per minute =~ once a minute?’ in hands of a creative reader. ‘Use Trickle with these constants’ is a short form for describing exponential backoff system which suppresses duplicate multicast messages from my point of view.

I’m soliciting input on how this could be better, though (in a way which is unlikely to be broken by lowest common denominator implementor). As always, pull requests welcome ;)

> 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.

Agreed. It started as a separate draft and MUST in separate draft was sensible but now, well.. I’m wondering even about PA stuff, because if you want to use different algorithm, it should be ok as long as you publish your delegated/assigned things in a compatible way.

> 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”.

Hmmh. Do you think it’s issue in the hncp-00 or prefix-assignment one? I’m not exactly sure I want ‘purpose’ bits for delegated prefixes. (see above also on mandatoriness of prefix-assignment _draft_)

> 4. Do we want the ability to mark an option as mandatory, as in
> "Please don't configure unless you understand the following TLV, and
> intend to act upon it".  One the one hand, this makes is easier to
> design compatible extensions to the protocol (by sending two
> configuration blocks, one with a mandatory incompatible option, one
> without the option, and having old routers ignore the block with the
> incompatible option).  On the other hand, it adds another failure mode.

I’m slightly concerned about that - from my point of view, ideal way to extend is to ignore unknown TLVs, and then embed all information that requires understanding the TLV _within_ that TLV in some way. 

> 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.  The routing daemon(s) should be started at
> boot, and notice when the config daemon adds IP addresses to
> interfaces.  Knowledgeable people appeared to disagree.

There seems to be various assumptions around. I think I have heard fairly good arguments towards different solutions (turning routing protocol on or off based on configuration, ‘always routing if possible using real protocol’ (possibly one of many)). I am not yet convinced the either way.

> (It seems to me that the config protocol should be routing-protocol
> agnostic, and merely say "this protocol assumes that a routing
> protocol satisfying the following conditions is available".  Homenet
> should specify what the protocol is, and mandate implementation of The
> One Homenet Routing Protocol (OHRP).)

From specification and dependency point of view, HNCP which assumes OHRP would work, _given_ we can assume everyone implements OHRP. If not, we wind up in the rathole of 0-1 routing protocols and the effects which trigger even that single OHRP on and off.. sigh.

> I'd like RIP to be the OHRP, but I don't have strong opinions on the
> subject.

On general level, I’m ‘RIP.. really?’ (does someone have an open-source RIP implementation which _does_ fullfill the requirements? And no, it doesn’t count if you patch existing one ;->). And yes, I know it happens in routers a lot, and I also know the implementation changes aren’t probably significant but still.

> I also don't care whether Homenet says that routers MUST implement
> OHRP, or whether they MUST implement OHRP and MAY implement other
> routing protocols.  In either case,
> 
>  - commercial Homenet router vendors will implement the OHRP and
>    ignore the MAY protocols;
>  - the OpenWRT routing overlay will probably install the OHRP by
>    default, but provide its usual set of optional routing daemons.
> 
> In short, there will be no difference in practice whether Homenet
> allows non-Homenet routing protocols or not.

I have thought about this for a while now (and the discussions in IETF have been helpful too). I really wonder how needs of everyone can be taken care of (notably, the crowd that wants 0 routing protocols).

My preliminary thought is as follows, repurposing the fallback routing - let me know if this sounds bad:

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). The no-routing node can also do routes towards other nodes similarly. (This has underlying assumption that HNCP TLV space covers all prefixes we care about, which is probably sufficient for packets to flow although possibly suboptimally.)

In this approach, there would be _no_ indication about routing protocol being used, and just an assumption that administrative domain has chosen one; for homenet case, it would be OHRP except for nodes which opt out of OHRP altogether and raise the no-routing flag. 

Admin or someone else who sets up a set of routers with different purpose on the other hand could configure (one or more) non-OHRP routing protocols and HNCP itself would be usable in that case too (and no magic, and no strong binding between configuration and routing).

(General zero routing protocols case is even simpler, but I am not very happy with OHRP = current hncp-routing idea.)

Now that I think more of this, giving an opt-out of routing would (by Juliusz’s logic) most likely lead to most simple implementations not doing OHRP at all in any case. Hmm. So fundamentally the choices boil down to (as far as I see them):

[1] 0/1-N routing protocols (OHRP in case of homenet, or something else elsewhere) per router (as long as the administrative distances/priorities work out ok)
[2] 1 routing protocol, period (OHRP in case of homenet) per administrative domain, on _every router_
[3] 0 real routing protocols (fallback-only)

Personally, [3] would make me a sad panda. [2] sounds nice, but I wonder if the crowd that is speciffying future SPERs etc are happy about adopting OHRP all over the place (and if not, there is a failure mode there right away). [1] is described above and is probably ‘political layer proof’ but not pretty due to the extra TLV shenaginans I describe above.

Cheers,

-Markus