Re: [homenet] Objection to late change in draft-ietf-homenet-prefix-assignment
Am 07.07.2015 um 23:24 schrieb Brian E Carpenter: 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 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Objection to late change in draft-ietf-homenet-prefix-assignment
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 meral.shirazip...@ericsson.com a écrit : 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:brian.e.carpen...@gmail.com] Sent: Tuesday, July 07, 2015 2:25 PM To: Pierre Pfister Cc: IESG; homenet@ietf.org; 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: 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
Re: [homenet] Objection to late change in draft-ietf-homenet-prefix-assignment
On 09/07/2015 02:10, Steven Barth wrote: Am 07.07.2015 um 23:24 schrieb Brian E Carpenter: 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 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? 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 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Objection to late change in draft-ietf-homenet-prefix-assignment
That seems OK to me. There are some aspects that we need to discuss over in Anima in due course. Brian On 09/07/2015 01:53, Pierre Pfister wrote: 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 meral.shirazip...@ericsson.com a écrit : 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:brian.e.carpen...@gmail.com] Sent: Tuesday, July 07, 2015 2:25 PM To: Pierre Pfister Cc: IESG; homenet@ietf.org; 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: 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
[homenet] Objection to late change in draft-ietf-homenet-prefix-assignment
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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Objection to late change in draft-ietf-homenet-prefix-assignment
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 brian.e.carpen...@gmail.com a écrit : 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
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: 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 brian.e.carpen...@gmail.com a écrit : 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
Re: [homenet] Objection to late change in draft-ietf-homenet-prefix-assignment
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:brian.e.carpen...@gmail.com] Sent: Tuesday, July 07, 2015 2:25 PM To: Pierre Pfister Cc: IESG; homenet@ietf.org; 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: 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 brian.e.carpen...@gmail.com
