Subject: [homenet] Objection to late change in draft-ietf-homenet-prefix-assignment

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Jul 2015 07:45:36 +1200

Hi,

Sorry to be so late with this but I had some personal distractions recently.

I am very surprised by a change that was made to this draft after IETF Last Call
and with no discussion, as far as I am aware, on the WG list. It is this
additional sentence in the first paragraph:

"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 professionally managed networks."

Firstly, this is a substantive change so I believe it should have been
discussed by the WG.

Secondly, the second half of the sentence seems completely unjustified, and
is way outside the Homenet context anyway. I believe that the range of
requirements for autonomic and/or professionally managed networks is far too
great to assert that "variable priority assignments" meet the needs; much
more general policy intent might be needed in autonomic networks, for
example, and the work on this topic is only just starting in Anima. As a
specific example, an international enterprise network might have geographical
requirements for prefix assignmnent.

Quite apart from the process issue, I believe that the second half of
the added sentence is wrong and must be deleted.

Regards
   Brian Carpenter

---

From: Pierre Pfister <[email-masked]>
Date: Tue, 7 Jul 2015 22:38:50 +0200

Hello Brian,

This change was introduced after the Gen-ART review from Meral Shirazipour, I quote:
  "I found the draft a bit hard to follow as the incentive was not clear at first. 
  A few sentences in abstract or introduction on 'why' we need this algorithm and what would the 'alternatives' be would be useful. Right now it only says 'what' the algorithm does."

This whole paragraph was therefore added:
   This document specifies a distributed algorithm for automatic prefix
   assignment.  The algorithm provides a generic alternative to
   centralized (human or software based) approaches for network prefixes
   and addresses assignment.  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 professionally managed networks.

Its purpose is to clarify the goal of the algorithm in a short sentence.

Digging back into my mails, I realize that the exchange I had about this update with Meral was private.
My mistake, i thought the mailing list was cc’d to the discussion. Apologies for that.
Too bad we did not settled this situation earlier, but anyway, I am glad we can discuss the change now.

Still digging, I see you invited the Anima mailing list to discuss that change as well. Feedback from
Anima is very welcome. I mean, not about the scopyness or not of a sentence,
but rather on the value of the algorithm for Anima. I see there were no reactions though.

Now, concerning the correctness of this sentence. I think it can be proven this way:

1. Professionally managed networks are configured by the mean of human configuration or by orchestrators.
2. The prefix assignment algorithm can be configured with preferred prefixes either by humans, or by orchestrators.
Therefore: You can use the algorithm to configure a professionally managed network.

Example 1:
The prefix assignment algorithm can be configured with static prefixes.
Static and automatic assignments can even be done depending on the link or the delegated prefix.
For example, an enterprise could want part of the network to be numbered statically, and another part of the network to be 
numbered automatically. 
This is perfectly possible by configuring some links with preferred assignment with a greater priority than auto-assigned prefixes.

Example 2:
Now, about your example of managed network with geographical constraints.
Nodes executing the prefix assignment are allowed to *not* make assignments from a given delegated prefix.
Which means if you have two areas (A and B), and two delegated prefixes (X and Y), nodes in A can be configured to only assign prefixes within X, and nodes in B configured to only assign prefixes from Y.

The prefix assignment algorithm is a network management tool enabling auto-configuration *where you want it to happen*.
It does not mandate auto-configuration (it does when used by HNCP, but that is only one possible use of the prefix assignment algorithm).
The document mostly explains:
- The main detailed specification of the algorithm.
- The rules that you MUST respect if you want the algorithm to work.

And the thing is that about everything that does not create prefix collision is, in the end, authorized.
You could put anything as a configuration tool on top of PA, 
from a netconf/Yang orchestrator to the usual linux ‘ip addr’ utility, or even what the Anima working group could end-up specifying.

I hope this helps with your concern about the correctness of this sentence.

I will be in Prague as well and would be happy to discuss whether PA could be useful to Anima.

Thanks,

- Pierre

> Le 7 juil. 2015 à 21:45, Brian E Carpenter <[email-masked]> a écrit :
> 
> Hi,
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Jul 2015 09:24:36 +1200

Pierre,

Thanks for the prompt reply. I am not too worried about the process
issue, and I do understand why that whole paragraph was added (I've
added Meral in cc).

