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

From: "Brian Haberman" <[email-masked]>
Date: Wed, 08 Jul 2015 08:34:43 -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:
----------------------------------------------------------------------

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.

---

From: Pierre Pfister <[email-masked]>
Date: Wed, 8 Jul 2015 23:25:35 +0200

Hello Brian,

Thanks for the comments.

See inline for comments and proposals.

> Le 8 juil. 2015 à 17:34, Brian Haberman <[email-masked]> a écrit :
> 

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.

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

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

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

> refers to Shared Link and Private Link, Delegated Prefix refers to

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

---

From: Pierre Pfister <[email-masked]>
Date: Thu, 9 Jul 2015 11:08:17 +0200

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

> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Brian Haberman <[email-masked]>
Date: Thu, 9 Jul 2015 08:21:10 -0400

On 7/8/15 5:25 PM, Pierre Pfister wrote:
>> 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.
>> 
>> 
>> 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.

So, this isn't just an address prefix assignment algorithm?  I certainly
don't get that from reading the specification given this statement:

"an implementation can make use of IPv4-mapped IPv6 addresses [RFC4291]
in order to manage both IPv4 and IPv6 prefix assignment using a single
prefix space."

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

Will there be some type of profile document coming next that describes
how to apply this general purpose algorithm to the Homenet/HNCP problem
space?  In the enterprise space?

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

*If* we consider this approach just for assigning IP prefixes, there is
still a need for some guidelines on how the prefix pool is divided
amongst the N links connected to a node. If your above recommendation of
using IPv4-mapped IPv6 addresses is adopted, the assignment of those
will differ from other IPv6 prefixes.

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

I think the above misses the point.  This algorithm has some unknown
convergence time bounded by "eventually".  The text says:

"When an Assigned Prefix is applied, it MAY be used (e.g., for host
configuration, routing protocol configuration, prefix delegation)."

When this algorithm does have to renumber, it gates the convergence time
of the routing protocol as well.  So, even when this algorithm marks the
prefix "Assigned" and it gets advertised to a set of hosts, there is no
way to know when the hosts can actually use the prefix successfully
since the infrastructure now has to wait on routing protocol convergence.

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

Right.  Those are the ones I saw and pointed out.  However, in
"professionally managed networks", you also have issues with firewalls,
ACLs, DNS, etc.

> 
> But instead of DNCP, the underlying protocols are referred to the
> Flooding mechanism and the node ID assignment mechanism.
> 
>> 
>> 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 ?
> 

That is the common practice.

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

I am not aware of such a hidden meaning.

I also have some additional points that I will be adding to my ballot.

Regards,
Brian

---

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

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

Please allow me to quote the whole sentence:
   The algorithm can be applied to any address space and can be used to
   manage multiple address spaces simultaneously.  For instance, an
   implementation can make use of IPv4-mapped IPv6 addresses [RFC4291 <https://tools.ietf.org/html/rfc4291>]
   in order to manage both IPv4 and IPv6 prefix assignment using a
   single prefix space.

This is given as an example of how the algorithm can be used to assign prefixes
from multiple addressing spaces at the same time.

It also is the only reference made to IP. 

> space?  In the enterprise space?

There already is.
You can have a look at HNCP, Section 6:
https://tools.ietf.org/html/draft-ietf-homenet-hncp-07#section-6 

> will differ from other IPv6 prefixes.

I think such considerations are also answered in HNCP, where which prefix length
should be used for what kind of prefix is stated.
https://tools.ietf.org/html/draft-ietf-homenet-hncp-07#section-6.2.3

> since the infrastructure now has to wait on routing protocol convergence.

Indeed, a prefix being « Applied » means that you can safely provide it to other processes,
without fearing too much for an unexpected withdrawal.
If you provide it to both hosts and RP at the same time, you will have a delay before the addresses are actually useful.
But this is a MAY. So in case your application/use-case has an additional requirement that you MUST NOT
provide an address to a host before the routing protocol has converged, you can enforce that in the « profile » specification.

But let’s have a look at how it is done today. In routed networks, addressing happens way before routing. 
Sometimes even before the routing protocol is started. In the Homenet scenario, getting a PD from the ISP does not
mean that it is useable (It does, most of the time, but the ISP is not going to withdraw the prefix when it detected an issue with its network).

The algorithm does not prevent you from being clever.
So although these are very interesting considerations, 
I don’t think they could be stated in the document without being out of scope.

> "professionally managed networks", you also have issues with firewalls,

The « professionally managed networks » terms have been discussed already and will be removed.

The new text is:
Although it does not require to be
   configured to operate properly, it supports custom configuration by
   means of variable priority assignments, and can therefore be used in
   fully autonomic as well as configured networks.

> That is the common practice.

OK, will be fixed.

> I am not aware of such a hidden meaning.

I will change it to « try to avoid ».

> I also have some additional points that I will be adding to my ballot.

I will send another mail with related comments.

Thanks,

- Pierre