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

"Benoit Claise" <bclaise@cisco.com> Wed, 18 November 2015 14:20 UTC

Return-Path: <bclaise@cisco.com>
X-Original-To: homenet@ietf.org
Delivered-To: homenet@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4541B2E27; Wed, 18 Nov 2015 06:20:49 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benoit Claise <bclaise@cisco.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.10.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20151118142049.12309.30247.idtracker@ietfa.amsl.com>
Date: Wed, 18 Nov 2015 06:20:49 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/homenet/kZIsg37XwdDHrA9EKhPbOvB8iQE>
Cc: homenet-chairs@ietf.org, mark@townsley.net, draft-ietf-homenet-hncp@ietf.org, victor@jvknet.com, homenet@ietf.org, jiangsheng@huawei.com
Subject: [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
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:20:50 -0000

Benoit Claise has entered the following ballot position for
draft-ietf-homenet-hncp-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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.


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



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


Below is Sheng's OPS-DIR review.

1. HNCP describes Prefix and Naming configuration. But it is not very
clear how they are matched in the DNCP architecture. It would be help to
understand if some description using DNCP architecture, like node state
and network state, etc., could be added.

2. It would be very useful to add a bootstrap and configuration procedure
of HNCP. So far, this is not clear.

3. Section 6.5 "only the one published by the node with the highest node
identifier". It is not very clear how to compare the value against node
identifier.