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

Steven Barth <cyrus@openwrt.org> Wed, 18 November 2015 14:40 UTC

Return-Path: <cyrus@openwrt.org>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB091B2E82; Wed, 18 Nov 2015 06:40:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.549
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAhDkzkIm9IQ; Wed, 18 Nov 2015 06:40:53 -0800 (PST)
Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82D9D1B2E80; Wed, 18 Nov 2015 06:40:53 -0800 (PST)
Received: from localhost ([127.0.0.1]) by mail.core-networks.de 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 <bclaise@cisco.com>, The IESG <iesg@ietf.org>
References: <20151118142049.12309.30247.idtracker@ietfa.amsl.com>
From: Steven Barth <cyrus@openwrt.org>
Message-ID: <564C8DF0.3090901@openwrt.org>
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: <20151118142049.12309.30247.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/homenet/QrNJOfz36RWwhDVv6LDOh0LtrWw>
Cc: homenet-chairs@ietf.org, mark@townsley.net, draft-ietf-homenet-hncp@ietf.org, victor@jvknet.com, homenet@ietf.org, jiangsheng@huawei.com
Subject: Re: [homenet] Benoit Claise's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=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.



> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
>    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
> https://tools.ietf.org/html/draft-ietf-homenet-dncp-12#section-1.1:
> 
>     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.



Cheers,

Steven