Your explanation is fine but the phrase "and can therefore be used in
fully autonomic as well as professionally managed networks" still makes
some big assumptions. How about "and can therefore be used more
widely than in unmanaged home networks"?

> I will be in Prague as well and would be happy to discuss whether PA could be useful to Anima.

I can easily imagine an autonomic service agent (in Anima terminology)
using this algorithm (quite independent from whether it uses DNCP).

Regards
   Brian

---

From: Meral Shirazipour <[email-masked]>
Date: Tue, 7 Jul 2015 21:54:56 +0000

Hi,
  Thanks for including me. Adding back gen-art list to this thread. I am ok with Brian's suggested text. 

Best,
Meral

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Tuesday, July 07, 2015 2:25 PM
To: Pierre Pfister
Cc: IESG; [email-masked]; Meral Shirazipour
Subject: Re: [homenet] Objection to late change in draft-ietf-homenet-prefix-assignment

Pierre,

Thanks for the prompt reply. I am not too worried about the process issue, and I do understand why that whole paragraph was added (I've added Meral in cc).

Your explanation is fine but the phrase "and can therefore be used in fully autonomic as well as professionally managed networks" still makes some big assumptions. How about "and can therefore be used more widely than in unmanaged home networks"?

> I will be in Prague as well and would be happy to discuss whether PA could be useful to Anima.

I can easily imagine an autonomic service agent (in Anima terminology) using this algorithm (quite independent from whether it uses DNCP).

Regards
   Brian

On 08/07/2015 08:38, Pierre Pfister wrote:
> Still digging, I see you invited the Anima mailing list to discuss 
> that change as well. Feedback from Anima is very welcome. I mean, not 
> about the scopyness or not of a sentence, but rather on the value of the algorithm for Anima. I see there were no reactions though.
> 
> For example, an enterprise could want part of the network to be 
> numbered statically, and another part of the network to be numbered automatically.
> You could put anything as a configuration tool on top of PA, from a 
> netconf/Yang orchestrator to the usual linux ‘ip addr’ utility, or even what the Anima working group could end-up specifying.
> 
>> I am very surprised by a change that was made to this draft after 
>> IETF Last Call and with no discussion, as far as I am aware, on the 
>> WG list. It is this additional sentence in the first paragraph:
>>
>> Firstly, this is a substantive change so I believe it should have 
>> been discussed by the WG.
>>
>> Secondly, the second half of the sentence seems completely 
>> unjustified, and is way outside the Homenet context anyway. I believe 
>> that the range of requirements for autonomic and/or professionally 
>> managed networks is far too great to assert that "variable priority 
>> assignments" meet the needs; much more general policy intent might be 
>> needed in autonomic networks, for example, and the work on this topic 
>> is only just starting in Anima. As a specific example, an 
>> international enterprise network might have geographical requirements for prefix assignmnent.
>>

---

From: Pierre Pfister <[email-masked]>
Date: Wed, 8 Jul 2015 15:53:49 +0200

Thank you for this proposal.

In the same spirit (but reducing the amount of changes), what about 
« and can therefore be used in fully autonomic as well as configured networks »  ?

I think « configured » has a smaller scope than « professionally managed network ».

- Pierre

> Le 7 juil. 2015 à 23:54, Meral Shirazipour <[email-masked]> a écrit :
> 
> Hi,

---

From: Steven Barth <[email-masked]>
Date: Wed, 08 Jul 2015 16:10:19 +0200

> widely than in unmanaged home networks"?

I would disagree here, the statement "autonomic" or "fully autonomic" is perfectly
fitting for the kind of networks this algorithms can be used in. It can certainly
also be used in professionally managed networks or do you see any reason why it
cannot?

This said, it does not necessarily mean that it is a perfect fit for all kinds of
these networks, but nobody did claim that either. It is extensible though so there
is no way to discard it for these usecases that easily.

Cheers,

Steven

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 09 Jul 2015 08:04:10 +1200

That seems OK to me. There are some aspects that we need to
discuss over in Anima in due course.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 09 Jul 2015 08:09:36 +1200

> also be used in professionally managed networks or do you see any reason why it

The current text implies (to me) that it's necessary and sufficient, which is
definitely not the case and was never discussed in the WG anyway. The change
most recently suggested by Pierre is OK for me.

Rgds
   Brian