Subject: Re: [Anima] Does Autonomic network need some intervention beyond intent

From: John Strassner <[email-masked]>
Date: Sun, 3 Apr 2016 14:48:29 -0700

Hi Brian,

could I request two points of clarification?

>>> Indeed not. An ASA will have some default behaviour that amounts to
having
>>> default settings for intent, but by definition intent comes from humans.
>>> (One qualification: if the intent that reaches a given node is
inconsistent,
>>> then resolving that inconsistency might be autonomic.)
>>
>> Brian: could you explain what you mean here, especially "resolving that
inconsistency might be autonomic"?
>> I guess you mean that ASAs/nodes can autonomously detect inconsistency
in intents and (try to) solve this inconsistency (on
>> their own or via collaboration)...?

> Yes. Actually if we allow more than one source of intent, this is
essential.

According to the reference architecture, an Autonomic Function (AF) can
be made up of one or more ASAs, and each ASA is instantiated on an
autonomic node. The set of AFs reside on the ANI.

I would prefer that intent is sent to the ASA, not directly to the
(autonomic)
node. This means that the autonomic node has to be able to understand
intent AND understand when intent conflicts, and the Industry has a poor
of providing useful support functions. Even with the hype that is IoT, show
me a vendor that wants to make their phone "intelligent" vs. providing
higher-resolution cameras or more codecs. :-(

Another consequence is that each ASA has to be able to understand intent
AND understand when intent conflicts. OK, I could suppose that we could
define AFs for this. But AFs are built on the ANI, so does this mean that
the ANI has to support intent as well? The draft says:

     The ANI provides functions like naming, addressing, negotiation,
      synchronization, discovery and messaging.

These are all functions that are needed by Intent, but Intent adds things
that are not needed by the ANI.

>> Without rewriting history, we are facing now with the "heavy"
>> design/conceptual discussions on the list, the effect of some
>> decisions to exclude architectural analysis / investigations in the
>> early phase of ANIMA...

> I maintain that these are issues of ASA design, not infrastructure design.
> We always knew that the infrastructure has to distribute Intent.

I think that the infrastructure has to distribute the **results** of parsing
intent. That is, the parsing is done in a dedicated agent, NOT in an
autonomic node, and the agent transforms Intent to a form that is
generally consumable. This "consumable form" has to be distributed,
but the original intent does not.

regards,
John

On Tue, Mar 29, 2016 at 12:29 PM, Brian E Carpenter <
[email-masked]> wrote:

> Hi Laurent, comments in line:
> On 30/03/2016 05:29, Laurent Ciavaglia wrote:
> > Hello,
> >
> >
> >> Indeed not. An ASA will have some default behaviour that amounts to
> having
> >> default settings for intent, but by definition intent comes from humans.
> >> (One qualification: if the intent that reaches a given node is
> inconsistent,
> >> then resolving that inconsistency might be autonomic.)
> >
> > Brian: could you explain what you mean here, especially "resolving that
> inconsistency might be autonomic"?
> > I guess you mean that ASAs/nodes can autonomously detect inconsistency
> in intents and (try to) solve this inconsistency (on
> > their own or via collaboration)...?
>
> Yes. Actually if we allow more than one source of intent, this is
> essential.
>
> >
> >>
> >>>> Of course, when we put Intent into the picture, there's a presumption
> >>>> that Intent comes from some authority such as a NOC, but that's an
> >>>> external semantic, not an assumption of the autonomic model.
> >>> Well, no - if the autonomic system is going to use intent, or at least
> >>> respond to it, then it must understand those external semantics.
> >>> This is even more important if the network is supposed to form
> >>> according to one or more intent rules.
> >> Right, but what I meant is that the network will operate perfectly well
> >> if no intent is sent, by using defaults. That will always happen to the
> >> extent that intent distribution will take a finite time. Until the
> intent
> >> reaches a node, it will operate on defaults.
> >
> > From collaborations with some operators on autonomic networking
> projects: default behavior without policy must equal to "do
> > nothing". But operators' views might change/evolve...
>
> That's certainly a possibility. I'm not sure it is always wise though.
> For example, if a network is fragmented by a natural disaster, the
> fragments
> might not receive Intent for several days.
>
> > Also, and this is based on feedback from the field (e.g. 3GPP SON),
> turning on autonomic functions, even with well-thought
> > parameter settings, turns out most of the times in chaotic behaviors and
> severe performance degradations.
> > A key element to consider here is how to "gracefully" start/ramp-up an
> autonomic network and aspects of coordination (cf
> > draft-ciavaglia-anima-coordination-01).
>
> Agreed. Obviously the defaults must be conservative and fail-safe.
>
> >
> >>   Of course, the semantics of
> >> intent must be well-defined, but it's an extra layer.
> >>
> >>> If intent is formulated at an abstract level, how is an autonomic
> >>> network going to consume intent that may have drastically different
> >>> syntactical structures, and likely, different semantics associated with
> >>> those syntactical structures?
> >> Agreed. We need a model, syntax and semantics.
> >>
> >>>> I think the point is that AN *adds* a new mode of communication
> >>>> between self-managing nodes, that doesn't exist in a strictly
> >>>> north/south scenario. That is meant to reduce the amount of
> >>>> north/south communication and reduce the amount of
> >>>> centralized work. So there's a trade-off - more autonomic
> >>>> messaging means less north-south messaging.
> >
> > north-south is a matter of convention / roles.
> > if we consider PBM / intent, for me it implies a "vertical" (authority)
> relationship.
> > if we consider a more "flat" system of collaborative entities, then
> let's have a look at MAS / DAI approaches and not reinvent
> > (a squarred) wheel.
> > we may end up pushing more or less intelligence in the autonomic
> functions, but we also consider the scope of ANIMA to address
> > "managed" networks (maybe not only this one), so it means some operators
> will expect certain behavior/performance from the
> > neworks. Intent is one way to inform the network what is expected.
>
> Sure. But always remember the disaster-recovery scenario where we are
> forced
> back to defaults.
>
> >
> >>> There may indeed be a new mode of communication required.
> >>> However, if intent is not standardized, how does this work?
> >> It doesn't. My only point is that intent is layered on top of an
> >> underlying autonomic behaviour based on default behaviours. Actually,
> >> that's why the question of intent was deferred in the WG charter.
> >
> > Your explanation is "valid", but I don't remember this was the reason
> used to consider intent FFS.
>
> OK, maybe that was just in my brain. Another aspect that Intent was
> incompletely
> understood.
>
> > Without rewriting history, we are facing now with the "heavy"
> design/conceptual discussions on the list, the effect of some
> > decisions to exclude architectural analysis / investigations in the
> early phase of ANIMA...
>
> I maintain that these are issues of ASA design, not infrastructure design.
> We always
> knew that the infrastructure has to distribute Intent.
>
> Regards
>    Brian
>
> > Laurent.
> >
> >
> >>
> >>      Brian
> >>
> >>> I understand how unstructured and structured P2P networks
> >>> work. Let's assume this is a structured P2P network. In that case,
> >>> a DHT is used to assign ownership of each file to a peer. I fail to
> >>> understand how this works in an intent case. Files are passive,
> >>> intent is active. Please explain.
> >>>
> >>> Regards,
> >>> John
> >>>
> >>> On Sat, Mar 26, 2016 at 11:53 AM, Brian E Carpenter <
> >>> [email-masked]> wrote:
> >>>
> >>>> Hi John,
> >>>> On 27/03/2016 04:54, John Strassner wrote:
> >>>>>> Correct, and there is also no presumption that individual nodes
> >>>>>> have perfect knowledge of the topology. Of course the ACP
> >>>>>> routing protocol will have perfect knowledge of the ACP topology,
> >>>>>> but individual ASAs only know what they have gleaned from
> >>>>>> discovery and what they have been told by Intent.
> >>>>>>
> >>>>>> It is, I think, a very different world view than the SDN or SUPA or
> >>>>>> NVO4 or NFV view.
> >>>>> Please note that I did NOT say anything about SDN, NFV, or SUPA
> >>>>> here. In fact, I'm confused as to why you both think I did.
> >>>> I can't speak for Zongpeng, but I was triggered by the mention of
> >>>> northbound and southbound APIs. There is no presumed direction in
> >>>> Anima relationships, since in the limit a network is self-forming;
> >>>> all relationships are peer-to-peer.
> >>>>
> >>>> Of course, when we put Intent into the picture, there's a presumption
> >>>> that Intent comes from some authority such as a NOC, but that's an
> >>>> external semantic, not an assumption of the autonomic model.
> >>>>
> >>>>> I specifically said "There are plenty of southbound APIs (from a
> >>>>> management function to a device). There are very few northbound
> APIs."
> >>>>>
> >>>>> Note the word "management function".
> >>>>>
> >>>>> For the record, I don't think that either Phase 2 of NFV or the SDN
> 1.1
> >>>>> architecture have treated policy in any detail. Both architectures
> lack a
> >>>>> policy management component. I hope that ANIMA doesn't make the
> >>>>> same mistake.
> >>>> Certainly, Intent needs a number of properties such as
> self-consistency
> >>>> and stability that imply it is managed in some way.
> >>>>
> >>>>>>> However, in ANIMA network, perhaps we do not have a centralized
> >>>>>>> parsing node (controller), which can replace almost all the
> >>>>>>> communications between nodes.
> >>>>> Earlier I wrote about intent requiring a translation function. I
> never
> >>>> said
> >>>>> that it was centralized or distributed. In the autonomic
> architectures I
> >>>>> have built, it was in fact a decentralized (agent-driven) function.
> >>>>> Furthermore, it did not "replace almost all the communications" - it
> >>>>> was used for compilation. There was, in fact, a separate distribution
> >>>>> mechanism (which I have also described), but that was limited to
> >>>>> "just" distribution.
> >>>>>
> >>>>> I really don't understand what "replacing communications" means.
> >>>> I think the point is that AN *adds* a new mode of communication
> between
> >>>> self-managing nodes, that doesn't exist in a strictly north/south
> >>>> scenario. That is meant to reduce the amount of north/south
> communication
> >>>> and reduce the amount of centralized work. So there's a trade-off -
> >>>> more autonomic messaging means less north-south messaging.
> >>>>
> >>>> Best regards
> >>>>     Brian
> >>>>
> >>>>> regards,
> >>>>> John
> >>>>>
> >>>>> On Fri, Mar 25, 2016 at 9:15 PM, Brian E Carpenter <
> >>>>> [email-masked]> wrote:
> >>>>>
> >>>>>>> However, in ANIMA network, perhaps we do not have a centralized
> parsing
> >>>>>> node (controller), which can replace almost all the communications
> >>>> between
> >>>>>> nodes.
> >>>>>>
> >>>>>> Correct, and there is also no presumption that individual nodes have
> >>>>>> perfect
> >>>>>> knowledge of the topology. Of course the ACP routing protocol will
> have
> >>>>>> perfect
> >>>>>> knowledge of the ACP topology, but individual ASAs only know what
> they
> >>>> have
> >>>>>> gleaned from discovery and what they have been told by Intent.
> >>>>>>
> >>>>>> It is, I think, a very different world view than the SDN or SUPA or
> NVO4
> >>>>>> or NFV view.
> >>>>>>
> >>>>>> Regards
> >>>>>>     Brian
> >>>>>>
> >>>>>> On 26/03/2016 16:46, Duzongpeng wrote:
> >>>>>>> Hi John:
> >>>>>>>
> >>>>>>> Thanks for your reply.
> >>>>>>>
> >>>>>>> <jcs>
> >>>>>>> How is this different than running a script, or invoking an API?
> There
> >>>>>> are plenty of southbound APIs (from a management function to a
> device).
> >>>>>> There are very few northbound APIs. That's what the operators that I
> >>>> have
> >>>>>> talked to want.
> >>>>>>> </jcs>
> >>>>>>>
> >>>>>>> I agree that intent belongs to northbound interface in the SDN
> network.
> >>>>>> And ANIMA network perhaps can share the same northbound interface.
> >>>>>>> But, my understanding is that ANIMA network is a little different
> from
> >>>>>> SDN network.
> >>>>>>> SDN controller will parse the intent, and transform to detailed
> >>>>>> configurations of every device. It is a good model, and little
> >>>>>> communications between nodes are needed.
> >>>>>>> Some network level parameters can be handled in SDN controller.
> >>>>>>>
> >>>>>>> However, in ANIMA network, perhaps we do not have a centralized
> parsing
> >>>>>> node (controller), which can replace almost all the communications
> >>>> between
> >>>>>> nodes.
> >>>>>>> So when a network operator is operating a ANIMA network, the
> network
> >>>>>> level parameters are still needed to be flooded.
> >>>>>>> I mean the ANIMA interface is perhaps something like “northbound +
> part
> >>>>>> of southbound”.
> >>>>>>> Best Regards
> >>>>>>> Zongpeng Du
> >>>>>>>
> >>>>>>>
> >>>>>>> From: John Strassner [mailto:[email-masked]]
> >>>>>>> Sent: Saturday, March 26, 2016 9:41 AM
> >>>>>>> To: Duzongpeng; John Strassner
> >>>>>>> Cc: Michael Behringer (mbehring); Laurent Ciavaglia; Sheng Jiang;
> >>>>>> [email-masked]; Jéferson Campos Nobre
> >>>>>>> Subject: Re: [Anima] Does Autonomic network need some intervention
> >>>>>> beyond intent
> >>>>>>> Hi Zongpeng,
> >>>>>>>
> >>>>>>> I think we have a misunderstanding here.
> >>>>>>>
> >>>>>>>
> >>>>>>> But I do not support that the intent writer should look every
> detail in
> >>>>>> the catalog.
> >>>>>>> <jcs>
> >>>>>>> Most catalogs that I have seen have very few details. They instead
> tell
> >>>>>> the user what services or products are available.
> >>>>>>> </jcs>
> >>>>>>>
> >>>>>>> The intent writer may mainly care about what they want, but how to
> do
> >>>> it
> >>>>>> can be left to the autonomic network to deal with.
> >>>>>>> <jcs>
> >>>>>>> I agree completely.
> >>>>>>> </jcs>
> >>>>>>>
> >>>>>>> Perhaps several solutions exist, and autonomic management system
> choose
> >>>>>> one according to the abilities collected.
> >>>>>>> <jcs>
> >>>>>>> This is one of the reasons why I would like to see capabilities
> (and
> >>>>>> needs) advertised.
> >>>>>>> </jcs>
> >>>>>>>
> >>>>>>> ...
> >>>>>>> I mean in current status, some of the Autonomic Functions should be
> >>>>>> exposed to the network operator, and some of the Autonomic Functions
> >>>> can be
> >>>>>> hidden to the network operator
> >>>>>>> ...
> >>>>>>> <jcs>
> >>>>>>> How is this different than running a script, or invoking an API?
> There
> >>>>>> are plenty of southbound APIs (from a management function to a
> device).
> >>>>>> There are very few northbound APIs. That's what the operators that I
> >>>> have
> >>>>>> talked to want.
> >>>>>>> regards,
> >>>>>>> John
> >>>>>>>
> >>>>>>> On Fri, Mar 25, 2016 at 2:31 AM, Duzongpeng <[email-masked]
> >>>>>> <mailto:[email-masked]>> wrote:
> >>>>>>> Hi John
> >>>>>>>
> >>>>>>> Some personal understanding here. If any misunderstanding, please
> >>>>>> correct me. Thanks.
> >>>>>>> <jcs2>
> >>>>>>> I would suggest a slight modification, to enable users of
> >>>>>>> intent (and even intent writers) to NOT have to have
> >>>>>>> detailed implementation information.
> >>>>>>>
> >>>>>>> What if all of the Autonomic Functions, after they joined
> >>>>>>> the network, advertised both their capabilities as well as
> >>>>>>> their needs? We can put aside the latter (needs) as this
> >>>>>>> is more complex, but if the capabilities are advertised,
> >>>>>>> then the autonomic management system can assemble
> >>>>>>> those needs into a catalog. Then, the intent writer can
> >>>>>>> look at the catalog and write a declarative request to
> >>>>>>> use the functionality of the catalog.
> >>>>>>>
> >>>>>>> I will look at your YANG model in a bit (sorry, I'm woefully
> >>>>>>> behind...).
> >>>>>>> < /jcs2>
> >>>>>>>
> >>>>>>> I agree that autonomic node should have that self-advertisement
> >>>> ability,
> >>>>>> and autonomic management system should have this catalog.
> >>>>>>> But I do not support that the intent writer should look every
> detail in
> >>>>>> the catalog.
> >>>>>>> The intent writer may mainly care about what they want, but how to
> do
> >>>> it
> >>>>>> can be left to the autonomic network to deal with.
> >>>>>>> Perhaps several solutions exist, and autonomic management system
> choose
> >>>>>> one according to the abilities collected.
> >>>>>>> In the ideal, the network operator may communicate with the
> autonomic
> >>>>>> network using network-level level intent and network-level report.
> >>>>>>> I mean in current status, some of the Autonomic Functions should be
> >>>>>> exposed to the network operator, and some of the Autonomic Functions
> >>>> can be
> >>>>>> hidden to the network operator
> >>>>>>> Perhaps in future, when the network nodes become more intelligent,
> the
> >>>>>> hidden part will increase.
> >>>>>>>
> >>>>>>> Best regards
> >>>>>>> Zongpeng Du
> >>>>>>>
> >>>>>>> From: Anima [mailto:[email-masked]<mailto:
> >>>> [email-masked]>]
> >>>>>> On Behalf Of John Strassner
> >>>>>>> Sent: Thursday, March 24, 2016 10:41 AM
> >>>>>>> To: Michael Behringer (mbehring); John Strassner
> >>>>>>> Cc: Duzongpeng; Laurent Ciavaglia; Sheng Jiang; [email-masked]
> <mailto:
> >>>>>> [email-masked]>; Jéferson Campos Nobre
> >>>>>>> Subject: Re: [Anima] Does Autonomic network need some intervention
> >>>>>> beyond intent
> >>>>>>> Hi Michael,
> >>>>>>>
> >>>>>>> thanks for your reply. I do think that we largely agree, and would
> >>>> enjoy
> >>>>>> chatting during or (hopefully before) BA. Please see
> <jcs2>..</jcs2>.
> >>>> Also
> >>>>>> trying to unclutter, so I am eliding points that we agree on.
> >>>>>>>
> >>>>>>> While *CIEs don’t like magic, they do understand the concept of a
> >>>>>> default behaviour which they can influence if needed. Any reasonable
> >>>>>> network management approach tries to define “default” behaviour and
> >>>>>> “exceptions”. The AN story fills the “default” part very nicely, and
> >>>> *CIEs
> >>>>>> get that.
> >>>>>>> <jcs2>
> >>>>>>> Agreed!
> >>>>>>> </jcs2>
> >>>>>>>
> >>>>>>> The “parameter” versus “policy” discussion: My view is that we
> >>>> shouldn’t
> >>>>>> try to define exactly *what* intent allows and doesn’t allow, since
> >>>> we’ve
> >>>>>> heard from many sides that the boundary is not clear, and it may be
> >>>>>> impossible to have a really clear, usable definition. So my point
> was:
> >>>>>> Let’s focus on the distribution model: Intent is flooded to all
> nodes.
> >>>>>> Let’s NOT do selective flooding, unicast Intent to specific nodes,
> etc,
> >>>>>> because that would blur the boundary even worse.
> >>>>>>> <jcs2>
> >>>>>>> I like flooding intent to all nodes. In FOCALE (v1-3, and
> remember, v1
> >>>>>> was 2006, almost 10 years ago), we used a message bus and pub-sub.
> In
> >>>> v2,
> >>>>>> we flooded; in v3, we went back to pub-sub because we wanted to do
> some
> >>>>>> optimization and auditing. But I would be happy to try some type of
> >>>>>> controlled flooding again.
> >>>>>>> </jcs2>
> >>>>>>> My suggestion: Intent is flooded to all nodes in a domain. The ASA
> >>>>>> owners define the content of what they want to push in their bit of
> the
> >>>>>> Intent. If we insist of full flooding, we encourage the right
> behaviour.
> >>>>>> And if someone really puts into his Intent “node A: do this; node
> B: do
> >>>> the
> >>>>>> other; node C: do the third” it is awkward enough for people to
> take a
> >>>> step
> >>>>>> back and think whether they’re doing the right thing ☺
> >>>>>>> <jcs2>
> >>>>>>> I agree in principle with what you said. Plus, see above.
> >>>>>>> < /jcs2>
> >>>>>>> <jcs>
> >>>>>>> Do you mean that the intent writer will **know the difference**
> >>>>>>> between the fabric and each autonomic function? I hope not,
> >>>>>>> but perhaps I'm misunderstanding you...
> >>>>>>> < /jcs>
> >>>>>>> Not sure I understand your concern. Yes, in my model there is a
> section
> >>>>>> for the fabric, and sections for the various functions. Seems a
> natural
> >>>>>> structure?!? <jcs2>
> >>>>>>> The intent **writer** would have to know implementation
> >>>>>>> details in order to place everything in a single file. I would
> >>>>>>> rather not require this, and instead, have the intent engine
> >>>>>>> (e.g., compiler and associated logic) do this.
> >>>>>>> < /jcs2>
> >>>>>>> “Function owner”: Yes, I’m suggesting to structure Intent around
> >>>>>> Autonomic Functions. This is not optimal from a scientific point of
> >>>> view,
> >>>>>> but aligns very well with the way how things are organised.
> Probably we
> >>>>>> need to discuss that in BA. But refer to my YANG model sent a few
> days
> >>>> ago.
> >>>>>>> <jcs2>
> >>>>>>> I would suggest a slight modification, to enable users of
> >>>>>>> intent (and even intent writers) to NOT have to have
> >>>>>>> detailed implementation information.
> >>>>>>>
> >>>>>>> What if all of the Autonomic Functions, after they joined
> >>>>>>> the network, advertised both their capabilities as well as
> >>>>>>> their needs? We can put aside the latter (needs) as this
> >>>>>>> is more complex, but if the capabilities are advertised,
> >>>>>>> then the autonomic management system can assemble
> >>>>>>> those needs into a catalog. Then, the intent writer can
> >>>>>>> look at the catalog and write a declarative request to
> >>>>>>> use the functionality of the catalog.
> >>>>>>>
> >>>>>>> I will look at your YANG model in a bit (sorry, I'm woefully
> >>>>>>> behind...).
> >>>>>>> < /jcs2>
> >>>>>>>
> >>>>>>>
> >>>>>>> regards,
> >>>>>>> John
> >>>>>>>
> >>>>>>> On Wed, Mar 23, 2016 at 3:57 AM, Michael Behringer (mbehring) <
> >>>>>> [email-masked]<mailto:[email-masked]>> wrote:
> >>>>>>> John,
> >>>>>>>
> >>>>>>> I think we’re on the same page. Couple of points, top posting here,
> >>>>>> otherwise it gets too messy.
> >>>>>>> While *CIEs don’t like magic, they do understand the concept of a
> >>>>>> default behaviour which they can influence if needed. Any reasonable
> >>>>>> network management approach tries to define “default” behaviour and
> >>>>>> “exceptions”. The AN story fills the “default” part very nicely, and
> >>>> *CIEs
> >>>>>> get that.
> >>>>>>> The “parameter” versus “policy” discussion: My view is that we
> >>>> shouldn’t
> >>>>>> try to define exactly *what* intent allows and doesn’t allow, since
> >>>> we’ve
> >>>>>> heard from many sides that the boundary is not clear, and it may be
> >>>>>> impossible to have a really clear, usable definition. So my point
> was:
> >>>>>> Let’s focus on the distribution model: Intent is flooded to all
> nodes.
> >>>>>> Let’s NOT do selective flooding, unicast Intent to specific nodes,
> etc,
> >>>>>> because that would blur the boundary even worse.
> >>>>>>> My suggestion: Intent is flooded to all nodes in a domain. The ASA
> >>>>>> owners define the content of what they want to push in their bit of
> the
> >>>>>> Intent. If we insist of full flooding, we encourage the right
> behaviour.
> >>>>>> And if someone really puts into his Intent “node A: do this; node
> B: do
> >>>> the
> >>>>>> other; node C: do the third” it is awkward enough for people to
> take a
> >>>> step
> >>>>>> back and think whether they’re doing the right thing ☺
> >>>>>>> <jcs>
> >>>>>>> Do you mean that the intent writer will **know the difference**
> >>>>>>> between the fabric and each autonomic function? I hope not,
> >>>>>>> but perhaps I'm misunderstanding you...
> >>>>>>> </jcs>
> >>>>>>>
> >>>>>>> Not sure I understand your concern. Yes, in my model there is a
> section
> >>>>>> for the fabric, and sections for the various functions. Seems a
> natural
> >>>>>> structure?!?
> >>>>>>> “Function owner”: Yes, I’m suggesting to structure Intent around
> >>>>>> Autonomic Functions. This is not optimal from a scientific point of
> >>>> view,
> >>>>>> but aligns very well with the way how things are organised.
> Probably we
> >>>>>> need to discuss that in BA. But refer to my YANG model sent a few
> days
> >>>> ago.
> >>>>>>> We should schedule some discussion time outside the ANIMA meeting
> >>>>>> window...
> >>>>>>> Michael
> >>>>>>>
> >>>>>>>
> >>>>>>> From: John Strassner [mailto:[email-masked]<mailto:
> >>>>>> [email-masked]>]
> >>>>>>> Sent: 22 March 2016 21:32
> >>>>>>> To: Michael Behringer (mbehring) <[email-masked]<mailto:
> >>>>>> [email-masked]>>; John Strassner <[email-masked]<mailto:
> >>>>>> [email-masked]>>
> >>>>>>> Cc: Duzongpeng <[email-masked]<mailto:[email-masked]
> >>;
> >>>>>> [email-masked]<mailto:[email-masked]>; Laurent Ciavaglia <
> >>>>>> [email-masked]<mailto:[email-masked]>>;
> >>>>>> Jéferson Campos Nobre <[email-masked]<mailto:
> [email-masked]
> >>>>>> ;
> >>>>>> Sheng Jiang <[email-masked]<mailto:[email-masked]>>
> >>>>>>> Subject: Re: [Anima] Does Autonomic network need some intervention
> >>>>>> beyond intent
> >>>>>>> In general, I agree with Michael. I'd like to emphasize and expand
> on a
> >>>>>> couple of key points:
> >>>>>>>
> >>>>>>> First, ANIMA isn’t the only thing “influencing” or “steering” a
> >>>> network,
> >>>>>> at least not initially. There is still traditional config, plus all
> the
> >>>>>> existing and emerging SDN models. My view has always been that ANIMA
> >>>> sets a
> >>>>>> “default” policy in a network, and all other means are more
> specific and
> >>>>>> can override intent. This is described in RFC7575. Main point here:
> >>>> ANIMA
> >>>>>> Intent isn’t the only tool in a network.
> >>>>>>> <jcs>
> >>>>>>> Absolutely agree. Note that even in the Congress case I mentioned
> >>>>>>> earlier, it is NOT pushing config, and it is NOT viewed as the
> >>>>>>> "only" policy
> >>>>>>> </jcs>
> >>>>>>>
> >>>>>>>
> >>>>>>> Intent could perfectly well cover a high level policy such as “all
> >>>> nodes
> >>>>>> of type x do this; type y does that”. (Which I think is what you
> mention
> >>>>>> below.) When we started with Intent, the vision was to keep it very
> high
> >>>>>> level, more along the line “do the right thing” ☺
> >>>>>>> <jcs>
> >>>>>>> Agreed. Although to me, this means that we need to consider the
> types
> >>>> of
> >>>>>> actors that are using intent. For example, most of my CCIE and JCIE
> >>>> friends
> >>>>>> have no interest in using an intent language for pushing
> configuration.
> >>>> On
> >>>>>> the other hand, when I talk to operators and application developers,
> >>>> they
> >>>>>> would love to be able to use a high-level intent and have the intent
> >>>> engine
> >>>>>> take care of the details for them.
> >>>>>>> </jcs>
> >>>>>>>
> >>>>>>> It has become clear that in today’s networking, people will want to
> >>>> push
> >>>>>> more “parameters” than “policy”, and I think we’ll just have to
> >>>> acknowledge
> >>>>>> that.
> >>>>>>> <jcs>
> >>>>>>> Sorry Michael, I don't follow here. What do you mean
> >>>>>>> by "parameters"?
> >>>>>>> </jcs>
> >>>>>>>
> >>>>>>>
> >>>>>>> Personally I think it’ll pan out like this: Intent will have
> sections
> >>>>>> per autonomic function. An Intent parser will validate overall
> >>>> correctness
> >>>>>> (signature, etc), then segment the Intent into its bits: One part
> will
> >>>> be
> >>>>>> the autonomic fabric itself, then there will be bits for each
> autonomic
> >>>>>> function.
> >>>>>>> <jcs>
> >>>>>>> Do you mean that the intent writer will **know the difference**
> >>>>>>> between the fabric and each autonomic function? I hope not,
> >>>>>>> but perhaps I'm misunderstanding you...
> >>>>>>> </jcs>
> >>>>>>>
> >>>>>>>
> >>>>>>> So the Intent parser on a node will grab intent, see there is some
> >>>>>> Intent for autonomic function A, will see whether this is running
> >>>> locally,
> >>>>>> and if so, it’ll just pass that piece of Intent to that function.
> >>>>>>> <jcs>
> >>>>>>> Agreed.
> >>>>>>> </jcs>
> >>>>>>>
> >>>>>>>
> >>>>>>> In this way, a function owner defines both the intent itself, and
> how
> >>>> it
> >>>>>> is consumed by his/her function.
> >>>>>>> <jcs>
> >>>>>>> I'm not sure what you mean by "function owner". (Sorry to be
> >>>>>>> picky, I'm likely under-caffeinated.)
> >>>>>>>
> >>>>>>> The above seemed like an autonomous decision, made by the parser.
> >>>>>>> I don't think that the intent writer should be cognizant of how
> many or
> >>>>>>> what types of autonomic functions are present.
> >>>>>>> </jcs>
> >>>>>>>
> >>>>>>>
> >>>>>>> The downside is that there is no “control” and people can do what
> they
> >>>>>> want, in the worst case even push config, which is clearly NOT what
> >>>> Intent
> >>>>>> is meant to do.
> >>>>>>> <jcs>
> >>>>>>> And hence, the "HAL 2000" scenario. :-)
> >>>>>>> </jcs>
> >>>>>>>
> >>>>>>>
> >>>>>>> I’d hope that people don’t start writing Intent like “node 17:
> here is
> >>>>>> your CLI; node 23: here is your CLI”; node 37: here is your CLI”.
> But
> >>>> what
> >>>>>> I describe above COULD be abused in this way. RFC7575 says this is
> NOT
> >>>>>> Intent.
> >>>>>>> <jcs>
> >>>>>>> Absolutely agree!
> >>>>>>> </jcs>
> >>>>>>>
> >>>>>>>   regards,
> >>>>>>> John
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Wed, Mar 16, 2016 at 1:16 AM, Michael Behringer (mbehring) <
> >>>>>> [email-masked]<mailto:[email-masked]>> wrote:
> >>>>>>> Hi Zongpeng,
> >>>>>>>
> >>>>>>> Yes, this is a recurring question and topic. Let me give my view
> on two
> >>>>>> levels:
> >>>>>>> First, ANIMA isn’t the only thing “influencing” or “steering” a
> >>>> network,
> >>>>>> at least not initially. There is still traditional config, plus all
> the
> >>>>>> existing and emerging SDN models. My view has always been that ANIMA
> >>>> sets a
> >>>>>> “default” policy in a network, and all other means are more
> specific and
> >>>>>> can override intent. This is described in RFC7575. Main point here:
> >>>> ANIMA
> >>>>>> Intent isn’t the only tool in a network.
> >>>>>>> Intent could perfectly well cover a high level policy such as “all
> >>>> nodes
> >>>>>> of type x do this; type y does that”. (Which I think is what you
> mention
> >>>>>> below.) When we started with Intent, the vision was to keep it very
> high
> >>>>>> level, more along the line “do the right thing” ☺  It has become
> clear
> >>>> that
> >>>>>> in today’s networking, people will want to push more “parameters”
> than
> >>>>>> “policy”, and I think we’ll just have to acknowledge that.
> >>>>>>> Personally I think it’ll pan out like this: Intent will have
> sections
> >>>>>> per autonomic function. An Intent parser will validate overall
> >>>> correctness
> >>>>>> (signature, etc), then segment the Intent into its bits: One part
> will
> >>>> be
> >>>>>> the autonomic fabric itself, then there will be bits for each
> autonomic
> >>>>>> function.
> >>>>>>> So the Intent parser on a node will grab intent, see there is some
> >>>>>> Intent for autonomic function A, will see whether this is running
> >>>> locally,
> >>>>>> and if so, it’ll just pass that piece of Intent to that function.
> >>>>>>> In this way, a function owner defines both the intent itself, and
> how
> >>>> it
> >>>>>> is consumed by his/her function.
> >>>>>>> The downside is that there is no “control” and people can do what
> they
> >>>>>> want, in the worst case even push config, which is clearly NOT what
> >>>> Intent
> >>>>>> is meant to do. I’d hope that people don’t start writing Intent like
> >>>> “node
> >>>>>> 17: here is your CLI; node 23: here is your CLI”; node 37: here is
> your
> >>>>>> CLI”. But what I describe above COULD be abused in this way. RFC7575
> >>>> says
> >>>>>> this is NOT Intent.
> >>>>>>> In other words: Let’s not be too prescriptive, and hope that folks
> will
> >>>>>> do more or less reasonable things.
> >>>>>>> I’ve been meaning to comment on the Intent drafts and possibly
> >>>>>> contribute, I’m just struggling with priorities at the moment (as
> you
> >>>> can
> >>>>>> see by my relative silence over the past weeks).
> >>>>>>> Michael
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> From: Anima [mailto:[email-masked]<mailto:
> >>>> [email-masked]>]
> >>>>>> On Behalf Of Duzongpeng
> >>>>>>> Sent: 16 March 2016 02:38
> >>>>>>> To: [email-masked]<mailto:[email-masked]>
> >>>>>>> Cc: Laurent Ciavaglia <[email-masked]<mailto:
> >>>>>> [email-masked]>>; Jéferson Campos Nobre <
> >>>> [email-masked]
> >>>>>> <mailto:[email-masked]>>; Sheng Jiang <[email-masked]
> >>>> <mailto:
> >>>>>> [email-masked]>>
> >>>>>>> Subject: [Anima] Does Autonomic network need some intervention
> beyond
> >>>>>> intent
> >>>>>>> Hello, everyone
> >>>>>>>
> >>>>>>>           I understand that Autonomic network should be able to
> work
> >>>> with
> >>>>>> as less configuration as possible. In the ideal case, an Autonomic
> >>>> network
> >>>>>> should be able to work well while only intent is needed from human
> >>>>>> operators.
> >>>>>>>           However, I wonder whether Autonomic network may need some
> >>>>>> intervention from human operators through some low-level policies
> beyond
> >>>>>> intents.
> >>>>>>>           For example, in the
> >>>>>> https://tools.ietf.org/html/draft-ietf-anima-prefix-management-00,
> it
> >>>> is
> >>>>>> suggested that the prefix lengths for the CSG, ASG, RSG (different
> >>>> roles in
> >>>>>> IP RAN) can be assigned as an "intent". These configuration
> parameters
> >>>> need
> >>>>>> to be distributed in the autonomic domain to influence the detail
> >>>>>> configurations on each autonomic node.
> >>>>>>>           As intent is described as an abstract, declarative,
> high-level
> >>>>>> policy used to operate an autonomic domain, such as an enterprise
> >>>> network.
> >>>>>> Perhaps we can rename the “intent” in the “prefix-management ID” to
> some
> >>>>>> other words.
> >>>>>>> Is “ASA parameters" ok here?
> >>>>>>>
> >>>>>>> I think some characteristics for this kind of low-level policies
> are
> >>>>>>>
> >>>>>>> 1.       Network level parameters, need to be distributed by GRASP
> and
> >>>>>> ACP
> >>>>>>> 2.       Relatively static compared to intent, perhaps only needed
> to
> >>>> be
> >>>>>> configured once
> >>>>>>> 3.       Unavoidable in current network environment, mostly for
> >>>>>> establishing the network infrastructure
> >>>>>>> 4.       Rarely need coordinations with others parameters, usually
> is
> >>>>>> closed related to one specific autonomic function
> >>>>>>> Welcome for comment. Your suggestions will be appreciated.
> >>>>>>>
> >>>>>>>
> >>>>>>> Best Regards
> >>>>>>> Zongpeng Du
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Anima mailing list
> >>>>>>> [email-masked]<mailto:[email-masked]>
> >>>>>>> https://www.ietf.org/mailman/listinfo/anima
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> regards,
> >>>>>>> John
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> regards,
> >>>>>>> John
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> regards,
> >>>>>>> John
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Anima mailing list
> >>>>>>> [email-masked]
> >>>>>>> https://www.ietf.org/mailman/listinfo/anima
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>
>

