Re: [homenet] writeup of my 2018 homenet experience on openwrt

I may or may not have some architectural/flow diagrams, but I am bit leery of putting them anywhere (if I were to have them that is) as they were not officially licensed to be distributed (as the code was) and as this was Cisco-funded research project back in the day. I could draw some basic

Re: [homenet] writeup of my 2018 homenet experience on openwrt

On 09.11.2018, at 9.48, Ted Lemon wrote: > My edge router is an Ubuntu machine. I haven’t been able to get Marcus’ HNCP > daemon to build there. It’s possible that that has changed since I last tried > it, but that was what stopped me last time. It built fine on Debian/Ubuntu last I tried it

Re: [homenet] writeup of my 2018 homenet experience on openwrt

First off, hnetd was team effort - me, Pierre Pfister and Steven Barth. Secondly, I did not particularly want to promote hnetd but 'existing implementations are bad, boo hoo' argument gets old and I think e.g. https://github.com/jech/shncpd is also quite sufficient. I use even

Re: [homenet] writeup of my 2018 homenet experience on openwrt

On 08.11.2018, at 19.16, Juliusz Chroboczek wrote: >>> From a user perspective, there are a few problems: >> When an interface goes down and then up again, it's renumbered. This >> includes reboots. > That shouldn't happen as long as there remains at least one Homenet router > to maintain the

Re: [homenet] Martin Vigoureux's No Objection on draft-ietf-homenet-babel-profile-06: (with COMMENT)

On 7 May 2018, at 22.30, Juliusz Chroboczek wrote: >> you should refer to 8174. > Perhaps you could kindly justify your advice? Non-capitalised "must" is > used just once in this document, and I don't see any opportunity for > ambiguity. Perhaps he refers to the RFC8174 update to

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

On 10 Aug 2017, at 23.33, STARK, BARBARA H wrote: > > With one day left in CFA for draft-tldm-simple-homenet-naming, here is my > summary of what I think I've read. > > Exactly 3 people have expressed support for adoption (Daniel [author], > Michael R, James). Hmm. That's not

Re: [homenet] Simple Homenet Naming Architecture...

