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 protected]> 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 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 > [email protected] > https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