-- 
regards,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 4 Apr 2016 11:39:30 +1200

On 04/04/2016 09:48, John Strassner wrote:
> (autonomic) node. 

[I'm going to use ANode to mean an autonomic node, because AN is
presumably Autonomic Network.]

Well yes, the ANode is just a carrier for information to and from
ASAs, but if the Intent is needed by multiple ASAs in one ANode,
I expect that it will be cached once in the ANode before being picked
up by the individual ASAs. But see my next comment...

> This means that the autonomic node has to be able to understand

...OK, terminology interrupt! Clearly what I (and I think others) mean by
Intent is the parsed, consumable intent in your terminology. But if we admit
that there may be multiple sources of parsed, consumable intent there may
still be a need for conflict resolution by the consumer, surely?

   Brian

---

From: John Strassner <[email-masked]>
Date: Sun, 3 Apr 2016 20:01:01 -0700

Hi Brian,

thanks for the clarifications. Snipping violently :-)

> up by the individual ASAs. But see my next comment...

I think we agree, though for security purposes, it may be preferable
to have a dedicated repository as part of the ANI, as opposed to an
ANode. But that is a nit and TBD.

...

> still be a need for conflict resolution by the consumer, surely?

Now that I can agree to! Forgive me, but this terminology was not obvious
to me, and I do think it will help for it to be clarified.

Also, I do agree that there is a need for conflict resolution.

Thanks for the clarification.

regards,
John

-- 
regards,
John