On 13 Mar 2017, at 23.58, Ted Lemon wrote: > Daniel Migault and I have been working on the Simple Homenet Naming > Architecture. I’ve posted a -00 that I hope we can discuss in Chicago. S1.1: The assumption in UI is false. The visible services (at least in the legacy browse

Re: [homenet] draft-ietf-homenet-babel-profile-01

> On 2 Dec 2016, at 15.50, Juliusz Chroboczek wrote: > I've just submitted > > draft-ietf-homenet-babel-profile-01 > > It should hit the IETF repository soon, in the meantime, my working copy is on > > >

Re: [homenet] Understanding DNS-SD hybrid proxying [was: Firewall hole punching]

> On 24 Nov 2016, at 11.28, Tim Chown wrote: > In dnssd we have the “stitching” topic on our plate, around operation of > dns-sd in unmanaged multi-link networks. So this is timely discussion. > > We’re beginning work on a BCP for the use of the discovery/advertising

Re: [homenet] Understanding DNS-SD hybrid proxying [was: Firewall hole punching]

On 23 Nov 2016, at 21.45, Juliusz Chroboczek wrote: - ohybridproxy (only really scalable and sensible IPv6 rdns source that I am aware of, given nodes talk mdns) > >>> Noted, thanks for the opinion. I still don't understand how it works (who >>> gets port 53? how are

Re: [homenet] Firewall hole punching [was: About Ted's naming architecture...]

On 22 Nov 2016, at 21.47, Juliusz Chroboczek wrote: >> Now that I have thought about it more, I do not control all devices in >> my home that well to start with (hello, embedded things that talk IP), >> and I am not that keen to allow them to punch holes in >> firewall. Obviously,

Re: [homenet] About Ted's naming architecture presentation and document

On 22 Nov 2016, at 18.51, Juliusz Chroboczek wrote: >> I can put that controller into my own home and operate it > Assuming that you can control the stateful firewall that's running on the > edge routers. Recall that the edge router is not necessarily on the local > link, and that

Re: [homenet] write up of time without clocks

On 3 Nov 2016, at 21.26, Brian E Carpenter wrote: > Yes, I agree it's possible to do better, but what's the incentive for a > bottom-feeding vendor > of cheap devices to bother? I hate to say this, but how about legal solutions? If you sell e.g. guns that explode

Re: [homenet] My comment about Ted's naming draft

> On 18.7.2016, at 19.55, Ted Lemon wrote: > Right now HNCP doesn't actually seem to have a TLV for advertising resolvers. > How does this work now? DHCP options have also DNS server options (for v4 and v6). -Markus ___ homenet

Re: [homenet] alternatives to .home

On 17.6.2016, at 10.37, Pierre Pfister wrote: > I think this is a key point indeed. > > mDNS works really hard to *not* show any name to the user. > I would like it to be the same for homenet, but I am not sure we have a > complete solution for no-name multi-link

Re: [homenet] HNCP in tcpdump and wireshark?

On 9.6.2016, at 19.38, Juliusz Chroboczek wrote: >>> Do you know if anyone is working on HNCP support for tcpdump and >>> wireshark? I'm considering giving it out as a student project this >>> summer, but of course it doesn't make a lot of sense if somebody beats

Re: [homenet] HNCP in tcpdump and wireshark?

> On 9.6.2016, at 18.38, Juliusz Chroboczek > wrote: > > Dear Markus, dear all, > > Do you know if anyone is working on HNCP support for tcpdump and > wireshark? I'm considering giving it out as a student project this > summer, but of course it doesn't make a

Re: [homenet] Shncpd updated to RFC 7788

> On 13.5.2016, at 23.22, Juliusz Chroboczek > wrote: > I've just updated shncpd to follow the changes made between the draft > I had used and RFC 7788. The consequence is that shncpd no longer > interoperates with the version of hnetd in current OpenWRT head :-/

Re: [homenet] How many people have installed the homenet code?

On 26.4.2016, at 16.34, Rich Brown <richb.hano...@gmail.com> wrote: > Ahhh... This is exactly the kind of advice I was looking for... >> On Apr 26, 2016, at 9:04 AM, Markus Stenberg <markus.stenb...@iki.fi> wrote: >> >>> On 26.4.2016, at 15.09, Rich B

Re: [homenet] Updating DNS [was: How many people have installed the homenet code?]

On 24.4.2016, at 6.03, Ted Lemon wrote: > Juliusz, the problem is that existing home network devices that do DNS-based > service discovery do not support DNS update. They could, but they don't, > because we didn't define an easy way for them to do it. Just 2136 isn't >

Re: [homenet] How many people have installed the homenet code?

have > made some fundamentally poor assumptions. > > There was a discussion back in Oct 2015 about running hnetd (I presume) on > mainstream linux distros (http://bit.ly/1XKc3Oi). Henning Rogge raised the > question and Markus Stenberg responded that it had been tried on Debian

Re: [homenet] I-D ACTION:draft-lemon-homenet-naming-architecture-00.txt

On 1.4.2016, at 16.09, Ted Lemon <mel...@fugue.com> wrote: > On Fri, Apr 1, 2016 at 3:32 AM, Markus Stenberg <markus.stenb...@iki.fi> > wrote: > Section 2.1: It looks interesting. I like having separate naming and > connectivity provider, if we can pry th

Re: [homenet] [Babel-users] Detecting bridges

On 18.12.2015, at 11.53, Juliusz Chroboczek wrote: >> Is there room in the protocol for a router to announce what link type it >> is on? > This could be carried by a sub-TLV of Hello (or a sub-TLV of IHU if you > want to make it per-host). > >> I.e., a router on

Re: [homenet] HNCP: interaction with routing protocol?

> On 14.12.2015, at 8.15, Mikael Abrahamsson wrote: > > On Sun, 13 Dec 2015, Juliusz Chroboczek wrote: > >> The OpenWRT hnetd configuration redistributes everything, indeed. The >> recommended shncpd configuration redistributes just hncpd routes: >> >> redistribute local

Re: [homenet] Stephen Farrell's No Objection on draft-ietf-homenet-hncp-10: (with COMMENT)

> On 4.12.2015, at 18.51, Stephen Farrell wrote: > Thanks for addressing my discuss about the options for > using DTLS. Sorry for being slow with this ballot update. > > The comments below are old, I didn't check if you've > made related changes. Happy to chat about

Re: [homenet] Alia Atlas' No Objection on draft-ietf-homenet-hncp-09: (with COMMENT)

Heya, thanks for the review :) > -- > COMMENT: > -- > > I support Brian's Discuss. > > 1) In Sec 1.1, it states "...in homenet environments where multiple

Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)

On 18.11.2015, at 16.56, Ted Lemon wrote: > Wednesday, Nov 18, 2015 8:24 AM Juliusz Chroboczek wrote: >> HNCP is an amazingly flexible protocol, and one that will hopefully be >> used well beyond it's original area of application. Many of the possible >> applications of HNCP

Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)

