Subject: [homenet] Two new drafts (and third one 'soon')

From: Markus Stenberg <[email-masked]>
Date: Wed, 5 Feb 2014 16:52:09 +0200

Drafts:
   http://tools.ietf.org/html/draft-stenberg-homenet-hncp-00
   http://tools.ietf.org/html/draft-stenberg-homenet-dnssd-hybrid-proxy-zeroconf-00
   (Generic PA one in the works, but submitted also ’soon’)

Experimental partial implementation:
   https://github.com/sbyx/hnetd/

Discuss.

Cheers,

-Markus

---

From: Mark Townsley <[email-masked]>
Date: Thu, 13 Feb 2014 09:41:36 -0800

All,

In case anyone missed it, Markus and Pierre posted drafts and a pointer to an implementation describing the Home Net Control Protocol. 

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 <[email-masked]> (and Pierre Pfister) wrote:

>   http://tools.ietf.org/html/draft-pfister-homenet-prefix-assignment-00 
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: "Townsley.net" <[email-masked]>
Date: Thu, 13 Feb 2014 10:22:30 -0800

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

I forgot to add that, after looking deeper  into what had actually been done, I warmed up to the idea greatly. That's just me though...I look forward to what others think here. 

- Mark

---

From: Dave Taht <[email-masked]>
Date: Thu, 13 Feb 2014 13:39:54 -0500

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

I am delighted to see the work. Unfortunately I haven't had time to
review the draft fully or much of the code as yet; it was quite the
surprise to see it! It was wonderful to see the git clone...

What I looked over appeared to be a massive step forward that can
break the logjam here, evolve rapidly,
and be deployed rapidly.

I'm not sure if it's an AHCP replacement (can I get a /128 somewhere a
few hops away?)

I am glad there is room in the protocol for other routing protocols.
Have the RPL (IoT) folk had a gander?

In the 5 minutes I had with it, I felt the crypto architecture needed
fleshing out, and I wondered if there
was a notion of "distance". (to explain that, take a network with two
multihomed egress points and dozens of routers in between. Fully
distributing both sets of prefixes in an entirely flat fashion might
not be feasible or necessary.)

Unlike some perhaps I'd like to solve at least a few ipv4 related
problems, notably nat detection and saner rfc1918 prefix distribution,
but I imagine that will be a rathole.

Lastly: Trickle is very cool.

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

---

From: Ray Hunter <[email-masked]>
Date: Fri, 14 Feb 2014 17:45:03 +0100

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.

> 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:
>
> - best-effort capabilities in simple topologies in case one common 
> routing protocol support was not available
> 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.
>
> 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.
>
> Markus Stenberg <[email-masked] 
> <mailto:[email-masked]>> (and Pierre Pfister) wrote:
>
>> Drafts:

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.

>> [email-masked] <mailto:[email-masked]>

-- 
Regards,
RayH

---

From: Steven Barth <[email-masked]>
Date: Fri, 14 Feb 2014 20:29:31 +0100

On 14.02.2014 17:45, Ray Hunter wrote:
>
> 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?
I think your arguments about the downsides are valid and we have thought 
about them as well. However the current approach seems to be practical 
given the current situation that there is no common consensus about an 
IGP or about there even being an IGP that fits all use cases. Some 
people even argue that in some or many common cases an IGP might be 
overkill.

On top of that I even think if there would be a consensus in the near 
future then we still need autoconfiguration and source+dest routing 
standardized and adopted for that given IGP which will probably take 
quite some time as well.

So yes, there are limitations and hopefully this is not the final stance 
on this topic and at some point there is some kind of industry-consensus 
on an IGP. But honestly I don't see this happening any time soon.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 17 Feb 2014 11:46:20 +0100 (CET)

>>   http://tools.ietf.org/html/draft-pfister-homenet-prefix-assignment-00

I have read all of the drafts. I still need to wrap my head around all the 
details, but I think this is excellent work. It solves most if not all the 
areas of concern within the home when it comes to service discovery, 
prefix assignment etc.

I am a bit confused about the disposition of the drafts, but I guess it 
can be carved a lot of different ways, so I don't see this as a problem 
really.

The choice to invent a new transport protocol is a concern, however as 
things should be fairly modular, let's focus on the mechanisms and 
architecture, and as far as I can tell, this looks fine. If I understood 
correctly, there is running code for most of this so it has actually been 
tested? I think this is extremely good if it has, because getting all of 
these mechanisms right is the important thing, then we can discuss 
transport as a separate issue.

As I am a router guy, redistribution between protocols is done all the 
time. It's hairy when you do redistribution between OSPF->BGP->OSPF and 
BGP->OSPF->BGP etc. There you have some identifier that helps you to stop 
redistribution loops. Do we need something like this here? If we decide 
that HNCP is not what we want long term and we want to migrate to 
something else, there might be the need for redistribution between old and 
now. How can we prepare for something like this so it's as least 
distruptive as possible?

I was thinking of failover. What happens with a LAN with 1 DR and 3 other 
routers, and I turn off the DR? There is a prefix, there might be some 
IA_NA handed out by the DR, and there is a lifetime of the prefixes etc. 
I can't find the relevant section in the prefix assignment draft that 
handles this (or it's implicit somewhere and I just missed it). Anyhow, I 
would like to see a whole new section on this topic that describes what 
happens in different scenarios with pointers to desired behavior, as 
described in other sections of the text.

-- 
Mikael Abrahamsson    email: [email-masked]