Subject: [homenet] HCNP: my points this morning

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 04 Mar 2014 14:56:40 +0000

Hi,

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

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.

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

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.

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.

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

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

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.

-- Juliusz

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 4 Mar 2014 15:35:34 +0000

> 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 ;)

> parts be made optional?  I'd personally like the DNS proxy stuff to be

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.

> 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_)

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

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

> 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

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.

> 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

---

From: Steven Barth <[email-masked]>
Date: Tue, 04 Mar 2014 19:06:27 +0100

>> 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. 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…
I suppose we want to differentiate between transport and payload here.
I'm not sure if splitting it up into individual drafts might make sense
but definitely - as I also pointed out in the presentation - it wasn't
meant to be interpreted in a way that any of the non-protocol related
TLVs are mandatory. Though in practice there are some inter-dependencies
between payloads atm, e.g. both the fallback-routing and the DNS/SD
stuff somewhat reuses prefixes and / or address-information announced by
the PA-mechanism.

> 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 _draf…
I don't know if we really consider a /128-assignment to be a prefix in
that sense. I would see this as a special case to aid in meshing and
similar so I think maybe adding a special kind of _assigned_ prefix type
of some sort might make sense for this from which every (supporting)
router should be able to pick a /128 regardless of the link.

> 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 som…
I'm not sure if that makes sense either. HNCP is a pretty agnostic
protocol and -please prove me wrong- I can only really see a point for
this for extensions to the actual transport or security logic. This also
refers to the discussion if we want mandatory payloads.

>> interfaces.  Knowledgeable people appeared to disagree.
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.
> 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…
I wouldn't really do it like that. Even though I agree with the 0-1 or 1
routing protocol agenda I wouldn't really do negative capability
announcements. If for some reason you want to make changes or use HNCP
for other purposes later this will get ugly.

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 4 Mar 2014 18:31:03 +0000

> stuff somewhat reuses prefixes and / or address-information announced by

Splitting TLV-only content to separate drafts (especially now that they have little extra content) probably wouldn’t help much. (Mostly because it would create bunch of very minimal drafts with at least strong dependencies on the generic drafts, and the core draft). I suppose the right way forward on that front is just to specify that extra feature sets are SHOULD/MAY-ish, and if implementing that feature set, relevant MUST/SHOULDs there.

> router should be able to pick a /128 regardless of the link.

We already have that assigned address TLV anyway, so given extra assigned prefix bit (we have 3 reserved ones), it could be probably fairly straightforward to do /128 allocations using this.

Logic along the lines of: 

- if /128 allocations are desirable, allocate one assigned prefix with <whatever size> and bit X=1 (possibly even allow multiple ones in race cases?)
- and then just allocate stuff from there.

> homenet-interfaces here if they have to wait for HNCP to assign prefixes

I suppose that if you were ambitious and wanted to run this non-root on non-suid binary system (e.g. Android) it would make sort of sense, because you’d want to do things as root early in the boot time and then just configure existing services (with sufficient privileges to do what is needed). 

> for other purposes later this will get ugly.

Hmmh, with 1 routing protocol agenda negative capability is not really needed in any case (in that one, you just assume routing happens and everyone lives happily ever after). So how do you think the 0-1 should be done?

- option a: negative capability indication, mixed network (what I wrote)

- option b: ‘support protocol X/Y/Z’ => mixed network (with explicit support for fallback too(?), somehow know/avoid bad combinations?)

- option c: ‘support protocol X/Y/Z’ =>  0/1 routing protocol in whole home

If I were <random ISP customer>, and they sent me braindead router, I’d be unhappy with option c as it would force 0 routing protocols in whole home. But that’s where you’d get with e.g. current hncp-00 text. Same thing with transitions between 0 and 1 routing protocols in a whole network, which I would rather avoid.

Cheers,

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 04 Mar 2014 18:50:14 +0000

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

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

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

>>> by the config daemon.

> homenet-interfaces here if they have to wait for HNCP to assign prefixes

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

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 4 Mar 2014 23:01:09 +0000

On 4.3.2014, at 18.50, Juliusz Chroboczek <[email-masked]> wrote:
> can be done in two hundred lines of code or so.  (Yes, I’m volunteering.)

It’s mostly the 0 real routing protocols case on some routers that it addresses. However, I’m perfectly happy to live with the ‘1 routing protocol, always’ mode of operation too ;)

Just snooping wouldn’t work very well, as for assuming no-real-routing arbitrary node in topology, both it and it’s neighbors have to do manual route maintenance to keep packets flowing. The fallback option (documented in hncp-00) would work, though, if the affected node and it’s on-link neighbors would do it.

Cheers,

-Markus

---

From: Pierre Pfister <[email-masked]>
Date: Wed, 5 Mar 2014 09:03:58 +0000

I agree with Markus and Steven on most points, but let me clarify a few aspects.