On 20.11.2015, at 16.47, Kathleen Moriarty wrote: >> It is question of threats <-> risks <-> mitigation analysis. Only thing >> HNCP security really brings is _in case of insecure L2_ _some_ security for >> routing/psk state. If we assume every other protocol

Re: [homenet] Stephen Farrell's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)

> On 19.11.2015, at 16.21, Stephen Farrell wrote: > (Sorry for the N-th discuss, I quite like this protocol and > I'm sure we'll get 'em all cleared soon, but... ;-) > > I'd like to chat about whether or not the DTLS recommendations > are correct here. To me, the

Re: [homenet] Barry Leiba's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)

On 20.11.2015, at 12.07, Steven Barth wrote: >> -- Section 13 -- >> I have two concerns with how the HNCP TLV Types registry is specified: >> >> 1. Because the DNCP TLV Types registry specifically allocates 32-511 for >> profiles, it'd be better to simply limit the range of

Re: [homenet] Alissa Cooper's No Objection on draft-ietf-homenet-hncp-09: (with COMMENT)

Thanks for the comments ;) On 18.11.2015, at 21.42, Alissa Cooper wrote: > -- How does a node end up in the leaf or guest category? Is it only if a > fixed category is configured? If so, who decides that that configuration > should happen? I think this info belongs in the

Re: [homenet] Barry Leiba's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)

On 20.11.2015, at 17.50, Barry Leiba wrote: > I can still be convinced that this is the way to go, but I haven't > been yet, so let's please talk about it a bit more. > > I see your point about the possibility that future DNCP updates could > change the registry, though

Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)

> On 20.11.2015, at 17.17, Kathleen Moriarty <kathleen.moriarty.i...@gmail.com> > wrote: > > Hi Markus, > > Thanks for your quick response, inline, > > On Fri, Nov 20, 2015 at 10:07 AM, Markus Stenberg > <markus.stenb...@iki.fi> wrote: >&g

Re: [homenet] IPv6 Prefix delegation on IETF network, please ?

> On 2.11.2015, at 14.52, Toerless Eckert wrote: > Thought maybe other folks beside me would chime in maybe help to ask for this > for IETF95: > > I was trying to play around with Homenet/OpenWrt during the hackathon and > could not > nicely build out Homenet connection to

Re: [homenet] Alia Atlas' Yes on draft-ietf-homenet-dncp-11: (with COMMENT)

On 21.10.2015, at 19.18, Alia Atlas wrote: > -- > COMMENT: > -- > > Thank you very much for addressing my previous Discuss points and >

Re: [homenet] Ben Campbell's No Objection on draft-ietf-homenet-dncp-10: (with COMMENT)

On 29.9.2015, at 23.46, Ben Campbell wrote: > Thanks for the new appendix B. How should we interpret the "(optional)" > tag on some of the sections of that appendix? For example, does for the > Transport Security section, does (optional) mean the section is optional, > that

Re: [homenet] Brian Haberman's Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS and COMMENT)

On 18.9.2015, at 23.58, Juliusz Chroboczek wrote: >> * When responding to a multicast request over a multi-access medium, >> why is the randomization of the transmit time only a SHOULD? >> I would think that needs to be a MUST. > >> Therefore I

Re: [homenet] Benoit Claise's Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS and COMMENT)

