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

Steven Barth <cyrus@openwrt.org> Fri, 20 November 2015 09:07 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 406FE1A90BC; Fri, 20 Nov 2015 01:07:35 -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 B4TH8dajxI3e; Fri, 20 Nov 2015 01:07:33 -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 6655E1A90BB; Fri, 20 Nov 2015 01:07:33 -0800 (PST)
Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1ZzhfF-00020A-SB with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for ; Fri, 20 Nov 2015 10:07:29 +0100
To: Brian Haberman <brian@innovationslab.net>, The IESG <iesg@ietf.org>
References: <20151119135929.8847.94406.idtracker@ietfa.amsl.com>
From: Steven Barth <cyrus@openwrt.org>
Message-ID: <564EE2D0.5060101@openwrt.org>
Date: Fri, 20 Nov 2015 10:07:28 +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: <20151119135929.8847.94406.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/homenet/u1sN6JEyz61MMFpOGmsUIzsFkwM>
Cc: homenet-chairs@ietf.org, homenet@ietf.org, mark@townsley.net, draft-ietf-homenet-hncp@ietf.org
Subject: Re: [homenet] Brian Haberman'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: Fri, 20 Nov 2015 09:07:35 -0000

Hello Brian,

thanks for the comments.

On 19.11.2015 14:59, Brian Haberman wrote:
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> * I see where HNCP describes how interfaces are classified as internal or
> external, but how does an interface get classified as leaf, guest, or
> ad-hoc?  Is this some manual configuration step that needs to be
> described somewhere?

These can only be manually selected. I have added a sentence:

  Note that all fixed categories
  except internal and external cannot be auto-detected and can only
  be selected using manual configuration.

to the second-last paragraph of the border discovery algorithm section.


> * The definition of Leaf in 5.1 is unclear.  It says "Such an interface
> uses the Internal category with the exception that HNCP traffic MUST NOT
> be sent on the interface, and all such traffic received on the interface
> MUST be ignored." The "all such traffic" is ambiguous. Based on the
> definition of the Guest category, I think "all such traffic" is really
> "all HNCP traffic".

I have changed it to

  Such an interface uses the Internal category with the exception that
  it MUST NOT operate as a DNCP endpoint.

to be in line with the changed definitions for the internal and external
categories (to address one of Ben's comments).


> * The text in section 5.3 seems incomplete. It gives a 4-step algorithm
> for border discovery, but says "if the node does not implement
> auto-detection, only the first step is required." If auto detection is
> not supported and a fixed category is not configured, what happens? Does
> this mean that if auto detection is not supported manual configuration of
> the border is required?

I changed it to "first and last" so the default is in line with the
default for the auto border discovery.


> * Section 7 describes how to handle non-HNCP capable routers. However, I
> don't see any operational issues described that could arise from having a
> non-HNCP capable router connecting two clouds of HNCP within the same
> home network. It seems like that could cause problems with a bunch of the
> services provided by HNCP.

I have added this as a paragraph to the applicability section:

  While HNCP routers can provide configuration to and receive
  configuration from non-HNCP routers, they are not able to traverse
  such devices based solely on the protocol as defined in this document,
  i.e., HNCP routers that are connected only by different interfaces
  of a non-HNCP router will not be part of the same HNCP network.


> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> * Section 3 has several ambiguous/confusing statements:
> 
> 1. Does "locally unique" mean unique to the node or unique to the
> link/network?

Clarified.

> 
> 2. On a node ID collision, which node re-computes? The one detecting, I
> assume.

Correct.

> 
> 3. "7 doublings" is an odd phrase.  Why not say "Imin * 2^7"?
> 

That phrase actually comes from the Trickle RFC
"The maximum interval size, Imax, is described as a number of
      doublings of the minimum interval size (the base-2 log(max/min))."



Cheers,

Steven