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

[Pierre Pfister <[e-mail]>]

Hello Brian,

Thanks for the comments.

See inline for comments and proposals.


> Le 8 juil. 2015 à 17:34, Brian Haberman <[e-mail]> 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?

As I mentioned as a response to Tim, the prefix assignment algorithm hardly speaks of IPv6.
You can assign IPv4 prefixes, string prefixes, numbers and so on.

These considerations are, of course, utterly important for homenet, and are discussed as such
in the context of HNCP, which already includes considerations regarding these points.

One of the main reason of separating the algorithm from HNCP was specifically to avoid
having such rules in a document which specifies an algorithm which can be applied in other areas.

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

I proposed the following addition as a reply to Alvaro’s concern.
Such topology changes may cause renumbering. For instance, when two links are joined, each of which being assigned a prefix from a given delegated prefix, one of the two prefix is withdrawn.

Almost any event can cause renumbering, it all depends on the nodes and what they are advertising at the point the event occurs.

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

Indeed. those assumptions are detailed in the applicability statement section.

But instead of DNCP, the underlying protocols are referred to the Flooding mechanism and
the node ID assignment mechanism.

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

Are you sure I should include the whole boilerplate even when I am clearly not using
all the words ?

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

Well noticed. ;)
For the Links, there is a circular dependency.
It is better to have ‘Link’ definition before sub-classes.

For the delegated prefix. Well. I am not sure it would make sense to but it all down.
It is a fairly important term. Having it among the first also makes sense. 
And I think a reader has a quite good idea of what an assigned prefix is at that point.
At least good enough to understand why the delegated prefix is used as prefix pool for them.

Also, doesn’t ‘avoid’ has an hidden meaning of ‘best effort’ ?

Thanks,

- Pierre