On 17.9.2015, at 12.11, Benoit Claise wrote: > -- > DISCUSS: > -- > > Other ADs focused on the protocol specific points. So let me focus on >

Re: [homenet] Spencer Dawkins' Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS)

On 16.9.2015, at 23.09, Spencer Dawkins at IETF wrote: > Do you think we should insert some sort of disclaimer there about the default > value to avoid potential misdesign? > > I haven't seen people tripping over using TCP keep-alives and assuming they'd > be

Re: [homenet] Brian Haberman's Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS and COMMENT)

On 16.9.2015, at 18.39, Brian Haberman wrote: A_NC_I calculation does not depend on how you synchronize things (full state dump <> delta). It is mostly about value <> cost of having Trickle, as opposed to fixed timers. What would you propose

Re: [homenet] Benoit Claise's Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS and COMMENT)

> On 17.9.2015, at 19.22, Benoit Claise wrote: > Instead of focusing on the specific questions/answers, the key message is. > The applicability section doesn’t answer my questions: when to (re-)use this > protocol? I still rephrase my previous answer - the one sentence that

Re: [homenet] Brian Haberman's Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS and COMMENT)

On 15.9.2015, at 20.24, Brian Haberman wrote: > On 9/15/15 12:52 PM, Steven Barth wrote: >> Hello Brian, >> thank you for your feedback. >> >>> -- >>> DISCUSS: >>>

Re: [homenet] I-D Action: draft-ietf-homenet-hybrid-proxy-zeroconf-01.txt

xy Nodes > Author : Markus Stenberg > Filename: draft-ietf-homenet-hybrid-proxy-zeroconf-01.txt > Pages : 16 > Date: 2015-09-02 > > Abstract: > This document describes how a proxy functioning between Unicast DNS- >

Re: [homenet] I-D Action: draft-ietf-homenet-hybrid-proxy-zeroconf-01.txt

