Hi
Aren't intents something related to the actual autonomics of the ANI, while the use case described by Toerless would be more from an operated context? RFC7575 in particular does not exclude operated environments, and the latter might or might not use intents or policy-based management principles. So, what is autonomic is the establishment and maintenance of the ACP, I,.e. the means to manage the environment (in any way you like). So, from my understanding, solely the autonomic part related to the self-* properties of the ACP and the autonomic domain (AD) as such would be driven by intents, and not more than that. Corroborating this interpretation, the scope of the intent is intrinsically bound to the very notion of AD by the definition of the latter, cf. RFC7575. Therefore, we could try to agree on something like this: - Within the scope of the ANIMA WG, we could interpret intents as solely related to the ANIMA itself, not to its usage. In other words, the existence, constraints, form, shapes and parameters of the AD per se (=the enabling substrate, the mandatory ASAs, the implementation of the ANI) are ruled by and derived from intents. [What is meant here is a form of policy based management, where instead of precise actions (do this), the expected conditions (pre- and post-) are formulated for and within the limits of the AD (pre-condition => post-condition). The only interesting property of this is that it is implementation agnostic, i.e. you are not prescribing how the post-condition is to be achieved. In my interpretation, this means that in particular the standardization effort is minimized (since we do not prescribe how to arrive at a particular situation, we do not have to worry about specific mechanisms within the ANIMA itself; a conforming implementation has different ways how to achieve it)]. - How the AD is used, e.g. by an operator, or by some end-user ASA, should rather be outside of the scope of ANIMA WG and is solely constrained by the API that ANIMA would propose and the imagination of the respective owners/developers. Note that this does not preclude any kind of "recursive" definitions, where an AF implemented on top of an ANI would constitute another AD, where the same would apply (ASAs would become "nodes"), etc. Does that make any sense? Regards artur -----Original Message----- From: Anima [mailto:[email protected]] On Behalf Of Zoran Despotovic Sent: 26 July 2017 09:30 To: [email protected] Subject: Re: [Anima] What is intent ? Hi, A little bit off the thread started by Toerless, I believe that the development of the infrastructure on which intents are distributed should not be tightly bound to our understanding of and consensus on what intents are (and what they are not). This, at least, as long as there are other parameters to be distributed over that infrastructure. In that sense, I do agree with Brian's mail. Regards, Zoran -----Original Message----- From: Anima [mailto:[email protected]] On Behalf Of Brian E Carpenter Sent: Wednesday, July 26, 2017 1:05 AM To: Toerless Eckert; [email protected] Subject: Re: [Anima] What is intent ? Distribution trimmed to Anima: Whenever I've asked "Is X Intent?", I've usually been told "No" except for cases where X is too abstract to interpret algorithmically. But in practice, I believe that many ASAs will need instructions from the NOC to modify their default behaviour. I don't care what we call those instructions; for the prefix management use case we just called them "parameters". So maybe Anima should focus on parameter distribution more than on Intent. I think that's the point of draft-liu-anima-grasp-distribution. A fairly simple change to the wording of draft-du-anima-an-intent would adapt it to generic parameter distribution. Converting abstract Intent to concrete parameters can be completely separate from this, and could well be a centralised operation. Or we could spend another 6 months discussing how to know Intent when we see it. But I would prefer that to happen in NMRG. Regards Brian On 26/07/2017 08:34, Toerless Eckert wrote: > I have an autonomic network, and i want for another customer another > L3VPN service instance in it. How would i tell the network that i > want this ? Via intent or via something else ? > > If it is something else, what is it ? I do not see any other > information flow from operator to network beside intent in RFC7575 or > draft-ietf-anima-reference-model. > Maybe i am missing something. > > If it is intent, how would it look like ? Could it simply be a > definition of an L3VPN service instance in the model defined in rfc8049 ? If > not, why not ? > > IMHO: Intent in ANIMA includes service definitions such as what > rfc8049 is, except that we would reserve the right to eliminate all > parameters of rfc8049 for which we figure out autonomic ways to > determine them. Which alas seems to be quite difficult for most parameters. > > Other folks in the IETF clearly think that a service definition is NOT > intent, but intent can only be some yet unclear high level policy. If > thats the prevailing opinion/wisdom in the IETF, then IMHO we need to > be more explicit about the fact that Intent is not the only input into > the network but that there is also other input. Such as services. And > anything else that people do not want to call Intent. > > Lets assume service and other necessary data operator->network should > not be called intent. But lets say the superset of intent + services + > everything else is called eg: "information". I think that > draft-du-anima-an-intent would equally apply to all information we > would want to distribute into an autonomic network. > > Cheers > Toerless > > _______________________________________________ > Anima mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/anima > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