- First, I think this is really cool if another area wants to use hncp. So I don’t see any reason we couldn’t adapt the documents to allow it. We should be careful *not* to make homenet specifications too complex thought. Having too many abstraction layers may not be desirable.

- As Markus said, I think removing some TLV’s from hncp transport layer specifications is not a problem. We can have a specification for hncp-transport, and another for hncp-homenet. I’m a bit more concerned about removing trickle algorithm behavior. We can abstract the TLV layer, but abstracting upper AND lower layer seems too ambitious. Having the network to correctly converge, and efficiently enough, is not an easy requirement. Trickle is lightweight, efficient, proven for this purpose. I think hncp should precisely specify the packets transmission behavior.

- The prefix assignment algorithm supports /128. I’m not sure we want Homenet to have such ‘carve it into /128’ option. Homenet doesn’t want to do that.

- Homenet-hncp intends to be incremental in terms of TLVs. Other TLVs will come, and, if hncp is widely used in homes, vendor-specific options will come as well. So I think ‘ignore TLVs you don’t know’ is the correct behavior.
Nevertheless, I understand hncp could be used for other purposes, in different contexts. But such use should run in different instances. Using a different UDP port, *or* creating a ‘context’ TLV or header value (With defined ‘homenet’ context, ‘ahcp’ context, etc…). Of course, in terms of performances, using a different UDP port is desirable.

- Concerning the routing protocol, finally. Although I like the 0,1 option and that negotiating a routing protocol doesn’t disturbs me so much, I think most vendors will only implement the 0 if they can… So, for Homenet, I think we are going to end up with a single RP. I may be dreaming, but I would like to see the hncp-routing (0 RP), because it would avoid a lot of redundancy in propagated information. But for that purpose, we’ll have to prove its design is correct.
Then, if we make a hncp-transport document, it will be completely agnostic to this routing stuff. Only hncp-homenet will. Using a different ‘context’ or UDP port, you could just define your own behavior for hncp-ahcp regarding routing.

- Thanks for you comments. It’s a very interesting discussion.

Le 4 mars 2014 à 14:56, Juliusz Chroboczek <[email-masked]> a écrit :

> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Mar 2014 22:29:02 +1300

> - The prefix assignment algorithm supports /128. I’m not sure we want Homenet to have such ‘carve it into /128’ option. Homenet doesn’t want to do that.

It was pretty clear in 6man yesterday that there is little support
for longer subnet prefixes than 64, and they are forbidden by the
homenet architecture. All the same, it seems to me that routing
should be strictly VLSN (and that is the IPv6 routing architecture).
So I think that basic protocols should be agnostic on the prefix
length, which means allow anything out to /128.

An implementation should follow the homenet architecture, of course.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Mar 2014 06:09:24 -0500

> - First, I think this is really cool if another area wants to use
    > hncp. So I don’t see any reason we couldn’t adapt the documents to
    > allow it. We should be careful *not* to make homenet specifications too
    > complex thought. Having too many abstraction layers may not be
    > desirable.

Copy and paste is an acceptable way to develop specifications.
The IETF owns the text, if someone wants to use it, let them write a
document.  If the documents can be converged later on, great.

    > hncp-transport, and another for hncp-homenet. I’m a bit more concerned
    > about removing trickle algorithm behavior. We can abstract the TLV

If you remove trickle, then you might as go back to OSPFv3.

    > - Homenet-hncp intends to be incremental in terms of TLVs. Other TLVs
    > will come, and, if hncp is widely used in homes, vendor-specific
    > options will come as well. So I think ‘ignore TLVs you don’t know’ is
    > the correct behavior.  Nevertheless, I understand hncp could be used

We actually need a "critical" bit on the Type value then.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting for hire =-

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 27 Mar 2014 08:07:58 +0100 (CET)

> We actually need a "critical" bit on the Type value then.

Or some kind of "feature election" within the home? Just the way HNCP now 
has a kind of voting system for which IGP to choose (which might go away 
since we only want a single IGP), perhaps we need a mechanism to choose if 
a feature is used within the home or not. This would only apply to some 
features that actually need the entire home to support the feature for it 
to work correctly.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 27 Mar 2014 09:29:50 -0400

Mikael Abrahamsson <[email-masked]> wrote:
    >> > - Homenet-hncp intends to be incremental in terms of TLVs. Other
    >> TLVs > will come, and, if hncp is widely used in homes,
    >> vendor-specific > options will come as well. So I think ‘ignore TLVs
    >> you don’t know’ is > the correct behavior.  Nevertheless, I understand
    >> hncp could be used
    >>

    > Or some kind of "feature election" within the home? Just the way HNCP
    > now has a kind of voting system for which IGP to choose (which might go

That's a higher level concept than understanding whether a particular tlv
can be decoded or not.

Or: I am not disagreeing with you, but saying it is an orthogonal issue.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-