On 2.9.2015, at 12.26, Henning Rogge wrote: > the name of the reference to the dnssd-hybrid proxy draft is still > called "[I-D.ietf-dnssd-hybrid]". This could be fixed in the next > draft version. Unfortunately that _is_ their latest version[1] (ping dnssd: make Stuart do

Re: [homenet] Host naming in Homenet

On 31.8.2015, at 14.33, Markus Stenberg <markus.stenb...@iki.fi> wrote: > Sure, you can define link segment name election mechanism and use per-link > names (they are even mentioned as an option in > draft-ietf-homenet-stenberg-hybrid-proxy-zeroconf; see also why doing that &

Re: [homenet] Host naming in Homenet

standards themselves or are specific to the OpenWrt implementation.) Implementation. > * Markus Stenberg <markus.stenb...@iki.fi> > >> On 31.8.2015, at 13.16, Henning Rogge <hro...@gmail.com> wrote: >>> Does homenet even need a “central" DNS server? >> &

Re: [homenet] Host naming in Homenet

On 31.8.2015, at 14.42, Ray Hunter (v6ops) wrote: > Also DND SD (RFC 6763) states "Address-based Domain Enumeration queries are > performed using names under the IPv6 reverse-mapping tree" which is under the > direct control of the individual upstream ISPs. > > So, what are

Re: [homenet] Host naming in Homenet

On 28.8.2015, at 10.02, Henning Rogge hro...@gmail.com wrote: So what IS the proposed solution for a decentralized HNCP configured homenet to share local configured DNS names with the rest of the homenet? For sharing in general, there are two methods (as far as HNCP goes); - publish a DNS

Re: [homenet] DNS delegation [was: Host naming in Homenet]

On 27.8.2015, at 18.10, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: In short -- the ability within the Homenet to do scp backup-20150827.tar mylaptop.home:backup/ and having it work no matter which link the laptop happens to be connected to. I'd add whether it was

Re: [homenet] Host naming in Homenet

On 27.8.2015, at 15.38, Ray Hunter ray.hun...@globis.net wrote: IMHO This is a very worthwhile discussion that we've glossed over for a long time. I've seen several drafts over the course of the Homenet WG. e.g.

Re: [homenet] HNCP WGLC

On 27.8.2015, at 9.26, Steven Barth cy...@openwrt.org wrote: A few issues may be a concern. The required support of UDP 4000 byte packets in Section 3 DNCP Profile suggests there may be a concern. Section 2.1.4. Amplification Issues of

Re: [homenet] Reachability of distributed prefixes

On 26.8.2015, at 12.39, Henning Rogge hro...@gmail.com wrote: My problem is not with the prefixes assigned to the interfaces of HNCP routers itself, my problem is with the prefixes provided to attached hosts. If I understand HNCP right then the uplink will announce a prefix which should be

Re: [homenet] Getting new HNCP TLV types

On 20.8.2015, at 0.35, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: Some sort of review seems advisable. In RFC5226 terms, I'd go for Expert Review at least. That would be fine with me. I am not big fan of expert review, as it can potentially bias what gets allocated or not.

Re: [homenet] [babel] Experiences implementing Babel in the Bird routing daemon

On 19.8.2015, at 23.32, Markus Stenberg markus.stenb...@iki.fi wrote: On 19.8.2015, at 23.26, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: If anybody knows how to write a test suite for a routing protocol, I'm interested. I imagine a set of scripts that set up some virtual

Re: [homenet] [babel] Experiences implementing Babel in the Bird routing daemon

On 19.8.2015, at 23.26, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: If anybody knows how to write a test suite for a routing protocol, I'm interested. I imagine a set of scripts that set up some virtual machines and perform some tests, but I have trouble imagining how it could

Re: [homenet] HNCP: avoiding renumbering

On 17.8.2015, at 9.57, Toerless Eckert eck...@cisco.com wrote: On Mon, Aug 17, 2015 at 09:41:24AM +0300, Markus Stenberg wrote: Just like in some other old workplace, cough, ???if it does not work without IPsec, do not expect it to work with it???. Should i even try to understand

Re: [homenet] HNCP: avoiding renumbering

On 17.8.2015, at 14.19, normen.kowalew...@telekom.de wrote: Hi, +1. a) Any idea how often this data changes and really needs a re-write in “a typical home ;-) ? Not very often, at least if you don’t bother to prune ‘old’ stuff much (it depends a bit, but most conservative setup would

Re: [homenet] HNCP: avoiding renumbering

On 17.8.2015, at 9.22, Toerless Eckert eck...@cisco.com wrote: On Mon, Aug 17, 2015 at 01:01:04PM +1200, Brian E Carpenter wrote: That may be desirable to limit churn, but must not be depended on. The architecture is explicit on pp 25-26 that renumbering is an expected event:

Re: [homenet] HNCP: avoiding renumbering

On 16.8.2015, at 14.40, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: When an HNCP router is restarted, the prefixes it allocated to a link are adopted by neighbouring routers; if the router then restarts, it will agree to the prefixes advertised by its neighbours, which avoids

Re: [homenet] Moving forward.

On 10.8.2015, at 11.23, Erik Kline e...@google.com wrote: Whilst not wanting to de-rail any effort to standardise Babel (since I firmly believe it should be standardised), I'd like to hear the WG's view on having part of our Homenet stack be on Experimental Track instead of PS. E.g., would it

Re: [homenet] Moving forward.

On 5.8.2015, at 13.08, Mikael Abrahamsson swm...@swm.pp.se wrote: And then, if people want to talk about additional hypothetical IS-IS capabilities that could be added to a homenet IS-IS, I think they should be required to describe how much memory and other resources would be needed to

Re: [homenet] RtgDir review: draft-ietf-homenet-dncp-05.txt

Now -09 is available. Changelog (diff is relatively large, but these are the main parts): - Reserved 1024+ TLV types for future versions (=versioning mechanism); private use section moved from 192-255 to 512-767. - Added applicability statement and clarified some text

Re: [homenet] RtgDir review: draft-ietf-homenet-dncp-05.txt

First of all, thanks a lot again for review comments; I think you are the most critical reviewer we have had yet, and it helps to improve the document quality a lot :) We have had a number of reviews by this point, but I believe you have raised order of magnitude more changes than the second in

Re: [homenet] some IS-IS questions

