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

Steven Barth <> Wed, 18 November 2015 14:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6AB091B2E82; Wed, 18 Nov 2015 06:40:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.549
X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_FAIL=0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DAhDkzkIm9IQ; Wed, 18 Nov 2015 06:40:53 -0800 (PST)
Received: from ( [IPv6:2001:1bc0:d::4:9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 82D9D1B2E80; Wed, 18 Nov 2015 06:40:53 -0800 (PST)
Received: from localhost ([]) by id 1Zz3uj-0008C9-R5 with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for ; Wed, 18 Nov 2015 15:40:49 +0100
To: Benoit Claise <>, The IESG <>
References: <>
From: Steven Barth <>
Message-ID: <>
Date: Wed, 18 Nov 2015 15:40:48 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Icedove/40.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [homenet] Benoit Claise's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF Homenet WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Nov 2015 14:40:59 -0000

Hello Benoit,

thanks for the review.

On 18.11.2015 15:20, Benoit Claise wrote:
> One issue to be discussed: the link with the future BCP
> draft-ietf-v6ops-reducing-ra-energy-consumption-03, on the same telechat.
> draft-ietf-v6ops-reducing-ra-energy-consumption-03 mentions:
>    "On links with a large number of battery-powered devices, sending
>    solicited Router Advertisements multicast can severely impact host
>    power consumption."
>>From this document: I see "HNCP operates on multicast-capable interfaces
> only"
> Do we expect battery-powered devices in homenet? I guess so: my phone for
> example.
> I discussed this topic with Mark Townsley, who is on it already.

DNCP (and thus HNCP) uses multicast only for unsolicited messages, e.g.
messages triggered by Trickle. Every solicited message (= reply to a
multicast or unicast packet) MUST always be sent using unicast. This is
mandated in the DNCP draft. So I think there should not be an inherent
conflict with this draft here.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
>    As HNCP uses DNCP as the actual state synchronization protocol, the
>    applicability statement of DNCP can be used here as well; HNCP should
>    not be used for any data that changes rapidly and constantly, and
>    locators to find such services should be published using it instead.
>    This is why the naming and service discovery (Section 8) TLVs contain
>    only DNS server addresses, and no actual per-name or per-service data
>    of hosts.
> What is it in in "using it"? If DNCP, then it contradicts
>     However, there are certain cases where the protocol as defined in
>     this document is a less suitable choice. ...  frequently changing
> data:  DNCP with its use of Trickle is
>     optimized for the steady state and less efficient otherwise.
> Chatting with Mark Townsley, he proposed some clarifying text:
>     HNCP should not be used directly for data that changes rapidly and
> constantly, though
>     stable locators to find such data by other means may be advertised
> within HNCP.

Okay we will discuss this one in the coming days and try to come up with
something more clear.

> - Each HNCP router MAY obtain external connection information such as
>    address prefixes, DNS server addresses and DNS search paths from one
>    or more sources, e.g., DHCPv6-PD [RFC3633], NETCONF [RFC6241] or
>    static configuration. 
> If you know pf the YANG model already, you should mention it.
We don't yet, but it would probably be something defining network
interface related. I will try to investigate if there is a relevant RFC
already that we could reference.

> Below is Sheng's OPS-DIR review.
Sorry, that somehow slipped through my radar until today, I just sent a
direct reply to that mail-thread.