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

From: "Benoit Claise" <[email-masked]>
Date: Wed, 18 Nov 2015 06:20:49 -0800

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.

---

From: Steven Barth <[email-masked]>
Date: Wed, 18 Nov 2015 15:40:48 +0100

Hello Benoit,

thanks for the review.

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

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

> 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