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

From: "Brian Haberman" <[email-masked]>
Date: Thu, 09 Jul 2015 05:31:06 -0700

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

Updated position based on feedback from Int-Dir review (Suresh
Krishnan)...

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.

4. How does the algorithm deal with prefix delegations that have holes
(e.g. RFC6603)? This text seems to preclude such delegations.

5. Section 6 discusses Listener nodes. Does there need to be some
discussion/warning about links that consist of all Listeners?  The link
will not get a prefix assigned to it in such a situation.

6. How does this approach deal with asynchronous link state changes?

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

* The definition of Node ID is unclear. What do you mean by "The set of
identifiers MUST be strictly and totally ordered". A node id is a single
identifier, right?

---

From: Pierre Pfister <[email-masked]>
Date: Thu, 9 Jul 2015 16:10:15 +0200

See inline for comments for the points that are not being discussed in the other mail thread.

> Le 9 juil. 2015 à 14:31, Brian Haberman <[email-masked]> a écrit :
> 

Is being discussed in the other mail thread.

> convergence is described as occurring "eventually ».

Is being discussed in the other mail thread.

> Node ID and the flood algorithm.

Is being discussed in the other mail thread.

> (e.g. RFC6603)? This text seems to preclude such delegations.

It can deal with it very well.
See HNCP document section 6.2.5: https://tools.ietf.org/html/draft-ietf-homenet-hncp-07#section-6.2.5 <https://tools.ietf.org/html/draft-ietf-homenet-hncp-07#section-6.2.5>

You can even have multiple holes in the same delegated prefix.

> will not get a prefix assigned to it in such a situation.

The statement is true, but I don’t think a warning is necessary because this 
could happen even with other nodes as well.
Prefix assignment is not mandatory (In this document I mean, it is in HNCP 
and would probably be under some circumstances in any profile document),
nodes may decide to not assign prefixes at all, although they are capable of
doing it.

The decision of making an assignment is out of scope of the document:
Decide whether the creation of a new assignment for the given Delegated
       Prefix and Link pair is desired (As any result would be valid,
       the process of making this decision is out of the scope of this

> 6. How does this approach deal with asynchronous link state changes?

Sorry but google does not tell me what an 'asynchronous link state change’ is.
Could you please clarify your question ?

Thanks

- Pierre