Re: [homenet] HNCP

[Ray Hunter <[e-mail]>]

Mark Townsley wrote:
>
> All,
>
> In case anyone missed it, Markus and Pierre posted drafts and a 
> pointer to an implementation describing the Home Net Control Protocol.
>

Running code is very welcome.

> I'd like to provide some additional background, hat off.
>
> The work Markus, Stephen and Pierre have been doing is funded by a 
> "Cisco Technology Fund" grant. The purpose of this grant has been to 
> deliver technology backed by open source code that will be adopted by 
> a community willing to maintain it, with the ultimate goal of that 
> technology making its way into commercial product (for this to matter, 
> it needs to make it into far more than Cisco product). During its 
> first phase of operation, the main focus was on work originally 
> started by Jari Arkko, Acee Lindem, and Benjamin Paterson in OSPF by 
> fleshing this out in code and spec. Much was learned, and you may have 
> seen some of the results at various bits-n-bytes and in draft updates 
> (or the Markus' github if you were watching). The second phase, which 
> began after the Berlin IETF, has been to take what was learned in the 
> first phase and focus on:
>
> - upstreaming the technology into an open source project (in this 
> case, OpenWRT)
> - modularity and adaptability to other routing protocols (e.g., ISIS)
> - best-effort capabilities in simple topologies in case one common 
> routing protocol support was not available
> - integration with draft-behringer-homenet-trust-bootstrap 
> and draft-kline-default-perimeter
>
> The result after several months of heads-down effort is contained in 
> the drafts below. The document from pfister is an evolution of the 
> IPv6 prefix assignment work started by Jari, but in its own document 
> such that it can be referenced by to OSPF, ISIS, HNCP, etc. The two 
> from stenberg describe HNCP, as well as a general way to support 
> Stuart's work in draft-cheshire-mdnsext-hybrid in a zeroconf mannter 
> when the list of routers in a site is known (as HNCP does, or any 
> link-state routing protocol should).
>
> Personally, I was very skeptical when the team let me know that the 
> result of their analysis led them to the need to create HNCP. If 
> nothing else, between the OSPF work done in Phase one, and the HNCP 
> work in Phase two, these are two concrete examples in draft and code 
> form for the WG to examine to help decide the first question at the 
> top of Ole's flowchart posted here earlier.
>
> For those with no time to read the drafts, here's my one paragraph 
> synopsis of what HNCP does:
>
> HNCP uses the Trickle (RFC6206) algorithm to trigger when basic 
> configuration state for the homenet is out of sync on any router. 
> Essentially, a hash (or signature if security is present) over an 
> ordered list of the known homenet nodes and attributes necessary to 
> keep the homenet alive is handed over to Trickle. Trickle worries only 
> about that hash value, and whether all nodes agree that the value is 
> the same. When they don't agree, HNCP sends update messages between 
> nodes until Trickle is happy again. The HNCP document also defines 
> some specifics used in the OpenWRT implementation for border detection 
> (based on draft-kline-homenet-default-perimeter), some hooks for 
> integration with Behringer's trust bootstrapping (not 100% finished 
> though), IPv4 and IPv6 prefix distribution, and an auto-negotiation 
> mechanism depending on what type of routing protocol support is 
> available. In the event no common routing protocol is available, HNCP 
> defines a "fallback" mode that at least gets packets out the right 
> interface and avoids loops, even if the path is not ideal, has no 
> metrics, etc.
>
> This is all pretty close to what the team set out to achieve with the 
> 4 bullets above as constraints and guidelines. Of this I can't help to 
> be impressed. It came with a new protocol though, which shouldn't be 
> taken lightly, but indeed might be necessary. I look forward to what 
> the WG ultimately decides here.
>
> Finally, if you want to follow some of the work being done by Markus, 
> Stephen, Pierre, et. al. without necessarily logging into a github to 
> do it, you can poke around here: http://www.homewrt.org (it may be a 
> tad behind the latest-greatest though).
>
> Hat back on now… Tim, Ray and I are working with the ADs to get the 
> homenet-arch doc through the system. According to Tim, all DISCUSS 
> points have been worked out on email with ADs weeks if not months ago, 
> and the results are in -12 which has been posted. We're back to 
> prodding ADs for time and mental cache reloading of their issues for 
> them to clear. Once that is finished, the WG will finally be at a 
> point that it can "officially" work on solutions.
>
> Now, as Markus asked, "Discuss"! :-)
>
> - Mark
>
>
> Markus Stenberg <[e-mail] 
> <mailto:[e-mail]>> (and Pierre Pfister) wrote:
>
>> Drafts:
>> http://tools.ietf.org/html/draft-stenberg-homenet-hncp-00

I have read this draft. Quotes below marked > are from the draft....

> > Is there a case for non-link-local unicast?
Not IMHO. That could be extremely unstable and introduce circular 
dependencies on routing.


My comments on the obvious questions.

> > Q: Why not use TCP?
>
>    A: It doesn't address the node discovery problem.  It also leads to
>    N*(N-1)/2 connections when N nodes share a link, which is awkward.
>

Agreed.

> > Q: Why effectively build a link state routing protocol without
>    routing?
>

>
>
>    A: It felt like a good idea at the time.  It does not require
>    periodic flooding except for very minimal Trickle-based per-link
>    state maintenance (potentially also neighbor reachability checks if
>    so desired).
>
I can understand that you might need to produce a separate Homenet 
configuration protocol, especially during development, just so you can 
play with it a bit. Running code is welcome.

But what is fundamentally different in this protocol compared to if the 
TLV flooding was folded back into the IGP implementation?
Link state IGPs come with tried and tested flooding mechanisms.

I'm not yet convinced dynamic negotiation of routing protocol is a 
desirable feature.

> > Q: Why not multicast-only?
>
>    A: It would require defining application level fragmentation scheme.
>    Hopefully the data amounts used will stay small so we just trust
>    unicast UDP to handle 'big enough' packets to contain single node's
>    TLV data.  On some link layers unicast is also much more reliable
>    than multicast, especially for large packets.
>

The choice of multicast or unicast should be made based on the 
underlying local link technology.

There are links where multicast is cheap and desirable (to reach many 
neighbors simultaneously) and there are links where unicast is 
desirable, to avoid waking non-neighbors or where multicast is not 
supported.
> > Q: Why so long IDs?  Why real hash even in insecure mode?
>
>    A: Scalability of protocol isn't really affected by using real
>    (=cryptographic) hash function.
>
> > Q: Why trust IPv6 fragmentation in unicast case?  Why not do L7
>    fragmentation?
>
>    A: Because it will be there for a while at least.  And while PMTU et
>    al may be problems on open internet, in a home network environment
>    UDP fragmentation should NOT be broken in the foreseeable future.
>
UDP fragmentation also has some downside in lossy radio networks.

> > Q: Should there be nested container syntax that is actually self-
>    describing? (i.e. type flag that indicates container, no body except
>    sub-TLVs?)
>
>    A: Not for now, but perhaps valid design.. TBD.
>
> > Q: Why not doing (performance thing X, Y or Z)?
>
>    A: This is designed mostly to be minimal (only timers Trickle ones;
>    everything triggered by Trickle-driven messages or local state
>    changes).  However, feel free to suggest better (even more minimal)
>    design which works.


The biggest obvious question to me is why is it desirable to negotiate a 
common Homenet routing protocol on the fly?

Upside is that it avoids a heated debate for now. But what else does it 
deliver?

Downside is you are likely going to get huge code bloat. And developers 
will have to maintain and debug multiple code streams that may be only 
run infrequently.
Not a great combination in devices that traditionally have a poor record 
of running the latest and greatest code.

You may also import massive instability and long convergence times: 
neighbors that have a determining vote in which routing protocol is 
chosen may disappear temporarily, meaning that an entirely different 
routing family is chosen, only for these routers (e.g. tethered mobile) 
to re-appear a couple of minutes later, meaning the whole process has to 
be undone.

What happens when some neighbors have been updated for HNCP before 
others that they now need to run OSPF, but the existing protocol was Babel?

Does the Homenet have to shut down all forwarding while the trickle 
updates converge, to avoid potential routing loops?
Different routing protocols may well make different forwarding 
decisions, especially if their potential next-hop neighbor hasn't even 
started speaking a particular protocol yet.

And if you are going to do this, you'd better include subversions, as 
features are added e.g. OSPFv4 may be preferred over an older 
alternative routing family whereas OSPFv2 would not.


>> http://tools.ietf.org/html/draft-stenberg-homenet-dnssd-hybrid-proxy-zeroconf-00
>> http://tools.ietf.org/html/draft-pfister-homenet-prefix-assignment-00
>>
>> Experimental partial implementation:
>> https://github.com/sbyx/hnetd/
>>
>> Discuss.
>>
>> Cheers,
>>
>> -Markus
>> _______________________________________________
>> homenet mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/homenet
>

-- 
Regards,
RayH