On 29.7.2015, at 17.35, STARK, BARBARA H bs7...@att.com wrote: Perfect! Thanks. I’d missed that. Yes, that’s exactly what I was looking for. So when the Design Team compares IS-IS to Babel, they really should be

Re: [homenet] Routing Protocol in HNCP

On 23.7.2015, at 6.39, Mikael Abrahamsson swm...@swm.pp.se wrote: On Wed, 22 Jul 2015, Markus Stenberg wrote: Agreed. I think we will remove routing protocol references from HNCP just to be clear, as in practise what we really interact with is the local route set and not the routing

Re: [homenet] Routing Protocol in HNCP

On 23.7.2015, at 10.41, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: Right now, the interaction between the routing protocol and the rest of the stack is very simple and very clean: HNCP redistributes assigned prefixes into the RP, and the RP redistributes the default route into

Re: [homenet] Routing Protocol in HNCP

On 23.7.2015, at 10.49, Markus Stenberg markus.stenb...@iki.fi wrote: On 23.7.2015, at 10.41, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: Right now, the interaction between the routing protocol and the rest of the stack is very simple and very clean: HNCP redistributes

Re: [homenet] Routing Protocol in HNCP

On 22.7.2015, at 19.19, David Lamparter equi...@diac24.net wrote: Fully agree with Brian, Juliusz and the various others - there needs to be a mandatory routing protocol, but there's no need at all for HNCP need to reference the actual protocol. The HNCP *protocol* works fine whatever

Re: [homenet] Last Call Comments on draft-ietf-homenet-dncp-07

Thank you for the review. On 20.7.2015, at 4.21, Margaret Cullen mrculle...@gmail.com wrote: I support the publication of draft-ietf-homenet-dncp-07. However, I think there are a few issues with the document that need to be fixed before it is published as an RFC, including: (1) The

Re: [homenet] HNCP interaction with DHCP

On 6.7.2015 13.24, Steven Barth wrote: What happens when a new router appears on the link, a new election is called, and the new router becomes the designated DHCPv4 server -- won't address collisions occur? Perhaps DHCPv4 service should be sticky, in the sense that a new election isn't

[homenet] Fwd: New Version Notification for draft-stenberg-shsp-00.txt

Stenberg markus.stenb...@iki.fi, Markus Stenberg markus.stenb...@iki.fi A new version of I-D, draft-stenberg-shsp-00.txt has been successfully submitted by Markus Stenberg and posted to the IETF repository. Name: draft-stenberg-shsp Revision: 00 Title: Simple Home Status

Re: [homenet] DNCP questions (and minor nits)

On 4.7.2015 0.28, Juliusz Chroboczek wrote: Markus, Steven, Section 4.4 of DNCP says that the NODE-STATE TLVs sent in reply to a REQ-NODE-STATE MUST NOT contain the optional part. Why is that? If I've recently republished my own data (e.g. because I gained a neighbour), it makes sense to me

Re: [homenet] draft-ietf-homenet-hncp-06 now in WGLC

On 30.6.2015 18.22, Dave Taht wrote: My request was more dogfooding. a *lot* more dogfooding. Any practical suggestions on how? Even back in Atlanta in _2012_, there wasn't that many problems detected when we let rampaging horde play with the cables (+- few bugs +- Windows XP and ULAs). I

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-06.txt

On 27.6.2015 2.49, Juliusz Chroboczek wrote: If the considered delegated prefix is an IPv6 prefix, and whenever there is at least one available prefix of length 64, a prefix of length 64 MUST be selected unless configured otherwise by an administrator. In case no prefix of length 64

Re: [homenet] Inconsistencies between hnetd and the DNCP/HNCP drafts

On 30.6.2015 15.01, Juliusz Chroboczek wrote: I've had two surprises trying to interoperate with hnetd. 1. nncp-06 Section 10 says that the Version is 0. hnetd sends and expects a version field of 1. Changed the default value to 1 to match the implementations. 2. The same section says the

Re: [homenet] Concerns about DNCP

