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

Pierre Pfister <pierre@darou.fr> Thu, 09 July 2015 09:08 UTC

Return-Path: <SRS0=m4Uy=HR=darou.fr=pierre@bounces.m4x.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 47B961ACE9B; Thu, 9 Jul 2015 02:08:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 fN3oFvtH6jVJ; Thu, 9 Jul 2015 02:08:22 -0700 (PDT)
Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F17DC1ACE78; Thu, 9 Jul 2015 02:08:21 -0700 (PDT)
Received: from [10.148.10.58] (unknown [173.38.220.44]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 328C9140AC444; Thu, 9 Jul 2015 11:08:18 +0200 (CEST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_CCDE8DA2-C772-4B31-A28C-926BD2CBDCE0"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Pierre Pfister <pierre@darou.fr>
In-Reply-To: <20150708153443.24832.8574.idtracker@ietfa.amsl.com>
Date: Thu, 09 Jul 2015 11:08:17 +0200
Message-Id: <0253CA77-0F7F-499D-853C-F68EF947DCFB@darou.fr>
References: <20150708153443.24832.8574.idtracker@ietfa.amsl.com>
To: Brian Haberman <brian@innovationslab.net>
X-Mailer: Apple Mail (2.2102)
X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Thu Jul 9 11:08:18 2015 +0200 (CEST))
Archived-At: <http://mailarchive.ietf.org/arch/msg/homenet/Do8PtRHCS2tFaFgdiL4R1_lzKms>
Cc: HOMENET <homenet@ietf.org>, Alia Atlas <akatlas@gmail.com>, Mark Townsley <mark@townsley.net>, The IESG <iesg@ietf.org>, Ray Bellis <ray@bellis.me.uk>
Subject: Re: [homenet] Brian Haberman's Discuss on draft-ietf-homenet-prefix-assignment-07: (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: Thu, 09 Jul 2015 09:09:25 -0000

Hello again Brian,

Following the discussion concerning topology changes, here is a proposal:

OLD:
   The algorithm supports dynamically changing topologies:

   o  Nodes may join or leave the set of participating Nodes.
   o  Nodes may join or leave Links.
   o  Links may be joined or split.


NEW:
   The algorithm supports dynamically changing topologies and therefore
   will converge if the topology remains unmodified for a long enough
   period of time (That time depends on the Flooding Mechanism
   properties).  Nevertheless, some topology changes may induce
   renumbering, while others do not.  In particular, Nodes joining the
   set of participating Nodes do not cause renumbering.  Similarly,
   Nodes leaving the network may be dealt with without renumbering by
   using the prefix adoption procedure.  On the other hand, Links
   junction or split may break correctness conditions, and therefore
   cause renumbering.

Thanks,

- Pierre


> Le 8 juil. 2015 à 17:34, Brian Haberman <brian@innovationslab.net> a écrit :
> 
> Brian Haberman has entered the following ballot position for
> draft-ietf-homenet-prefix-assignment-07: 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-prefix-assignment/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> I don't object to the publication of this document, but there are some
> issues that need to be remedied.
> 
> 1. Section 5 provides the considerations for selecting prefixes. However,
> those considerations are incomplete. RFC 7421 provides the analysis for
> the use of the /64 boundary.  The Homenet Architecture (RFC 7368)
> discusses various Homenet-related issues around not getting sufficient
> address space to allocate /64 prefixes to links. RFC 6164 discusses the
> use of 127-bit prefixes on point-to-point links. Why does this section
> not mention any of these considerations when selecting a prefix?
> 
> 2. I am raising Alvaro's point about the impact of topology changes to a
> DISCUSS.  I think there needs to be sufficient discussion in the document
> on the impact of topology changes on the prefix assignment algorithm and
> the impact of changing prefix assignments on nodes in the network. This
> ties in to the point raised by Brian Carpenter on the claim in the
> Introduction that this algorithm can be used in "fully autonomic as well
> as professionally managed networks". This is especially true when
> convergence is described as occurring "eventually".
> 
> 3. I understand that this document became standalone when the HNCP and
> DNCP documents split. What dependencies/assumptions does this document
> have on either one of them?  There appears to be some assumptions on the
> Node ID and the flood algorithm.
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> * ID-nits complains about the malformed 2119 keywords text in the
> Terminology section.  It would be good to use the entire boilerplate for
> the 2119 keywords.
> 
> * The terminology section claims that the definitions are ordered to
> avoid forward reference, but that is not the case. For example, Link
> refers to Shared Link and Private Link, Delegated Prefix refers to
> Assigned Prefix, etc.
> 
> 
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet