Another aspect to consider: IMHO, industry player/marketeers use the term "intent" not to describe a particular subset of instructions into the network but as a term to describe the overall systems operation.
Eg: Google: https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/45687.pdf Intent driven operations, from slide 22 on. IMHO Cisco also jumped onto this terminology in its latest intent based networking pitch. In this context, intent based networking is simply that the operator specifies a target ("intended") state of the network and some "rendering engine(s)" try to continuously modify the network to match that intended state. Including changes to the network due to failures. Eg: re-establish services such as BGP speakers on other nodes when current instances fail. IMHO: with this notion of intent, it would be perfectly valid to enter any type of high or low level declarative and even instructive data into the network - including my favourite instance of an rfc8049 L3VPN service. The input into the network has no name in these models. It is whatever operators put into SDN controllers or workflow engines, or whatever the tool of the day is called. My vision for ANIMA and intent is something like this: We come up with a term for everything operators would want to send into a network. Lets say we call it "directives". And we can keep the term for everything the operator gets out of a network "reporting". We structure and define some taxonomy for "directives", eg: "service definitions", "service instances", {user, topology, reliability, performance, acc-control,...}-policies, workflows, ... We describe an architecture how directives are rendered, eg: how the network is made to match the directives. Different type of directives may require different rendering. The key difference between existing systems (google, cisco, ..) is that we define a hybrid central + distributed rendering architecture: draft-du-anima-intent IMHO would be the basis for the distributed rendering: This is used whenever there are self-rendering autonomic functions (aka: a group of ASA that know how to render directives). Even for central rendering there are no well established standards. That too IMHO would be worth looking at. Maybe some other IETF WG would like to do this as well, which would be fine too, as long as we allow this option in ANIMA as well. The word intent does not happen in these definitions, and we are totally free to decide later if we call the whole system "intent based", or iwf we call all of the directives or just a subset of the directives "intent". I am not sure if we would still want to take this step for the reference model. For me it would be fine not to change reference model at all, and take the step above afterwards. Its afer all not really a functional change to what we describe in the reference model, but really only a refinemenet and then renaming to match evolving industry terminologies. Cheers Toerless P.S.: I would have gone for "Objectives" instead of "Directives", but that word is already occupied by GRASP and reuse would IMHO be confusing... In-Reply-To: <5d36713d8a4e7348a7e10df7437a4b927ce3a...@nkgeml515-mbx.china.huawei.com> On Wed, Jul 26, 2017 at 10:58:06AM +0000, Sheng Jiang wrote: > Hi, Toerless, Brian & Jeferson, > > Please see my replies in line with quotas from you. > > Toerless> 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. > > I prefer such distinguish definitions. Intent itself does not have a clear > definition. It does not a clear role in Autonomic network either. This word > has been abused a lot. If we cannot reach consensus on its semantics. It may > be wise to give up it and choose more precise terminologies. > > Toerless>I think that draft-du-anima-an-intent would equally > > apply to all information we would want to distribute into an autonomic > > network. > Jeferson>I believe this could be addressed in draft-du-anima-an-intent. > > As a co-author of this draft, I also think we have a very good base already. > However, we may need to rename the document in order to avoid the too-hot > term "intent". > > Brian>we could spend another 6 months discussing how to know Intent when we > see it. But I would prefer that to happen in NMRG. > Jeferson>I agree with Brian, the intent "philosophical" discussion fits > better the NMRG. > > This suggestion is actually very pragmatic. Let's focus on these concrete and > generic solutions first. > > Regards, > > Sheng > > > -----Original Message----- > > From: Anima [mailto:[email protected]] On Behalf Of Brian E Carpenter > > Sent: Wednesday, July 26, 2017 7: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 -- --- [email protected] _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