On 1.7.2015 14.26, Juliusz Chroboczek wrote: ### NODE-ENDPOINT is stateful NODE-ENDPOINT identifies the sender of this packet, and applies to all TLVs in this packet. The current specification implies that the NODE-ENDPOINT may appear anywhere in the packet, which would force the receiver to

Re: [homenet] Concerns about DNCP

On 2.7.2015 12.55, Juliusz Chroboczek wrote: You're right, I don't need endpoint except in NETWORK-STATE. - NetS: need (possibly with delay, to update Trickle state match; we do Trickle state update last so ordering does not matter) Well, for HNCP Trickle is per-interface, so it's only really

Re: [homenet] More about state desynchronisation in DNCP

On 1.7.2015 21.23, Juliusz Chroboczek wrote: (given neighbor TLVs stay around, and why would they not?). Milliseconds since origination overflow? (By the way -- where does it say what a non-originator node should do when the field overflows?) In dncp-07. Implementation fixed already :)

Re: [homenet] [hackathon] homenet in Hackathon

I inserted preliminary topic to the wiki page ( https://www.ietf.org/registration/MeetingWiki/wiki/93hackathon ). Anyone can feel free to improve the entry or volunteer to champion (nudge Pierre :-) by editing the page. I will provide moral support on Saturday and possibly show up then, but

Re: [homenet] More about state desynchronisation in DNCP

On 1.7.2015 17.03, Juliusz Chroboczek wrote: It took me that long to realize that use of Trickle to detect that [1]_someone has different state_ is very different from [2]_you are able to actually get that state_. Markus, this is *very* enlightening. You *must* put that in the draft. In some

Re: [homenet] More about state desynchronisation in DNCP

On 1.7.2015 15.44, Juliusz Chroboczek wrote: In my previous mails, I used the term persistent state desynchronisation. Since this apparently worried some people, so I guess I'll explain. DNCP uses dynamic timers (Trickle) to flood a hash of the global state and separate unicast request/response

Re: [homenet] More about state desynchronisation in DNCP

On 1.7.2015 16.10, Juliusz Chroboczek wrote: Your definition of the worst-case here is slightly pessimistic I believe (c.f. appendix B changenotes); in practise, as Trickle reset occurs if and only if _locally_ calculated network state changes, I've obviously missed something. Yes, I have.

Re: [homenet] Concerns about DNCP

On 30.6.2015 20.10, Juliusz Chroboczek wrote: Concerns about DNCP === DNCP is an elegant and small protocol that distributes HNCP data across the Homenet. DNCP works by flooding a hash of the full network state over link-local multicast, and synchronising the actual state

Re: [homenet] More about lack of fragmentation in HNCP

On 1.7.2015 15.19, Juliusz Chroboczek wrote: HNCP maximum packet size is 4000 bytes (Section 3 of -06). Assuming a router wishes to publish 400 bytes of per-router information, and for each interface two neighbours, two assigned prefix TLVs (one /64 and one IPv4 /24) and two node addresses (one

Re: [homenet] draft-ietf-homenet-hncp-06 now in WGLC

On 30.6.2015 15.41, Mikael Abrahamsson wrote: On Tue, 23 Jun 2015, Ray Bellis wrote: If I understand correctly, work is now ongoing to create a separate implementation of HNCP? This would be a good step to address my concern I have voiced privately to the authors that not enough people have gone

Re: [homenet] DNCP: issue with network partitions and monitoring nodes

On 30.6.2015 15.12, Juliusz Chroboczek wrote: A --- M --- B [...] M doesn't publish a NODE-STATE TLV, but other than that it fully participates in the protocol. However, if you want to _bridge_ stuff, you can just forward 'things from A to B, and things from B to A' on the M node, and

Re: [homenet] How to compute DNCP/HNCP node data?

On 27.6.2015 20.23, Steven Barth wrote: Profile recommendations section in dncp recommends sha-256. Er... -06 recommends the leading 8 octets of MD-5. Section 3. DNCP recommends sha256 for profiles. HNCP uses what you mentioned. 1. simply copy the has received from the originator, no

Re: [homenet] A few more DNCP -06 nits and questions

On 27.6.2015 17.55, Juliusz Chroboczek wrote: Markus, Section 4.4 of -06 seems to say that Node Endpoint TLVs MUST be silently discarded. Not really, it is not unknown TLV as supporting it is required. However, wording deltas accepted if it makes it clearer. Section 5, containing data

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-06.txt

: Markus Stenberg Steven Barth Pierre Pfister Filename: draft-ietf-homenet-hncp-06.txt Pages : 31 Date: 2015-06-17 Abstract: This document describes the Home Networking Control Protocol

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-05.txt

Thanks for the review from me as well. On 8.6.2015 17.28, Juliusz Chroboczek wrote: You don't define ad-hoc interfaces. From Section 4, it would seem that these are for non-transitive links with no prefix assignment (a la AHCP), but in that case some changes may be needed to DNCP, In it's

Re: [homenet] WG Last Call for draft-ietf-homenet-dncp-03

On 28.5.2015, at 18.38, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: (1) it is impossible to reliably snoop the protocol without contributing a Node-State TLV and a full set of Neighbor sub-TLVs; This is not true, at least assuming the profile specifies even partially

Re: [homenet] WG Last Call for draft-ietf-homenet-dncp-03

On 28.5.2015, at 19.20, Dave Taht dave.t...@gmail.com wrote: (3) it is impossible to act as a dumb DNCP forwarder without publishing a Node-State TLV and a full set of Neighbor sub-TLVs. This is not true. Given basic bridging of ‘remember one guy on end of each link’, you can do essentially

Re: [homenet] WG Last Call for draft-ietf-homenet-dncp-03

On 28.5.2015, at 23.45, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: Section 5.2 explicitly says how to reach to each TLV (and no semantics about this, IIRC). Section 5.3 states what Node Endpoint TLV means (=I want to be your neighbor), section 5 (start) says that that

Re: [homenet] WG Last Call for draft-ietf-homenet-dncp-03

On 28.5.2015, at 16.11, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: Thank you for the recent reviews and update of draft-ietf-homenet-dncp. Please take the next 3 weeks to make your final reviews. I strongly support this work. We have recently set up an HNCP experiment here

Re: [homenet] I-D Action: draft-ietf-homenet-dncp-02.txt

On 24.4.2015, at 7.46, Brian E Carpenter brian.e.carpen...@gmail.com wrote: You can process TLVs invididually (the length is in second byte received), or in small chunks. TLV processing definition has only one dependency on other TLVs (node data has to have respective node state ’nearby’, for

Re: [homenet] I-D Action: draft-ietf-homenet-dncp-02.txt

On 23.4.2015, at 2.37, Brian E Carpenter brian.e.carpen...@gmail.com wrote: 1. Changed DNCP messages into series of TLV streams, allowing optimized round-trip saving synchronization. So, I have a couple of questions about the new text: A DNCP message in and of itself is just an

Re: [homenet] T.M.S. proudly presents - Babel: the 2nd implementation

On 26.3.2015, at 11.36, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: After a first read, it looks like a pretty complete implementation of RFC 6126. I have't checked in detail, but it looks like you got both the loop avoidance and the blackhole avoidance mechanisms right.

Re: [homenet] Selecting a routing protocol for HOMENET

On 26.3.2015, at 13.20, Terry Manderson terry.mander...@icann.org wrote: That is certainly not omitted, why do you think it would be? ..Specifically when we look at outputs from the routing area (and Alia can certainly speak for her own Area on this) two reference implementations are

Re: [homenet] T.M.S. proudly presents - Babel: the 2nd implementation

On 26.3.2015, at 13.19, Ted Lemon mel...@fugue.com wrote: On Mar 26, 2015, at 10:07 AM, Michael Thomas m...@mtcc.com wrote: At the very least, I think it's totally fair to subject it to any torture tests you have :) I would suggest that you do interop tests, rather than trying to give him

[homenet] T.M.S. proudly presents - Babel: the 2nd implementation

On Tuesday, there was much whining about single Babel implementation. Luckily T.M.S.[1] to the rescue - ~15 hours after start, routes synchronized unidirectionally, and after fixing bug or two this morning they go both ways, loop-free, etc. So I would argue I have implemented RFC6126 (aka

  1   2   >